Vulnerability Detection in Imported SBOMs

Overview

When you import an SBOM into FOSSA, the system attempts to identify vulnerabilities for each package it contains. The matching method (and the confidence of the result) depends on what identifiers the SBOM provides.

CPE-based matching

A CPE (Common Platform Enumeration) is a standardized identifier for software components, defined by NIST. SBOMs may include CPEs to describe packages. When FOSSA encounters a CPE during import, it attempts to match the package against its vulnerability database using that identifier.

Because CPEs allow wildcards (*) in fields like OS, ecosystem, and version range, they offer variable precision. A CPE with specific version information produces tighter matches than one with wildcards. FOSSA cannot independently verify the accuracy of a user-provided CPE.

Learn more about the CPE specification at NIST's Security Content Automation Protocol.

How CPE-matched vulnerabilities appear

Issues identified through CPE matching are flagged as Unverified throughout the Security Issues page. The tooltip on the badge reads: "This vulnerability was identified based on a CPE with limited context in the SBOM and could not be verified by FOSSA."

When you open the issue drawer for an Unverified issue, a banner confirms the source: "This vulnerability was supplied by the SBOM. Accuracy cannot be verified by FOSSA's analysis."

Unverified issues should be reviewed with this context in mind. The vulnerability may or may not apply to the specific package version in your project.

Why CPEs resolve poorly

CPE-based matching is inherently imprecise for several reasons:

Wildcard fields. The CPE format allows * in place of specific values for fields like version, product, and vendor. A CPE of cpe:2.3:a:vendor:product:*:... means "any version", so FOSSA cannot determine whether the specific version in your project is actually affected and must treat all matching vulnerabilities as candidates rather than confirmed hits.

No ecosystem context. A CPE doesn't encode which package registry a dependency comes from. When an SBOM entry has a CPE but no locator that FOSSA can resolve to a known ecosystem, FOSSA falls back to the broadest available CVE dataset (Debian) to attempt version range comparisons. This means a Python, npm, or Go package may be compared against Linux system package vulnerability ranges, producing both false positives and false negatives.

Vendor and product name mismatches. CPE vendor and product fields often don't align with package registry names. For example, cpe:2.3:a:apache:log4j:2.14.1 refers to the same library as Maven's org.apache.logging.log4j:log4j-core, but FOSSA has to resolve that mapping heuristically rather than by exact lookup.

Version range epoch stripping. Some ecosystems encode version epochs (e.g. 1:2.14.1-1) in their CVE data. When FOSSA compares a CPE-sourced version against these ranges, it strips epoch tokens to make the comparison possible, which can cause matches to be missed or overapplied.

Using PURLs for more accurate matching

A PURL (Package URL) eliminates all of these issues. PURLs encode the ecosystem, package name, and exact version in a standardised format, for example, pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1 or pkg:npm/lodash@4.17.11. This gives FOSSA an unambiguous identifier to match directly against its vulnerability database without fallback heuristics, wildcard handling, or ecosystem guesswork.

When your SBOM contains PURLs, FOSSA resolves each dependency to a precise locator and applies the same high-confidence vulnerability matching it uses for CLI-analyzed projects. Issues found this way are not marked Unverified.

To generate an SBOM with accurate PURLs automatically, integrate your codebase with FOSSA and use the CLI to produce the SBOM rather than importing a hand-authored one.