Selecting AST tools for your CI/CD pipeline requires an understanding of where to integrate and how to configure your tools to get the most out of your investments.
The benefits of application security (AppSec) tool integration in the continuous integration/continuous delivery (CI/CD) pipeline are greater the earlier (the “further left”) you perform them in the process. Development organizations are continuing to shift left to implement security earlier in the CI/CD pipeline. But software security group leaders need to know where AppSec tools should go in the CI/CD workflow, and their purposes in different phases. Based on a four-part webinar series on automating application security testing (AST) tools into your AppSec program, this blog post will help you assess the right tools for your CI/CD pipeline and explain where to integrate and how to configure your AST tools to get the most out of your security investments.
How do you pick the right AST tools for your CI/CD pipeline?
It’s important to choose the right security tool, and configure and run it at the right time, so you get the most benefit out of it. Two of the prerequisites for AST tools are accuracy and speed. If a tool cannot meet the deployment velocity of the team, the chances of it being adopted successfully are low to nil. Likewise, if the tool results aren’t accurate, it causes developers to waste time triaging false positives. Developers and operations can’t wait several hours for results before moving to the next stage in their CI/CD pipeline, because delivery delays can have cost implications. Using AST tools that provide results quickly can help developers identify vulnerabilities as they make their way through the pipeline.
AST tools must be able to seamlessly integrate within the development environment, where developers prefer to work. It’s vital that developers are comfortable using them day in and day out.
AST tools must also integrate easily with the build environment to ensure continuous integration, delivery, and deployment; otherwise, they will become useless due to potential pushback from the DevOps teams. The tool must also offer command-line invocation ability, integration with the metrics dashboard, defect tracking, and the ability to break the build and send automated email notifications.
Languages, frameworks, and API change constantly. AST tools must offer quick support for new languages, frameworks, and API to keep pace.
Last but not least, AST tools should provide continuous metrics and seamlessly integrate within a common metrics dashboard so developers, managers, and business executives can see the risk and also the progress being made. Reporting capabilities should showcase results and allow managers to incentivize developers to continually improve.
Once a tool or a set of tools is selected, it must be tested thoroughly before automating it in a CI/CD pipeline. Performing a pilot study is necessary to ensure the tools are accepted and integrated into the organization’s CI/CD environment. Conducting a pilot involves careful planning, buy-in of stakeholders, and adequate allocation of time and resources.
Where should you integrate your AST tools in the pipeline?
After selecting the AST tools and conducting a pilot, the next step is determining where to integrate these tools in the pipeline.
Software development teams use DevSecOps to accelerate software delivery. By integrating and automating security testing solutions early in the DevSecOps pipeline, teams can run scans for security vulnerabilities on every build without affecting velocity. This DevSecOps practice stands in sharp contrast to traditional software security methods, where application security testing is done late in the software development life cycle (SDLC).
Application security testing activities must be added to every DevOps pipeline. This isn’t a comprehensive list of activities—it includes only static analysis, software composition analysis, and dynamic and interactive testing. There are more automated and manual activities that need to happen. This is meant to just give you an idea of how to run a few activities. Once you get the idea, you can apply the same principles for all other security activities.
These activities can be performed in series or in parallel to other development activities. For example, when the application is packaged, integration tests and software composition analysis (SCA) can execute in parallel.
How should you configure security tools?
Now that you know which AST tool should be integrated at each stage in the pipeline, let’s examine how to configure the tools. The table below shows the stages of the DevSecOps pipeline, what type of test to run, and what tools to use.
| Stage | Type of test | Synopsys tool | Description |
|---|---|---|---|
| Developers IDE | Incremental static application security testing (SAST) / SCA | Code Sight™ | Seamlessly integrates with IDEs to identify security weaknesses as developers code in real time. |
| Lightweight SCA | Black Duck® | Lightweight scans in IDE; runs only dependency analysis. | |
| Commit time | Incremental SAST | Coverity® | Each analysis saves discoveries about the code, moving the analysis forward each time. Should be used to analyze sequential versions of the same codebase. |
| Enhanced SCA | Black Duck | Signature analysis. | |
| Build time | SAST | Coverity | With control over the type of analysis, checkers, and results, teams can turn the dial up or down to get the results they need in the timeframe they have. |
| SCA | Black Duck | Scans appropriate per policy. | |
| Test time | SAST | Coverity | Full analysis and comprehensive results. |
| Dynamic application security testing (DAST) / interactive application security testing (IAST) | Tinfoil™/Seeker® | Passive scans and customized rules such as checking for vulnerabilities related to SSL/TLS, HTTP headers, and cookie attributes. | |
| Deploy time | DAST/IAST | Tinfoil/Seeker | Full scan with rules such as XSS and injection attacks to spider through the entire application. |
What does it look like when you build a pipeline?
The diagram below outlines a pipeline separate from what the development team uses. This is just one possible implementation; you can also build all the stages within your development team’s pipeline. The continuous integration server used here is Jenkins. It’s a Java Maven project, and all AST tools are Synopsys.
Upgrade your application security program today
For more information, please contact ASIC Technologies at (+84) 24 3748 1504 | Sales@asic.vn to learn more about building a CI/CD pipeline using real-world examples.