What is a vulnerability?

A vulnerability is a weakness or flaw in a system, application, hardware, or process that can be exploited by an attacker to cause damage or gain unauthorised access.

These weaknesses can arise due to design flaws, implementation defects, or inadequate security measures.

Vulnerabilities in dependencies and SBOMsCopy Anchor Link

Modern software projects often rely on third-party components and libraries, called dependencies.

These may contain vulnerabilities that, if not managed, compromise the security of the entire system.

By using SBOMs, organisations can identify which dependencies exist in their systems and address any vulnerabilities in them.

Common types of vulnerabilitiesCopy Anchor Link

There are several categories of vulnerabilities that commonly occur:

• Buffer Overflow: When a program writes more data to a buffer than it can handle, which can lead to execution of malicious code.

• SQL Injection: Input of malicious SQL code into an application's database queries, which can provide unauthorised access to data.

• Cross-Site Scripting (XSS): Injection of malicious script code on websites, which can affect users visiting the site.

• Insecure Deserialization: When an application deserializes data from untrusted sources, which can lead to execution of malicious code.

• Directory Traversal: Exploitation of vulnerabilities to gain access to files and directories outside the intended directory structure.

See the references below for a more comprehensive list of different types of vulnerabilities compiled by the OWASP organisation.

Assessment of vulnerability severity: CVSS and EPSSCopy Anchor Link

To effectively manage vulnerabilities, it is important to be able to assess their severity and likelihood of exploitation.

Two established systems for this are the Common Vulnerability Scoring System (CVSS) and the Exploit Prediction Scoring System (EPSS).

Common Vulnerability Scoring System (CVSS)Copy Anchor Link

CVSS is a standardised framework that provides a score between 0 and 10 based on the vulnerability's characteristics, such as how it can be exploited and its impact on the system's confidentiality, integrity, and availability.

This score helps organisations understand the vulnerability's potential impact and prioritise actions accordingly.

Exploit Prediction Scoring System (EPSS)Copy Anchor Link

EPSS is a system that uses machine learning and real-time data to predict the likelihood that a vulnerability will be exploited.

EPSS complements CVSS by providing insight into which vulnerabilities are most likely to be exploited in reality, helping to further prioritise actions.

CVSS says how severe a vulnerability is, EPSS how likely it is to be exploited. Together they give a better basis for prioritising than either one alone.

Known Exploited Vulnerabilities (KEV)Copy Anchor Link

A KEV list contains vulnerabilities that have demonstrably been exploited in real attacks. The most widely used is the catalogue from CISA in the United States. The EU vulnerability database EUVD has a corresponding view of known exploited vulnerabilities.

CVSS and EPSS are assessments. A KEV list is a statement of fact: the vulnerability is being exploited. That is why it is often used as the first sorting criterion. For manufacturers it also has legal significance, because the Cyber Resilience Act (CRA) requires actively exploited vulnerabilities in their own products to be reported within 24 hours.

Remedying vulnerabilities through patchesCopy Anchor Link

When a vulnerability is identified, it is important to quickly implement corrective measures, often in the form of patches or updates, to prevent potential attacks.

New vulnerabilities are discovered every day. Monitoring therefore has to be automated and continuous.

By automating this process, organisations can ensure that their systems remain protected against both known and newly discovered threats.

Threats and risks associated with vulnerabilitiesCopy Anchor Link

A threat is a potential event or actor that can exploit a vulnerability to cause harm to a system or organisation. It can be anything from a malicious hacker to malware.

A risk, on the other hand, represents the likelihood that a threat exploits a vulnerability and the potential impact it can have. Risk is assessed by analysing both the likelihood of exploitation and the consequences of such an event.

By understanding the relationship between vulnerabilities, threats, and risks, organisations can better prioritise their security efforts and resources.

Prioritisation and management of vulnerabilitiesCopy Anchor Link

Managing vulnerabilities effectively requires a structured method for identifying, assessing, and prioritising them.

By using tools such as SBOMs (Software Bill of Materials), organisations can get a detailed inventory of their software components and their dependencies, facilitating vulnerability management.

Prioritisation of vulnerabilitiesCopy Anchor Link

To ensure that the most critical vulnerabilities are addressed first, it is important to:

• Assess vulnerability severity: Use standardised frameworks such as CVSS (Common Vulnerability Scoring System) to quantify the vulnerability's potential impact.
• Evaluate likelihood of exploitation: Tools such as EPSS (Exploit Prediction Scoring System) help predict the likelihood that a vulnerability will be exploited within a certain timeframe.
• Analyse business impact: Consider how a vulnerability may affect business continuity, especially in systems that handle sensitive information or are business-critical.

Patch ManagementCopy Anchor Link

By updating software components regularly, known vulnerabilities are fixed before they are exploited.

Automated tools can monitor systems and identify which patches need to be applied, which reduces manual work and human error.

Connection between SBOM and specific environmentsCopy Anchor Link

SBOMs provide a detailed inventory of all components in software, including their versions. By having system support for linking SBOMs to specific environments, organisations can:

• Track components in different systems: Understand exactly which components exist in which environments, such as production or test environments.
• Prioritise actions based on environment: Vulnerabilities in production systems that handle sensitive information should be prioritised higher than those in test systems.
• Simplify compliance and reporting: Have a clear overview of software composition to facilitate audits and ensure compliance with regulations.

The above enables organisations to quickly respond to the critical questions that arise when new vulnerabilities are discovered:

• Are we affected?
• Which systems and environments are affected?
• Do we need to act immediately?

With SBOMs and structured patch management you can see which environments are exposed to a given vulnerability and in which order to fix them.

How are vulnerabilities managed and published?Copy Anchor Link

To understand how vulnerabilities are managed and published, it is important to know the different actors and steps in the process.

Below are important terms and how a vulnerability goes from discovery to publication and enrichment.

Important concepts in vulnerability managementCopy Anchor Link

• CVE (Common Vulnerabilities and Exposures): A unique identification system for known vulnerabilities in software and hardware.

  Each discovered vulnerability is assigned a CVE identifier, facilitating tracking and management of security issues.

• CNA (CVE Numbering Authorities): Organisations authorised to identify and assign CVE identifiers to vulnerabilities.

  These can be software vendors, research institutions, or other security organisations.

  When a vulnerability is discovered, it is reported to a relevant CNA, such as a software vendor or security organisation, which reviews the information and, if it meets the criteria, assigns a CVE identifier.

• NIST's role: The National Institute of Standards and Technology (NIST) is responsible for maintaining the National Vulnerability Database (NVD), a comprehensive database of known vulnerabilities.

  After a vulnerability has received a CVE identifier from a CNA, it is published in NVD. Here the vulnerability is enriched with additional information, such as CVSS scores (Common Vulnerability Scoring System), CWE categories (Common Weakness Enumeration), and CPE names (Common Platform Enumeration), helping organisations understand the vulnerability's severity and which systems are affected.

• Enrichment: After a vulnerability has been published in NVD, it undergoes an enrichment process where additional details are added.

  This includes assigning CVSS scores to assess the vulnerability's severity, categorizing the vulnerability with a CWE (Common Weakness Enumeration), and associating relevant CPE names (Common Platform Enumeration) to identify which products are affected.

  This process ensures that organisations have all the necessary information to manage the vulnerability effectively.

• CPE (Common Platform Enumeration): A standardised system for naming and identifying software and hardware products.

  By using CPE names, organisations can quickly determine if a specific product is affected by a vulnerability.

  It is important that CNAs include correct CPE names when reporting vulnerabilities to facilitate this process.

• CWE (Common Weakness Enumeration): A system for categorizing and identifying common types of weaknesses in software.

  By associating a vulnerability with a specific CWE category, organisations can better understand its nature and take appropriate action.

What does the process look like?Copy Anchor Link

1. Discovery and reporting: A security researcher, vendor, or other party identifies a potential vulnerability and reports it to a CNA, such as a software vendor or security organisation.
2. Review and CVE assignment: The CNA reviews the report and, if the vulnerability meets the criteria, assigns it a CVE identifier.
3. Publication in CVE database: When a CVE has been assigned, it is officially published in the CVE database, often without complete metadata.
4. Enrichment in NVD: NVD, maintained by NIST, retrieves CVE information and supplements it with additional data such as CVSS scores, CPE names, and CWE categories.
5. Availability to security teams: When the vulnerability has been enriched, it becomes more useful for security teams and organisations, making it possible to identify impact and take action.

Changes since 2024Copy Anchor Link

During 2024 NVD had problems with enrichment, and many vulnerabilities were published without complete metadata such as CVSS scores and CPE names. That made them harder to assess and to match against products. One consequence is that more CNAs now provide the information themselves when the vulnerability is reported.

In May 2025 ENISA launched the European Vulnerability Database, EUVD, established under the NIS2 Directive. It gathers vulnerability information from CSIRTs, vendors and the CVE programme, among others, and has views for critical vulnerabilities, known exploited vulnerabilities and vulnerabilities coordinated within the EU.

Package URL (purl) is used more and more alongside CPE to identify software packages. A purl states ecosystem, name and version in one string and pins down a package more precisely than a CPE name. Since December 2025 purl has been an Ecma standard, ECMA-427.