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?

Introducing DevSecOps

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.

Adding security to DevOps without compromising speed

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.

Spaghetti

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:

• Analyze on every commit
• Analyze on every push request
• Analyze on major releases
• Choose analysis checkers
• Configure analysis checkers

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:

• Scan your application
• Scan your deployment container
• Choose scanning granularity and other configuration options
• Components with CVEs violate policy
• Components with CVEs over a certain CVSS violate policy
• Components with high operational risk violate policy
• Components with certain licenses violate policy
• Noncompliant scan summaries go to your issue tracker
• Each noncompliant component finding goes to your issue tracker

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.

I’m going to say it: Policy as code

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.

An overlay for risk management

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.

Critical functions of a security layer in DevSecOps

The security layer in DevSecOps performs several crucial functions:

• It contains and enforces the policy as code. “Policy” here describes what testing should be done, what kinds of results are allowed (or will break the build or deployment), what kinds of findings will be sent to the regular issue-tracking system, what kinds of compliance activities need to happen, and more. Codifying this makes it unambiguous, and having it in one place makes your team nimble in responding to changes. Multiple policies can exist, each reflecting a different kind of application and a different kind of risk profile.
• It performs appropriate testing at specific events in the development pipeline as dictated by the policy, but it is optimized for the current state of the project. The security layer handles the integrations with the tools.
• It normalizes results from the security tools. As directed by the policy, it feeds findings into your normal issue-tracking system, where they can be handled like any other issues.

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.

• When should I do the security stuff? At events such as repository commit or repository merge request, your pipeline asks the security layer to perform security testing. The security layer can work some powerful magic, which we call intelligent orchestration. First, it consults the policy to understand what security testing is appropriate. Based on the policy, the testing that has already been done, and some common sense about what has actually changed, the security layer can optimize how the testing is done. For example, if the developer has just committed a change to a CSS file, intelligent orchestration will realize that a full SAST scan and a full SCA scan are unnecessary. For changes to a few Java source files in a specific module, incremental SAST can be performed to optimize speed.
• Am I compliant? The development pipeline can ask the security layer to issue a judgement about whether the project complies with the policy.
• What do I need to fix? The database of aggregated results supplies your issue-tracker, but it can also serve as a valuable source of intelligence for those colorful dashboards that make executives so very happy.
• How are we doing with security? You can categorize findings by severity, examine them through the lens of CWE Top 25 or OWASP Top 10, or filter and sort them any way you please. You can pull results into analytic tools like Tableau or Power BI and slice and dice them as needed. You can make graphs that show your bugs (and risk) drifting downward as your team works through security issues.

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.

Poised for the future

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.