LetsSeal

Sign and verify software artifacts, containers & SBOMs

Release binaries, container images, and SBOMs signed under your own certificate authority, verifiable with stock cosign, anchored on the blockchain and a public transparency log. Supply-chain proof that drops into the pipeline you already run.

For dev teams, devops, platform and security engineers.

Open the app Developer docs
What a seal proves

Four guarantees, in software supply chain

The exact bytes that shipped

A signed artifact can't be swapped or tampered. The signature is over its precise contents, and cosign catches any change.

Your own code-signing root

Every signature and attestation chains to a published root you control, no third-party trust list, no Fulcio dependency.

An independent record of the release

Artifacts are timestamped on the blockchain and recorded in the public transparency log, provable evidence of what shipped, and when.

Verified with stock cosign

Downstream consumers run unmodified cosign, no bespoke tooling, and no dependency on Let's Seal to check a signature.

How it works

From your file to a proof anyone can check

The same pipeline every time. The seal and the timestamp travel with the file, so the proof is self-contained.

Your file
Your artifact / SBOM
Seal
Signed over every byte · cosign-compatible
Anchor
Blockchain timestamp + public transparency log
Proof page
A permanent /d/… link travels with the file
Anyone verifies
Free, public, offline-capable, for anyone
The proof travels inside the file. Verification stands on the published root, the transparency log, and the blockchain, so a court, a bank, or a counterparty can check it independently, forever.
Step by step · the web app

Seal it in the app, no setup

  1. 1

    Create your org and code cert

    Sign in at app.letsseal.org and create your organisation. It provisions a code-signing certificate (EKU codeSigning) that cosign recognises.

  2. 2

    Get an API key for CI

    Generate an API key in Settings and add it to your CI secrets. From here, sealing is one CLI call in the pipeline.

  3. 3

    Sign in the pipeline

    Run sealbot on your build artifacts, images, and SBOMs (below). Nothing but the digest leaves the runner.

  4. 4

    Publish the proof

    Ship the signature, cert, and attestation next to the release. Consumers verify with stock cosign, or open the transparency-log record.

Step by step · the CLI

Automate it from your terminal or CI

The sealbot CLI does the same thing, scriptably, one command per file, straight into your pipeline.

# Sign a release artifact (cosign-compatible)
$ sealbot sign-blob app-2.1.0.tar.gz --org examples
signed   app-2.1.0.tar.gz  (cosign-compatible artifact seal)
  sig    app-2.1.0.tar.gz.sig
  cert   app-2.1.0.tar.gz.pem  (+ app-2.1.0.tar.gz.chain.pem)

# Attest an SBOM (SPDX / CycloneDX / SLSA provenance)
$ sealbot attest app-2.1.0.tar.gz --org examples \
    --predicate sbom.spdx.json --type spdxjson
wrote    app-2.1.0.tar.gz.att.bundle

# Anyone verifies with stock cosign, no Let's Seal required
$ cosign verify-blob --certificate app-2.1.0.tar.gz.pem \
    --certificate-chain app-2.1.0.tar.gz.chain.pem \
    --signature app-2.1.0.tar.gz.sig \
    --certificate-identity-regexp '.*' \
    --certificate-oidc-issuer-regexp '.*' --insecure-ignore-tlog \
    app-2.1.0.tar.gz
Verified OK

sign-image signs an OCI image in its registry so `cosign verify <image>` works; attest-image attaches an SBOM or SLSA provenance to an image. Everything chains to your own published root.

Full CLI & API reference
See it in action

What a proof looks like, and what you can seal

Issuer verified, controls letsseal.org
Authentic & unaltered
Artifact
A signed release artifact
Issuer
Let’s Seal Examplesletsseal.org
SHA-256
64-hex fingerprint ✓

Anchored on the blockchain

Recorded in the public transparency log

Public and free to verify, by anyone, with standard tools.

The proof is the verification itself, reproducible with stock cosign on any machine.

A single use case, many documents. Each of these is sealed the same way:

  • A signed release artifact

    The proof here is the verification itself: stock cosign confirms the artifact's signature against your published root, reproducible on any machine, no Let's Seal required.

  • A container image

    Sign an OCI image in its registry so `cosign verify <image>` passes for anyone pulling it, provenance that travels with the image.

  • An SBOM or SLSA provenance attestation

    Attach an SPDX or CycloneDX SBOM, or SLSA build provenance, as a cosign attestation, a signed, timestamped statement of what's in the release and how it was built.

Common documents

What you’ll seal

  • Build artifacts
  • Container images
  • SBOMs (SPDX / CycloneDX)
  • Release binaries
  • SLSA provenance attestations
Questions

Straight answers

Does this work with stock cosign?
Yes. Signatures and attestations verify with unmodified `cosign verify-blob` and `cosign verify-blob-attestation`. The artifacts are cosign's native format, chained to your published root.
Do I need Fulcio or a public Sigstore?
No. Let's Seal is your own CA, so you sign under a root you control and publish. The same cosign commands verify against it, with no keyless-OIDC round trip required.
Container images and SBOMs too?
Yes, `sealbot sign-image` signs an OCI image in its registry, and `sealbot attest` / `attest-image` attach SPDX, CycloneDX, or SLSA provenance that cosign verifies.
Where does the timestamp come from?
Each seal is anchored on the blockchain via OpenTimestamps and recorded in a public, append-only transparency log, an independent record of the release that doesn't depend on your CI logs.

Start sealing software supply chain documents

Free and open. Seal in the app, automate from the CLI, and hand anyone a proof they can verify themselves.

Open the app All use cases