What is an open source vulnerability?
An open source vulnerability is a weakness that can be exploited to gain unauthorized access to a system or network to cause damage or manipulate it in some way. Vulnerabilities are not intentional but can leave a system vulnerable to attack.
Two things typically cause a vulnerability:
-
Oversights from developers.
-
Programming errors.
Vulnerabilities don’t only affect developers unwittingly using compromised components. They also place customers using compromised software at a heightened risk of a data breach or supply chain attack. These zero-day exploits are called a Common Vulnerability Exposure (CVE).
Are open source vulnerabilities and cyber threats the same thing?
A vulnerability is not a cyber threat. While cybercriminals might leverage open source vulnerabilities in their attacks, vulnerabilities are not part of an intentional effort from the attacker.
How do I identify an open source vulnerability?
Once a vulnerability is publicly disclosed, it is assigned a Common Vulnerability Scoring System (CVSS) Score and added to several publicly available databases. The two best ways to identify vulnerabilities include
-
Generate a Software Bill of Materials (SBOM) for your application. This is a concise list of all the components in a project, including the ones brought in by direct dependencies. It can be used by some tools to look for vulnerabilities–or improve the accuracy of results–and makes it easier to identify if an application contains a vulnerability.
-
Check the application against data sources. Open source vulnerabilities get reported and aggregate by a number of different public and private databases.
It’s important to note that not all vulnerabilities receive public disclosure. Furthermore, disclosure is often delayed to give package maintainers time to patch the vulnerability before announcing a weakness in their users’ application security.
Software Composition Analysis (SCA) tools are a more comprehensive way to access proprietary vulnerability data without waiting for public disclosures.
How do I evaluate an open source vulnerability’s risk to my organization?
Vulnerabilities are constantly being discovered, and there is no blanket fix–each one is unique. A best practice is to decide which risks your organization can tolerate. When making an assessment, consider the following
Impact
How bad would it be if your organization’s application was attacked using the vulnerability?
Example: Any vulnerability that gives an attacker access to additional data is a big risk for an application that processes payments. But it might not be as risky on an application that only stores email addresses.
Exploitability
How easy is it to execute the vulnerability? Vulnerabilities that require more work to exploit are lower risk than those that are easy to take advantage of.
Aspects to consider:
-
Required permissions.
-
Level of access.
-
Overall complexity
Cost
Fixing a vulnerability takes money and a good amount of developers’ time. How expensive an open source vulnerability will be to address depends on how it can be remediated.
In many cases, the vulnerable component can be upgraded to a compatible patched version. When there isn’t a compatible version available, an organization will be forced to switch libraries or patch the components themselves. Both require a lot of work and resources that not everyone has.
Is there an easy way to assess open source vulnerabilities?
The simplest way to stay on top of identifying vulnerabilities that affect your applications is to automate the process as much as possible.
Best practices include:
-
Using SBOMs.
-
Creating groups of applications based on their various risk tolerance levels.
If both practices above are in place, it’s possible to efficiently assess a vulnerability’s risk by checking the SBOMs for application groups that require remediation. This eliminates wasting time and resources manually checking each application to determine if they need remediation.