Common Rejection Reasons

Submitted SBOMs go through format validation and vulnerability analysis, and are rejected if they fall short of the criteria. Below are the rejection reasons that come up repeatedly in actual intake. Review them together with the Validation Checklist before submitting.

A rejection only ever means a format or completeness issue with the SBOM; fix it as described below and resubmit.

Rejection Reasons at a Glance

Representative Cases

Case 1: All PURLs missing from an installation-directory scan

A supplier scanned an installation directory lacking package manager metadata with syft dir:<install directory> and submitted an SBOM in which almost none of the components had a purl; nearly all vulnerability matches failed and the SBOM was rejected outright. When you scan a location without package manager metadata (package.json, go.mod, an RPM/DEB package DB, etc.), the tool cannot identify the ecosystem.

Change the scan target to a built image or the source code, and check the purl count right after generation. The verification commands are in the Validation Checklist.

Case 2: Transitive dependencies missing from a pre-build scan

If a project has several direct dependencies but the SBOM has fewer than 10 components in total, suspect missing transitive dependencies. A typical web application yields tens to hundreds of components once transitive dependencies are included. Completing the build first (npm install, mvn package, and the like) and then generating resolves this.

Case 3: A generation tool fills the top-level component name with a fixed value, colliding with another submission

A supplier submitted a CycloneDX SBOM generated with a manufacturer-provided SBOM generation tool, and it was rejected because the name collided with an SBOM for a different device that had already been registered. On inspection, this tool always fills metadata.component.name with the same fixed value, regardless of which device it scanned. SBOMs for other devices generated with the same tool keep producing that same value, so each one collides with whatever was registered first.

When using a tool like this, open the SBOM in a text editor and manually change the metadata.component.name value (CycloneDX) or the top-level name value (SPDX) to something that identifies the device before submitting.

Case 4: OS packages omitted and PURLs declared for a different distribution

The SBOM for a RHEL server product was generated against the application source tree only, so it was submitted without a single installed rpm package. On top of that, libraries bundled in the source were declared as Debian source packages, such as pkg:deb/debian/libpcap@1.1.1-2+squeeze1. The generating tool had used source file names as a clue and attached whichever Debian package ships a file of that name.

This type passes format validation. The purl points at a package that really exists, so matching succeeds and no error appears on screen. Yet the vulnerabilities reported belong to components unrelated to the real server, and upgrading the OS changes nothing in the result.

Scan the rootfs or image as delivered so that the OS packages are included, and declare libraries bundled in the source with their real versions. See the server delivery section of How to Generate an SBOM for the procedure.

Case 5: The distribution appeared in a query parameter instead of the namespace

For a server product running a self-built Linux distribution, the rpm package PURLs in its SBOM carried the distribution value as a query parameter after the question mark, e.g. pkg:rpm/bind@9.11.36?distro=customdistro-1.0. The tool had identified the distribution, but recorded it in the auxiliary-info slot instead of the required namespace.

That value is not used for vulnerability matching, so the entire set of rpm packages for that server failed to match and the SBOM was rejected. Move the distribution value into the path (between the type and the package name) and regenerate as pkg:rpm/<distribution>/bind@9.11.36.

What a Passing SBOM Looks Like

Download the example file that meets the acceptance criteria and compare its structure. Every component has a purl and a version, and the dependencies array captures both direct and transitive relationships.

• Download the example SBOM (CycloneDX 1.6 JSON)

Related Documents

• Validation Checklist: Pre-submission checks and verification commands
• Submission Requirements: Required data fields and PURL rules
• Submission Process: The remediation and resubmission process after a rejection