Static application security testing, or SAST, is the process to test the source code to find any security defect in the code or its vulnerabilities. In the application security assurance program, SAST is performed to identify and remove all security vulnerabilities early in the DevSecOps process.
It can be difficult to integrate SAST tools into DevSecOps processes and create a sustainable program. SAST tool automation is an imperative part of adoption and can drive consistency, efficiency and detect the vulnerabilities in an early stage.
The process is automatic but still, clients have doubts regarding SAST tool integration with DevSecOps pipeline, including:
- How should false positives be managed?
- How should the result be triaged?
- How should newly identified issues be handled?
- If any existing scan is taking four to five hours, then how should the DevSecOps pipeline use this tool?
- What is a baseline scan?
So, if you also have any of these questions or are not aware of the integration process of SAST tools with your DevSecOps pipeline, then this article is for you.
There are several stages in project development life cycle where SAST tools should be run, including in developer’s ID as a pre-commit check, at build time, commit time and test time. These stages are not specific, however, and there can be many more other stages where you can integrate SAST tools, but for all these integrations you should know the complete process and steps of integration.
The main idea behind this integration is to choose the best combination of manual oversight with the appropriate level of automation, so that a cost-effective, secure and proactive DevOps process can be implemented through DevOps pipeline and SAST tool.
5 Integration Steps in the DevSecOps Pipeline
Step 1: Application Onboarding into DevSecOps Pipeline
Application onboarding is a crucial step for every application and this one-time effort is usually performed either by the development team or security analyst. It is usually performed through SAST tools in the DevSecOps pipeline through the following steps:
- Code scanning and auditing/triaging results.
- Merge subsequent scan result.
- Removal of false positives.
- Ruleset customization.
- SAST tool automation in the pipeline.
The scan cycle usually starts with gathering artifacts, and for that you should have all libraries and source code with you, as well as a clean cache. Scanning is a smaller process than building the application, so it takes less time. The scan result report can have two types of reports:
- In first scans, the complete source code is scanned in which a complete review has to be done (aka triaging).
- In any subsequent scan, the scan report of source code is uploaded to the enterprise server, where it is merged with the previous scan report or triage scan result. The merge will highlight new issues that have not been audited.
In this step, you can easily identify the bugs that may need to be fixed and prioritize them by their complexities. When the bugs are fixed, new code is added and incremental or differential scans are performed to understand which code needs to be fixed. Below listed steps are performed in this step:
In case of merging of subsequent scan results, the results of all subsequent steps are merged on the enterprise server. All scans are also pushed on the server before breaking or pushing the build defects to your bug tracking system. Identified bugs can be flagged as:
- Tag the bugs or findings as “suspicious,” “not an issue,” etc.
- Suppress all false positives.
- Hide those findings.
Integration of SAST tool decreases your work and improve the performance.
Bugs that are marked by the SAST tool but in reality are not identified as bugs by the developers are known as false positives. A tool cannot scan the code like a human, as it lacks the real-time context of the application to bring a real issue to the user’s attention. These false positives should be removed prior to the onboarding process of the application by the developers.
Now in the case of rule customization, there should be effective tuning between a rule set and rule customization to get an accurate result. Injection attacks must be identifiable by tracing the data sources before interpretation. As the data origin may be different—such as property files, user input or database or any file system—SAST tools should identify and resolve them.
Now after these steps, the SAST tools can be integrated and automated into the DevSecOps pipeline.
Step 2: SAST01: Rule Set Configuration
After onboarding, triaging and rule customization you can roll-out a SAST IDE plugin to your developers. SAST tools can identify bugs automatically and suggest and guide developers as soon as they start typing the code.
Developers can follow the tool’s guidance and remove common security problems. Here they can minimize the false positives as much as possible or eliminate them. The following rules can be configured and run in the developer’s IDE:
- SQL injections.
- Cross-site scripting (stored/reflected).
- Resource leaks.
- Hard-coded credentials.
- Configuration review.
Step 3: SAST02: Top 10 Issues of Client
As developers often don’t run SAST tools religiously, the same ruleset of SAST01 and few additional (client’s top 10 issues) are run automatically further in the DevSecOps pipeline and take just a few minutes of scanning. The rules are listed below:
- All rules of SAST01.
- Session management.
- Configuration management.
Step 4: SAST03: Top 10 Issues of OWASP
At this point, you are moving toward DevSecOps process and your activities become longer. You should run the SAST tool with the OWASP Top 10 issues if you are going to implement a web application. Here you also can run your customized rules such as REST services, custom framework or web services. Few such rules are listed below:
- Command and malicious file injection and execution resp.
- Weak encryption.
- Path manipulation.
- Insecure cryptographic storage.
Step5: SAST04: Comprehensive Ruleset
In this final step, you can perform scans by combining SAST03 and SAST04 rule sets. This complete process may take 60 to 90 minutes. Some of the comprehensive rules include:
- XPath injection.
- DOM XSS.
- Open redirect.
- Header injection.
- XML external entity.
- LDAP injection.
It can be said that for broader rule sets a complete SAST scan process may be longer, so follow the divide-and-conquer rule formation and implementation strategy while implementing SAST. After this phase, you will have full coverage of your rule set. There is no standard rule size and may depend on language, architecture, technology and framework. Careful rule configuration may help you in a successful SAST implementation.