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 the process feedback.
All this more also brings more security risk. More code and more complexity mean 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 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.
The alternative is the typical evolution of security testing in software development. One tool—say, static analysis —is integrated first, and along with it comes a variety of choices based on policies that get buried in the tool itself or in the automation scripts. Then another tool—say, software composition analysis (SCA)—is integrated separately into the pipeline, along with an array of additional choices.
This 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.
A better way to articulate policy is in the form of machine-readable files, sometimes called policy as code. Using policy as code means it’s precisely specified, and changes made to policy can be readily understood and supported by a change management process. Of course, this implies 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 performs several crucial functions:
- It contains and enforces the policy as code
- It performs appropriate testing at specific events in the development pipeline as dictated by the policy (but optimized for the current state of the project)
- It normalizes results from the security tools
- It simplifies adding new security testing tools or swapping out existing tools
As we think about the future of software security, or trying to build a DevSecOps strategy, treating security holistically as its own layer can ease integrations and make processes resilient to future innovations.
Learn more about intelligent orchestration and how to make security testing a seamless part of the development process in this invaluable report by Gartner, 12 Things to Get Right for Successful DevSecOps.
Jonathan Knudsen, Senior Security Strategist, Synopsys
Synopsys Software Integrity Group helps development teams build secure, high-quality software, minimizing risks while maximizing speed and productivity. Synopsys, a recognized leader in application security, provides static analysis, software composition analysis, and dynamic analysis solutions that enable teams to quickly find and fix vulnerabilities and defects in proprietary code, open source components, and application behavior. With a combination of industry-leading tools, services, and expertise, only Synopsys helps organizations optimize security and quality in DevSecOps and throughout the software development life cycle. Learn more at www.synopsys.com/software.
