Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Analyzing the DevOps and DevSecOps software marketplace demonstrates the high demand for tools and platforms that reduce false positives. As businesses and organizations adopt a rigorous, disciplined software development life cycle and ascribe to strict compliance frameworks, they quickly realize that automated tools can generate a substantial amount of noise, in the form of false positives, that pollute their efforts to maintain a lean and focused operation.
True Positive Vs. False Positive Vulnerabilities
Static application security testing (SAST) is fundamentally about using pattern recognition to identify vulnerabilities in code. The more aggressive the scan rules, the more likely a snippet of code will be flagged as a vulnerability; in other words, a “true positive” finding. Automated scanning is fundamental to effective DevSecOps. But if the scanning is too aggressive, it may generate findings that aren’t actual problems; in other words, false positive findings
You want your scan to return true positive findings—actual vulnerabilities that can be fixed and remediated. A false positive is a finding that isn’t actually a vulnerability. The ideal tool catches all the true positive vulnerabilities and returns a minimal number of false positives.
Many platforms give their users granular control over which rules run and are applied to their code. This first layer of control is similar to allowing your team to tune their scans to focus only on certain frequencies while ignoring others. Often, this is used to increase the speed with which a platform might complete a scan. It can also be used to tune out “noisy” rules. It’s perfectly legitimate to use controls like these, but it’s important to recognize that those completed scans aren’t comprehensive.
Speeding Up Can Slow You Down
Positive findings, whether they are true or false, take more time and resources to evaluate and remediate. Investing resources to remediate true positives is worthwhile. It would be ideal if they had been caught earlier in the process, but catching a vulnerability before it hits production is the entire reason you are doing DevSecOps in the first place! False positives may not require actual remediation, but reviewing them and then manually confirming their false nature is directly counterproductive to the reasons an organization adopted automated SAST in the first place.
SAST Plus DAST Keeps You Ahead
The gold standard for effective security testing is to pair SAST with dynamic application security testing (DAST), sometimes also called interactive application security testing (IAST). This process will correlate the positive findings from the SAST scans and test them using simulated data in an emulated runtime environment.
DAST/IAST actually tests each bit of code that looks problematic because of a particular pattern and then tests whether the code is actually vulnerable. DAST provides an automated, testable, repeatable and provable method to test those positive findings for trueness and falseness. If you are only doing SAST scanning, then the noise-to-signal ratio from your platform is governed strictly by the intelligence embedded into their pattern-matching code. Depending on the quality of the tool being used, your actual mileage may vary.
DevSecOps Is the Right Path
Businesses and organizations clearly understand the problem of potential vulnerabilities. Guarding against a security breach is critically important to protecting proprietary information and the privacy of their customers. DevSecOps is clearly the right path to take to reach that goal. However, it is critically important that the vehicle(s) these teams use to get there (in this case, SAST and DAST/IAST) have built-in functionality to focus their efforts on real problems and not waste it on phantom issues.
