DevSecOps: Automation at the core of secure development | Cyber Risk | Deloitte Netherlands


DevSecOps: Automation at the core of secure development

Embedding automated security tools and controls as code from the start and in every part of the process

DevSecOps calls for a security-based design of the continuous integration and continuous deployment (CI/CD) pipeline by embedding automated security tools and controls as code from the start. This security integration greatly benefits both the security department and DevOps teams. It enables the organization to embrace a new risk mindset: make mistakes, and make them small, fast and cheap.

Written by Fons Mijnen

“Release early and often” is a much-used mantra by developers embracing the agile way of working. Developers want to deploy their code to test, acceptance, and production as soon as they can, and with small increments of change. This is great for both users of software and the developers themselves. For users it means getting access to new features earlier. For developers it means reducing the amount of changes to deploy, making them less likely to fail.

The implications for the application security is clear in this model. Security is often applied in the very beginning with extensive security requirements, and at the end of development by performing a penetration test. However, using a “release early and often” method with small increments means the requirements are not fit for incremental changes and security tests are blocking a fast deployment into production. To ensure security receives the right attention, but at the same time does not kill the flexibility and short time to market, things must change. This calls for moving security to the left and automate as much as possible while embracing a new risk mindset: make mistakes, make them small, make them fast and solve them cheap.

Building security tools in the pipeline

To achieve these rapid deployments in small and incremental changes Continuous Integration and Continuous Deployment (CI/CD) tools are implemented. In CI/CD tools, the steps required to build and deploy software are defined in a “build pipeline” where code is put in at the start of the pipeline and a working software product comes out by the end. By making security an integral part of the CI/CD pipeline, security controls can be embedded as code into the very creation of software, working much closer to the developers than ever before.

Automating these security controls benefits both the security department as well as the developers greatly. For security officers, there is a clear overview of security controls that are continuously tested by machines and the output and reports are saved centrally (the CI/CD pipeline). Developers benefit greatly by saving time. Through addressing security issues early, developers safe time and gain the capability to address any security concerns early before code is deployed to any environment. The tooling guides the developer in fixing the code by providing guidance and suggestions on resolving found issues. A possible security flaw solved early can be as much as 50 times cheaper to resolve than one found in the later development phases.

Finding and reporting security issues early in the development process reduces the costs to fix them and positions security controls to foster innovation rather than hindering it. This is important because it will give developers the feeling that the security team is working with them rather than against them. Three key principles are required by the security team implementing these tools:

  1. Make it as easy as possible to use for the developers;
  2. Make it as seamless as possible for the development teams;
  3. Don’t significantly increase the time it takes to run the code through the entire pipeline.

Essential tools to automate security

Great tools to start building security in your CI/CD pipeline are the following:

  1. Static Application Security Testing (SAST)
  2. Dynamic Application Security Testing (DAST)
  3. Dependency checking

SAST tools analyse the source code of the application itself for security issues. SAST tools often use compositional analysis to identify the complexity of the code and the context in which the code is later executed. The tools can directly show the developer the code which has issues and then guide the developer in fixing it. A form of SAST can also be integrated directly in your Integrated Development Environment (IDE) so a developer is notified of potential vulnerabilities immediately while he or she is still coding.

DAST tools are often more complex to implement but are usually capable of finding issues that SAST tools cannot. DAST tools automatically simulate attacks against the application (which must be running and be functional for a high-quality test) and report on any attacks that work. This means the tool should be able to ‘attack’ the application in a functional state. Since attacking production is never advised (since the attack could touch or interfere with user data) there needs to be a test or acceptance environment to correctly perform these tests. It is not always trivial to efficiently run a DAST tool. It has to properly assess and analyse the application on its own which proves to be cumbersome. A best practice we often use is combining a DAST tool with automated regressions tests. By running regression tests through the DAST tool, the tool will analyse the core functionality as it comes by. This means you are less dependent on the ability of the DAST tool to analyse the application.

Finally, dependency checks verify if any third-party component used in the software itself contains known security vulnerabilities. Attacks are often achieved by leveraging these known vulnerabilities in software widely used. The major challenge in controlling these dependencies is the fact that dependencies often pull in additional dependencies to work. This means that developers often don’t know exactly which dependencies run in their code. Dependency check tooling can be used to find issues in dependencies even if they are invisible to the development team.

Secure early and often

The way software is developed is rapidly changing. To cope with these changes, security will have to adopt a mantra of “secure early and often”. Security professionals can join the developers in their paradigm shift from large and infrequent releases to small incremental releases by leveraging new tooling and automated software building. CI/CD pipelines are an excellent opportunity to position security tooling and controls early and in every phase of the development process increasing the security of every line of code delivered by the development team.

Our next blog will focus on Process; how can people and technology be glued together with lean processes supporting the goals of both developers and security?

More information

For more information about Automation at the core of secure development or DevSecOps, please contact Gijs Zijderveld, Tom Zijderhand or Jelle Niemantsverdriet via the contact details below.

Did you find this useful?