> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pharussecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.
# SBOM quality
> What Pharus checks in every SBOM against the CRA minimum, BSI TR-03183-2 and CISA's 2026 minimum elements, and how to close the gaps.
**Plans:** Every plan. **Who:** every member.
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
| Check | What it asks |
| - | - |
| **CRA minimum** (Annex I Part II(1)) | The SBOM is machine-readable and lists at least the product's top-level dependencies |
| **BSI TR-03183-2 2.1.0** | Germany's technical guideline for SBOMs under the CRA: 15 required elements, plus additional ones needed when the information exists and an optional one |
| **CISA 2026 minimum elements** | The 14 minimum elements CISA and 17 other agencies, BSI among them, published in July 2026. They replace NTIA's 2021 list. |
The CRA minimum has three outcomes:
| Outcome | Meaning |
| - | - |
| Met | Machine-readable, and lists the product's top-level dependencies |
| Top level unclear | Machine-readable, but the product's own dependencies aren't listed, so which components are top-level can't be told. Most tools add them with a dependency graph. |
| No components | The SBOM lists no components |
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](/api-reference/sboms#responses) has the result in `quality`, and the gaps as
`warnings` that the pipeline examples print on the run.
* **Reports.** The [weekly digest](/monitoring/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](/reports/technical-file) 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](/monitoring/vex-documents).
## Related
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.