The Essential Components of a DevSecOps Pipeline

DevSecOps pipelines arose in response to DevOps and CI/CD, which made it possible for developers to iteratively and continuously deliver small code changes, rather than massive deployments periodically.

In theory, by integrating security into DevOps processes that enable continuous integration and delivery, developers could find and resolve security issues early in the software development lifecycle (SDLC), which is much faster than fixing security issues in production.

While most modern implementations of product security integrate vulnerability scanning and remediation within the CI/CD system, this doesn’t mean they will help developers deliver more secure code without significantly slowing them down.

In this blog, we’ll examine the essential components of DevSecOps pipelines that empower engineers to resolve vulnerabilities before production, without hampering their velocity.

This will require integrating DevSecOps into developer workflows, which is described in the video below:

What is a DevSecOps Pipeline?

As mentioned, a DevSecOps pipeline should be more than just integrating security scanning tools into the SDLC. 

Rather, this shift demands a reevaluation of processes, advocating for security to be woven into the fabric of software design, development, testing, and deployment from the outset. If developers aren’t empowered to fix vulnerabilities (not just find them!) before production, your code security program won’t be too helpful.

A DevSecOps pipeline is a set of technologies and processes integrated into the CI/CD system. Any AppSec or DevOps team can implement these pipelines to surface vulnerabilities – the real challenge is empowering engineers to quickly resolve those vulnerabilities as they make iterative changes to the codebase. 

Let’s examine some practical methods of integrating security analysis into the SDLC to form the foundation of a DevSecOps pipeline, and then we will discuss making security actionable and practical for developers.

» Learn more: Key techniques every DevSecOps professional needs

The Key Stages of a DevSecOps Pipeline

The SDLC encompasses several stages, each integral to the successful development of software. Let’s examine how security can be integrated into these stages:

Planning

This initial stage involves defining the project's objectives, scope, and constraints. It sets the groundwork for what needs to be developed and how. 

This is where architectural decisions can be made that adhere to secure design principles, which have a large impact on security down the road. This is the stage to answer questions like:

• What are the security requirements and objectives based on the nature of the project?

• Who are the potential stakeholders and what are their security expectations?

• What are the potential security threats and vulnerabilities?

• What is our risk tolerance for security vulnerabilities?

• What security measures and controls will be implemented?

• How will security be integrated into the development process?

• How are we going to prioritize vulnerabilities?

• What do we need to do to fulfill our compliance requirements?

• What methods should we be using to minimize blast radius? How about implementing a model of least privilege?

Coding

You can integrate DevSecOps tools directly into the IDE (Integrated Development Environment) to scan code as it's being written, so developers can catch vulnerabilities as early as possible. This is the earliest stage in the SDLC for developers to actually surface and resolve vulnerabilities.

To prevent security from slowing down development, developers should have the option to fix the vulnerability, accept the risk of the vulnerability, or mark a false positive – as opposed to being blocked whenever there is a security issue. Of course, these actions should be monitored to prevent developers from accepting serious risks.

Most often, Static Application Security tools, Software Composition Analysis tools, and secrets detection are integrated into the IDE to find code vulnerabilities.

Below is an example of three detections within VScode: hard-coded secret, Python code vulnerability and Terraform misconfiguration.

Pre-commit hooks

Often used for quality checks and debugging, pre-commit hooks are a great way to run security testing before code is introduced to the codebase. This way, whenever the security scanners detect issues, the code commit will be blocked. 

Some developers may prefer to scan their code in pre-commit hooks rather than the pull request, so that errors aren’t documented in their SCM.

CI (Continuous Integration) pipeline

Integrating security within the CI pipeline means automatically scanning and testing new code for vulnerabilities when a pull request is created. This is a foundational stage in the SDLC, so it's where many developers prefer to scan their code.

Whenever branch protection is enabled, developers can’t merge the Pull Request until the detected issue is resolved. This is an efficient mechanism to “stop the bleeding” and prevent vulnerable code or misconfiguration from finding their way to the codebase.

In addition to integrating application security tools into the CI pipeline, you can also integrate IaC scanning to surface cloud infrastructure misconfigurations in the PR before they’re pushed to production.

>> Learn more about CI/CD security checks

Finally, the CI pipeline is a good place to integrate container image scanning to ensure vulnerable built images aren’t pushed to production. Container runtime analysis can be integrated after deployment (more below).

Jit provides immediate feedback on the security of each pull request, so developers can immediately resolve vulnerabilities before PR is merged. This experience is delivered entirely within the PR, so developers never need to leave their environment

In the video below, see how Jit scans code within the PR:

The build

Some code languages can only be analyzed as it is being compiled, so security scanning is often integrated into the build phase of the CI/CD pipeline.

For example, with Java Gradle, you’ll need to integrate scanning into the build to surface vulnerabilities.

For languages that do not need to be compiled as they’re analyzed for vulnerabilities, we recommend integrating security scanning into the IDE or SCM, which provides immediate security feedback without waiting until the build is complete.

In production after each deployment

The shift left mindset prefers to surface vulnerabilities early in the SDLC, however, some vulnerabilities can’t be found until runtime. Plus, when you find a vulnerability in production, you know it's a true positive. 

For this reason, tools like Dynamic Application Security Testing (for detecting vulnerabilities in web applications in runtime) and Cloud Security Posture Management (for detecting misconfigurations in cloud infrastructure in runtime) are often integrated into the production environment. 

While these tools can often be configured to run scans periodically, some may prefer to scan their environment after each deployment, to immediately catch new risks as they’re introduced.

Below is an example of a yaml file that initiates a Jit security scan after a deployment:



» Check out our list of continuous security tools

Making Code Security Practical and Actionable for Developers

As discussed at the beginning of the article, tacking a security scanning tool onto your SDLC isn’t a sure path to effective security engineering. Rather, a DevSecOps pipeline should be constructed with the developer experience in mind to encourage adoption and enthusiasm for delivering secure code.

Let’s review some of the ways security scanning can slow developers down, as well as practical strategies to reduce the time needed to fix vulnerabilities before production.

Integrate the security control directly into the developer routine

In many modern application and cloud security practices, code scanning tools will automatically trigger during an event within the SDLC, and generate long backlogs of vulnerabilities in separate UIs outside of the developer environment.

This takes developers out of their flow state – requiring them to leave their IDE or SCM to scroll through a list of security issues that may not be relevant to their current code change.

Alternatively, security can be baked into the day-to-day developer routine with technologies like Jit, which integrate security scanning and remediation into the IDE and pull request.

Jit provides immediate feedback on the security of each code change entirely within the PR or IDE – which means developers never need to leave their environment to interact with a backlog of vulnerabilities.

When developers can quickly understand how their current code change impacts the security of their system, resolving vulnerabilities is far easier and faster. 

While integrating security early in the SDLC is faster than finding vulnerabilities in production, scanning the runtime environment is critical to surface security issues that may have slipped through the cracks.

Similarly to creating PRs, deploying code is another routine for developers. By automatically scanning runtime after every deployment, development teams get security feedback on their deployments without changing their usual workflows. 

Automate prioritization for real security risks

Many vulnerabilities generated by code security tools don’t actually pose security or compliance risks. For example, a medium severity security vulnerability within a service connected to the internet could pose far greater security risks than a high severity vulnerability that isn’t exposed to the internet.

However, determining whether vulnerabilities are actually exploitable in production requires developers to trace the attack path of each vulnerability, which can be manual, technically complex, and time consuming.

To help developers prioritize long backlogs of vulnerabilities and focus their attention on the most critical risks, security issues should be automatically prioritized by their exploitability and reachability in production.

With Jit’s Conext Engine, developers can quickly determine which vulnerabilities are exploitable and reachable in production, so that they can focus their time remediating issues that pose real security risks, rather than chasing down vulnerabilities that can’t be reached by attackers.

Context Engine uses machine learning to correlate security issues with services in production, which determines the attack path for each vulnerability.

Provide thorough remediation guidance and automated code fix suggestions

Regardless of how seamless the security control is integrated into the developer experience or how easy it is to determine whether a vulnerability is exploitable, security issues will go unresolved without helpful guidance to make the right fix.

Oftentimes, developers will need to conduct research in third party websites to understand how security issues can be mitigated, which takes more time away from delivering new code and can ultimately erode developer confidence in security tools. If you don’t tell me how to fix it, why should I bother?

For this reason, each vulnerability should be paired with thorough remediation advice – which may include how a vulnerability can be exploited, why it matters, and resolution strategies – within the developer environment. Ideally, the developer will also get a specific code fix they can use to mitigate the issue.

Learn more about the benefits of auto remediation in this video:

In the example below, you can see how Jit explains what the vulnerability is, how to fix it, why it matters, and a suggested code fix to automatically remediate the issue – it's all within the PR in GitHub, so the developer doesn’t need to leave their environment. 



Next steps for building your DevSecOps pipeline

Product security can require many different tools and components, which may include static analysis to scan your code, software composition analysis to flag vulnerabilities in open source libraries, secrets detection, IaC scanning, cloud and application runtime scanning and more.

Each of these tools have their own interfaces, configuration requirements, integration points and other attributes. Plus, development and security leaders will often need to report their product security findings to auditors and customers, which can be a headache with many different scanning tools.

With Jit, you can implement a complete DevSecOps pipeline that covers the entire code-to-cloud security landscape. 

Jit’s Security Plans contain the exact security controls, monitoring, and reporting needed to satisfy common product security objectives like gaining compliance with SOC2 or achieving Minimum Viable Security for customers. These plans can be rolled out across repos in a matter of minutes.

To get started with Jit, you can try it for free or request a demo.