Category: Software Supply Chain

Artifact Signing

Also known as: Code Signing, Binary Signing, Digital Signing

Simply put

Artifact signing is a security process that attaches a digital signature to a software artifact (such as a compiled binary, container image, or package) to confirm that it has not been tampered with and to verify who produced it. This helps users and systems trust that the software they receive is authentic and unmodified since it was built. Signing typically happens at the end of the build process before an artifact is released or distributed.

Formal definition

Artifact signing is a cryptographic process that ensures the integrity and provenance of a released artifact or binary. It works by generating a digital signature over the artifact's content using a private key, allowing consumers to verify the signature with the corresponding public key to confirm that the artifact has not been altered and to authenticate its origin. Implementations vary across ecosystems: some rely on certificate authority-issued signing certificates, while others use PGP-based key pairs, keyless signing flows (such as Sigstore/Cosign), or other trust models. Because signing operates on the final artifact, it is generally simpler to implement than build attestation, though it does not by itself capture metadata about how or where the artifact was built. Signing does not detect vulnerabilities or malicious logic within the artifact; it only asserts integrity and a binding to a signing identity.

Why it matters

Artifact signing serves as a foundational trust mechanism in software supply chains. Without it, consumers of a software artifact, whether end users, automated deployment pipelines, or downstream developers, have no cryptographic assurance that the artifact they received is the same one that was produced by the claimed author. This gap creates opportunities for attackers to substitute tampered or entirely malicious artifacts during distribution, a category of attack that has proven both practical and damaging in real-world supply chain compromises.

By binding a verifiable identity to an artifact's content, signing enables both humans and automated systems to enforce policies such as "only deploy artifacts signed by our build system" or "only install packages from a known publisher." This is especially important in environments where artifacts traverse multiple repositories, mirrors, or caching layers before reaching their final destination, since each hop introduces a potential point of tampering. Organizations that lack signing verification at consumption points may be unable to distinguish a legitimate update from a supply chain attack.

It is important to note that artifact signing addresses integrity and provenance, not safety. A properly signed artifact can still contain vulnerabilities or even intentionally malicious code. Signing confirms who produced the artifact and that it has not been altered since signing, but it does not make any assertion about the quality or security of the artifact's contents. For this reason, artifact signing is typically one layer in a broader defense-in-depth strategy that also includes vulnerability scanning, build attestation, and access controls on signing keys.

Who it's relevant to

DevOps and Release Engineers

Release engineers are typically responsible for integrating signing into CI/CD pipelines. They must select the appropriate signing mechanism for their ecosystem, manage or configure access to signing keys or keyless identity flows, and ensure that signing is applied consistently to every artifact before publication.

Security Architects and AppSec Teams

Security architects define signing policies, choose trust models (CA-based, PGP, keyless), and establish verification requirements at consumption points. They also assess whether signing alone is sufficient or whether additional controls like build attestation are needed to meet the organization's supply chain security goals.

Platform and Infrastructure Engineers

Teams responsible for container orchestration, package repositories, and deployment infrastructure must configure signature verification at ingestion and deployment gates. Without enforcement on the consumption side, signing provides no practical protection.

Software Consumers and Downstream Developers

Anyone who downloads or depends on third-party artifacts benefits from verifying signatures before use. This includes developers pulling open-source packages, organizations consuming vendor-supplied binaries, and automated systems fetching container images from registries.

Compliance and Governance Teams

Artifact signing is increasingly referenced in supply chain security frameworks and regulatory guidance. Compliance teams need to understand what signing does and does not guarantee, specifically that it asserts integrity and provenance but not the absence of vulnerabilities or malicious logic, to accurately represent the organization's security posture.

Inside Artifact Signing

Cryptographic Signature

A digital signature generated using asymmetric cryptography (typically a private key) that is attached to or associated with a software artifact, enabling consumers to verify both the identity of the signer and the integrity of the artifact.

Signing Key or Certificate

The cryptographic material used to produce the signature. Depending on the ecosystem, this may be a certificate issued by a certificate authority (common in Windows Authenticode and Java code signing), a PGP key pair, or an ephemeral key bound to an identity through a transparency log (as in Sigstore keyless flows).

Verification Metadata

Supporting data that enables signature verification, which may include public keys, certificate chains, transparency log entries, or trust root configurations depending on the signing framework in use.

Artifact Digest

A cryptographic hash of the artifact content that serves as the basis for the signature. The digest ensures that any modification to the artifact after signing will cause verification to fail.

Trust Model

The framework that defines how verifiers establish trust in the signing identity. Trust models vary significantly across ecosystems, ranging from hierarchical certificate authority chains, to web-of-trust models (PGP), to transparency-log-backed identity binding (Sigstore).

Signature Format and Placement

The encoding and storage mechanism for the signature itself. Signatures may be embedded within the artifact (e.g., in-toto attestations, Authenticode PE signatures), stored as detached files (e.g., .asc files for PGP), or recorded in external registries or transparency logs.

Common questions

Answers to the questions practitioners most commonly ask about Artifact Signing.

Does artifact signing guarantee that an artifact is free of vulnerabilities or malicious code?

No. Artifact signing verifies the identity of the signer and confirms the artifact has not been modified since signing. It does not make any assertion about the quality, safety, or vulnerability status of the artifact's contents. A legitimately signed artifact can still contain bugs, vulnerabilities, or even intentionally malicious code if the signer's environment was compromised before signing occurred.

Does artifact signing always require a certificate from a traditional certificate authority (CA)?

No. While some ecosystems such as Windows Authenticode and Java code-signing typically rely on CA-issued signing certificates, many other approaches exist. PGP-signed source tarballs use a web-of-trust model, Sigstore enables keyless signing flows tied to OIDC identities, and container image signing with Cosign can operate without a traditional external CA. The signing mechanism and trust model vary significantly by ecosystem and toolchain.

How should signing keys be stored and managed in a CI/CD pipeline?

Signing keys should be stored in a hardware security module (HSM), a cloud-based key management service (KMS), or a similarly hardened secrets store, never in source control or pipeline configuration files. Access to signing operations should be restricted through role-based controls, and audit logging should be enabled. Some organizations use ephemeral or short-lived signing credentials (as in Sigstore's keyless model) to reduce the risk associated with long-lived key material.

At what point in the software delivery process should artifacts be signed?

Artifacts should typically be signed as close to the build process as possible, ideally as a final step in a controlled, reproducible build pipeline. Signing at this stage helps ensure that the artifact being signed matches what was built and tested. Verification should then occur at every subsequent trust boundary, such as registry upload, deployment, and runtime admission.

What happens if a signing key is compromised?

If a signing key is compromised, all artifacts signed with that key become suspect because an attacker could have signed malicious artifacts that appear legitimate. Response steps typically include revoking the compromised key or certificate, rotating to a new key, re-signing trusted artifacts with the new key, and notifying downstream consumers. Having a documented key rotation and revocation plan in place before an incident occurs is essential for timely response.

How should signature verification be enforced in practice?

Signature verification should be enforced at policy-defined trust boundaries rather than relying solely on optional or manual checks. Examples include configuring container orchestrators (such as Kubernetes admission controllers) to reject unsigned or invalidly signed images, setting package manager policies to require valid signatures, and integrating verification checks into deployment pipelines. Without automated enforcement, signature verification may be inconsistently applied, reducing its effectiveness.

Common misconceptions

Artifact signing guarantees that the signed software is free of vulnerabilities or malicious code.

Artifact signing attests to the identity of the signer and confirms the artifact has not been tampered with since signing. It provides no assurance about the quality, safety, or security of the artifact's contents. A legitimately signed artifact may still contain vulnerabilities, backdoors, or malicious dependencies.

Artifact signing always requires a certificate authority-issued signing certificate.

While certificate authority-issued certificates are common in certain ecosystems such as Windows Authenticode and Java JAR signing, many widely used approaches do not rely on external CAs. PGP-signed source tarballs use a web-of-trust model, Sigstore's keyless signing binds ephemeral keys to identities via OIDC and transparency logs, and container image signing with Cosign may use local key pairs or keyless flows. The trust model depends on the ecosystem and tooling.

Once an artifact is signed, the signature remains trustworthy indefinitely.

Signatures can become untrustworthy over time due to key compromise, certificate expiration, or revocation. Organizations typically need to manage key rotation, monitor revocation status, and in some cases re-sign artifacts. Transparency-log-based approaches (such as Sigstore's Rekor) address this partially by recording the time of signing, allowing verification that a signature was valid at the moment it was created.

Best practices

Store signing keys in hardware security modules (HSMs) or similarly hardened key management systems to reduce the risk of key compromise, and enforce strict access controls on who and what can initiate signing operations.

Automate artifact signing as an integrated step in CI/CD pipelines rather than relying on manual processes, ensuring every released artifact is consistently signed without depending on individual developer action.

Implement signature verification as a mandatory gate in deployment and consumption workflows so that unsigned or incorrectly signed artifacts are rejected before they reach production environments.

Establish and document a key rotation and revocation strategy appropriate to the signing framework in use, including procedures for responding to suspected key compromise and re-signing affected artifacts when necessary.

Select a signing approach and trust model appropriate to your ecosystem and threat model. Evaluate whether CA-issued certificates, PGP key pairs, or transparency-log-backed keyless signing (e.g., Sigstore) best fits your supply chain requirements.

Maintain transparency and auditability by logging all signing events, and where available, leverage public transparency logs to provide tamper-evident records that allow independent verification of when signatures were created.