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 usually only a scan before the release.
Security must 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, explaining why information radiators matter, and making the cost-benefit arguments that can help convince management to do the right thing.
Ultimately, for the best impact, you need to embrace continuous testing and introduce security testing into the early phases of the continuous-testing pipeline using three tools: SAST (static application security testing), DAST (dynamic application security testing), and SCA (software composition analysis).
Here's what you need to know, and how to get started.
Embrace continuous testing
One of the weaknesses in most security testing strategies is the last-minute nature of most of the testing. Organizations invest in a variety of testing tools and techniques, assemble the data, and analyze the results only just before the release.
In contrast, an established QA organization gives frequent feedback to developers in the form of constant bug reports and automated test results. Additionally, if developers are following best practices, elements of unit testing and light integration testing are 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 and continuous delivery.
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 to understand how vulnerable your software is, you need some form of security testing to take place, and results to be reported, almost every day—even on code that may already be deployed.
Shift security left
You can start to theorize how to shift security left by looking at three common security testing tools: SAST, DAST, and SCA.
The idea is to take the huge static report generated just before release by these tools and turn it into something actionable by developers every week, every night, or even every build.
1. Static application security testing
One reason SAST can often be an initial candidate for continuous security testing is its proximity to the code. SAST is a literal scan of the source code that can happen at the time of compilation. If your code is already going through a CI/CD pipeline, then you have a majority of the infrastructure needed to create an automated testing framework for applying SAST to your source code.
As with all security tools, to keep pace with disclosures there must be an automated process to keep the vulnerability analysis up to date on top of the scanning itself. Next, you can leverage the existing automated build tools or your CI engine (Jenkins, Bamboo, etc.) to invoke a source code scan in parallel to the build.
Once the scans are happening automatically, they will produce an enormous amount of data.
The results of this automated scanning should produce two artifacts. First, to make the data useful, the results of the scan need to be summarized and put into a dashboard displayed in the CI engine.
Second, the detailed report must be organized in a way that is traceable to the original build for compliance, reporting, and research purposes. For relatively low overhead you can get an initial, constant assessment of your application.
2. Software composition analysis
SCA implementations vary compared to SAST. As with SAST, the vulnerable component database must be automatically kept up to date. The build process invokes some tools to analyze all of the third-party dependencies at build time.
Other tools are set up as part of the CI/CD infrastructure to intercept the dependencies and create the analysis as the normal build process runs.
With the first method you get an after-the-fact report of which vulnerable components are in your application. With the latter method, you can dynamically block components that are not of a certain quality and have reports that are updated in real time, and which represent how much risk you have to assume based on the third-party components leveraged.
This proactive approach is more expensive to implement but will cause failed builds rather than allow insecure software to be built.
3. Dynamic application security testing
If your DevOps pipeline does not include automated testing, DAST will be prohibitively expensive to set up.
To implement DAST with the least amount of security-specific effort, you can run your automated functional tests through an attack proxy and fuzzer. Since you're running DAST as part of the automated functional test suite now, this is a little bit further right than SAST or SCA, but it is still highly automated.
Some of the main advantages of this implementation are testing frequently used paths through the application and frequent execution so new attack methods can be used to evaluate security.
Get your organization's support
Now that you have a general idea of how to implement security in your CI/CD pipeline, you need to persuade the powers that be to fund the changes needed.
The first stage is to ensure that your stakeholders are aware of the risks of having a long lag time for finding flaws. The long cycle time that scanning at the end of the development cycle introduces is typically a good discussion point to start with.
Next, it is imperative that you convince your stakeholders that you can achieve value by leveraging the CI/CD resources already in place and introducing security at a nominal cost. DON'T TRY TO BOIL THE OCEAN.
Last, you need to be clear that you can show incremental improvement in a short time frame. By picking the initial set of security automations carefully, you can accomplish incremental change in a short time frame.
Start with SAST happening with every build, then a sprint or two later SAST will produce a dashboard with the reports, then another few sprints later a dashboard can appear with a drill-down that developers can use in real time, creating a shorter feedback cycle.
Showing small, incremental pockets of value trending toward your security goal is easier to judge. This allows stakeholders to buy small bits of security rather than having to make an all-or-nothing decision, taking some of the pressure off.
Go with the flow
Without a constant flow of information about your software's security, you will be doomed to become the next front-page breach. 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.
Want to know more? During my STAREAST Virtual conference session, I'll offer more tips about how to shift security left as part of your testing strategy. The conference runs May 4-7, 2020.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
