DevSecOps is a team effort. Learn how to build security into DevOps to deliver secure, high-quality software faster using SAST and SCA software solutions.
Modern software development is more of everything: more code, in more languages, on more platforms, with more deployment options. DevOps demands automation to maximize velocity and continuous improvement throughout process feedback.
All this more also means more security risk. More code and more complexity means more places where things can go wrong. More velocity means less time to get things right.
How can you infuse security into DevOps without losing your mind?
The transition to DevSecOps is especially challenging because it’s a collision of two significant paradigm shifts. On the one hand, the focus on security is exiting insular security groups and spreading outward into development teams, which are now getting both responsibility and budget to make security an integral part of the development process. On the other hand, development teams are adopting DevOps practices by optimizing velocity through automation and continual process improvement.
In terms of security, organizations are doing more testing and more kinds of testing. Security and development teams cannot keep pace.
If you’ve managed to sandwich functional testing into a once-per-check-in DevOps cycle, you’ll find that strategy is untenable when you try to run full scans with your security tools. Teams also struggle to handle the influx of results from security tools.
Deep in the weeds, many teams lose sight of the big picture, which is managing risk. Instead of taking a measured, deliberate approach to improving security, teams get bogged down trying to make everything run fast enough to keep up with DevOps, and get so caught up in a sea of findings that they don’t know where to start to make things better.
At Synopsys, we’re proud to have a comprehensive portfolio of testing solutions that cover the entire SSDLC. We’re thrilled that the number of customers that use multiple tools from us is skyrocketing.
But that leads to the bigger question: what’s the best way to approach security holistically, from a boots-on-the-ground perspective on risk reduction?
The answer is better automation. Instead of running full scans every time you change some code, use intelligent test execution, based on the context, to decide what to run, when to run, and how to run.
This frees up teams to handle each application the best way, with limited configuration by the toolchain team and the flexibility to easily adjust policy in one place.
Let’s look at a typical evolution of security testing in software development. Maybe you start with static analysis (SAST). The analysis integration alone has many possibilities:
The choices you make are based on your policies, but they get buried in the tool itself or in your automation scripts.
Maybe that works out fine, and overall the activity of finding and fixing more bugs means lower risk.
Next you decide to up your game and add software composition analysis (SCA). You integrate it separately into your pipeline, but still you have many choices:
With duct tape and prayers, maybe you get all that working. Now what if you add interactive testing (IAST)?
An organic, incremental approach often leads to a mess. Cobwebs of integrations join various internal parts of the build and deployment pipelines with various security testing solutions. Policy is implemented in a dozen different integration scripts and configuration files, and it’s nearly impossible to articulate or adjust.
Policy is important. Policy describes how you want the world to be. Your town has a policy about fire safety in homes: you need a smoke detector in every bedroom, a fire extinguisher readily available, and so forth. Policy should be based on an informed approach to risk reduction.
A simple but ineffective policy for software security would be to require all application development teams to use static analysis. A better policy would specify the tool to be used, the required configuration, and most importantly, the types of results required before an application can be released.
In the spaghetti train wreck, fragments of policy are embedded throughout scripts and configuration files. This is exactly the opposite of how policy should work.
A great way to articulate policy is in the form of machine-readable files, sometimes called policy as code. (I wouldn’t actually call it code; it’s really a configuration file, probably JSON or YAML. But I don’t get to make up the terminology.) Using policy as code means that it’s precisely specified, and changes made to policy can be readily understood and supported by a change management process.
Policy as code implies that you have something that knows how to interpret and apply the policy. Instead of spreading the interpretation over multiple tool integrations, you use a single integration layer to provide security, hovering protectively over your usual processes.
The security layer in DevSecOps performs several crucial functions:
From your existing pipeline, integration is now an order of magnitude easier. Lightweight integrations to the security layer happen at specific events, such as a merge request. The security layer is designed to simplify integration and allow you to answer fundamental questions.
Using a security integration layer also simplifies adding new security testing tools or swapping out existing tools. Each new tool is integrated into the security layer, but the interface between the development pipeline and the security layer remains unchanged.
Software security is an exciting, dynamic field. If you’re trying to build a DevSecOps strategy, pinning down the tools and processes you need might be challenging. Treating security holistically as its own layer can help ease your integrations and make your process resilient to future innovations in the field. Let’s say somebody discovers a whole new way to do security testing. Or more prosaically, maybe you just want to incorporate an additional type of testing or an additional tool. With a security layer, the integrations in your development process don’t have to change at all. You just need to integrate from the security layer to the new tool and perhaps adjust your policies.
Jonathan Knudsen likes to break things. He has tested all kinds of software, from network infrastructure and medical devices to cryptocurrency nodes. Jonathan has worked as a developer, consultant, and author. He has published books about 2D graphics, cryptography, and Lego robots, and has written more than one hundred articles on a wide range of technical subjects.