SBOM quality

Pharus checks every SBOM it receives against what the CRA asks for and the two most used sets of guidance around it. The check tells you what your SBOM states and what it leaves out, so you can improve your pipeline before a market surveillance authority asks for it. Pharus never refuses an SBOM because of its quality.

​

What Pharus checks

The CRA minimum has three outcomes: BSI’s guideline is strict: it asks for CycloneDX 1.6 or SPDX 3.0.1 and later, SHA-512 hashes and BSI’s own file properties, so few SBOMs meet it in full. Information that can’t be known for a component may be left out (§3.2.1).

​

Where it shows

• An SBOM’s page. The SBOM quality card, below Components, shows the CRA minimum and, for each standard, “n of m required met”. Expand a standard to see every element as Met, Partly, Missing or Not in this format, with its § reference and a hint naming the field to fill in. Elements about components say how many components have it, and name up to five that don’t.
• The SBOMs page. The Quality column shows, for example, “BSI 9/15” over “CISA 12/14”, with a warning icon when the CRA minimum isn’t met.
• CI. The answer to an SBOM upload has the result in quality, and the gaps as warnings that the pipeline examples print on the run.
• Reports. The weekly digest says how many SBOMs received that week don’t list the product’s own dependencies, and each signed edition of the technical documentation records the quality of the family’s SBOMs.

“Not in this format” means the format can’t express the element: SPDX 2 has no field for BSI’s executable, archive and structured properties. It still counts as not met. An SBOM received before Pharus checked quality says “Not checked yet” until Pharus checks it from the original.

​

Close the most common gaps

• Top level unclear. Make your tool write the dependency graph: dependencies in CycloneDX, DEPENDS_ON or CONTAINS relationships from the product in SPDX.
• SBOM author and creator’s email or URL. Add your company as metadata.manufacturer with a URL or a contact’s email in CycloneDX, or a creator “Organization: name (email)” in SPDX.
• Hashes. Have the build tool add SHA-512 hashes of the files you ship.
• Format version. BSI asks for CycloneDX 1.6 or SPDX 3.0.1 and later.
• No vulnerability information. BSI keeps vulnerabilities out of the SBOM. Send scanner findings and VEX as their own documents. Pharus still reads vulnerabilities inside an SBOM, as its VEX. See VEX from other tools.

​

Related