What a False Negative is and why it should be your primary criteria for a SAST tool

In our earlier post, we discussed False Positives and why having some of them is a good thing for your teams. This blog is about a term that is not as popular as False Positive, but is the reason security companies like ShiftLeft exist. The term is False Negative, which is one of my focus areas for the last few years. It is so central to security that experts take it for granted, but new-comers might miss it due to vendor’s focus on False Positives.

False Negative — Incorrectly indicating that a defect or a vulnerability doesn’t exist when it really exists.

It is extremely hard to build a security tool with limited resources to achieve a low False Negative or False Positive Rate. Per the OWASP Benchmark, great open-source linting tools such as fndsecbugs and pmd have a False Negative rate of over 60%. One of my hobby projects called “AppThreat” has a False Negative rate of over 50% even after 3 years of hard work. I regularly come across open-source projects that include the words “sec” or “grep” in the name with a False Negative rate of over 90%, yet have several thousand GitHub stars. In contrast, some commercial tools such as ShiftLeft CORE have a False Negative rate of 0% (with the corresponding 100% True Positive Rate) for the OWASP Benchmark and many other projects.

So, why is building an open-source security tool with a low False Negative rate really hard? After all, we have some great projects such as Linux and even CNCF backed projects that are fairly large and complex. I observed a few reasons for this.

Need for a large corpus of data

Let’s say an open-source tool developer is implementing a security rule to detect remote code execution. Remote code execution is possible when an attacker controlled input reaches a method that can execute commands without any validation or sanitization. The input or the entry point is commonly referred to as the source and the exit as the sink. Now the developer has to have a list of all possible sources and all possible sinks that can lead to command execution. For ecosystems such as npm, pypi or even go where new packages are constantly created and readily adopted, this developer and the tool should now have a steady corpus of data for sources and sinks. How would you create, store and maintain this data? It’s difficult for open-source linting tools to keep their tools updated with this third-party package information. Open-source tools often only track built-in functions and standard libraries.

Let’s take a look at gosec, a popular linting tool for golang.

Gosec can only detect command injection when a code uses the following 7 sink methods

gosec/subproc.go at master · securego/gosec

rule.Add(“os/exec”, “Command”)

rule.Add(“os/exec”, “CommandContext”)

rule.Add(“syscall”, “Exec”)

rule.Add(“syscall”, “ForkExec”)

rule.Add(“syscall”, “StartProcess”)

rule.Add(“golang.org/x/sys/execabs”, “Command”)

rule.Add(“golang.org/x/sys/execabs”, “CommandContext”)

A new upcoming tool called gokart can just detect a single method as shown:

gokart/cmdi.go at main · praetorian-inc/gokart

“os/exec”: {“Command”, “CommandContext”}

Bandit for python has a slightly longer list with over 30 sink methods. However, being a linting tool it reports every use of those execute methods as a vulnerability, which leads to excess false positives.

bandit/injection_shell.py at master · PyCQA/bandit

In contrast, a commercial platform like ShiftLeft could detect RCE with several more sink methods. For languages like node.js in fact there are over 100s of ways of executing a command thanks to npm packages. Our knowledge graphs and vulnerability database is constantly refreshed and kept updated with a semi-automated annotation process.

By simply looking at the source, we can identify the limitations of tools such as gosec, njsscan, which limit their focus to a small subset of builtin-methods. Even when the tools use a grep based engine, the rules are often not comprehensive enough. I found that an android static analysis tool called mobsfscan only contains two method names to detect deserialization vulnerability which is definitely not comprehensive. For instance, it cannot detect deserialization due to the use of xstream package.

mobsfscan/mobsfscan/rules/semgrep/deserialization at main · MobSF/mobsfscan

Need for skills

Building a code analysis tool that doesn’t suck requires the following skills.

• Code parser and code science background: The ability to correctly parse code to construct various aspects such as the syntax, call flows, dependency flows, and finally data flows and to ensure that everything including inter-procedural and inter-modular tracking can operate at scale
• Application security background: Identifying patterns and constructs that lead to vulnerabilities and chaining of constructs and patterns to identify new vulnerabilities and successful exploits
• Secure development experience at various levels: startup, large enterprises, dealing with monolith and monorepo mess
• Secure DevOps and IT experience to make the tool easy to integrate with CI/CD and workflows
• Project management: Ability to get the tool to the right audience (important even for free open-source tools); offering support and gathering feedback continuously

Tool developers with limited experience in building code parsers and analyzers often resort to easy techniques such as using a grep tool or simple Abstract Syntax Tree (AST) parsing, which cannot operate at inter-procedural or inter-modular level. Tools such as findsecbugs, njsscan and even gosec rely heavily on AST and therefore suffer from this weakness. Projects such as gokart or pysa improve the analysis by implementing a technique called Taint-analysis. This level 2 approach could yield better results with lower False Positives. However, to reduce False Negatives one needs a level 4 analysis, such as data-flow analysis that spans across custom code, SDK and third-party libraries.

Lastly, great developers might not be adept at marketing and supporting their project. Users often cannot discover tools that are not spoken about in developer and AppSec communities.

In a commercial organization like ShiftLeft, there are teams of people with specific expertise such as Code Scientists, Application Security Engineers, Full-stack Engineers, Sales Engineers and Marketing professionals. All complement each other to produce the best code analysis platform. Further, you could have teams who are solely focused on a specific language, such as Go or C#, or a specific kind of analysis such as Software Composition Analysis (SCA) or even detecting injection vulnerabilities.

Open-source security tools and even some commercial tools built by teams that do not have all such skill sets might exhibit some weakness in the end-to-end experience. Inexperienced developers without enterprise development background might misclassify the severity of vulnerabilities and consider every finding produced by their tool as a CRITICAL vulnerability. Aside from prioritization, there can be other usability issues. Top application security professionals may not have the time to learn and maintain an open-source tool. Often, we see a bespoke PoC repo on GitHub for a specific exploit or a CVE, but that’s it. Commercial tools supported by marketing and customer-facing teams can incorporate user feedback that improves a tool’s experience, so it can be used repeatedly as part of a program.

Need for balancing security with developer productivity

Security is a continuous process that requires a dedicated partner during your journey. Using a free tool with known False Negatives problems could result in far fewer findings. This would help developers spend less time on security issues, but also expose your application to unnecessary risk that comes with undiscovered vulnerabilities. There is a need to balance security with productivity. From my experience, when introducing AppSec tools or DevSecOps culture, it is fine to tilt the processes towards productivity initially. This would help reduce the friction and anxiety associated with introducing a new tool and/or processes. But remember this is borrowed time. What you don’t know can hurt you, your customers, or undermine the service you are busy trying to build. As the teams mature, it is then essential to tilt and favor security, reducing any security debt over time. Commercial tools such as ShiftLeft are purpose built for such a phased rollout, and therefore would make an ideal choice if you are just getting started with your AppSec or DecSecOps program or even considering replacing your legacy code analysis fortresses.

Need for ongoing support

Did you know that open-source projects and open-source developers are not free? By using any open-source tool (even AppThreat) there is a trust that the user of the tool would contribute back to the project in terms of bug reports, pull requests, social media marketing and even financially. Clicking a GitHub star is unfortunately not a contribution. Open-source tools could become unmaintained and even unavailable at a very short notice if the developers and contributors do not feel rewarded or appreciated by the users and the community. Unmotivated developers are not going to actively reduce the False Negative and False Positive rate of their projects. In contrast, any commercial tool is always benchmarked by prospective users and even competitors. Nearly every week I work with prospects who usually compare ShiftLeft with other tools during evaluation. There is a continuous feedback loop and our commercial platform is always improved.

Closing thoughts

It is essential that security leaders and security champions start thinking about False Negatives, which is far more serious than False Positives (which are more like an inconvenience) during the evaluation. Any DevSecOps or AppSec program requires a trusted commercial partner to increase the likelihood of success and to reduce risk. Adopting an open-source tool with no commercial support is nice, but is risky more than anything else.

To discuss further about false positives and false negatives, please join my upcoming webinar.

---

What a False Negative is and why it should be your primary criteria for a SAST tool was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Prabhu Subramanian. Read the original post at: https://blog.shiftleft.io/what-a-false-negative-is-and-why-it-should-be-your-primary-criteria-for-a-sast-tool-1a735ef7073c?source=rss----86a4f941c7da---4