Developer-led Security: Hotspots Continue To Maintain Engagement

I've said before that accurate analysis and the killing of the noise are the keys to developer-led security. As an issue of credibility, developers have to know that when we raise a Vulnerability issue, there is something to fix.

But there's another class of security issues, a class that can never be clear-cut. Each issue in this class has a 50/50 chance of being a real Vulnerability or of being no big deal at all. At SonarSource, our SAST mission is to eliminate false positives but we can't simply ignore this class because these issues can represent real vulnerabilities and our goal is to provide a complete SAST offering. 

Of course, we never want to simply dump everything on developers and leave them to sort it out. So we've segregated these issues into what we call Security Hotspots. And we see this separation as key to retaining credibility and keeping developers engaged in the SAST process. 

I've talked before about what kinds of things fall into the Security Hotspot class. One good example is the use of a weak hashing algorithm (i.e. one that's too easy to reverse). It's easy for SAST analysis to spot the use of a weak algorithm. What's harder is knowing if the value being hashed ought to be better-protected. For instance, if the value I'm hashing contains your credit card number, CVV, and expiration date… well it's obviously a problem to use a weak algorithm. But if instead that value contains your favorite milkshake flavor (double peanut butter, please!) then there's no issue. Knowing the difference? Well, that takes a human. 

Once we get that human involved - ideally the developer who wrote the code - we want to make sure there's no perception that we're crying wolf. So we've built an entirely separate interface for reviewing Security Hotspots. That does a couple things. First, it takes you out of the context of Vulnerabilities and takes the sting out having something security-related raised on your code. Instead of presenting it as "There's something broken and you have to fix it!" it's more like "Hey, can you take a look at this?" After all, it's not what you say, it's how you say it, right?

The other thing having a separate interface allows us to do is present the Security Hotspot in the context of the background information developers need to assess whether or not there's actually a problem, and what the consequences could be. If there's not, it's easy to dismiss the Security Hotspot you're on and move automatically to the next one. If there is a problem, or if you're not sure, then you can assign it for fixing or further review.

Security Hotspots are a new concept in the SAST world, and we believe they're an important part of shifting the overall SAST paradigm. We know that maintaining engagement is key to making developer-led code security work, and our strategy for this is two-pronged: minimize False Positives among true Vulnerabilities, and properly label and route Security Hotspots. 

It would be great if SAST analysis could tell the difference between credit card info and milkshake flavors so we could eliminate the Security Hotspot category altogether. But just like sports needs referees, Security Hotspots need developers to make the call. At least as a developer, you get to referee your own code.