Skip to content

Docs

Image security

Three things you can know about an image in your registry: what vulnerabilities it carries, what is actually inside it, and whether anyone vouched for it. Each is optional and switched on per deployment — ask your operators if a panel is greyed out.

Vulnerability scanning

New images are scanned as they land, and the tag list shows the worst severity found — or Clean when nothing was. Open a tag to see the findings: severity, CVE id, the affected package and the version that fixes it.

You can re-run a scan at any time from the manifest view — worth doing on an image you have not rebuilt in a while, since new CVEs are published against packages that have not changed.

Scanning never blocks a push. If the scanner is unavailable the image still lands and the tag simply shows no result — you are told the scan failed rather than being told the image is clean.

SBOM

A Software Bill of Materials lists every package baked into an image. Generate one per tag in either CycloneDX or SPDX and download it — the format your downstream tooling or your customer's security review asks for. Generation runs in the background; the panel shows the package count when it finishes.

Signing

A signature is a claim that someone your consumers trust vouched for this exact image. Subnomic uses cosign, so the signatures are verifiable by anyone with the public key — including admission controllers in a cluster that has never heard of Subnomic.

Each workspace signs with its own key. That is what makes a signature mean something: with one shared key, "signed" would only tell you the server signed it, and a consumer checking your image against that key would just as happily accept someone else's.

Choosing how your key is held

Under Container registry → Signing, pick one:

  • Your KMS — you point at a key in your own AWS KMS, Google Cloud KMS, Azure Key Vault or HashiCorp Vault. Subnomic holds only a reference; the private key never leaves your provider, so even a compromise of our database cannot forge your signatures. Prefer this where you have it.
  • Managed by us — you upload the private key. It is encrypted at rest and decrypted only for the moment a signature is made, never written to disk. Simpler to set up, but the key does sit in our database.

To create a key pair for the managed option, run cosign generate-key-pair and paste the contents of cosign.key along with its password. You do not need to upload the public key — it is derived from the private one, which also proves the password is right before anything is stored.

Signing and verifying

Open a tag and use Sign now, or sign from your pipeline with the cosign sign command shown on the same panel — signing in CI, right after the build, is the stronger habit. Either way the tag list shows a shield for every signed image, and Verify re-checks a signature on demand.

Rotating your key keeps the previous public keys, so images signed before the rotation still verify. Removing your key entirely drops that history — anything signed with it stops verifying here.
A signature says who vouched for the image, not that the image is safe. Read it together with the scan results — a signed image with a critical CVE is a signed image with a critical CVE.