Container Image Signing Operating Model Guide

What Container Image Signing Actually Is

Container image signing attaches a cryptographic signature to an OCI image (or to any OCI-compatible artefact, including Helm charts, WebAssembly modules, and policy bundles) that proves which build identity produced the artefact and that the content has not been altered since the build. The signature lives either as a separate OCI artefact alongside the image in the registry (the modern pattern used by Sigstore cosign, Notary v2 / notation, and the OCI 1.1 referrers API), or, in the legacy Docker Content Trust flow, in a separate signing service. The verifier (an admission controller, a deployment system, a customer attestation flow, or a security evaluation pipeline) reads the signature, checks it against an allowed signer policy, and either admits or denies the artefact.

The signature is a small, well-defined artefact: a payload that names the artefact digest, a cryptographic signature over the payload, a signer identity (either a long-lived public key fingerprint or a short-lived certificate tied to an OIDC identity), and, optionally, an attestation that carries SBOM, VEX, SLSA provenance, or vulnerability scan results bound to the same digest. The verifier never trusts the payload alone; it trusts the signature over the payload, anchored to a documented root of trust.

Signing is not the same as scanning. Scanning answers what is in an artefact and whether any known weaknesses are present. Signing answers whether the artefact is the one a documented build produced. Most modern programmes run both: scanning detects the long tail of dependency CVEs through authenticated and unauthenticated scanning and SAST and SCA code scanning; signing closes the integrity question that scanning cannot answer.

Why Image Signing Is Now a Baseline

Container image signing crossed from advanced practice into baseline expectation for three reasons: regulator pressure on software supply-chain integrity, the maturation of the Sigstore tooling stack and the OCI 1.1 referrers API, and the operational failure modes that high-profile incidents (SolarWinds, the Codecov bash uploader, the 3CX desktop client, the Sisense customer key incident, the ASUS Live Update compromise) exposed in unsigned release flows. Each of those incidents shared a common thread: an attacker compromised the build or distribution path, replaced the legitimate artefact with a tampered version, and the downstream consumers ran the tampered artefact because no integrity check could distinguish it from the legitimate one.

Regulator pressure now names integrity controls explicitly. EO 14028 and OMB M-22-18 / M-23-16 require federal software producers to provide a self-attestation that aligns with NIST SP 800-218 (SSDF). SSDF PS.2 names verification of release integrity. NIST SP 800-204D names signing as a load-bearing CI/CD control. The CISA Secure by Design pledge names signed releases as a transparency commitment. The EU Cyber Resilience Act names component integrity in Annex I. NIS2 Article 21(2) names supply-chain security as a required cybersecurity risk-management measure for essential and important entities. DORA Article 28 names ICT third-party risk management requirements that signed releases support.

The tooling stack matured at the same time. Sigstore reached v1.0 in October 2022, the OCI 1.1 referrers API stabilised, Kubernetes admission control through Kyverno and the Sigstore policy controller reached production scale, and major cloud providers shipped managed signing flows (AWS Signer for container images, Google Cloud Binary Authorization with Sigstore, Azure Container Registry signing). Image signing is no longer a research-grade practice; it is the operating norm for any organisation that ships container images and answers to a regulator or a customer security questionnaire.

The OCI Image Signing Landscape

The OCI ecosystem has converged on two dominant approaches for image signing, plus several vendor-specific implementations and one legacy approach that is now deprecated. Understanding which one to pick is the first operating decision.

Most enterprises end up running either cosign or notation as the primary, with one vendor-native flow for a specific provider context (a managed services line or a customer-facing cloud product). Running both is acceptable when the artefact classes are distinct (cosign for OSS-style releases, notation for detached corporate-PKI releases). Running both for the same artefact class is a smell; document the policy decision in writing rather than letting two tools drift independently.

Keyed vs Keyless Signing

Both Sigstore and notation support two signing modes. Picking the right mode is the second operating decision and the one that drives the rotation and incident-response posture for the rest of the programme.

The trade-off is well-understood. Keyed signing gives you cryptographic identity independent of any external identity provider; you own the root and the rotation schedule. Keyless signing removes the long-lived key from the threat model entirely but requires the verifier to trust the OIDC issuer (Sigstore public fulcio, or a private fulcio instance) and the transparency log. Most internal enterprise programmes settle on a hybrid: keyless for routine release signing tied to the build platform identity, KMS-backed keyed signing for offline release flows, emergency manual signing, and the air-gapped deployments where a transparency log is not reachable.

Whichever mode the programme picks, the signing policy must name it explicitly, name the rotation procedure for the keyed case, name the OIDC issuer trust list for the keyless case, and name the verifier-side policy that reads against signer identity. The decision belongs in the workspace policy document so any auditor can read what the programme commits to.

Transparency Logs and Why They Matter

Rekor is the Sigstore transparency log: a tamper-evident, append-only Merkle tree that records every signature event. The cosign CLI publishes the signature, the associated signer certificate, and a timestamp to rekor as a normal step in the sign command. Anyone, including downstream consumers, regulators, and the producer themselves, can later query rekor to verify that a specific signature was issued at a specific time under a specific identity.

Transparency logs solve a problem that signatures alone cannot: detection of backdated or repudiated signing events. A long-lived private key compromised today could in principle sign an artefact and backdate it to yesterday. A keyless signing certificate could in principle be issued for a build identity that was never actually run. The rekor log, by recording every signature event with an immutable timestamp and a witnessed Merkle proof, makes both of those scenarios detectable after the fact. The producer can audit their own log entries; the regulator can audit the log; the customer can audit the log.

The trade-off is the public-log dependency. A public rekor instance means every signature event is publicly visible. For most open-source releases that is the desired property. For some enterprise contexts (closed-source product releases, restricted customer flows, classified deployments) the public visibility is a non-starter. The mitigations are well-trodden: run a private rekor instance with controlled access, run rekor in a witnessed configuration where multiple parties co-sign the log root, or step down to notation where the trust model does not depend on a transparency log at all.

The operating point: if the programme adopts Sigstore, treat rekor as a load-bearing dependency. Monitor rekor availability, capture the rekor log entry alongside the signature in the workspace record, and document the policy for the closed-source case explicitly rather than letting individual teams skip the log silently.

Root of Trust: KMS, HSM, and the Sigstore TUF Root

Every signing programme has one or more roots of trust. They are the highest authority a verifier consults when deciding whether a signature is valid. Anyone who can replace or forge the root can sign anything. The root is the load-bearing artefact in the entire programme and deserves top-tier access control, hardware backing, and a published rotation procedure.

• Sigstore TUF root. The Sigstore project maintains a TUF (The Update Framework) root that distributes the fulcio CA public key, the rekor log public key, and the certificate transparency log roots. Verifiers download the TUF root and refresh it on a defined cadence. If the programme runs against the public Sigstore root, monitor TUF root rotation events; if it runs against a private Sigstore instance, the operator must run their own TUF root and a documented key ceremony.
• KMS-backed signing key. Cloud-managed KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) holds the private signing key with hardware-backed protection (FIPS 140-2 Level 3 or higher in most regulated regimes). The KMS becomes the root: anyone with the ability to call Sign on the KMS key can sign the image. Lock down IAM, require MFA on key operations, enable KMS-side audit logging, and rotate the key on a defined schedule.
• On-premises HSM. PKCS#11-compatible HSMs (Thales Luna, Entrust nShield, Utimaco SecurityServer, YubiHSM 2 for smaller programmes) hold the private signing key with physical security guarantees and a documented key ceremony. Right choice for regulated regimes that require on-premises hardware control or that have an existing PKI hosted on HSMs.
• Notation trust store. The notation CLI verifies against a configured trust store listing the trusted signing CA certificates. The trust store is the root for the notation flow; distribute it through a controlled channel, sign updates to it, and capture every change in the workspace record.

Document the root of trust in the signing policy. Treat root-of-trust ceremonies (initial generation, scheduled rotation, emergency rotation, decommission) as high-severity engagement records: named witnesses, named cryptographic officer, documented procedure, evidence-of-completion stored alongside the cryptographic artefacts.

The Producer Surface: Signing at Build Time

On the producer side, signing is a CI/CD step that runs after the image is built and pushed but before the image is published as released. The shape is consistent across tools:

1. The build platform produces the image and pushes it to the registry under a build-specific tag (typically a digest reference, not a floating tag).
2. The build platform invokes the signing CLI (cosign sign, notation sign, or the vendor equivalent) with the image digest and the signing identity (an OIDC token for keyless, a KMS key reference for keyed, an HSM-backed key for on-premises).
3. The signing CLI produces the signature artefact and pushes it to the registry as an OCI 1.1 referrer of the image. For Sigstore, the rekor log entry is also published.
4. Optionally, the build platform produces additional attestations (SLSA provenance, an SBOM in SPDX or CycloneDX, a VEX statement, scan results from Trivy or Grype) and attaches them to the image as additional signed referrers.
5. The build platform moves the floating tags (latest, edge, release-candidate, prod) only after the signature is verified by an automated post-sign verification step in CI. This catches misconfiguration before the artefact reaches a customer or a cluster.
6. The build event lands in the activity log with the build identity, the artefact digest, the signature reference, the rekor log entry (or notation signature), and the named owner of the release.

The producer-side path must produce evidence. The signing event itself is the evidence; capture it as part of the engagement record so AppSec, GRC, and product security can read the same release history when the customer or the auditor asks. The CISA Secure Software Development Attestation explicitly expects this evidence trail under the SSDF PS.2 mapping.

The Consumer Surface: Admission-Time Verification

The verification surface is where most programmes fail. Producing signatures is mechanical; verifying them at the right point with the right policy is the operating discipline that turns signing into a control rather than a label. The dominant verification surface is admission control inside Kubernetes; equivalent surfaces exist for non-Kubernetes deployments (Nomad with image-policy plugins, AWS Lambda with Signer-enforced verification, Azure Container Apps with built-in verification).

The admission policy is the load-bearing artefact on the consumer side. Treat it like the WAF rule set or the IAM policy: version-controlled, peer-reviewed, tested in non-production before production, and observable in the activity log when a denial event happens. An admission policy that fails open (admits unsigned images on verification error) is not a control; it is a label.

Cluster-scope policies belong in the workspace record. Each policy change is an engagement with a named owner, a target close date, and an evidence-of-closure requirement. The same review cadence applies that the breach and attack simulation guide names for control validation: rehearse the admission policy regularly with a test unsigned image and capture the denial event as evidence.

Image Signing Inside the SLSA Build Levels

SLSA Build Level 2 expects the build platform to produce a signed provenance attestation describing how the artefact was built: source identity, build steps, materials consumed, builder identity. Build Level 3 hardens that further: the provenance is non-falsifiable, the build runs in an isolated environment, and the provenance is signed by the build platform itself rather than by a developer.

Container image signing is how SLSA provenance reaches the consumer. The cosign CLI (and the notation equivalent) attaches the in-toto attestation describing the build provenance to the image as a separately signed referrer. The verifier reads the signature, then reads the attestation, then makes a policy decision: was this image built by the expected build platform, from the expected source, under the expected workflow? The SLSA framework defines what the provenance must contain; image signing defines how it is delivered and verified.

For a programme that targets SLSA Build L2 or L3, the operating picture is consistent: the build platform produces both the image and the provenance attestation, the build platform signs both with the keyless or KMS-backed identity, the verifier reads both at admission, and the policy reads against the provenance fields (builder identity, source repo, source commit, workflow path). The signing programme and the SLSA programme are not two programmes; they are one programme with two evidence artefacts attached to the same release identity.

Key Rotation and Incident Response

Key rotation is the operational discipline that separates a real signing programme from a paper one. Three rotation scenarios must each have a written procedure.

• Scheduled rotation. Define a calendar cadence (typically annual for KMS-backed keys, shorter for keys on critical paths) and rotate on schedule. The rotation procedure names the new key generation step, the signing-policy update, the verifier-side policy update (publish the new public key, keep the old key trusted for a defined overlap window), and the retirement step (remove the old key from the verifier-side trust list once no signed artefact under the old key remains in production).
• Emergency rotation. Triggered by suspected or confirmed key compromise. The procedure names the immediate revocation step (remove the compromised key from the verifier-side trust list, even if downtime results), the customer and regulator notification path, the re-signing step for affected artefacts under a new key, and the post-incident review that lands in the workspace as a high-severity engagement with a named owner and a target close date. NIS2 Article 23 and DORA Article 19 name the regulator notification timelines that an emergency rotation triggers.
• OIDC-trust rotation for keyless. When the OIDC issuer the keyless signing flow trusts changes (a new fulcio CA, a new GitHub Actions OIDC issuer, a new private fulcio instance), the verifier-side trust list must update. The cadence is dictated by the issuer; capture the issuer rotation calendar in the workspace and reconcile the verifier-side policy on every change.

Each rotation is a documented event. The activity log captures who initiated the rotation, who approved it, when the new identity went live, and when the old identity retired. The signing policy document is amended in document-management with named custodian and version history. The compliance grid reads the rotation log against ISO 27001 Annex A 8.24 (use of cryptography), SOC 2 CC6.1 (logical and physical access controls), PCI DSS 3.7 (cryptographic key management), and NIST SP 800-53 SC-12 (key establishment and management).

Audit Evidence the Programme Carries

Every regulator, customer security questionnaire, and internal audit cycle reads against roughly the same set of signing evidence. Build the evidence pack once and re-use it across audits.

• Signing policy document with named custodian, version history, current root of trust, current signer identities, allowed verification surfaces, rotation cadence, emergency rotation procedure, exception process, and named amendment triggers.
• Producer-side signing event log: per release, the artefact digest, the signer identity, the rekor log entry (for Sigstore) or detached signature reference (for notation), the named release owner, the named approver, and the build identity (workflow path plus commit SHA).
• Consumer-side admission policy with named owner, current allowed signer identities, denial-event sample, and policy-change history.
• Verification rehearsal record: scheduled exercises where a deliberately unsigned or maliciously-signed test image is presented to the admission surface and the denial event is captured as evidence. The same pattern the BAS guide describes for control validation more broadly.
• Key ceremony records for KMS-backed and HSM-backed signing keys: named participants, date, witnessed steps, key material destination, key material retirement procedure.
• Exception register entries for any release that bypassed signing or any cluster that runs with verification disabled, with a named owner, a target remediation date, and a documented compensating control.
• Cross-framework compliance grid mapping the signing evidence against SSDF PS.2 and PW.6, NIST SP 800-204D Sections 4 and 5, NIST SP 800-190 Section 4, NIST CSF 2.0 PR.DS-06 and PR.PS-01, ISO 27001 Annex A 8.24 and A 8.28, SOC 2 CC6.1 and CC7.1, PCI DSS Req 6.5 and 6.6, EU CRA Annex I, NIS2 Article 21(2)(e) and (h), and DORA Article 28.

The evidence pack is the artefact the auditor reads, the customer reads, and the board risk committee reads. Keep it in one record. SecPortal's document-management, engagement-management, activity-log, and compliance-tracking together hold this evidence shape; the signing operations themselves stay in the build platform and the registry.

Common Image Signing Failure Modes

Seven failure modes recur across signing programmes. Each is a signal to read the operating record against the policy commitments rather than a tooling problem to solve with a different CLI.

Each failure mode is a finding in the workspace record. Open it against the named release owner, name the compensating control, set a target close date, and let the retesting workflow verify the fix.

A Pragmatic Image Signing Rollout

A typical enterprise rollout runs over six to twelve months across five phases. Each phase produces evidence that can be read against the regulator-side expectations and against the internal operating record.

1. Phase 1: Scope and policy. Name the artefact classes in scope (production container images first, internal-only images and CI tooling later, Helm charts and other OCI artefacts last). Pick the signing tool (cosign, notation, or a vendor flow) and the signing mode (keyless, keyed, or hybrid). Define the signer identities and the root of trust. Land the signing policy document in document-management and capture the decision in the activity log.
2. Phase 2: Producer-side signing. Wire the signing step into the build platform for every in-scope artefact class. Verify the signature in CI after every sign step. Land each signing event in the activity log. Target output: every production image published in the rolling window carries a signature with a named build identity.
3. Phase 3: Verifier-side admission policy in non-production. Install the admission controller (Sigstore policy controller, Kyverno, or equivalent) in non-production clusters with a deny-on-failure policy. Rehearse against deliberately unsigned and maliciously signed test images. Capture rehearsal records as evidence.
4. Phase 4: Verifier-side admission policy in production. Promote the admission controller to production behind a feature flag that initially warns rather than denies, monitor admission events for one to two weeks, then switch to deny mode. Capture the cutover event in the activity log with named owners. The cutover is the point where image signing becomes a control rather than a label.
5. Phase 5: Hardening and evidence pack. Add SLSA provenance attestation, SBOM attestation, and VEX attestation on the same signature. Build the cross-framework compliance grid. Wire the signing programme into the quarterly programme review (the security program quarterly review template names the cadence). Rehearse a scheduled key rotation and an emergency key rotation. Capture both as engagement records.

The phasing is deliberate. Producer-side signing without verifier-side admission is a label. Verifier-side admission without producer-side discipline is denial events with no signal. The five phases together produce a control that the regulator, the customer, and the board can read.

Where the Signing Programme Sits Alongside SecPortal

SecPortal does not sign container images, run a signing service, distribute a trust root, operate an admission controller, host a transparency log, ingest production cluster telemetry, or replace the build platform that owns the signing artefacts. Image signing happens on the build platform, the signing CLI, the registry, the transparency log, the KMS or HSM, and the admission controller. The cryptographic chain belongs there, not in a workspace tool.

SecPortal holds the operating record around the signing programme so AppSec, product security, platform engineering, GRC, and CISOs can read the same workspace record when the auditor or the customer asks. Code-scanning runs Semgrep against the connected GitHub, GitLab, and Bitbucket repositories where the signing CLI is invoked from, so configuration drift in the signing step shows up as a finding against the same record the policy document lives in. Bulk-finding-import ingests Trivy, Grype, Snyk Container, or any other container-scan output through CSV alongside the signature evidence so the integrity layer and the vulnerability layer sit on the same engagement record.

Document-management stores the signing policy with named custodian, version history, and the immutable amendment record. Activity-log captures every policy review and approval with named actor, timestamp, and CSV export by 30, 90, or 365-day retention depending on plan. Team-management gates read and amend access through RBAC (owner, admin, member, viewer) so the policy custodian and the release owners have the authorities the signing programme requires. Multi-factor authentication is enforced via TOTP on the workspace itself so the sign-off events are not phishable. Compliance tracking maps the signing evidence pack against SSDF PS.2 and PW.6, NIST SP 800-204D, NIST SP 800-190, ISO 27001 Annex A 8.24 and 8.28, SOC 2 CC6.1 and CC7.1, PCI DSS Req 6.5 and 6.6, EU CRA Annex I, NIS2 Article 21(2)(e) and (h), and DORA Article 28 with CSV export.

Engagement-management ties third-party signing audits (vendor signing assessment, key ceremony witnessing, regulator audit) to the same workspace where the policy lives. Retesting-workflows verify that an exception is closed by re-running the admission-time check against the previously-failing image. Finding-overrides record compensating controls for exception cases (a closed-source artefact that cannot publish to a public transparency log, a legacy artefact under Notary v1 awaiting migration) with the eight-field decision chain that names the operator, the justification, the compensating control, the target remediation date, and the renewal cadence. AI reports drafts a leadership summary and an audit-ready evidence pack from the same record so the CISO read, the auditor read, and the customer read all share one source.

None of these features sign anything, verify anything cryptographically, or replace the build platform. They are the workspace that the signing programme reads against so AppSec, product security, platform engineering, GRC, and CISOs do not each run a parallel record that drifts apart. Reading the same workspace is how a signing programme stays a programme rather than a tool deployment.

Wider Reading

Container image signing sits inside a wider supply-chain operating model. The following pages cover the adjacent layers from different angles.

• Software supply chain security guide for the umbrella programme that signing sits inside.
• SLSA framework explained for the build-integrity model and the provenance the signature carries.
• SBOM guide for the component-inventory artefact that rides under the same signature.
• VEX guide for the exploitability statement that filters the SBOM-derived CVE tail.
• CISA SSDA guide for the federal attestation that reads signing under SSDF PS.2.
• NIST SSDF implementation guide for the secure development practice groups signing operationalises.
• EU CRA guide for the EU regulatory frame that names integrity in Annex I.
• DORA ICT third-party risk implementation guide for the financial-services regime that names signed releases under Article 28.
• Breach and attack simulation guide for the control-validation cadence the admission policy rehearsals fit inside.
• Security control validation runbook template for the per-control rehearsal procedure that proves the admission policy still behaves as designed.
• Security program quarterly review template for the management-review cadence the signing programme reads against.
• Code scanning for the Semgrep-based scan of the repositories where the signing step lives.
• Audit evidence retention and disposal for the lifecycle policy that governs how long each piece of signing evidence stays on the record.
• NIST SSDF, ISO 27001, SOC 2, and CISA Secure by Design for the framework-side reads that share the signing evidence stack.
• SecPortal for product security teams and SecPortal for AppSec teams for the persona-side reading paths into the signing record.

Frequently Asked Questions