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 code security. The security team can't own it because they can't it; they can't change the code. And developers can't own it because they can't of it. They don't own the rules, the timelines, or the reports, so they own the result. Boris Karloff Karloff's Mummy owns impact take ownership can't 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. 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. Which 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 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. want SonarCloud latest versions of SonarQube

SonarSource

We build world-class Code Quality & Security tools: SonarQube, SonarLint and SonarCloud

2021 - HackerNoon Contributor of the Year - CYBERSECURITY

Write better code!

2021 - HackerNoon Contributor of the Year - SECURITY

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

SAST Analysis: No Angst Edition

Too Long; Didn't Read

Company Mentioned

SonarSource

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

SAST Analysis: No Angst Edition

Too Long; Didn't Read

Company Mentioned

SonarSource

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES