Skip to content
ECZ-IDSDK
Free Passport: Get a FREE SDK Passport

Origin

Publisher identity and provenance

A consumer tracing a package back to its publisher is, today, mostly guessing from a registry account name. Provenance answers the question that guess is standing in for: who publishes this, and is that the same publisher as the last release.

What it answers

Origin, continuity and the organisation behind both

Four questions that a public record can answer, and that nothing in a registry currently answers on its own.

  • Who publishes this

    The organisation on the record as the library's operator, with the date it declared itself.

  • Is this the same library

    One identity across registries and renames, so continuity is a fact on a record rather than an inference from a name.

  • Where it is distributed

    Each registry channel and the canonical repository, declared by the publisher rather than assembled by a third party.

  • Has anything changed

    Decisive lifecycle transitions are kept as evidence, so a consumer can see that a publisher relationship changed rather than discovering it later.

The part that matters most

Provenance is not a security review

An ECZ-ID does not make anything safe, certified, approved or compliant, and holding one does not make you compliant with anything.
  • No code has been read, scanned, tested or audited by anyone because a library holds an ECZ-ID.
  • A record says nothing about the dependencies a library pulls in, or about anything they do.
  • It is not a signature and it does not replace one. Artefact signing and attestation live in your registry and your pipeline, and they answer a different question.
  • It does not mean a registry has reviewed anything. Registries run their own processes, and an ECZ-ID is not an input to any of them.
  • A binding recorded against the library does not grant, prove or imply authority to act — on a registry, a repository or anything else.
  • A VERIFIED or ASSURED Parent verifies the publishing organisation. It does not verify the library.

Kept distinct

Three questions, three kinds of evidence

Identity, SBOM and provenance are often said in one breath. They answer different questions, and none of them proves that a build was secure.

  • Identity

    Who publishes this, and is it the same library as last time?

    The SDK Passport: one enduring ECZ-ID, the publisher on the record, registry channels and the repository as bindings.

    The free SDK Passport

  • SBOM

    What does this release contain?

    Composition evidence from your own tooling, attached to the release and the identity it describes.

    SBOM & software-composition evidence

  • Provenance attestations

    Where, and how, was this release built?

    Build provenance and signatures from your pipeline, organised against the SDK's identity for customer review.

    SDK Release Provenance & Customer Assurance Kit

Optional

SDK Publisher & Provenance

Publisher identity and provenance across the SDKs and packages you publish.

The boundary

Provenance records where a package came from. It is not a security audit of its code.

Nothing here is required to hold a free SDK Passport, to publish its record or to have it resolved. Publisher-level provenance is useful when you publish enough libraries for the estate to be the unit; one library needs one Passport and nothing else.

Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal.

Where next

Keep going with ECZ-ID SDK.

Get a FREE SDK Passport