Security Hotspots bring a new approach to C++ SAST
A lot of people associate Static Application Security Testing (SAST) with false positives, but it doesn't have to be that way. The fact is that there are really three classes of SAST issues: true positives, false positives, and what we call Security Hotspots. Security Hotspots are security-sensitive pieces of code that need human review because whether or not there's a Vulnerability depends on the context. At SonarSource, we make it our mission to stamp-out false positives. For the rest, we believe the answer is to clearly segregate true positives (Vulnerabilities) from the ones that need review (Security Hotspots) and give you the tools to evaluate and triage them.
If you've used SAST before, you know that it analyzes your source code to find mistakes like buffer overflows that can put your systems, your users, and your reputation at risk. SonarQube and SonarCloud detect such vulnerabilities for most POSIX functions and raise the issues directly to the developers best suited to handle them - the ones who touched the code last. For memory safety vulnerabilities, whether or not there's something to be fixed is pretty cut and dried: there is. But there's another class of issues SAST analyzers might raise. It's the class that makes developers wary of SAST: the issues that look like false positives - the ones raised on security sensitive pieces of code.
As an example, `strncpy` could result in a buffer overflow if any of these is true:
- There is a possibility that either the source or the destination pointers is null
- The security of your system can be compromised if dest is a truncated version of source
- The source buffer can be both non null-terminated and smaller than count
- The destination buffer can be smaller than count
- You expect dest to be a null-terminated string
- There is an overlap between source and destination
The problem here is that most of your uses of `strncpy` are probably just fine. But some of them might not be. If you're seeing Vulnerability issues raised on every use of the function, you and everyone else on the project is going to get desensitized pretty quickly. Eventually, you'll all start overlooking the clear-cut buffer overflow vulnerabilities because everyone sees the analyzer as always crying wolf.
The answer, as we see it, is to separate security-sensitive issues from true-positive Security Vulnerabilities. We call the new class Security Hotspots, and give you a dedicated interface for handling them in SonarQube. That way you know what to expect going in. It's clear that these aren't for-sure Vulnerabilities. They're pieces of security-sensitive code that need human review because they might be vulnerabilities, and they might not; you won't know until you look. Here's an example of a Security Hotspot presented in the dedicated review interface:
Hotspots are grouped by rule and rules are sorted by review priority (i.e. potential danger). In the main pane, you see the Hotspot in context, with guidance on how to assess the danger and simple controls for updating its status once you've reviewed it.
The first five Security Hotspot rules for C and C++ are available in SonarQube 8.4 and SonarCloud:
- S5816: Using “strncpy” or “wcsncpy” is security-sensitive
- S5815: Using “strncat” or “wcsncat” is security-sensitive
- S5814: Using “strcat” or “wcscat” is security-sensitive
- S5801: Using “strcpy” or “wcscpy” is security-sensitive
- S5824: Using “tmpnam”, “tmpnam_s” or “tmpnam_r” is security-sensitive
We feel that introducing the distinction between clear problems - Vulnerabilities - and potential problems - Security Hotspots - is the SAST innovation developers have sorely needed. Now you can face your analysis results with clear expectations about what you'll be getting and how you should deal with it. Fix the Vulnerabilities, review the Security Hotspots, and know that you're shipping more secure code as a result.