IT is part of the business

In the last few days I have had the opportunity to talk with people from different fields about development issues and the metrics and objectives associated with them. As part of these conversations, some thoughts about security and how it fits into the development process have emerged, which I think are interesting to share.

We have probably encountered situations in which, when a security component is added to DevOps team, it is not always well received. From the DevOps team, it is very likely that they see the security team as the bad cop that does not let them do anything and that puts obstacles for the work to go ahead with all the agility that the DevOps team would like, on the other hand, we will have the security team that will see the DevOps team as a group of programmers that generate code without taking into account the security implications that may arise, simply trying to minimize deployment times and often obviating the minimum security measures.

Historically, the DevOps team and the security team have had different objectives and metrics, while the first ones focused on making fast and efficient releases, the second ones focused on eliminating vulnerabilities in the developments, so that with each new release, the security team had new probabilities of finding new security flaws and vulnerabilities in the code.

But the reality is that they must understand each other for the good of the company; it is important to have new solutions that add value to the business in the shortest possible time, but they must be secure and reliable. As an advertisement from some time ago said, “power without control is useless”, for example, it is not enough to have a website that allows us to place orders just by thinking about them, if we cannot ensure the identity of the buyer and the reliability of the transaction. This is where DevSecOps is born, and although in many organizations it is still called DevOps, in reality it is already normal to incorporate in their team people dedicated to ensure security during the development of each of the releases.

The advantages of DevOps and security operations feeding back into each other is really beneficial for enterprises and the best way for both teams to work together is by sharing a common language, shared metrics and goals, so that the successes of one are the successes of all. Let’s look at some examples.

Security audits passed

From the headline of this indicator, it may seem to indicate that it only applies to security teams, but nothing could be further from the truth. Failure to pass an audit impacts both teams DevOps and security equally and undermines the organization’s confidence in IT. Likewise, when security audits are passed day after day, it has a positive impact on the entire team as a whole, which can feel proud of its achievement.

Reduction of failed security tests

Failure of a release to pass security tests may be seen by the DevOps team as unnecessary testing or that the security team is putting more than expected obstacles to the deployment of that release, creating friction between the two teams. Therefore, if the expected security guidelines are set at the outset and a common goal of reducing failed security tests is established, everyone is more likely to work together to solve the problem. In addition, this indicator has a direct impact on the indicator seen above.

Reduction of the total number of open security tickets

This is a clear objective for the security team, however, for the DevOps team it is not so obvious. If we think that a security problem in most of the occasions can lead to a delay in the delivery of the software, we see a clear implication for the DevOps team. If we were to take it to the extreme, in the case of serious security incidents, it could cause us to go back to previous versions of the developments, which would have a great impact on the DevOps team.

By incorporating security tools into CI/CD pipelines, we can help security teams look for vulnerabilities while DevOps teams can leverage them to find solutions to security issues.

The further to the left we move the security review, the sooner we can fix the problems. From here we could come up with a new metric based on the number of vulnerabilities that are discovered before reaching production, a metric that would be beneficial for both teams too, security by having better control of vulnerabilities and not reaching production, and DevOps by not having to do rework or delay deployments.

Deployment time reduction

This is a typical metric for DevOps teams that is not often considered in DevOps teams. The faster each release can be deployed, the better for the DevOps team. In the case of the security team, we can look at it under the view that the shorter the time between deployments, the shorter the time to wait to fix a vulnerability, the faster we will have the solution in production. Closely related to this metric is the following.

Reducing repair time

Life is not perfect, and neither is software. No matter how many controls we put in place, vulnerabilities will eventually find their way into production. Resolving these security bugs is a task that requires collaboration between the two teams, with the security team taking the initiative to find out what went wrong and DevOps taking the lead in fixing the problem. In this case the nature of this metric indicates a shared responsibility, so it is an object to be shared between the two teams. Again, we can find common objectives to both.

As we have seen, both teams can share objectives and metrics in such a way that both are interested in working as closely as possible for their benefit and that of the company. Both teams are one team: DevSecOps, a perfect symbiosis.