Sonatype

What is Component Security Risk?


What is Security Risk?

When you think about risk from open source components, security risks are probably what come to mind. Security risks are flaws or intentionally malicious behavior in an open source component that allow hackers to misuse or abuse your application. This is a broad category of risk that includes getting unauthorized access to data, installing or running additional code, or disrupting the normal operation of your application. All this can result in financial loss, damaged reputation, and harm to users. 

There are two main categories of security risks from open source components:

Vulnerabilities – These are typically caused by oversights from the developers or programming errors. These vulnerabilities are not intentional but can leave your system vulnerable to attack. Some prominent examples include Log4j, the Apache Struts vulnerability used in the Equifax hack, and Heartbleed

Malware – These are components masquerading as functional OSS packages that are designed to gain access to your systems. Examples include the SolarWinds exploit and dependency confusion attacks

Security risks are fairly common. Most open source developers aren’t cybersecurity experts and are focused on making the best tool they can in their spare time. Tracking and managing the potential security risks from your open source components is one of the inherent costs of using open source packages. Learning to manage risk from your open source packages is a key step in protecting your business and delivering high-quality products. 

Identifying Security Risk

There are many ways to find security risks. Once a security vulnerability is publicly disclosed, it is assigned a Common Vulnerability Scoring System (CVSS) Score and added to several publicly available databases. The CVSS Score uses several metrics to determine the severity of a vulnerability, which makes the system easy to use and understand. To formulate a process for identifying security vulnerabilities, we suggest the following steps:

  1. Generate a Software Bill of Materials (SBOM) for your application. This is a concise list of all the components in your project, including the ones brought in by your direct dependencies. It can be used by some tools to look for vulnerabilities or improve the accuracy of results. The SBOM makes it easier to identify if an application contains a vulnerability and has benefits beyond vulnerability reporting. 
  2. Check your application against your data sources. Security risks get reported and aggregated by a number of different public and private databases, and your results can vary dramatically based on which sources you use.

One of the biggest values of Software Composition Analysis (SCA) tools like Nexus Lifecycle is access to proprietary vulnerability data, which is more comprehensive than the public disclosures. This is because not all vulnerabilities receive a public disclosure, and many that are publicly disclosed have been known for some time before being announced. Usually the delay is to give the package maintainers a chance to patch the vulnerability before announcing a weakness in their users’ application security. 

Automating vulnerability discovery is a key step to actively managing your risk from open source components. SCA tools include APIs and integrations with common build systems, and there are several open source tools that can be run as part of your build process to alert you to public disclosures. Even with automated discovery, keeping up with all the new disclosures can be a challenge. Creating alerts for specific threat levels and risk categories can make securing your applications simpler and faster and keep you safer through proactive management. 

Last, get involved with the open source projects you rely on. Vulnerability disclosures are often released to package maintainers before the general public, which can keep you ahead of the curve while patching the projects you consume. This will reduce tech debt by limiting the number of internal forks your teams need to maintain. 

Evaluating a Component’s Risk to You

Security vulnerabilities are constantly being discovered, and each one is unique. If you tried to fix each one on every application, you’d never find time to write your own code. So you’ll need to decide which risks you can tolerate and which risks you can’t. When assessing a security vulnerability in your application, you need to consider the following criteria:

Impact – How bad would it be if this application was attacked using the vulnerability? A vulnerability that gives an attacker access to additional data is a big risk for an application that processes payments but might not be a big risk on an application that only stores email addresses. 

Exploitability – How easy is it to execute the vulnerability? Consider the required permissions, level of access, and complexity. Vulnerabilities that require more work to exploit are lower risk than vulnerabilities that are easy to exploit. 

Cost – Fixing vulnerabilities takes developer time and money. This cost is variable depending on how the vulnerability can be remediated. In many cases, the vulnerable component can be upgraded to a compatible patched version. When there isn’t a compatible version, you’re faced with either switching libraries or patching the component yourself, both of which can be a lot of work. Patching the component can be especially expensive if you opt to maintain an internal fork of the component. 

A note on reachability: At Sonatype, we don’t think reachability is a great way to assess open source risk. Reachability focuses on determining if the attack vectors for an exploit can be accessed using your code to help prioritize security risks. The flaw here is that you can’t prove that the exploitable code hasn’t been called, even if it’s unreachable by normal means. Check out this blog to read more

To simplify the vulnerability-assessment process, we recommend creating groups of applications based on their various risk tolerance levels. When a vulnerability is disclosed, you can assess its risk, then check the SBOMs for the application groups that require remediation based on the severity. This is faster than manually checking each application and determining if it needs to be remediated.

Ultimately, your goal should be to automate this process as much as possible. Nexus Lifecycle is a powerful tool for tracking, assessing, and enforcing OSS governance policies at scale. Sonatype also offers several open source tools to help with assessing OSS risk, such as our OSS Index, a free catalog of open source vulnerability data, and several tools that can scan your applications using a REST API. 

5 1 vote
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments