Trust cannot be removed.
It can only be moved.
ISCProof is an open specification for verifiable build attestations and artifact proofs.
It defines a protocol for proving who built an artifact,
from what source, in which environment, and with which inputs —
in a way that can be verified independently.

ISCProof is not a product. It is a specification.

PROBLEM

Modern software supply chains rely on trust.

You trust the CI system. You trust the maintainer. You trust the registry. You trust the binary.

In most cases, this trust is not verifiable.

An artifact may claim to be built from a source, but the claim itself is rarely provable. Logs can be modified. Build systems can be compromised. Maintainers can make mistakes. Signatures alone do not prove how something was built.

Most systems provide statements. Few provide proof.

ISCProof moves trust away from people and infrastructure, and attaches it to verifiable records.

SPECIFICATION OVERVIEW

ISCProof defines a protocol for generating portable, verifiable build attestations.

The specification defines:


ISCProof does not define a CI system.
ISCProof does not define a package registry.
ISCProof does not define a hosting service.
ISCProof defines a verification layer.

DESIGN GOALS

Deterministic — Artifacts must be identifiable by hash
Verifiable — Proof must be checkable without trusting the builder
Portable — Proof must survive transport across systems
Minimal — Protocol should not depend on specific platforms
Composable — Multiple tools should be able to implement the spec
Transport-independent — Proof must remain valid outside CI, registry, or hosting

TRUST MODEL

ISCProof defines the following roles.

BUILDER

Produces the artifact.

ATTESTOR

Creates a signed statement about the build.

VERIFIER

Checks that the artifact matches the statement.

TRANSPORT

Carries artifact and proof.

ROOT OF TRUST

The key or identity used for signature verification.

The protocol assumes that signatures are valid only if the verifier trusts the corresponding root key.

Trust must be attached to proof, not to infrastructure.
Verification must not depend on the builder.
An artifact is trusted because its proof can be verified.

CORE CONCEPTS

ARTIFACT

A binary output produced by a build. Artifacts are identified by hash.

ATTESTATION

A signed record describing the build. Contains: artifact hash, source reference, builder identity, timestamp, build inputs, signature.

SEAL

The canonical ISCProof record. Binds artifact → attestation → signature. Must be portable and verifiable without external state.

VERIFICATION

Requires: artifact, seal, public key. Must confirm hash matches, signature valid, attestation format valid, rules satisfied. Must not require CI or registry access.

PROTOCOL RULES

Artifact must have a deterministic hash
Attestation must include artifact hash
Attestation must be signed
Signature must be verifiable offline
Seal must contain all required data
Verification must not depend on transport
Multiple implementations must produce compatible seals

NON-GOALS

ISCProof does not attempt to:


ISCProof only ensures that claims about a build can be verified.

REFERENCE IMPLEMENTATION

The ISCProof specification is implemented by BuildSeal.

BuildSeal provides: CLI builder, seal generator, public verifier, signature validation.

BuildSeal is a reference implementation, not part of the specification. Other implementations are expected.


buildseal.io →

PHILOSOPHY

Today, trust lives in CI systems, maintainers, registries, and logs.

ISCProof moves trust to hashes, signatures, attestations, and verifiable records.

Trust should be transferable.
Trust should be verifiable.
Trust should not depend on authority alone.

ISCProof exists to make that possible.

iscproof.io — open specification — no warranty — trust nothing, verify everything — independent verification required