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.

Case 6: Every format check passed, and 642 PURLs still failed to match

A supplier submitted a CycloneDX SBOM with 8,129 components. Every component carried a purl, so coverage was 100%; there was no pkg:generic; and no OS package was missing its distribution. The file passed every checklist item and automated criterion in force at the time. Yet 642 of its 2,785 unique purls failed to match when the repositories were queried.

Three separate causes were mixed together.

• Missing namespace, 663 entries: identifiers such as pkg:maven/org.slf4j.jcl-over-slf4j@2.0.15, where the groupId and artifactId were joined by a dot into one slot. The form is valid and passes schema validation, but the coordinate does not exist in the repository.
• A type not defined by the spec: pkg:applications/java@11.0.25 used an invented applications type. Because it is not generic, the existing prohibition did not catch it.
• A vendor string in the namespace: pkg:maven/The%2BApache%2BSoftware%2BFoundation/poi@5.4.1 and pkg:maven/http%3A/www.jboss.org/jbossxts@1.1 placed a company name or a URL in the groupId slot.

None of the three is caught by schema validation, so check them directly with the PURL commands in the Validation Checklist before submitting.

The same file also contained identifiers such as pkg:maven/org.drools/org.drools.drools-core-dynamic@7.67.2.Final-redhat-00054, where the groupId is repeated in front of the artifactId; the real coordinate is org.drools:drools-core-dynamic. Unlike the three above, this one cannot be decided from the form alone, because plenty of valid coordinates do have an artifactId that starts with the groupId, such as org.drools:org.drools.updatesite and org.apache.felix:org.apache.felix.http.jetty. Eclipse plugins and OSGi bundles conventionally use the bundle symbolic name as the artifactId. The checklist therefore carries no item for this; confirming it means querying the repository for the coordinate.

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