The Evolving Narrative of Moving from DevOps to DevSecOps

Today, we hear a lot about DevOps, automation, and speed. This is expressed in everything from the tools used to automate, the metrics gathered to deliver increasingly faster, and the emphasis on lightweight governance to deliver in a lean way. Taking a step back, however, we still see security issues prevalent in our software.

There is a shift in the industry narrative to align the discussion on “speed only” to a broader discussion on why this is not enough to satisfy the needs of the business.

To be clear at the outset, it makes sense to automate repeatable tasks for speed. Otherwise, you have to do tasks manually, which takes time and is error prone. We have learned from experience that automation can go a long way toward improving consistency and quality. For example, it used to take weeks or months to manually provision and deploy a server. Today, we can do it significantly faster and with greater consistency. So naturally, most organizations try to emphasize development automation in an effort to reduce the cost of rework and focus their people on more value-added activities.

Now a similar evolution needs to happen in the security domain. Without detracting from the value that security brings to the table around business risk management, we need to balance security activities against a well-oiled development pipeline that emphasizes automation. Speed can be a great asset but is even greater when it's balanced with safety and security. This avoids the pitfall of having to fix security issues once deployed into a production environment. Taking the time to fix those production security issues takes time away from deploying new features for the business. The net result is an inadequate delivery pipeline from the business point of view.

Security, therefore, must be inserted at each and every stage of the software development life cycle (SDLC). We need to test early and often. For example, in a change cycle, we need to assess the risk of the changes against security, privacy, and regulatory impact.

In the past, many organizations made the mistake when adopting DevOps to focus the benefits exclusively from a development speed perspective without due consideration of a balance against business needs like risk and security. Today, when we see data and security breaches, it’s clear that our processes focused on development speed are at fault if we accept that quality artifacts are an output based on the strength and quality of our processes.

Therefore, we need an integrated balanced development approach that is automated to create the right balance between speed and risk to avoid costly rework and business slowdown.

Achieving a balanced development approach

Looking back, during the early days of DevOps, there were many challenges in bringing development and operations together because developers wanted to move fast and change the code while operations wanted stability and infrequent changes. Today, we are witnessing a similar change pattern as we transform from DevOps to DevSecOps. Many security teams favor stability and infrequent change. Security checks take longer with this mindset and lead to repetitive security activities such as security testing, risk assessment, and environment certification. These processes are not integrated into the DevOps processes. Rather, they are conducted out of band, and it can be difficult to inject security activities in a fast-moving pipeline. Instead, these security activities need to be baked into the automated SDLC process and radiate metrics that are relevant to security stakeholders.

Injecting security to achieve balanced development automation does not imply reinventing the wheel. There are good tools already in place to help you execute DevOps efficiently. There are also existing governance and metrics in place to help key people make informed decisions. You need to embed security into each and every phase of SDLC activities, and the more you shift to the left, the more benefits that you will see.

We also need to teach and educate people that security is a joint effort and it's everyone's responsibility to achieve balanced development automation. It's not only the responsibility of security teams. Security cannot be isolated from developers and other stakeholders, where they run a security tool stack in an isolated manner. We need to inject security automation at every stage of the SDLC from threat modeling to code scanning, testing, and operations.

Measuring success

The industry narrative around DevOps development automation is shifting to a balanced development automation perspective as we start to inject security, risk, and compliance requirements into software development. This means that, just as we did with DevOps, we need to have a cross-functional matrix of tradeoffs that articulate the right balance required to be both fast and safe. This needs to be measured so that every set of processes across these teams is contributing tangible value toward balanced development. And therein lies the ultimate business value.

Ayhan Tek is the VP of information security at Cyber Electra. He is a seasoned information security professional specialized in risk management, security architecture, and application security domains with over 20 years of experience. Ayhan is active with ISACA, ISC2, IEEE and other professional organizations and provides cyber security events and trainings in North America. Ayhan holds CISSP, CISM, TOGAF, SOA, ITIL, Oracle, IBM and many other professional certifications.