Software supply chain · ECZ-ID API
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.
Enterprise buyers ask what your API is built from and where its components came from. An SBOM file on its own is detached from the API it describes and from the endpoints the buyer actually calls, and goes stale with the next release.
Built for
- API providers facing enterprise software supply-chain review.
- Teams that ship an API together with the SDKs that wrap it.
- Organisations that want composition evidence tied to an enduring API 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.
- Product
- The enduring ECZ-ID of the API
- Release
- The 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 API 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
- Answering an enterprise supply-chain review for an API and the service behind it.
- Keeping composition evidence attached to the same API across releases and base-URL changes.
- Connecting an API's evidence to the SDK Passports of the client libraries that wrap it.
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 client libraries that wrap the API.
- LedgerCore for append-only evidence receipts.
- Does an SBOM prove my API 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
- API specialist kitECZ-ID API Enterprise Security Review & Customer Assurance KitTurn API ownership, control and security evidence into an enterprise-review pack.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 API Passport stays free. SBOM & software-composition evidence sits above it; TrustOps shows its current state.