Compare · software trust evidence
SBOM vs trust packet: the inventory and the review record around it
An SBOM tells a reviewer what components a build contains. A trust packet records who looked at the risks in that inventory, what they decided, and binds it into a signed record a buyer can read and check.
| SBOM | Trust packet | |
|---|---|---|
| What it produces | An inventory of the components a build contains | A signed record of the review and the decision |
| The human decision | Lists components; carries no reviewer's decision | Records who accepted a risk, with owner and expiry |
| Buyer can independently check | Buyer reads the listed contents and versions | Buyer checks the signature for integrity and origin |
| Re-run vs durable record | Regenerated per build as a fresh snapshot | A durable record that keeps the finding visible |
| Scope | What is in the build | Who reviewed the risks and what they decided |
What sboms do well
A Software Bill of Materials gives you a precise, machine-readable inventory of the components a build contains — names, versions, and how they nest. It is the foundation for asking the right questions: which package is here, where it came from, and what advisories touch it. Standard formats like SPDX and CycloneDX make that inventory portable across tools and easy to diff between releases.
Where the scope stops
An SBOM describes what is in the build, not who reviewed it or what they concluded. It lists a component and the advisories against it, but it does not carry the human decision a reviewer made about a specific finding, or hold an owner and an expiry for a risk someone chose to accept. As an input it is a snapshot of contents — the review history around those contents lives somewhere else.
What trust packet adds
OpenSoyce treats the SBOM as one input and records the review around it. It observes the dependency, CI, package, and AI-agent evidence, binds each item to its source, and surfaces where sources contradict each other as review signals. When you accept a risk, it records the entry with an owner and an expiry without resolving or hiding the original finding. The result is a signed evidence packet plus a buyer-readable dossier and a JSON export, where the signature attests integrity and origin and the full decision history travels with the record for the reader to weigh.
When to use which
Use both: the SBOM to know what components a build contains, OpenSoyce to record who reviewed the risks in that inventory and what they decided. Generate or ingest the SBOM as an input, then bind the review, the accepted risks, and the contradictions into a signed packet a buyer can read. One tells you the contents; the other preserves the decision around them.
The boundary
OpenSoyce preserves and explains the evidence and the decision around it; it does not certify, verify, or approve anything. A signature proves integrity and origin, not that a finding is resolved, and your buyer's policy decides trust.