Managing Open Source 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: