Skip to main content
Every container image 2501 publishes is signed with a single ECDSA P-256 key held in AWS KMS. The private half is non-exportable and never leaves KMS. We publish the public half so you can verify any image against a key you hold, with no call to a 2501 service, using cosign.

​
Signing key

Download the key once and keep your own copy. Its SHA-256 fingerprint is:
Check what you downloaded against it, and pin that fingerprint in your own procedures:
We announce any key rotation in the release notes, so treat an unannounced change as a verification failure. A superseded key stays published under a dated name, so images signed with it remain verifiable.

​
Verify an image

Verify against the image digest, not the tag: a tag can be reassigned, a digest cannot.
If verification fails, do not deploy the image. Keep the digest and the cosign output, and contact 2501 support.

​
Verify the installation files

Every file of a Release on github.com/2501-ai/install comes with its signature, <file>.bundle, made with the same key. Verify each file before you apply it:
If verification fails, do not use the file: download it again, and contact 2501 support if it still fails. The chart and compose.yaml carry the digest of every image they run, so a verified file installs only the images it was built with. Verify those images too when you copy them into your registry.

​
Verify the chart in the registry

The chart of each build is also at oci://ghcr.io/2501-ai/charts/2501, with the build as its version, signed with the same key. Verify it before Helm or ArgoCD pulls it:

​
Verify the SBOM

Every image carries a software bill of materials (SBOM), the full list of packages it contains, in SPDX format. It is signed with the same key:
--insecure-ignore-tlog=true is required. We sign without publishing to the public Rekor transparency log, so verification rests on the key alone. The flag disables the transparency-log lookup, not the signature check.

​
Verify without network access

--key also accepts a local file, so the check needs no route to us once the key is on the host. Fetch the key on a connected machine, confirm its fingerprint, then carry it across:
cosign stores the signature and the SBOM attestation in the registry beside the image, under tags derived from its digest. A mirrored or air-gapped registry has to carry those across too, or there is nothing left to verify against. cosign save writes the image and both to disk for transfer and cosign load pushes them into the destination registry; oras copy -r does the same registry to registry.

​
Enforce verification at admission

On Kubernetes you can reject unsigned images at admission rather than verifying them by hand. Any policy engine with cosign key verification works, Kyverno and the Sigstore Policy Controller among them: point it at the same key, and disable the transparency-log check as above. This is how 2501 operates its own clusters.