Code signing is the cryptographic process of attaching a digital signature to a software artifact so any consumer can verify two things: who built it, and that nothing has changed since. It is the control that makes the rest of supply chain security verifiable. Without signatures, the SBOM, the build provenance, and the artifact itself can all be modified silently in transit.
This guide walks through what code signing is, how digital code signing works step by step, what it does and does not protect against, and how modern code signing software (Sigstore, keyless certificates, transparency logs) is replacing the older long-lived-key model.
Code signing is the cryptographic process of attaching a digital signature to a software artifact to prove its authenticity and integrity. A consumer learns two things at once from a valid signature: that the artifact came from the stated publisher (authenticity), and that it has not changed byte-for-byte since the publisher signed it (integrity).
Signing applies to any software artifact: container images, executables, packages, libraries, scripts, SBOMs (Software Bills of Materials), Helm charts, and other files generated during the software development lifecycle.
The control exists because modern software passes through many environments before reaching the consumer: developer workstations, cloud build systems, artifact registries, CDNs, and end-user deployments. Each handoff is an opportunity for tampering or corruption. A signature creates an immutable cryptographic record that survives every handoff and lets any party independently verify that nothing changed.
The closest physical analog is a wax seal on a letter. A broken seal signals that the letter was opened between sender and recipient. A mismatched code signature signals the same thing for software.
In production cloud-native environments, signing is the cryptographic floor under hardened image platforms. Minimus, for example, signs every container image, SBOM, and provenance attestation it ships using Sigstore cosign, with all signing events logged to a public transparency log so any consumer can verify the artifact independently.
A code signing certificate is a digital file issued by a trusted Certificate Authority (CA) that binds a public key to the identity of a software publisher. It is the credential that lets users and systems verify who signed a piece of software.
A code signing certificate contains:
There are three common code signing certificate types in production today: a standard (OV) code signing certificate, an extended validation code signing certificate (also called an EV code signing certificate), and a short-lived keyless certificate.
Common CAs for code signing include DigiCert, Sectigo, GlobalSign, and open-source options such as Sigstore Fulcio, which issues short-lived ephemeral certificates tied to identity providers rather than long-lived keys. The Sigstore approach is growing fastest in cloud-native and containerized environments because it removes the long-lived private key as an attack target entirely.
Code signing relies on four foundational components from public key cryptography: a public key, a private key, a digital certificate, and a hash. Each one fails differently when broken, which is why understanding all four matters for supply chain security.
A public key is a shareable cryptographic value linked to a specific publisher. Anyone, including users, automated systems, and package managers, uses it to verify a signature without needing access to the private key. Public keys are distributed via code signing certificates.
A private key is a secret cryptographic value known only to the software publisher. It generates signatures. The security of the entire system depends on keeping the private key secret. If a private key is stolen, attackers can sign malicious software as if it came from the legitimate publisher, and downstream consumers see a valid signature.
A digital certificate packages a public key together with verified identity information about its owner and is issued by a trusted Certificate Authority. It is the mechanism that ties a public key to a real-world identity, allowing relying parties to trust who created the signature.
A hash is a fixed-length value computed from the full contents of a software artifact using a hashing algorithm such as SHA-256. Every unique artifact produces a unique hash. If even a single byte of the artifact changes, the hash changes completely. Hashes are the mechanism that enables byte-for-byte integrity verification.
Code signing follows a four-step process that runs once at publish time and again every time a consumer verifies the artifact.
The software publisher generates a public/private key pair (the signing key pair). The private key is kept secret, ideally in a Hardware Security Module (HSM). The public key is embedded in a digital certificate issued by a Certificate Authority and shared publicly.
Before signing, the publisher computes a cryptographic hash of the exact artifact being signed (a container image, binary, or SBOM). This hash is a unique fingerprint of that artifact at that moment in time.
The publisher feeds the hash through a signing algorithm using their private key. This produces a unique digital signature mathematically linked to both the artifact's content (via the hash) and the publisher's identity (via the private key).
When a user or system downloads the artifact, they recompute the hash of the downloaded artifact, use the publisher's public key to decrypt and verify the signature, and compare the two hashes. If the hashes match, the artifact is verified as authentic and unmodified. If they do not match, the artifact was modified after signing, whether through malicious injection, file corruption, or incomplete transfer.
Three additions strengthen the basic flow:
In a typical Minimus image build, this four-step flow is fully automated. The pipeline computes the hash on the source-built image, signs with an ephemeral Sigstore Fulcio certificate, logs the signature and SBOM to Rekor, and ships the verifiable artifact in a single pass. There is no key vault to manage and no manual signing step for the engineering team to remember.
Code signing delivers four operational benefits and one regulatory benefit, and each maps to a specific supply chain attack class.
Code signing provides byte-for-byte integrity verification. Any change to a signed artifact (malicious code injection, incomplete file transfer, or data corruption) changes the hash and invalidates the signature. Tampering becomes detectable at any point in the supply chain. A consumer of a Minimus hardened image, for example, can run cosign verify against the public Rekor log and confirm in under a second that the image matches the build pipeline that produced it.
Code signing proves an artifact was released by a specific, verified publisher. Users can confirm a container image, package, or binary actually came from the organization it claims to come from, not from an impersonator or compromised distribution channel.
Many high-profile supply chain incidents involved malicious code injected at a build or distribution stage after legitimate code was written. The SolarWinds Orion compromise (CVE-2020-10148, CISA Alert AA20-352A, December 2020) and the XZ Utils backdoor (CVE-2024-3094, disclosed March 2024) both took this shape. Code signing that covers the build pipeline, not just the final artifact, makes these attacks detectable.
Code signing is now a mandatory or near-mandatory control across modern compliance frameworks:
Combined with transparency logs (Sigstore Rekor), code signing creates a permanent, tamper-evident record of every signing event: who signed, what artifact, with which key, and when. Regulators and incident responders increasingly expect this record to exist.
Code signing applies to virtually any software artifact, and most modern code signing tools target multiple artifact types in a single workflow. Container image signing and SBOM signing are the most common signing targets in cloud-native environments because both move through multiple registries and tools before reaching production.
For container images specifically, signed SBOMs and signed provenance attestations together let a consumer verify both what is inside the image and how it was built. This is the basis of moving from SBOM toward CBOM (Cryptographic Bill of Materials) for full cryptographic visibility.
Code signing is a critical control, but it does not guarantee that signed software is safe. Understanding the limitations prevents overreliance on signatures alone.
If an attacker obtains a publisher's private key, they can sign malicious software as if it came from the legitimate publisher, and users will see a valid signature with no indication the software is compromised. The fix is hardware. Store private keys in HSMs, use ephemeral keys via Sigstore keyless signing, and rotate on a schedule.
Attackers with access to a software repository or build environment can inject malware before the code is signed. Developers then unknowingly release legitimately signed but compromised software. This was the vector in the XZ Utils backdoor in 2024 and in the Trivy v0.69.4 supply chain compromise. Harden the build runner. SLSA Build L3 platforms and tools like StepSecurity Harden-Runner exist for this purpose, alongside code review and audit before signing.
Attackers may create certificates with names or details similar to a trusted publisher, tricking users who do not inspect certificate details carefully. Certificate Transparency logs catch most impersonation attempts. Always verify the full certificate chain and publisher identity, not just the presence of a signature.
Code signing verifies the integrity of a specific signed artifact, but it does not guarantee the artifact's dependencies are also secure. A validly signed container image may pull and run malicious or vulnerable dependencies at runtime. Pair signing with Software Composition Analysis (SCA), SBOM generation, and dependency pinning. Signing covers the artifact; SCA covers what is inside it.
Long-lived signing keys that are exposed or stolen can be abused for the full duration of the certificate's validity (1 to 3 years). Use short-lived certificates instead. Sigstore Fulcio issues them for minutes, which closes the abuse window almost entirely.
A working code signing program in 2026 looks roughly like this:
Hardened image platforms like Minimus apply most of these defaults out of the box. Every image ships signed, with a signed SBOM and a SLSA Build L3 provenance attestation, so engineering teams inherit the practices rather than having to build the pipeline themselves.
Sigstore is an open-source project (originally developed by Google, Red Hat, and Purdue University, now under the Open Source Security Foundation) that provides a free, standardized suite of tools for software signing, verification, and transparency. It is the emerging standard for supply chain security signing in the open-source ecosystem.
Traditional code signing requires publishers to generate and securely store long-lived private keys, manage certificate renewals every 1 to 3 years, and protect those keys against theft for the full validity period. Sigstore keyless signing removes long-lived keys from the equation entirely. The publisher authenticates via an OIDC token (a GitHub Actions identity, a Google account), Fulcio issues a certificate valid for only a few minutes, the certificate and signature are logged to Rekor, and the ephemeral private key is discarded after signing. There is nothing left for attackers to steal.
The operational consequence is that signing becomes a default, not a project. CI/CD pipelines sign every build automatically, no key vault to manage, no rotation schedule to maintain.
Minimus treats container image signing and SBOM signing as default product behavior: every hardened container image, SBOM, VEX document, and provenance attestation it produces is signed with Sigstore cosign as part of a SLSA Build L3-aligned pipeline. Signing is applied at build time on the source-built image, not bolted on after distribution, so consumers can cryptographically verify that what they are pulling from the Minimus Hardened Image Gallery is exactly what Minimus built, with no modification at any point in the distribution chain.
Concretely, every Minimus image version ships with:
Verification is a single cosign verify command in CI/CD or in a Kubernetes admission controller. Because Minimus is image- and supply-chain-centric (not a runtime CNAPP), signing is treated as a primary product surface rather than a feature flag.
Code signing proves who created a piece of software and that it has not been modified. It does not hide the content. Signed software can be read by anyone. Encryption hides content from unauthorized parties but does not prove who created it or whether it was tampered with. They solve different problems and are often used together. A signed artifact can also be encrypted for confidential distribution.
Keyless code signing is a signing approach pioneered by Sigstore that eliminates the need for long-lived private keys. A publisher authenticates via an identity provider (GitHub, Google, Microsoft), receives an ephemeral certificate valid for a few minutes, signs the artifact, and discards the key. All events are logged to a public transparency log. Because no persistent private key exists, there is nothing for attackers to steal and reuse.
Code signing proves a software artifact's integrity and authenticity (that it was not tampered with and came from the stated publisher). An SBOM (Software Bill of Materials) is an inventory of every component, library, and dependency in a piece of software, including versions and licenses. They are complementary: a signed SBOM proves the inventory itself has not been tampered with, while SCA tools use the SBOM data to check whether listed components contain known vulnerabilities.
No. Code signing proves an artifact is unmodified and authentic. It does not evaluate the security quality of the code itself. A legitimately signed artifact may still contain vulnerabilities, malicious dependencies, or backdoors introduced before signing. Code signing should be combined with SCA, SBOM generation, vulnerability scanning, and secure build practices for a complete supply chain posture.
Minimus applies container image signing and SBOM signing to every hardened image, VEX document, and SLSA Build L3 provenance attestation at build time using Sigstore cosign. Signatures are logged to the public Rekor transparency log, so any consumer can verify with a single cosign verify command that the image they pulled is exactly what Minimus built. There are no long-lived keys to manage and no post-distribution signing step. Every image ships verifiable by default.
Code signing is the cryptographic floor under modern software supply chain security. Without it, every other control (SBOMs, vulnerability scanners, provenance attestations, compliance dashboards) is reading data that could have been altered between the publisher and the consumer. With it, every layer becomes verifiable.
When we audit signing pipelines, the same failure pattern keeps coming up. The headline binary is signed, but the SBOM is not. The provenance attestation often is not either. Helm charts almost never are. Each of those gaps is a place an attacker can substitute content without breaking the visible signature on the headline artifact. The point of modern signing infrastructure (Sigstore, keyless certificates, transparency logs) is to make signing every artifact cheap enough that there is no reason to skip any of them.
.svg)
.svg)
.svg)
.svg)
