SAST Analysis: No Angst Edition

In 2008 SonarSource upended the static analysis market for code quality and reliability. Today it's doing it again for code security.

When SonarSource was founded in 2008, code quality was the realm of specialists, who typically reported their results just before production deployment, weeks or months after the code was written. Inevitably, by then the authors had moved on to other things - mentally if not physically - and getting anything fixed was a contest of wills. Fast-forward to today, and you find that most teams have integrated static analysis from the first keystroke, starting with SonarLint in the IDE and moving forward with SonarQube and SonarCloud in the CI/CD workflow.

With code quality and reliability integrated into the development workflow, the bad-old-days of specialist-owned, quarterly analysis may seem as quaintly horrific as an old  film. But in the realm of security analysis, much like , that paradigm has so far refused to die. Today most SAST (Static Application Security Testing) tools are still owned and run outside the development team. Results are delivered intermittently, and if the past is a guide, no one really owns code security. The security team can't own it because they can't impact it; they can't change the code. And developers can't own it because they can't take ownership of it. They don't own the rules, the timelines, or the reports, so they can't own the result. 

Fortunately, you have the tools in hand today to break that pattern and shift code security - like code quality and reliability - to developers. With the SonarSource model:

SAST is integrated into the development workflow by making it part of the tools developers already use: SonarQube and SonarCloud analysis.That means quick security feedback, and - because the code is still fresh in mind - efficient, effective fixes.Giving developers control of SAST tooling lets them take ownership of code security, so pushback turns into pride of workmanship.

Those are the changes that are visible on the surface. But making this work - making sure developers accept, respect, and act on SAST feedback - means a more fundamental shift. It's not enough to change how, and when issues are raised. Which issues are raised has to change too. Most SAST tools raise issues for everything even remotely suspicious and let the auditors sort it out. But developer-led security won't work that way. Developers simply don't have the time or the patience for false positives. 

At SonarSource, we know all about killing False Positives. It's been our mission for years now, first with Bugs and Code Smells and now with Vulnerabilities too. In fact, earlier this year we acquired RIPS Technologies for access to their SAST engine. Our own SAST analysis was already pretty good, but with the addition of RIPS, it's even more precise. 

But it's not just about technology; the underlying philosophy has to change too. I'll write more on that next time and leave you with this: Good developers want to write good (and secure!) code. Let them know they already have the tools to do that -  and the  - and all you have to do next is just get out of the way.