On this page
- Choose the SBOM for the release being assessed, not simply the newest file.
- Keep document readability and quality separate from shipped-inventory completeness.
- Investigate component findings in product context.
- Retain the earlier assessment when an inventory is replaced.
Start at the build handoff
Suppose your team produces a desktop installer and an SBOM in its release pipeline. Before upload, identify the product version, the build output and the tool that produced the inventory. Check whether bundled runtimes, plugins and native libraries are included. A package-manager inventory can be useful without representing the entire installer.
Annex I, Part II of the CRA addresses component and vulnerability documentation, including an SBOM in a commonly used machine-readable format. Treat the inventory as evidence for a wider process. The upload itself does not satisfy all software publisher compliance duties.
Supply the inventory and inspect what was read
ConformOps accepts CycloneDX JSON and SPDX JSON. Format support is specific: an XML or tag-value file is not supported merely because it carries the same standard name. A structurally unusable supplied document cannot serve as the release inventory; the assessment falls back to the repository-derived components and explains that boundary.
For usable input, inspect the number of components read, which identities can be correlated with vulnerability information, and what the document-quality view flags. A strong quality score describes the document fields under the published scoring method. It does not prove that every component ships, that none is omitted or that the build is secure.
Resolve differences without erasing their origin
A supplied SBOM takes precedence as the effective inventory when usable. Repository discovery still provides a separate observation. For example, a lockfile may mention a library absent from the supplied document. That difference may reflect a missing shipped component, a build-only dependency or a different release input. Someone must investigate which explanation fits.
Do not fix the appearance of the dashboard by combining the lists indiscriminately. Retain the supplier or build explanation and correct the inventory if needed. ConformOps keeps the source distinction visible; accepting manufacturer-supplied evidence is not independently validating it.
Connect monitoring to an affectedness decision
Exact component coordinates enable correlation with supported vulnerability sources. Unresolved ranges and uncorrelated identities remain limits. When a match appears, inspect the relevant product version, how the component is used, and the available test or architecture evidence before deciding whether the product is affected.
ConformOps records affectedness history with attribution and rationale. The history is VEX-style investigation information, not standards-format VEX interchange. A not-affected decision for one version must not become an unsupported blanket statement about every version. Article 14 reporting review is another decision and must be considered on its own facts.
Correct the inventory, then assess the corrected input
An assessment refers to the particular SBOM it used. Replacing the active document does not silently rewrite a completed run. A later assessment can use the replacement while the previous record remains understandable. Withdrawal similarly removes a document from active use without erasing the historical record.
This gives a reviewer a useful sequence: what was supplied, what was assessed, what was found and why the team corrected it. Reproducibility here means identifying the retained inputs and outputs. It does not promise that a later live advisory lookup or optional AI explanation will produce identical results.
Keep a small, complete handoff for the next reviewer
Before closing the investigation, identify the release, inventory origin, assessment, relevant findings, decision rationale and corrective version. Preserve uncertainty that remains. Use the release-evidence checklist for the surrounding tests and documentation, and the ConformOps overview for access and workflow boundaries.
This reduces the need for an external reviewer to reconstruct basic engineering facts. It does not remove the value of independent testing, supplier follow-up or legal advice. Continuous is needed for ongoing monitoring and named release operations; confirm the appropriate plan for the workflow you intend to run.
Frequently asked questions
Does uploading an SBOM prove CRA compliance?
No. It provides component evidence. The manufacturer still needs to assess its completeness and relevance, handle vulnerabilities and meet the other applicable requirements.
What happens when the repository and SBOM disagree?
ConformOps keeps supplied and derived origins distinct and shows relevant discrepancies. Investigate whether the difference concerns shipped, build-only or outdated material rather than assuming either source is complete.
Does replacing an SBOM change a historical assessment?
No. A run stays bound to the document it assessed. A replacement is used by a later assessment, preserving the meaning of the earlier evidence record.