At the build phase, run a deeper-level SAST scan with expanded rulesets. For example, the tool could check for the OWASP Top 10 and any rules for custom frameworks or other risks that may not have been covered by comprehensive rules.
Also, use an SCA tool at the build phase of the pipeline to catch known open source and third-party vulnerabilities and license risks. The build environment can provide dependency information to the SCA tool to augment open source scanning. Then the data from both sources can be combined into a complete and accurate open source bill of materials (BOM).
For the test phase, use a DAST tool to scan web applications and APIs, if present. Configure the DAST tool to run rulesets for common critical and high-severity issues. And in the test phase, run more extensive SAST operations as an out-of-band activity or asynchronously in the CI/CD pipeline. If an unexpected number of vulnerabilities is found, this should trigger an out-of-band manual code review using penetration testing. Interactive AppSec testing (IAST) tools can also be used in the test phase.
How should you configure AppSec tools?
For different phases of the CI/CD pipeline, AppSec tools should be configured to find different security issues. For example, during the pre-commit phase, a SAST tool plugin should be configured to catch security issues that have zero false positives, such as SQL injection and cross-site scripting (XSS). Concentrating on security problems with no false positives at this stage will give developers confidence that the tool is working properly. The SAST tool plugin in the CI/CD pipeline (Figure 2) should provide just-in-time guidance to developers to help them remediate security issues while they are in the code. If too many vulnerabilities are found, the plugin can trigger an out-of-band activity, such as threat modeling or architectural risk analysis.