Understand data sources and update frequency
Our SBOM vulnerability management product integrates data from multiple sources to ensure you have the most comprehensive and up-to-date information, including frequency of updates. By integrating these sources, our SBOM vulnerability management product ensures you are well-equipped to manage and mitigate risks effectively.
How often is data updated?
| Action | Updated |
|---|---|
Data ingestion | Daily |
Continual monitoring | Every 2 hours |
What data sources does Helm use?
Each vulnerability in Helm shows what data source or sources it was pulled from. Links are provided to the original CVE, as well as to exploitability and threat information.
National Vulnerability Database (NVD)
The National Vulnerability Database (NVD) is the world’s most comprehensive repository of publicly available vulnerability management data. Maintained by the National Institute of Standards and Technology (NIST), the NVD is built on the foundational work of MITRE and other leading cybersecurity entities. The database catalogs vulnerabilities identified as Common Vulnerabilities and Exposures (CVE), offering detailed information on over 100k documented CVEs, reaching back to the 1990s. The NVD not only provides vital intelligence on software flaws and misconfigurations but also includes crucial metadata such as severity scores, impact and exploitability metrics, and remediation steps, making it an indispensable resource for cybersecurity professionals.
You can easily see which vulnerabilities come from the NVD via the NVD badge indicator in the Source column.
AI co-pilot
In response to the NVD backlog, MedISAO, in collaboration with Medcrypt, has experimented with an AI copilot that leverages Large Language Models (LLMs) to process vulnerabilities, showing promising results. This strategy aims to bridge the gap until NVD and CISA resolve their backlogs.
This system constructs CPE product and version match data to ensure rapid and continuous and continuous vulnerability enrichment.
This AI copilot pulls information from vulnerability databases like NVD, MITRE, and other external sources to stay up-to-date and continuously update vulnerability information.
AI copilot data sources and updates
This AI copilot pulls information from vulnerability databases like NVD, CISA, CVE.org, MITRE, and other external sources to stay up-to-date and continuously update vulnerability information.
CVE.org integration
We are currently adding CVE.org as a data source, and this support should be available in an upcoming release. CVE.org provides a list of publicly disclosed cybersecurity vulnerabilities, each assigned a unique CVE ID. With over 230,000 CVEs identified, defined, and catalogued, CVE.org partners with community members worldwide to grow CVE content. CVE.org has now been tasked with enriching CVEs in the NVD with CPE information to handle the backlog.
Support and integration
Supported by Helm, Medcrypt’s vulnerability management tool, this AI-driven approach uses historical data and a custom grammar parser to minimize inaccuracies and increase reliability. This AI copilot’s output mirrors the NVD data feed, allowing tools compatible with the NVD feed to seamlessly utilize enriched data.
How often is the NVD data feed updated?
This feed is updated daily and is available to MedISAO members and partners. It has thus far analyzed thousands more vulnerabilities than the NVD or CISA and integrated into Medcrypt's Helm product, enabling more enhanced vulnerability identification.
CVE.org
We are currently adding CVE.org as a data source and this support should be in an upcoming release.
CVE.org provides a list of publicly disclosed cybersecurity vulnerabilities, each assigned a unique CVE ID. It currently has over 230K CVEs identified, defined, and catalogued. It partners with community members worldwide to grow CVE content. CVE.org has now been tasked with enriching CVEs in the NVD with CPE information, to handle the backlog.
Private vulnerability repository
This feature is currently being developed and is expected in an upcoming release.
You can add, track, remediate, and resolve private vulnerabilities from other sources such as penetration testing or threat modeling in Helm. These vulnerabilities are identified and reported privately by organizations and cybersecurity firms, and often include zero-day vulnerabilities and proprietary software issues.
The three primary use cases for private vulnerabilities are for organizations:
Tracking vulnerabilities in internally-developed components, whether unique to one product or that spans multiple products across the organization
Documenting security research on an issue before deciding whether to disclose it publicly
Using unmanaged data sources to identify vulnerabilities, such as change logs, commit logs, issue trackers, and social media posts, among others.
Exploit Database (ExploitDB)
Exploit Database (ExploitDB) is an archive of public exploits and corresponding vulnerable software, providing insights into how vulnerabilities can be exploited. ExploitDB provides information on active exploits as well as Metasploits, which are hacker toolkits that less technical users can leverage to exploit a vulnerability. Each vulnerability in Helm provides information on its exploitability and threats, and which source that information was retrieved from.
Any active exploit retrieved from this database will show either an ExploitDB badge or Metasploit badge, depending on whether it is just an active exploit or whether there is a Metasploit toolkit. Additionally, you can view the impact of each vulnerability, which shows all known exploits and threats and provides links to the original source details.
Exploit Prediction Scoring System (EPSS)
The Exploit Prediction Scoring System (EPSS) is a data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild. They aim to assist companies to better prioritize vulnerability remediation efforts. While other industry standards have been useful for capturing innate characteristics of a vulnerability and provide measures of severity, they are limited in their ability to assess threat. EPSS fills that gap because it uses current threat information from CVE and real-world exploit data. The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.
Helm provides EPSS scores for any vulnerabilities that have a CVSS v3 score, as only CVSS v3 vulnerabilities have been assessed using the EPSS methodology.
Top 25 CWE (Common Weakness Enumeration)
Top 25 CWE is a list of the most common, widespread, and impactful software weaknesses, which can be exploited by adversaries to steal data, take over a system, or prevent applications from working. and critical software weaknesses.
To create the 2023 CWE Top 25 list, the CWE Team leveraged Common Vulnerabilities and Exposures (CVE®) data found within the National Institute of Standards and Technology (NIST) U.S. National Vulnerability Database (NVD) and the Common Vulnerability Scoring System (CVSS) scores associated with each CVE Record, including a focus on CVE Records from the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) Catalog. A formula was applied to the data to score each weakness based on prevalence and severity. The Top 25 CWE list is maintained by the MITRE corporation.
Any vulnerability that is considered a top 25 CWE threat will show a Top CWE badge in Helm. You can also view more impact information in the vulnerability details, as well as review original sources.
CISA Known Exploited Vulnerabilities (KEV)
The CISA KEV catalog includes vulnerabilities known to be actively exploited in the wild.
For the benefit of the cybersecurity community and network defenders—and to help every organization better manage vulnerabilities and keep pace with threat activity—CISA maintains the authoritative source of vulnerabilities that have been exploited in the wild. Organizations should use the KEV catalog as an input to their vulnerability management prioritization framework.
Any vulnerability that is in the CISA KEV list will show a CISA KEV badge in Helm. You can also view more impact information in the vulnerability details, as well as review original sources.
Microsoft Knowledge Base (KB) catalog
The Microsoft KB update catalog includes patches and updates for Microsoft products, essential for tracking and managing vulnerabilities in Microsoft software. Microsoft provides a list of important, recommended, and optional updates that can be distributed over a corporate network. You can use it as a one-stop location for finding Microsoft software updates, drivers, and hotfixes.
Important updates provide significant benefits, such as improved security and reliability. Optional updates might include, for example, new or updated driver software for devices that you have added to your computer.
Any vulnerability that has a recommended patch update will show an available patch indicator. You will soon be able to view patch recommendations in the vulnerability details as well.
Tidelift
We have partnered with Tidelift and are in the process of integrating relevant open-source component data into Helm.
Tidelift provides security, maintenance, and licensing information for open source packages, ensuring dependencies are secure and well-maintained. It identifies current versions, as well as highlighting outdated or unstable components and recommending stable versions that will resolve vulnerabilities.
Tidelift also partners with open-source maintainers to implement industry-leading secure software development practices and commit to these practices so that organization can feel confident in the security of their open source components in their ecosystems both now and in the future.
Data source routing
Components often belong to one or more ecosystems. These ecosystems typically have one or more sources of truth that provide additional data about the components. For example, Maven Central and the NPM repository provide information about Java and Node components respectively.
Vulnerabilities can be identified through the use of three fields: CPE, PURL, and SWID. Helm supports PURL and CPE.
Package URL (PURL)
Helm supports Package URL (PURL) that provides a flexible way to represent metadata about components and their place in various ecosystems. PURL is supported by the CycloneDX SBOM specification.
Helm uses PURL in several ways:
Match components to identify vulnerabilities
Reduce false positives and false negatives
Identify outdated components across ecosystems
Supported package manager ecosystems
Helm natively supports several package managers natively and has extended ecosystem and package manager support for open-source components via our partnership with Tidelift.
| Language | Package manager | Package repository |
|---|---|---|
C# | NuGet | |
JavaScript | NPM | |
Python | PyPI | |
Rust | Cargo |
When does a PURL match get made?
For any vulnerability that was matched using a package manager, it will show the corresponding package manager name in its badge. If a dependency component is matched with a package manager badge, but also has a NOT IN NVD badge this means that Helm has identified your software in the package manager, but that no vulnerabilities have been reported in the NVD.
What is PURL used for?
PURL is recommended for use in identifying a container, library or framework (package), or operating system package.
PURL syntax
Package URL (PURL) standardizes how software package metadata is represented so that packages can universally be located regardless of what vendor, project, or ecosystem the packages belongs to. A PURL is an attempt to standardize existing approaches to reliably identify and locate software packages. It is a URL string used to identify and locate a software package in a mostly universal and uniform way across programming languages, package managers, packaging conventions, tools, APIs and databases.
As mentioned above, we currently support the following PURL package managers: Cargo, NPM, NuGet, and PyPI.
PURL format
A PURL is composed of 7 components:
scheme:type/namespace/name@version?qualifiers#subpath
The definition for each component is:
scheme: this is the URL scheme with the constant value of "pkg". One of the primary reason for this single scheme is to facilitate the future official registration of the "pkg" scheme for package URLs. Required.type: the package "type" or package "protocol" such as maven, npm, nuget, gem, pypi, etc. Required.namespace: some name prefix such as a Maven groupid, a Docker image owner, a GitHub user or organization. Optional and type-specific.name: the name of the package. Required.version: the version of the package. Optional.qualifiers: extra qualifying data for a package such as an OS, architecture, a distro, etc. Optional and type-specific.subpath: extra subpath within a package, relative to the package root. Optional.
Examples:
pkg:pypi/django@1.11.1pkg:nuget/EnterpriseLibrary.Common@6.0.1304pkg:npm/foobar@12.3.1
Common Platform Enumeration (CPE)
NIST defines CPE as a structured naming scheme for IT systems, software, and packages. It is based on the generic syntax for Uniform Resource Identifiers (URI) and includes a formal name format, a method for checking names against a system, and a description format for binding text and tests to a name. The CPE specification was designed for operating systems, applications, and hardware devices. It is maintained by the NVD.
When does a CPE match get made?
For any vulnerability that was matched using a CPE match, it will show a CPE badge. If a dependency component is matched with a CPE badge, that means that it has at least one vulnerability that has been reported in the NVD. A CPE is only assigned to software when a vulnerability has been reported in the NVD.
CPE syntax
CPE follows this format: cpe:<cpe_version>:<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>
cpe_version: This is the version of the CPE definition. As of this writing, the latest CPE definition version is 2.3.part: This can be one of three values: a for Applications, h for Hardware, o for Operating systems. It is sometimes referred to as type.vendor: This identifies the person or organization that manufactured or created this dependency component.product: This is the name of the system/package/component.version: This is the version of the system/package/component.update: This shows any update or service pack information, also known as minor versions.edition: This describes the build of the system/package/component beyond version.sw_edition(2.3 only): This indicates the language of the system/package/component, such as en-us for US English.target_sw(2.3 only): This indicates the language of the system/package/component, such as en-us for US English.target_hw(2.3 only): This indicates the language of the system/package/component, such as en-us for US English.other (2.3 only): This indicates the language of the system/package/component, such as en-us for US English.
CPE string examples
Application:
If the URI is cpe:/a:microsoft:office:2007:sp2:professional then the CPE string is:
cpe:2.3:a:microsoft:office:2007:sp2:-:*:professional:*:*:*
Operating system:
If the URI is
cpe:/o:microsoft:windows_7:-:sp1:x64 then the CPE string is:
cpe:2.3:o:microsoft:windows_7:-:sp1:-:*:*:*:x64:*
Hardware (not supported in an SBOM):
If the URI is cpe:/h:3com:3c13612 then the CPE string is:
cpe:2.3:h:3com:3c13612:-:*:*:*:*:*:*:*
What does a wildcard in a CPE string indicate? Anything that is a wildcard (*) means that no particular value was provided for that section, so it will encompass any applicable value in that section.
Last updated
