Why SAST tools need to be as easy to use as linters
When it comes to ensuring software is reliable and secure, many developers are focusing on "shifting left" or incorporating practices, such as static application security testing (or SAST), earlier and earlier in the development cycle. With how complicated SAST tools are, developers struggle to shift left, lumping in SAST along with other lengthier processes, such as when building software, running tests, or reviewing code. In a perfect world, SAST tools would be as easy to use as a linter. Click install, and up pop security issues while writing code, making it as easy to catch SQL injections as it is missing semicolons or poorly named functions.
You're not alone if you daydream of this perfect world where SAST tools aren't annoying to use, and it has a real cost. Google researchers also felt this way, and when trying to solve it themselves, they found showing SAST errors early on doubled the chance a developer thought it was significant. Here at Semgrep, we develop our own bespoke SAST product, along with a cloud platform and an SCA product. Clearly, we're dogmatic about linter-like SAST tools, so what are we doing about it?
Semgrep VS Code Extension: What we're doing about it
In case you didn't know, we make Semgrep, a blazing-fast SAST tool that until now was only available through CLI or CI/CD integrations. Most users like to use it as either a pre-commit hook or as a pull/merge request (PR/MR) check. These are still important, especially as a way to monitor and record security findings. It'd be even better if we could get this functionality while writing code too. That's where the new Semgrep VS Code Extension comes in, available on the VS Code marketplace, all it takes is one click to install, and right away, you'll start seeing findings alongside those missing semicolon errors:
Install the VS Code Extension, navigate to a file, and findings show up
Like most linters, Semgrep will scan for problems whenever you open a workspace, open or save a file, and when prompted through the command palette. Something we worked extra hard on was speed; on most files, Semgrep will scan and provide you results instantaneously, meaning we'll catch stuff like secrets before you have a chance to run your code and potentially leak them. We've also focused on ensuring the extension is low noise, scanning only lines and files that have changed since the last commit (though this can be changed in Settings).
We've all seen a linter, though, so none of this should be surprising, except this isn't one and is instead a powerful SAST tool. This is where things get really cool and we take a giant leap past the average linter. In case you didn't know, Semgrep supports writing custom rules, and through the Semgrep Cloud Platform, you can write and manage what rules are scanned for across your entire organization. What does this mean for the extension? Well, it means if you're on a team and you've logged in through the extension, not only can you ensure everyone's code is scanned for the same quality and security issues, but you can write custom rules that will then be automatically scanned for across everyone's IDE.
Let's think about this again from the linter perspective. Let’s say a developer keeps seeing a style or security issue specific to a project or library. With a lot of linters, if they're even expandable, you'd have to struggle through their documentation, add the rule to a repo, and wait for it to be merged to take effect. Now this rule is being scanned for one language, for one project, and only for developers who are working on an up-to-date branch. With Semgrep and its extension, you can easily write a rule for multiple languages and, within seconds, have every developer across every project (or branch) get their code checked for that issue.
Remember, Semgrep isn't a linter; it's a SAST tool that can also scan for supply chain issues, secrets, and more. This means on top of the rules you write, we're also constantly writing and improving rules to detect the latest security risks, so if and when a dependency you use is compromised, we'll show you right in your editor where you're using it, and what versions are affected. No need to update your linter or rework your code during review time to use another dependency; you'll see it right there as you type, only if you use the dependency and only if you use it in a way that is affected by the vulnerability.
Oh, and for those who don't use VS Code, we've built all of this according to the Language Server Protocol specifications, so it should be pretty easy to hack together an extension for your editor in a day. Though, we are planning to support more editors in the future officially.
Hopefully, you see now why we're so excited about this; not only is using a SAST tool now as easy as using a linter, it's faster, customizable, extensible, and works everywhere, on everything, for everyone. Developers are now able to incorporate security concepts early in the development cycle, getting warnings long before they've even run or built their code, fixing security issues on a conceptual level, not as a workaround afterward.
Check out the extension on Visual Studio Marketplace here, and if you have any questions, feel free to let us know on GitHub or on our Community Slack.
