Security Think Tank: The many dimensions of DevSecOps

“Is SAST done? DAST too? Great – we have DevSecOps!”

I have heard this assertion recently more than I had expected.

Moving to a DevSecOps approach is more than just doing code analysis, even if it is done at early stages. According to a CSA study, 30% of companies are already in the process of implementing DevSecOps in their organisation, which reflects the relevance it has for the sake of cloud security.

DevSecOps is very human-centred and it must be clear across the entire organisation. Processes and culture are the solid foundation upon which DevSecOps must be built. That said, let’s talk about toolchain. When we think of security controls within DevOps, we need a broad view of what needs to be protected. It involves how automation is done, how building is being approved, how many risks are being deploying to production, and so on.

Shifting left has become popular in DevOps teams, with more and more people including it in their projects. Having visibility around what your peers are developing is necessary in order to act accordingly. Plenty of testing tools can uncover security gaps in code phases, with SAST/DAST as references in that matter. But shift-left means you keep awareness on your right side.

In a very simplistic three-step flow of code-build-deploy, DevSecOps is usually attached only in the first step. Each step has its own challenges. Starting with source code management (SCM), do we know how many vulnerabilities our source repo has? Can we track each one of them back to its source package? How do we control/monitor them? These are some of the questions that pop up in this step. While some SASTs help, others don’t. And always bear in mind that the toolchain has solid, complementary processes.

Then we move to the next step: build. Whatever innovative product is being built at your repo, it will jump to an artifact repo, most likely a registry, the house of container images. How can we be sure that those artifacts passed with the same status? If some risk acceptance took place – for example, a package with no available fix but is imperative for the application to work – or all vulnerabilities have been remediated, the artifact should remain with that same status. Is there any way to know if something bad made its way to the container image?

All those questions arise without taking into account that the build process itself must be monitored, too, because of CI/CD security risks associated with weak IAM control, improper usage of third-party tools, and more.

All of the previous steps lead us to: deploy. A whole new world of possibilities depends on the foundational architecture of the application. Is it serverless? Perhaps a microservices approach fits better? Are we going to use CSP managed services for our containers and/or orchestration? It is important to know these traits in advance because once the application is deployed, a proper toolchain needs to be ready to maintain security at a certain level.

Every option I mentioned has its own restrictions and considerations – for instance, if our solution is agent-based, then we may struggle with PaaS architecture. We may be deep in the journey and the code ship has already sailed, but new controls and processes need to be implemented.

DevSecOps is DevOps around security. Balance between agility and proper protection is the goal. DevSecOps is not only about the code, but its journey. Besides that three-step flow I used as an example, there will be additional risks that need to be addressed according to the pipeline and application we are dealing with: what will happen with the security monitoring while in production and what will we do with identity through the whole DevOps process?

Continuous monitoring and zero-trust also come into the picture in the DevSecOps framework, which goes far beyond analysing what is going on in our code.

This is a tough journey, no doubt about it. But it is necessary to consider all of these elements early on. From security practitioners to security architects, it is imperative to make our colleagues and customers know that when we talk DevSecOps, we are facing a multiphase challenge that starts at the very beginning of DevOps (even in the design phase, which I skipped intentionally), and involves a journey with no end because new features will always be needed, new tech trends will emerge in the market, and so on.

The clearer it is to understand what DevSecOps entails, the better we will handle these challenges.

Alejandro Bernal is a security architect and member of ISACA’s Emerging Trends Working Group