Many have often inquired about how to integrate SAST tools into the DevSecOps workflow. They enquire about essential issues such as:
➡️What are my options for dealing with false positives?
➡️I'm not sure how I'm going to sort through the findings.
➡️What happens when new problems arise?
➡️It takes 4–5 hours for my scan to finish. How can I include this tool into my DevSecOps workflow?
➡️What exactly do you mean when you say "baseline scan"?
Here are some of the benefits of SAST:
Finding security, safety, and quality concerns by checking for known vulnerability patterns for internationally accepted coding standards.
Defects are detected sooner, resulting in cheaper remedial costs.
Supporting a shift-left strategy by making analysis available across the board, including on developer desktops and in CI/CD pipelines.
Providing immediate feedback and pinpointing the specific position and source of vulnerabilities.
SAST tools should be executed as a pre-commit check, as well as during commit, build, and test times, in your developers' IDE. Examine each stage in further depth.
That assessment, on the other hand, does not focus on what you must do to properly incorporate SAST technologies into your DevSecOps pipeline. The justification for selecting this solution is that it combines the required amount of manual control with a suitable level of automation to build a cost-effective, proactive, and secure DevOps process in the existing pipeline through five key activities.
Let's talk about ways in which organizations can strategize with the shift left mindset.
Always do these checks right
Scan code and audit/triage results
The collecting of artifacts is the first step in a scan cycle. There are no hard and fast rules when it comes to how long the scan should take. The scan time is determined by the number of lines of code and the application's complexity. Perform a differential or incremental scan of the code that was just altered when problems are resolved and new code is introduced.
You'll receive a scan report file with all the results after the scan is completed. Then there are two scenarios to consider:
If this is your first time scanning the source code, perform a full audit review of the findings, often known as triage.
Upload the scan report file to the enterprise server if this is a subsequent scan of the source code. The fresh scan will be merged with the previously audited/triaged scan findings on the corporate server. The merger will bring to light new concerns that have yet to be investigated. You save duplication of effort this way.
When you scan your application for the first time, you're establishing a baseline. This implies you should examine each discovery or collection of findings and take one of the following steps:
- Label the discovery ("not a problem," "suspect," etc.).
- Suppress the appearance of false-positive results.
- Keep your discoveries hidden.
- Merge subsequent scan results
- Assume you can at week n and examine the data, finding one false positive in bug 1 and a true problem in bug 2. The initial step is to combine the scans from weeks n and o.
Because you gave the SAST tool background knowledge, it will remember that you suppressed bug 1, and it will also note that you repaired bug 2. You resolve problem 2, label bug 1 in the scan file as "false positive," and then add more code to your project.
Let's pretend you went through a scan, damaged the build, and created a defect in your bug tracking system, which the developer has now rectified.
You've now contributed code between weeks n and n+1, as well as a new problem, bug 3. Bug 3 will be marked as "new" by the tool.
When you publish your scan findings to the business server, Merge is an effective function that is performed automatically. Before breaking the build or submitting bugs to your bug tracking system, send all future scans to the corporate server.
Remove false positives
Knowing information about the app's users, trust boundaries, sensitive data handling, security systems in place, input validation methods in use, and so on can considerably improve your capacity to minimize false positives and assess the true severity of actual problems. A huge percentage of false positives is due to a simple reason: Because it lacks a portion of the context in which the application exists, the tool cannot evaluate like a person; as a result, it must err on the side of caution and bring numerous possible concerns to the user's notice.
False positives arise when a tool reports something as an issue that isn't actually a problem. Because it offers security expertise to developers and identifies implementation issues that they may have ignored, and SAST tool may be thought of as a virtual security analyst. False negatives, on the other hand, arise when the tool fails to detect flaws that should have been detected. Make sure you understand the application's context before diving into the tool's findings.
The developers, with the help of a security analyst, are the most competent persons to evaluate the source code.
Customizing Ruleset
Getting the most accurate and useful results from the tool requires customising and fine-tuning the rules to fit a specific application. You may wish to tweak the rulesets now that you have the information about the application and the triaged results.
Because injection attacks are the most common sort of online assault today, knowing where data comes from and which APIs it passes through before being processed or ingested is critical.
Getting the most accurate and useful results from the tool requires customizing and fine-tuning the rules to fit a specific application. You may wish to tweak the rulesets now that you have the information about the application and the triaged results.
Because injection attacks are the most common sort of online assault today, knowing where data comes from and which APIs it passes through before being processed or ingested is critical.
After scanning, triaging, deleting false positives, and configuring the tool, the next stage in the DevSecOps pipeline is to automate it.
This includes scanning using command-line options or building server plugins, defining thresholds for broken builds, providing email notifications to developers who introduce issues, and automating bug tracking.
SAST01: Highly configured rulesets - DNS_lecture_notes.pdf (lth.se)
It's time to distribute the SAST IDE plugin to your developers once you've onboarded, triaged, and configured rulesets. As developers input their code, the SAST tool automatically detects vulnerabilities and delivers just-in-time security recommendations.
Developers may avoid the most frequent security concerns by having their code checked for security flaws and following the tool's instructions to correct bugs as they code.
Because developers are continually examining the results, it's critical to keep the false-positive rate as low as feasible, if not nil. The triaged findings will help developers trust the SAST tool by allowing them to put out just the rulesets that are true positives.
Here are a few examples of rules that may be set up to execute in the IDE for developers:
- SQL injection
- Cross-site scripting (stored)
- Cross-site scripting (reflected)
- Resource leaks
- Hard-coded credentials
- Configuration review
SAST02: Client’s top 10 issues
There would be no need to run any more SASTs in the DevSecOps pipeline if every developer used the SAST tool religiously. However, this is never the case. So, assuming the SAST tool is automated, as soon as developers put their code into a version control repository, the same scan rules defined in SAST01—plus a handful more, such as the client's top 10 issues—are performed totally automated. The scan should take no more than 4–5 minutes with the SAST tool.
So, let's go through the rules for the SAST02 tests once more:
- SQL injection—same as SAST01
- Cross-site scripting (stored)—same as SAST01
- Cross-site scripting (reflected)—same as SAST01
- Resource leaks—same as SAST01
- Hard-coded credentials—same as SAST01
- Session management
- Configuration review
SAST03: OWASP Top 10 issues
After you read the article here, you're going toward the right of your DevSecOps pipeline now, and the tasks are taking longer to complete. If your application is a web application, this is when you should run your SAST tool against the OWASP Top 10 concerns. For applications that employ web services, REST services, or bespoke frameworks for which your SAST tool may not have extensive rules, you may also execute any unique rules you've built. In your SAST01 and SAST02, a few problems, such as SQL injection and XSS, have already been searched for.
The following are a few examples of rulesets for the OWASP Top 10:
- Malicious file execution
- Insecure direct object reference
- Information leakage and error handling
- Command injection
- Weak encryption
- Denial of service
- Path manipulation
- Insecure cryptographic storage
SAST04: Comprehensive rulesets
This is the last step, during which you may run scans using detailed rulesets. You may do the tests simultaneously by combining SAST03 and SAST04, or you can break them off further, as I do. The SLA here might range from 60–90 minutes to several hours.
- XML injection
- XPath injection
- XML external entity
- Open redirect
- DOM XSS
- Cookie injection
- Expression language (EL) injection
- Header injection
- LDAP injection
The longer it takes for the tool to perform the scan, the larger the collection of criteria you use. One of the reasons to attempt to divide and conquer the rules you run at each stage of the DevSecOps pipeline is to reduce the number of rules you have to run.
Once you've finished this phase, you should have a clear understanding of all of your SAST rules. As I usually say, "one size does not suit all." You'll need to properly configure your rules and be prepared to build bespoke rules depending on the language, architecture, technology, and framework you choose.
Once everything is in place, include the IDE plugins in the pre-commit checks so that developers have access to the tool and can identify and resolve issues as they arise.
Finally, while testing, configure extensive rulesets.
All other tests, with the exception of the SAST tool running in the IDE, break the build, send email notifications, and upload defects to the bug tracking system.
The actions recommended meet the following important objectives:
Allow developers to concentrate on defect correction.Use pre-commit checks in the developers' IDE to strategically align source code analysis early in development release cycles.During the commit-time checks, the identical set of rules and the client's top 10 are run.Encourage the development organisation to adopt a precautionary mindset.
Allow security teams to maintain governance and track the residual risk posture on a continuous basis from a central location.Allows DevSecOps teams to incorporate SAST technologies without adding to their time to market.
Configure the OWASP Top 10 throughout the construction process.
Many developers who are using SAST technologies for the first time go through a period of learning and exploration. When the tools are onboarded and automated in the DevSecOps pipeline, trust me when I say they'll start paying more attention to the security of their code.
Oldest comments (0)