One significant concern revolves around Open Source License Obligations, a topic that deserves its own post to delve into in depth. Furthermore, it’s essential to address disclosed security vulnerabilities associated with these libraries.Traditionally, the mantra for many internal security teams has been to “run a vulnerability scanner and fix all ‘High’ and ‘Critical’ issues” when dealing with security problems in third-party libraries. However, this approach may prove impractical in fast-paced or large companies with a microservices architecture.

In a typical company that employs a microservices based architecture, there may be hundreds of microservices, each with a unique set of third-party open-source dependencies spanning a wide range of technology stacks. Monitoring these service-level third-party dependencies using popular scanners like Dependabot can lead to an influx of daily alerts. These alerts cover a spectrum of issues, from straightforward package version upgrades to complex dependency conflicts.

Most of these scanners assign a severity rating based on the Common Vulnerability Scoring System (CVSS), with Version 3 (CVSS V3) being the widely adopted standard at the time of this writing. However, crafting security policies and making decisions solely based on the CVSS score can lead to an overwhelming number of vulnerabilities to address. This can result in developers not taking these alerts seriously or struggling to manage them effectively.

Prioritising Vulnerabilities Detected by Scanners:

Vulnerability prioritisation is an essential process in modern cybersecurity that involves identifying and ranking security vulnerabilities based on their severity and potential impact on an organization’s systems and data. Prioritisation is crucial because it allows security teams to focus their limited resources on the most critical vulnerabilities, thereby reducing the overall risk to the organization.

Why Do we Need Vulnerability Prioritisation?

At present, the Common Vulnerability Scoring System (CVSS) serves as a widely embraced approach for evaluating the seriousness of security vulnerabilities. It assigns a numerical rating on a scale from 0 to 10 to gauge the potential impact of a vulnerability, taking into consideration factors such as the intricacy of the exploit and the potential consequences for the compromised system. Although the CVSS scoring system proves valuable for prioritising vulnerabilities, it does have certain constraints that limit its effectiveness when used in isolation.

To begin with, the CVSS scoring system relies on a set of predefined metrics, which may not fully capture the intricacies and repercussions of certain vulnerabilities. For instance, a vulnerability might receive a less severity rating according to the CVSS score, yet in reality, it could be a part of a more extensive attack sequence that might lead to a significant security breach.

Additionally, the CVSS scoring system primarily concentrates on technical aspects and does not factor in the business impact of a vulnerability. This can result in situations where vulnerabilities with substantial implications for business operations or critical data receive lower severity ratings than less impactful vulnerabilities.

Finally, the CVSS scoring system doesn’t incorporate the likelihood of a vulnerability being exploited in real-world scenarios. Vulnerabilities with low CVSS scores may still be actively targeted by malicious actors if there are no effective countermeasures in place or if the vulnerability is part of a widespread cyberattack campaign.

How Can We Achieve Vulnerability Prioritisation?

There are few crucial attributes to look at whenever we analyse a third party library security alert. Note that this can be extensively applied to other assets / systems. (containers, servers etc)

1. Is it a direct / transitive dependency?
2. Is it a runtime / Development Dependency ?
3. Is the vulnerable function from the affected dependency reachable by first party code?(Reachability Analysis)
4. What are the attack trends associated with the discovered vulnerability(PoC exploit available? etc) and how to prioritise based on such trends?
5. Is Patch Available / package abandoned by maintainer?

Is it a direct / transitive dependency?

Security vulnerabilities in your project’s / service’s direct dependencies should be given the highest priority. These are the libraries or packages you explicitly include in your project, and any vulnerabilities in them directly affect your code. Transitive dependencies are the libraries or packages that your direct dependencies rely on.While they are not directly part of your codebase, they can still pose a risk if they have known security issues.

Is it a runtime / Development Dependency ?

If you work in a typical company environment that was described earlier, you would know about 10’s of ReDOS vulnerability alerts that are marked as “High” on a day to day basis by these scanners . dependencies marked with “development” attribute  . DevDependencies often include things like testing frameworks, build tools, linters, and other development-related libraries or packages. These dependencies are essential for developers working on the project to ensure code quality, test functionality, and build the software, but they do not need to be installed or included in the final production deployment.

In contrast, “dependencies” (without the “dev” prefix) refer to the packages or libraries that a software project relies on for its normal operation during runtime. These are essential components of the software and must be installed and available when the software is used in production.

Runtime Dependency issues should be given the highest priority as its reachable / exposed to attackers when application is in production.

Tip: Dependabot has a rule which can be configured to auto dismiss low impactful alerts and can be enabled in security analysis settings.

Is the vulnerable function / code from the affected third party dependency reachable by first party code?(Reachability Analysis)

Next prioritisation attribute to look at is “Reachability” . Vulnerability can only be exploited by a threat actor if our first party code consumes vulnerable function from the third party library and is reachable to an external threat actor via any means. ( functionality on web etc). There are several Reachability analysis tools which are efficient & commercial for automated reachability analysis for better prioritisation. ( https://www.endorlabs.com/  & https://semgrep.dev/products/semgrep-supply-chain/ ) .

Vulnerabilities which are reachable by first party code should be given highest priority. If you plan to conduct manual reachability analysis, it’s crucial to recognize that this should be an ongoing, recurrent task. Even if there are currently no existing references for your analysis, it’s essential to acknowledge the potential for such references to emerge in the future. This looming possibility, often likened to a “ticking time bomb,” underscores the importance of not disregarding this task. Utilising automated reachability analysis tools is the recommended approach to address this concern effectively.

What are the attack trends associated with the discovered vulnerability(PoC exploit available?) and how to prioritise based on such trends?

Most of the alerts received by scanners has a CVSS score and CVE ID attached.As CVSS v3 do not take into account of attack trends , For effective prioritisation of vulnerabilities , it can be combined with metrics such as Exploit Predictability Score System ( EPSS ) and can be clubbed with other feeds such as CISA’s Known Exploited Vulnerabilities Catalog ( KEV).

Exploit Predictability Score System : (EPSS) (here)

One effective method of prioritisation is the use of an exploit predictability score system, which assigns a score to vulnerabilities based on the likelihood that they will be exploited by threat actors in next 30 days. The system works by analysing factors such as the availability of exploit code, the complexity of the vulnerability, and the popularity of the affected software or system. By using an exploit predictability score system to prioritise vulnerabilities, organisations can focus their efforts on addressing the most critical threats first. This approach allows security teams to efficiently allocate resources and remediate vulnerabilities before they are exploited, thereby reducing the risk of data breaches, downtime, and other security incidents.

CISA’s Known Exploited Vulnerabilities Catalog: (KEV)(here)

CISA’s Known Exploited Vulnerabilities Catalog is a public database maintained by the United States Cybersecurity and Infrastructure Security Agency (CISA). The catalog provides information on known vulnerabilities that have been exploited by cybercriminals, as well as information on the tactics, techniques, and procedures (TTPs) used in those attacks.The catalog contains a list of Common Vulnerabilities and Exposures (CVEs) that have been actively exploited by threat actors, along with information on the types of attacks and malware associated with each CVE. The catalog is regularly updated with new information as it becomes available, making it a valuable resource for security teams and other stakeholders.

The following Sample Prioritisation matrix can be used internally for better prioritisation of vulnerabilities combining CVSS V3 Severity , EPSS Score and KEV.

this matrix , assumes you are not using automated reachability analysis tools and are blinded by the “time bomb” scenario that was mentioned in the reachability part. Offering development teams a bit of extra buffer time for issue resolution would undoubtedly be appreciated. The prioritisation matrix can be tailored to align with your company’s preferences and risk tolerance

Example :

lets assume ‘P0‘ critical vulnerability in your third party library discovered via an alerting tool. and SLA to fix P0 is 48 hours , SLA to fix P1 is 72 hours ,SLA to fix P2 is 7 days , SLA to fix P3 is 15 days.

Without the above prioritisation ,final priority would be “P0” Developers need to fix this issue within 48 hours. considering the above prioritisation , assuming EPSS score is < 0.088 and not reachable by first party code & also vulnerability is not available in KEV catalog, its final priority would be P3, buying 13 more days of time to fix .

Note : EPSS score (api), KEV catalog(here) details should be fetched every day as scores are updated everyday and can be used for reprioritisation of historical open alerts based on the changes. Reachability analysis should be done on recurring basis to make sure there are no new references after past analysis.

Why have we taken 0.088 as EPSS V3 score baseline?

As rightly highlighted here , the following baseline score was chosen. it can be modified as per companies risk appetite and availability of resources to fix the vulnerability .

Is Patch Available / package abandoned by maintainer?

Frequently, identified vulnerabilities lack an active patch, and, in more concerning cases, the maintainer has abandoned them. It is essential to give priority to alerts with available patches, but abandoned vulnerabilities should not be disregarded. They still represent potential threats, and their prioritization can be based on other attributes and the availability of potential workarounds. Considering an abandoned package as a risk, exploring the transition to an alternative package, or even taking on in-house maintenance can be viable steps in mitigating this risk.

References :

1. https://www.endorlabs.com/blog/epss-exploit-prediction-reachability-analysis
2. https://arxiv.org/pdf/2302.14172.pdf
3. https://www.first.org/epss/#
4. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

The post Open Source Vulnerability Management : Insights on Prioritisation appeared first on .