DeepSource's Guide to SAST
Static Application Security Testing, or SAST, is a method of analyzing an application’s source code for known security vulnerabilities. When implemented as a pre-merge check in your team’s software development workflow, SAST helps developers spot these vulnerabilities in their code so they can fix them before the code is merged into the main development branch. Usually termed as “shifting left,” pre-merge is the ideal place to fix security vulnerabilities since the “cost” of fixing these vulnerabilities increases exponentially after the code is merged or, worse, shipped to production.
Engineering and security leaders unanimously agree that SAST should be a critical part of a modern engineering workflow to ensure the team is shipping secure code, just as Continuous Integration (CI) ensures the team is not shipping any broken code. But there are several practical challenges when implementing SAST in your development workflow.
At DeepSource, we’ve helped 4,000+ engineering teams implement a SAST solution in their workflows through our code health platform. Over 70% of these teams didn’t have any existing SAST or static analysis solution in their workflows. Over 50% of these teams have 100+ developers, and only about 20% have a dedicated application security team.
In this post, we outline what we’ve learned about the challenges you’ll face as you implement SAST in your development workflow and talk about how DeepSource helps you solve them.
Challenge #1: Integration with existing workflow and tools
Most SAST tools require integration as part of your CI's build process or the testing pipeline, where you’d need to add the SAST analysis tool as a build step. This is the most common blocking problem we’ve seen teams face as they start integrating SAST.
Increasing the build time on every pull request is undesirable since it invariably decreases developer productivity and increases the total build minutes consumed on your CI, costing you more money. On another note, integrating SAST as a build step is time-consuming, as it’ll require modification and maintenance of the CI config. This makes the SAST implementation a no-go for several teams who cannot afford to disrupt the existing workflow.
On DeepSource, no CI integration is required; hence, new build steps are unnecessary. We directly integrate with your version control provider, such as GitHub or GitLab, and automatically trigger analysis for each commit in our independent analysis environment — parallel to your CI. This means zero changes to your CI configuration, faster analysis results, and the same amount of dollars spent on your CI.
Challenge #2: Managing false positives
Talk to any developer with experience using a SAST tool, and they’ll invariably tell you they don’t use the results because they’re full of noise and invalid warnings. A high rate of false positives is the second most common blocking problem for security leaders trying to implement SAST in their workflows.
If the results are noisy and largely invalid, developers will inevitably ignore them. Valid warnings get buried underneath all the noise and make it into the code base, defeating the very purpose of having SAST in the workflow in the first place. But most importantly, this erodes the developers’ confidence in automated security tooling.
A SAST solution must optimize for issues fixed rather than just issues raised. Ensuring the warnings flagged by DeepSource are highly relevant and least noisy, we guarantee a false positive rate of less than 5% in our results. We’ve built our Analyzers ground up, considering accuracy as the primary focus. In addition, if you come across a false positive, you can simply mark it as such from the dashboard. We act on each false positive report and fix the relevant check in our Analyzers. In the last six months, we’ve resolved over 75% of false positives reported by our users within a week.
Challenge #3: Handling existing technical debt
If your team has never used a SAST solution, a new SAST tool will likely throw hundreds or thousands of warnings in the existing code base. This is a significant cause of general apprehension amongst developers in adopting the tool — will their development be blocked due to existing technical debt? SAST should help developers move fast, after all, and not slow them down.
Practically, this is the number one cause of pushback from developers when security leaders introduce SAST in the workflow. Most SAST tools aren’t “context-aware” and raise all warnings found in a file when only a few lines were modified. Imagine getting inundated by hundreds of alerts when all you did was change a small function — no wonder you’d push back on the tool.
In DeepSource, we’ve solved this using “baseline analysis.” Since we store the latest state of the issues in each repository by tracking the default branch (usually “master” or “main”), we understand the “new code” on each new pull request. When the SAST analysis runs on the pull request, we can show only those issues that the developer is introducing in the changes they’re making — regardless of the existing problems in the file.
This means even if you have a large amount of technical debt or existing security issues in your code, you’re not blocking new development because of them. Developers only need to fix the problems they’re introducing in their proposed changes and are more likely to fix them.
Challenge #4: Visualizing the current security posture
Running a SAST solution on the code is one thing, but understanding the results for taking action or securing buy-in from other engineering functions or the leadership is usually critical for a security team. Proposing changes to the development workflow of an engineering team is a tall order, and security leaders often struggle with getting everyone on board.
Most SAST solutions provide only very minimal reporting or none at all. A lot of manual effort — including exporting the analysis results to CSVs, mangling spreadsheets, and creating visualizations by hand — is required to get some even rudimentary insights into the current state of security of the code base.
We’ve built reports as a first-class feature in DeepSource to solve this. From the moment the first SAST analysis runs on a repository, security teams can see security reporting for OWASP Top 10 and CWE/SANS Top 25 compliance for their code base. These are the two most popular security recommendation frameworks adopted by security teams in the industry and provide a robust system to measure the code base's security. These reports are available per repository and across the entire organization, providing security teams with a single view of everything they need to prioritize action.
DeepSource is SAST built for modern teams.
SAST is a crucial part of DeepSource’s code health platform. In a modern engineering organization, security is everyone’s job, not just the security team’s. Security leaders from leading tech companies strive to shift the security left of the development workflow, and we’ve built DeepSource’s SAST solution in line with that.
At its core, DeepSource helps security teams implement SAST in the team’s development and delivery pipeline with minimal configuration and no disruption to the day-to-day development, guarantees less than 5% false positives, and provides robust reporting to help understand what needs to be done on priority.
If you’re a security leader exploring SAST for your team, DeepSource has got you covered. Talk to us for a personalized demo for your organization.
