Managing Open Source Vulnerabilities
When you test your code, are you really testing all of it?
It seems impossible to write software without using open-source components. A single “import package” can mean thousands of lines of code added to an application. When you look at the software you’ve written, you’ll probably find that 80 to 90 percent of the code is written by someone else.
Since you did not write these open source components, you cannot control how they were written. That means that even if you’ve secured the code that you did write, a vulnerability in an open-source component can easily compromise the application. And although the first instinct might be to assume that these open-source packages are vetted and secure, doing so means completely ignoring the risks that they carry.
Supply Chain Attacks
You’ve probably heard of a “supply chain attack”.
A software supply chain is all the tools you need to make your software. Think: repositories, package managers, scripts for deployment, and open-source components. Supply chain attacks refer to attacks that target these tools or components. Dependency confusion vulnerabilities discovered by Alex Birsan a while ago are a type of supply chain attack. I highly recommend reading his blog about it:
Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies
Another type of supply chain attack is to exploit unpatched open-source vulnerabilities. Every piece of software has bugs and popular open-source packages are no exception. Attackers can find vulnerabilities in these open-source packages to compromise applications that rely on them.
And unfortunately, you can’t scan for these issues with your traditional static analysis tools since the imported components are not a part of your application’s codebase. Open-source software can be changed without notice, new CVEs in open source components are constantly being discovered, conditions that allow these vulnerabilities to be exploited in your application are also changing. This makes managing open-source vulnerabilities in your application a unique technical challenge.
Detecting Open-Source Security Vulnerabilities
This is where Software Composition Analysis (SCA) comes in. SCA are tools that scan an application’s open-source components for disclosed vulnerabilities. They work by first generating an inventory list of open source components that the application uses. It then scans public or private databases to find known vulnerabilities associated with the application's dependencies and report them back to you, the developer.
You might have noticed: does this mean that SCA tools do not discover vulnerabilities that are not registered in the database? The answer is, unfortunately, yes. Unlike static analysis tools, which scan your codebase for new vulnerabilities using pattern matching or data flow techniques, SCA tools only find vulnerabilities that are discovered and disclosed in the tool’s database. Although this feels dangerous, scanning all of an application’s open-source components using these techniques would be prohibitively time-consuming. So SCA tools focus on the known vulnerabilities that attackers are most likely to exploit instead.
Another issue that exists in SCA tools is that they tend to generate a lot of false positives. How often have you imported a dependency without using it? And even if you use the vulnerable component, is the vulnerability actually exploitable by attackers? Most of the time, SCA tools report any and all vulnerabilities that correspond with any imported packages. But this does not mean that these vulnerabilities are all exploitable. This is similar to how static analysis tools tend to generate false positives if they don’t consider the context of the potential vulnerability. One way to mitigate this issue is to focus on currently reachable vulnerabilities by combining traditional SCA with the concept of “reachability”.
In code analysis speak, a “source” is the code that allows a vulnerability to happen. Whereas a “sink” is where the vulnerability actually happens. Take command injection vulnerabilities, for example. A “source” in this case could be a function that takes in user input. Whereas the “sink” would be functions that execute system commands. If the untrusted user input can get from “source” to “sink” without proper sanitization or validation, there is a command injection vulnerability. Many common vulnerabilities can be identified by tracking this “data flow” from appropriate sources to corresponding sinks. Tracking data flow like this instead of relying solely on pattern matching helps static analysis tools drastically reduce the number of false positives in scan reports because the tool would not report potential vulnerabilities that are not “reachable” by malicious input.
Open-source vulnerabilities can be classified this way too. By tracking data flow from untrusted input locations to open source vulnerabilities, we can identify which open source vulnerabilities are actually triggerable.
ShiftLeft’s security platform ShiftLeft Core is equipped with an intelligent SCA tool that factors reachability into account. ShiftLeft CORE users report up to a 90% reduction in tickets using Intelligent SCA as compared to other SCA vendors. If you’re interested in learning more, visit us here: https://www.shiftleft.io/nextgen-static-analysis/.
Want to learn more about application security? Take our free OWASP top ten courses here: https://www.shiftleft.io/learn/.
Thanks for reading! What is the most challenging part of developing secure software for you? I’d love to know. Feel free to connect on Twitter @vickieli7.
Managing Open Source Vulnerabilities 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 Vickie Li. Read the original post at: https://blog.shiftleft.io/managing-open-source-vulnerabilities-7eeb94c02b00?source=rss----86a4f941c7da---4
