Developer-led Security: Hotspots Continue To Maintain Engagement
Author profile picture


We construct world-class Code Quality & Security instruments: SonarQube, SonarLint and SonarCloud

I’ve mentioned earlier than that correct evaluation and the killing of the noise are the keys to developer-led safety. As a problem of credibility, builders should know that once we increase a Vulnerability problem, there is one thing to repair.

But there’s one other class of safety points, a category that may by no means be clear-cut. Each problem on this class has a 50/50 likelihood of being an actual Vulnerability or of being no large deal in any respect. At SonarSource, our SAST mission is to eradicate false positives however we will not merely ignore this class as a result of these points can symbolize actual vulnerabilities and our objective is to supply a whole SAST providing. 

Of course, we by no means need to merely dump all the pieces on builders and depart them to type it out. So we have segregated these points into what we name Security Hotspots. And we see this separation as key to retaining credibility and preserving builders engaged within the SAST course of. 

I’ve talked earlier than about what sorts of issues fall into the Security Hotspot class. One good instance is the usage of a weak hashing algorithm (i.e. one which’s too simple to reverse). It’s simple for SAST evaluation to identify the usage of a weak algorithm. What’s more durable is realizing if the worth being hashed should be better-protected. For occasion, if the worth I’m hashing accommodates your bank card quantity, CVV, and expiration date… properly it is clearly an issue to make use of a weak algorithm. But if as an alternative that worth accommodates your favourite milkshake taste (double peanut butter, please!) then there isn’t any problem. Knowing the distinction? Well, that takes a human. 

Once we get that human concerned – ideally the developer who wrote the code – we need to make sure that there isn’t any notion that we’re crying wolf. So we have constructed a completely separate interface for reviewing Security Hotspots. That does a pair issues. First, it takes you out of the context of Vulnerabilities and takes the sting out having one thing security-related raised in your code. Instead of presenting it as “There’s something broken and you have to fix it!” it is extra like “Hey, can you take a look at this?” After all, it isn’t what you say, it is the way you say it, proper?

The different factor having a separate interface permits us to do is current the Security Hotspot within the context of the background info builders must assess whether or not or not there’s really an issue, and what the implications may very well be. If there’s not, it is simple to dismiss the Security Hotspot you are on and transfer robotically to the following one. If there’s a downside, or should you’re unsure, then you’ll be able to assign it for fixing or additional overview.

Security Hotspots are a brand new idea within the SAST world, and we imagine they’re an necessary a part of shifting the general SAST paradigm. We know that sustaining engagement is vital to creating developer-led code safety work, and our technique for that is two-pronged: reduce False Positives amongst true Vulnerabilities, and correctly label and route Security Hotspots. 

It could be nice if SAST evaluation may inform the distinction between bank card data and milkshake flavors so we may eradicate the Security Hotspot class altogether. But similar to sports activities wants referees, Security Hotspots want builders to make the decision. At least as a developer, you get to referee your personal code.

Previously printed at


Join Hacker Noon

Create your free account to unlock your customized studying expertise.