SDK specialist kit · ECZ-ID SDK

ECZ-ID SDK Release Provenance & Customer Assurance Kit

Make SDK release provenance and dependency evidence easier for customers to review.

A practical pack for SDK and package publishers that need to connect a persistent publisher identity to release, provenance and dependency evidence across registries.

Open in TrustOps All SDK products

Type: Digital product
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.

Before an enterprise approves an SDK, its reviewers ask who publishes it, whether the release they are pulling came from that publisher, what it depends on and how releases are controlled. Publishers answer from registry screenshots and scattered CI logs, differently for every customer — and the answer is stale by the next release.

Built for

SDK and client-library publishers selling to enterprises.
Open-source maintainers whose libraries have commercial or enterprise users.
Developer-platform teams answering customers' supply-chain reviews.
Enterprise reviewers who need one consistent publisher and release story.

What changes

Clearer release provenance
Reusable customer evidence
Less registry-by-registry reconstruction

What you receive

Concrete deliverables, not a vague trust score.

Publisher and package identity evidence
Release provenance prompts
Dependency evidence structure
Customer assurance artefacts

The SDK release assurance pack

Publisher: Your Business Passport and the SDK's ECZ-ID
Distribution: Every registry channel, recorded against the one identity as a declared binding
Release: vX.Y.Z — source repository, pipeline and attestation references, where supplied
Composition: The SBOM for that release, from your own tooling
Gaps: Open questions a customer's reviewer will raise about the release, stated plainly
Boundary: Documents provenance — does not prove the build was secure

Illustrative structure with placeholder values. The pack is assembled from your evidence; the Resolver remains the live proof.

How it works

A short path from need to something usable.

Select the SDK.
Collect release and provenance evidence.
Resolve gaps.
Produce the buyer-facing pack.

How it relates to your Passport

The kit builds on the free SDK Passport: one identity for the SDK, the source repository and each registry channel recorded against it, the publisher on the record. It organises release, provenance and dependency evidence around that identity and points reviewers to the Resolver for current proof. Your SBOMs and attestations stay yours; the kit connects them to an identity that outlives every release.

Use cases

Answering an enterprise customer's supply-chain questionnaire for a client SDK.
Getting a library onto a bank's or insurer's approved-dependency list.
Giving every downstream customer one consistent release-provenance story instead of a per-customer email thread.
Preparing for a customer's DORA ICT third-party review of an embedded SDK.

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.

You choose what goes into the pack and what, if anything, is published.
Build logs, attestations and SBOMs stay in your systems; the pack references them and never asks for secrets or private source.
Nothing is installed in your pipeline or in your customers' applications.
LedgerCore can keep decisive evidence as append-only receipts where you hold it; ledger anchoring is not live yet.

Boundaries

The claims stop here.

The kit documents provenance and evidence; it does not guarantee package security.
An ECZ-ID identifies the publisher and the SDK; it does not prove a build was secure, reproducible or free of vulnerabilities.
Your SBOMs and attestations stay your own build outputs; the kit organises them and neither re-signs nor certifies them.

Integrations and questions

Works with what you already run.

Package registries — npm, PyPI, Maven Central, NuGet and others — recorded as declared bindings.
Your source repository and CI/CD pipeline, as the origin of release evidence.
SBOMs and provenance attestations in the formats your build already emits — for example CycloneDX or SPDX, and SLSA-style provenance — referenced, not re-issued.
Your Business Passport at VERIFIED or ASSURED for publisher assurance, and LedgerCore for append-only receipts.

Does the kit prove my SDK is secure?: No. It documents who publishes the SDK, where each release came from and what it contains, from your evidence. It does not prove a build was secure or free of vulnerabilities.
Do I have to change my build or CI?: No. The kit organises the provenance, SBOM and release evidence your pipeline already produces. Nothing is installed in it.
Is this the same as an SBOM?: No. An SBOM describes what one release contains. The kit ties SBOMs and provenance to the SDK's enduring identity and publisher, across releases and registries.
Where do I buy it?: In TrustOps, which owns purchase, payment, fulfilment and entitlement for the kit — never on this site.

Keep the identity free. Everything above it is optional.

Your SDK Passport stays free. ECZ-ID SDK Release Provenance & Customer Assurance Kit sits above it; TrustOps shows its current state.

Open in TrustOps