The problem: You validate SBOMs at release and you scan for vulnerabilities. The two activities produce different answers, and nobody can say which one the CRA evidence should reference.
Two different questions
| Validation | Continuous monitoring | |
|---|---|---|
| Question | Is this document structurally valid and usable for matching? | Does this shipped component version match a published advisory today? |
| Moment | Build and release | Continuously, for the support period |
| Input | One SBOM document | Stored component identities plus advisory feeds |
| Failure mode | A green run against a document nobody can match | Alerts nobody can attribute to a product version |
| Output | Defects, identity quality, query readiness | Matches with applicability review |
What validation can and cannot tell you
Validation is deterministic and cheap: the schema either accepts the document or it does not, references either resolve or they do not, components either have an exact version and an identifier or they do not. This is exactly what you want as a release gate, because the answer does not depend on an external service.
What it cannot do is measure risk. A perfectly valid SBOM can describe a product full of vulnerable components, and a well-formed component list can still be incomplete.
What monitoring needs from the SBOM
- Stable identifiers per component, so an advisory map is possible at all.
- Exact versions, so version ranges in advisories can be resolved.
- A product-version anchor, so a match can be attributed to something you shipped.
- An owner and a decision record, so an alert becomes a decision rather than a ticket.
- A retention policy, because support periods outlive most dashboards.
This is why “we run a scan” and “we have a component inventory” are not substitutes. The scan is only as good as the identity data it runs on.
The combined loop
- Generate the SBOM in the build and validate it. Fail on schema and identity defects.
- Store the validated inventory against the product version.
- Match advisories continuously against the stored identities.
- Review matches for applicability on the device, and record the decision.
- When a fix ships, compare the new SBOM with the previous one and attach the change list to the release record.
Where EmbedHarbor is today
Validation, comparison and local certificate decoding are available now. Continuous monitoring and product-version status are Early Access; the public site does not simulate them.
Scope and limits
- The public website does not perform vulnerability matching or monitoring.
- Monitoring availability is Early Access and requires the application, not the marketing site.