the Key to the Future of DevSecOps – InApps 2022

Synopsys sponsored this post.

Modern software development embraces the concept of more: more code, in more languages, on more platforms, with more deployment options. And the natural reaction to this increase in, well, everything, has been the rise of the culture of DevOps in organizations. But DevOps isn’t anything new to development and operations teams — they’ve been using DevOps practices to build high-quality software quickly for years.

DevOps depends on automation to maximize velocity and continuous improvement throughout process feedback. Yet the greatest threats to any DevOps environment are the threats you don’t yet know about.

If you’re forewarned, you can be forearmed.

And although it’s true that DevOps environments enable faster deployments to production, they also pose great threats to an organization if not properly secured. Attackers are on the lookout for DevOps environments, because they know they may offer access to source code, libraries, cloud environments, defect reports, and more.

In reaction to these threats, security teams are increasingly adopting DevOps methodologies to infuse security into already (in many cases) mature DevOps practices. After all, more code and more complexity mean more places where things can go wrong.

More velocity also means less time to get things right.

Seamlessly Infusing Security into DevOps

Traditional security tools often cause friction, decrease velocity, and require time-consuming manual processes. Very un-DevOps.

Such legacy application security approaches limit a security team’s ability to deliver timely and actionable security results, along with the instant feedback needed to drive improvements at the pace of modern development. The result is a continued increase in security threats and vulnerabilities, despite a growing awareness and interest in application security.

In an effort to bridge this gap between DevOps and Security teams, innovative new solutions are emerging to address challenges — such as finding the best way to approach security holistically, from a boots-on-the-ground perspective around risk reduction.

The key? Better automation.

Rather than running full scans every time you make a change to the code, there are now solutions coming to market that use intelligent test execution — based on context — to decide what test to run, when to run it, and how to run it. This frees teams to handle each application with limited configuration and the flexibility to easily adjust policy in one place.

Critical Functions of Security in DevSecOps

Speaking of policy, let’s take a moment to discuss policy as code. Policy should be based on an informed approach to risk education. A simple yet 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, and identify the configuration and types of results required before releasing an application.

One way to articulate policy is in the form of machine-readable files — that is, policy as code. Using policy as code means that the policy is precisely specified, and changes made to it are readily understood and supported by a change management process. This also implies there is something that knows how to interpret and apply the policy. Rather than spreading interpretation across multiple tool integrations, you can use a single integration layer to provide security to your usual processes.

This security layer in DevSecOps performs several crucial functions. It contains and enforces the policy as code — 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, etc. Codifying this makes it unambiguous. Having it in one place makes your team nimble when responding to change. And multiple policies can exist, each reflecting a different kind of application and different risk profile.

It also performs appropriate testing at specified events within the development pipeline, as dictated by — you guessed it, the policy — but optimized for the current state of the project. The security layer should also handle tooling integrations, and normalize the results from the security tools. Directed by the policy, it feeds findings into your issue-tracking system, where they can be handled like any other issues.

When events such as a repository commit or repository merge request occur, your pipeline asks the security layer to perform security testing. The name of this powerful process is intelligent orchestration. It consults the policy to understand what testing is appropriate, and then — based on the policy, the testing that has already been conducted, and some common sense around what has actually changed — the security layer optimizes how the testing takes place.

For example, if a developer has just committed a change to a CSS file, intelligent orchestration determines that a full static analysis scan and a full software composition analysis (SCA) scan aren’t necessary. For changes to a few Java source files in a specific module, incremental static application security testing can be performed to optimize speed.

The Future Is Bright

Integration is an order of magnitude easier from your existing pipeline. This security layer is designed to simplify integration. If you’re trying to build a DevSecOps strategy, applying 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.

Whether someone discovers a new way to carry out security testing, or you just want to incorporate an additional type of testing or 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.

And there you have it — the Sec earns its place in DevSecOps through intelligent orchestration.

Feature image via Pixabay.