Software supply chain · ECZ-ID SDK
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 is inside an SDK and where it came from. An SBOM file on its own is detached from the library it describes, says nothing about who publishes it, and goes stale with the next release on the next registry.
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.
- Product
- The enduring ECZ-ID of the SDK or library
- 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
Identity, SBOM and provenance answer three different questions. The SDK Passport says who publishes the library and which releases belong to it; the SBOM says what one release contains; provenance says where and how it was built. The solution attaches the second and third to the first, so a reviewer sees one SDK over time rather than a pile of files.
Use cases
- Answering an enterprise supply-chain review for a client SDK, with composition evidence tied to the release in question.
- Keeping SBOMs attached to the same enduring identity across every release and every registry the SDK ships to.
- Letting a downstream vendor connect the SBOM of an embedded library to the organisation that publishes 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.
- Identity, SBOM and provenance stay distinct: none of them is proof that a build was secure.
Integrations and questions
Works with what you already run.
- The SBOMs your build already produces, in the format your tooling emits — for example CycloneDX or SPDX.
- Provenance attestations from your pipeline, referenced against the release they describe.
- LedgerCore, for append-only evidence receipts.
- Package registries and the source repository, recorded against the SDK's Passport as declared bindings.
- Does an SBOM prove my SDK or library 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
- SDK specialist kitECZ-ID SDK Release Provenance & Customer Assurance KitMake SDK release provenance and dependency evidence easier for customers to review.Read more
- Regulated financeDORA ICT-vendor evidencePrepare reusable ICT-vendor evidence for customers operating under DORA.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 SDK Passport stays free. SBOM & software-composition evidence sits above it; TrustOps shows its current state.