Overview

Continuous delivery is a cornerstone of contemporary software development, enabling teams to deliver high-quality software quickly. However, it can be a challenge to integrate software security scanning practices like static analysis into the continuous delivery process because these scans are comparatively slow. That often puts security scanning at odds with high-quality software delivery. However, with thoughtful implementation that need not be the case.

In this post, I propose a scan integration strategy called “just-in-time” scanning that leverages the CI pipeline and the Pull Request workflow to put security scan results in front of developers when they are the most timely and useful.

Shift Left

Just-in-time security scanning contributes to a broader “shift left” effort to move software scanning to the earliest practical point of time in the development cycle. The goal of the approach is to execute software scans when the development team is most likely to see the results and most able to act on them. Generally, the later (or further right) in the process this information becomes available, the more expensive it is to fix.

Branching Strategy

Regardless of your chosen branching strategy and workflow, there is generally a medium or long-lived branch that serves as the first point of entry for code that receives contributions from and is visible to more than one developer. Let’s call the branch develop for the sake of this discussion. The just-in-time scanning proposes that teams scan code and process the results before the code is ever allowed into that shared branch.

In the next section, I will discuss what this looks like in a practical implementation.

Leverage Pull Requests for Seamless Integration

Pull requests (PRs) are a fundamental component of collaborative development using version control systems like Git. PRs are also the most common point at which code reviews happen. This makes them an ideal place to have security scan results handy for the code reviewer. Given this, as a foundational practice, I recommend that teams use pull requests for any code that goes into the previously defined develop branch. Pull requests encourage an early/often code review mentality, but they also enable the ability to scan the code at the point in which any scan findings would be easiest to remediate.

In most cases, there is a natural lag time between when a developer creates a PR and when the reviewer reviews the code. This makes it an opportune time to execute longer-running processes like security scanning. The bonus to this is that when the security scan completes the code reviewer has an additional set of information to use as input to the code review process. In addition to coding style compliance and quality issues, reviewers can now ensure that no new vulnerabilities are introduced with the corresponding code changes.

Configure Just-In-Time Security Scans For Continuous Delivery 

Below are the five steps you should follow to configure a security scanning tool into the CD process.

1. Select the Right Scanning Tool

Teams should select a security scanning tool thoughtfully based on the quality of results and, nearly equally important, the integration features the tool provides. Specifically, you will want to find scan tools that support the following:

• Integration that supports automated scanning via your chosen CI 
• Pull request decoration for your given code repository platform.
• Support for your language(s), package managers, and (ideally) developer IDE’s

If your organization purchases a scan tool that doesn’t integrate with your CI/CD pipeline, doesn’t support your chosen development language(s), or doesn’t provide integration with your developer IDE’s the most likely outcome will be developer rejection. Make sure that your security tools support integration with your developer tools. Read my previous blog on this topic for more details.

2. Setup The Pipeline

Once you have procured your scanning tool, review the documentation for your chosen tool and learn how to set up scans from the CI pipeline. While it is an option to make the scan a part of the normal CI pipeline that builds your code, I recommend creating a standalone pipeline dedicated to security scans for reasons that I will clarify in the following section. 

3. Set Up The Scan Trigger

This step is going to vary depending on your CI provider, but the documentation for your scan tool should guide you in this step and most offer some sort of feature to accomplish this. Set up your CI platform to initiate a scan any time a developer creates a PR that targets your develop branch. In Azure DevOps this feature is called branch policies. Azure DevOps users should, for example, create a branch policy on the develop branch that requires a completed scan pipeline (see previous step) before the user can merge the PR.

This workflow essentially sets up a tunable quality gate that scans all code prior to a merge.

4. Tune The Workflow

These policies can be more or less restrictive depending on the needs of your team. If this is the first time your team has done any sort of security scanning it is likely that you have a nontrivial amount of technical debt that you will address over time. For teams in this situation, I recommend a phased approach in which, at least initially, even if the security scan fails the repo will still permit the merge. As your team grows more security-proficient and works down some of the technical debt, you can begin to make the branch policy more restrictive.

A phased approach might look like this:

• Phase 1: Allow merging even on scan failures.
• Phase 2: Prevent merging for any new high-severity findings
• Phase 3: Prevent merging for all new findings.

5. Educate Developers

Educate your team about the importance of reviewing the scan results and formalize these scan reviews as a part of your normal code review workflow. Most security tools provide extensive documentation that often includes general code security topics, making them excellent resources for the development team as they grow their security acumen. Curate a list of recommended resources from the documentation and from other places like OWASP to level up your team’s security awareness.

Conclusion

Security scanning is a necessary friction point in the development cycle for teams that wish to observe the security posture of their code. The goal for any workflow setup is to reduce the friction as much as possible so that the team is not burdened with a heavy additional workload for doing the right things. I believe that the proposed workflow here is a great way to achieve this goal for your team.

If this is something you would like assistance with please reach out to Trailhead for additional information. We would love to help!