Shifting Security Left in Your Continuous Testing Pipeline

Security is often the black sheep of testing. At many organizations functional testing has continuous support and funding throughout the lifecycle of the application, but when the focus shifts to security, there is only a scan before the release.

We need to discuss how to get security to be considered a first-class testing citizen with similar full-lifecycle support. This involves analyzing technologies that integrate cleanly into the modern CI/CD pipeline, why information radiators matter, and the cost-benefit arguments that can help convince management to do the right thing.

Ultimately, for the best impact, we need to introduce security testing into the early phases of the continuous testing pipeline.

One of the first weaknesses I’ve observed in most security testing strategies is the last-minute nature of a majority of the testing. Organizations will invest in a variety of testing tools and techniques, assemble the data, and only analyze the results right before the release.

In contrast, an established QA organization is giving frequent feedback to the developers in the form of constant bug reports and automated test results. Additionally, if developers are following best practices, there are elements of unit testing and light integration testing built into the automated build process, giving feedback on every build. Informally, the efforts of the developers and the QA organization start to lay the foundations for continuous testing.

Continuous testing is generally thought of as automating testing at every stage of development to innovate quickly without compromising quality. Applying this to security is critical today because even without the code changing a single line, new vulnerabilities are discovered and disclosed on a daily basis.

This means that in order to understand how vulnerable your software is, you need some form of security testing to take place and report results almost every day on code that may even already be deployed.

We can start to theorize how to shift security left by looking at three common security testing tools: SAST (static application security testing), DAST (dynamic application security testing), and SCA (software composition analysis). The idea is to take that huge static report being generated just before release by these tools and turn it into something actionable by developers every week, every night, or even every build.

With a little ingenuity, we can integrate SCA and SAST analysis into the automated build process, helping give some form of daily feedback. With DAST testing, we can run functional tests through an attack proxy, leveraging the work that QA has already done to provide a platform to find more insidious security vulnerabilities.

Without a constant flow of information about your software’s security, you will be doomed to become the next front-page breach. In order to get that flow of information, you need to shift security testing left along with all your other testing. By leveraging SAST, DAST, and SCA into your continuous testing pipeline in a meaningful way, you can defend against the constantly changing security landscape.

Glenn Buckholz is presenting the session Shifting Security Left in Your Continuous Testing Pipeline at the completely virtual STAREAST conference, May 4–7, 2020.

• Login or Join to add your comment