Data model fundamentals
How SBOM Observer turns uploaded SBOMs, VEX, and provenance into one linked index that policies run against.
SBOM Observer imports each attestation (an SBOM, a VEX document, SLSA provenance) into one index per namespace. Policies run against that index, so one policy sees what every uploaded file says about a component.
linked components, findings, suppliers
What the index holds
- Components: every package, library, container, and application found in any imported attestation. The same component listed in two SBOMs is one entry, linked to both sources.
- Vulnerabilities: found by matching components against SBOM Observer's advisory sources.
- VEX analysis: exploitability statements, imported from VEX documents or entered in the app, attached to the vulnerability they cover.
- Suppliers: organizations or people named as supplier or manufacturer of components.
- Annotations: data a user adds in the app, such as business criticality or tags, kept separate from what the SBOM said.
The uploaded files are kept as uploaded. Annotations and VEX analysis are stored alongside the index rather than written back into the files, so the original SBOM stays intact as evidence.
What policies get from the index
Because the index links these objects, one policy can combine them: a component-scoped policy receives the component and its vulnerabilities, each with any VEX analysis, so a rule like "no critical vulnerabilities in libraries unless VEX says not affected" reads one input, even when the SBOM and the VEX document were uploaded separately.
When the index changes, for example a new SBOM arrives, a VEX analysis is added, or new advisory data matches a component, SBOM Observer rescans for vulnerabilities and evaluates all policies again.
Related
- Reference: Data model
- Reference: Component-scoped input
- Concept: Policies