Software supply chain · ECZ-ID Service & Workload
SBOM & software-composition evidence
Turn software composition and provenance into evidence a buyer can actually review.
The SBOM solution organises software-component, dependency and provenance evidence around the digital product being supplied, so reviewers can understand what is in scope and what changed.
- Type
- Solution
- Price
- Not restated on this site; TrustOps publishes the current price and availability
- Acquired and paid in
- TrustOps
- Operated in · proved by
- Dashboard · Resolver
The problem
Why it matters.
A service ships a new container image many times a week. An SBOM attached to one image digest describes one build; reviewers want to know what the service they depend on is built from, release after release.
Built for
- Software suppliers facing enterprise supply-chain review.
- Connected-product, SDK, plugin, API and service teams managing third-party components.
- Organisations that want SBOM evidence tied to an enduring product identity rather than an isolated file.
What changes
- More reviewable software-composition evidence.
- A clearer link between a release, its product identity and its supporting provenance.
- Less manual reconstruction of component evidence during customer or regulatory review.
What you receive
Concrete deliverables, not a vague trust score.
- Structured software-composition evidence around the relevant ECZ-ID subject.
- Release and provenance context where supplied by the customer workflow.
- Support for buyer-facing evidence packaging.
- Managed and enterprise depth for larger programmes.
- Service
- The service's enduring ECZ-ID
- Release
- The image or release the composition describes
- Composition
- Component and dependency evidence you supply
- Provenance
- Build and source context, where supplied
- Boundary
- Describes composition — does not declare the software secure
Illustrative structure. Contents come from your own build and supply-chain tooling.
How it works
A short path from need to something usable.
Identify the software product or service whose composition must be evidenced.
Collect the relevant composition and provenance inputs.
Organise them against the enduring ECZ-ID identity and release context.
Re-use and update the evidence as dependencies and releases change.
How it relates to your Passport
The Passport gives the service or workload one enduring identity across releases. SBOM evidence attaches to that identity and its release context, so reviewers see one product rather than a pile of files.
Use cases
- Tying each container image's SBOM to the one enduring service it belongs to.
- Answering an enterprise supply-chain review for a hosted service rather than a downloadable product.
- Connecting a service's evidence to the SDK Passports of the libraries it is built from.
Tiers and price
Price and availability
Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal. This site does not restate this product's price; TrustOps publishes its current tiers, price and availability, and shows them before anything is bought.
How it is arranged
TrustOps acquires
TrustOps publishes the tiers and holds payment and entitlement whenever it is offered.
Dashboard operates
Once you hold it, it appears in your Dashboard, where you operate it.
Resolver proves
Public facts stay on the Resolver; holding it never changes what a record proves.
Privacy, security and evidence
What is collected, published and kept.
- Evidence you supply stays yours; publication requires your consent.
- ECZ-ID does not turn missing source evidence into verified facts.
- LedgerCore keeps eligible evidence as local records; ledger anchoring is not live yet.
Boundaries
The claims stop here.
- An SBOM describes composition and evidence; it is not a declaration that software is secure.
- ECZ-ID does not turn missing source evidence into verified facts.
Integrations and questions
Works with what you already run.
- The SBOM and provenance outputs your build already produces.
- SDK Passports for the packages your service or workload is built from.
- LedgerCore for evidence receipts.
- Does an SBOM prove my service or workload is secure?
- No. An SBOM describes composition. It is not a declaration that software is secure.
- Do I have to change my build?
- No. The solution organises the composition and provenance evidence you already produce.
Related
- Service & Workload specialist kitECZ-ID Service & Workload Identity & Secretless Migration KitTurn workload identity and secretless-migration evidence into an implementation-ready kit.Read more
- CounterpartyDCI — Digital Counterparty InfrastructureMake a digital counterparty easier for people and machines to identify, inspect and re-check.Read more
- Evidence · HistoryLedgerCoreKeep decisive identity and lifecycle evidence without pretending evidence proves the claim inside it.Read more
Keep the identity free. Everything above it is optional.
Your Service & Workload Passport stays free. SBOM & software-composition evidence sits above it; TrustOps shows its current state.