Software supply chain · ECZ-ID Plugin
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 your plugin and where it came from. An SBOM file on its own is detached from the product it describes and goes stale with the next release.
Built for
- Software publishers 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 plugin
- 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 plugin 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 your plugin.
- Keeping composition evidence current across releases of the same plugin.
- Connecting the evidence for your plugin to the packages 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 plugin is built from.
- LedgerCore for evidence receipts.
- Does an SBOM prove my plugin 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
- Plugin specialist kitECZ-ID Marketplace App Security & Enterprise Approval KitTurn publisher, permission, release and marketplace 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 Plugin Passport stays free. SBOM & software-composition evidence sits above it; TrustOps shows its current state.