Data Model Fundamentals

SBOM Observer ingests attestations—SBOMs, VEX, VDR, SLSA, and external datasets—and breaks them into a graph-shaped data model. Originals are preserved exactly as uploaded; we layer insights on top instead of mutating source evidence. That graph is the foundation for policies: every evaluation reads the same connected objects, so rules can span components, vulnerabilities, attestations, and namespaces without juggling raw files.

Our data model philosophy

Observer treats every attestation as a lens on the same software graph. Instead of storing SBOMs or VEX docs as disconnected blobs, we normalize them into shared building blocks:

• Components capture identity (PURL, version, supplier) and licensing facts.
• Findings attach vulnerability, exploitability, and advisory metadata to those components.
• Namespaces describe where the SBOM lives—tenant, environment, or customer-dedicated space—so policies can enforce different guardrails per context.
• Related attestations (VEX, VDR, SLSA, scan reports) link to the same components, letting policies reconcile what vendors claim with what your telemetry observes.

Because we keep the raw files immutable underneath these building blocks, every derived fact is traceable back to the attestation that supplied it. This graph-first approach means policies can answer questions such as “Does this VEX analysis apply to the SBOM uploaded from CI?” or “Which production namespaces still reference the vulnerable version even though a SLSA attestation says it was rebuilt?”

Conceptual flow

From ingestion to graph

1. Ingest — Observer accepts SBOMs, VEX/VDR statements, and other attestations through uploads, CLI commands, or API integrations.
2. Normalize — Each attestation is parsed into shared objects (components, findings, namespaces, provenance events) and written into the graph index.
3. Connect — We connect components across attestations so the same library version references related VEX statements, upstream advisories, and any SLSA or deployment metadata.
4. Evaluate — Policies (Visual Builder, Rego, or JavaScript) read the linked objects during every upload or advisory change, so violations reflect the latest context.
5. Prove — Observer stores the original attestations alongside violation results, so every decision cites the exact SBOM, VEX notice, or provenance file that informed it.

Because the model is shared, you write a rule once—“Production namespaces must not rely on components with unresolved critical findings”—and Observer applies it consistently across every SBOM that hits the workspace.

Where policies plug in

• Risk triage: Policies can down-rank findings that have matching VEX not_affected records while still flagging the ones without vendor justification.
• Regulatory coverage: CRA, NIS2, or DORA rules reference namespaces, suppliers, and attestations all at once; the graph already knows those relationships.
• Change tracking: Because namespaces and components carry timestamps, policies can enforce “must update within 14 days” windows or require re-attestation when new VDR data arrives.

These examples stay intentionally high-level—the goal is to explain how the model behaves, not its exact shape.

When to dive into details

• Read the policy data input reference to see the exact JSON object policies read and plain-language field-by-field notes.
• Follow the policy authoring guide to see how the model shows up in Visual Builder, Rego, and JavaScript.
• Explore Policies & Evaluations if you need a refresher on how violations are surfaced once policies run.

Learn more

• Review the policy data input reference for every field, how they relate, and a complete sample payload.
• Follow the policy authoring guide for implementation details.
• Explore Policies & Evaluations to see how the evaluator runs at scale.