Artifact signing is the process of attaching a cryptographic signature to a software artifact — a container image, binary, package, or build output — so that anyone downstream can verify who produced it and that it hasn't been altered since. It's the mechanism that turns "we trust this came from our build system" into a mathematically checkable fact instead of an assumption. Without it, a compromised registry, a poisoned CI runner, or a man-in-the-middle on a package mirror can swap out a legitimate artifact for a malicious one, and nothing downstream will notice. That's exactly what happened in the SolarWinds breach (disclosed December 2020) and the Codecov bash uploader compromise (April 2021) — both involved tampering with build or distribution pipelines that had no cryptographic verification step. Artifact signing, paired with signature verification at deploy time, closes that gap by making unsigned or mismatched artifacts detectable and blockable before they run.
What is artifact signing?
Artifact signing is the act of using a private key (or a short-lived keyless identity) to generate a digital signature over the hash of a software artifact, which any consumer can later verify against the corresponding public key or certificate. The artifact itself — a Docker image, an npm package, a Terraform module, a Java JAR — is never modified; instead, a separate signature file or in-toto attestation is generated and stored alongside it, typically in a registry like OCI or a transparency log. When someone pulls that artifact, their tooling recomputes the hash and checks it against the signature. If the hash doesn't match, or the signature doesn't verify against a trusted key, the artifact is rejected. This is the same underlying cryptographic principle as HTTPS certificates or GPG-signed Git commits, applied to build outputs instead of web servers or code changes.
How does artifact signing actually work in a CI/CD pipeline?
In practice, signing happens as the last step of a build job, right after the artifact is produced and before it's pushed to a registry. A build system like GitHub Actions, GitLab CI, or Jenkins invokes a signing tool — commonly Sigstore's cosign — which hashes the artifact, signs that hash, and pushes the resulting signature to the same OCI registry as a separate manifest. With Sigstore's keyless flow (generally available since 2021), the CI job authenticates via OIDC to Fulcio, which issues a short-lived X.509 certificate valid for about 10 minutes — just long enough to sign — and the transaction is recorded permanently in the Rekor transparency log for public auditability. On the consumption side, a Kubernetes admission controller such as Kyverno or OPA Gatekeeper, or a CLI check in the deploy pipeline, calls cosign verify before the artifact is allowed to run. If verification fails, the deployment is blocked automatically, with no human in the loop required to catch it.
Why does artifact signing matter for software supply chain security?
Artifact signing matters because it's the control that directly stops tampered or substituted artifacts from reaching production, which is the exact failure mode behind several of the highest-impact supply chain incidents of the last five years. In the 2022 discovery of typosquatted and hijacked npm packages (including the ctx and coa package compromises that fall of that year), attackers pushed malicious versions to the registry under legitimate-looking names; unsigned packages gave install tooling no way to distinguish the real maintainer's build from the attacker's. The US Executive Order 14028 (May 2021) and the resulting NIST Secure Software Development Framework (SP 800-218, published February 2022) both name artifact integrity verification as a baseline control for any vendor selling software to the federal government. Registries have followed: npm shipped provenance attestations in June 2023, and PyPI adopted digital attestations under PEP 740 in 2023, both built on Sigstore, specifically to give consumers a way to check that a published package matches its source build.
What's the difference between keyed and keyless signing?
Keyed signing uses a long-lived private key that a team generates, stores (usually in a KMS or HSM), and rotates on a fixed schedule — commonly every 90 days — while keyless signing, popularized by Sigstore, issues a brand-new short-lived certificate for every single signing event tied to a verified identity like a CI workload's OIDC token. The tradeoff is operational: keyed signing requires you to build key storage, access control, and rotation processes, and a leaked key can be used to forge signatures until it's revoked. Keyless signing eliminates long-term key custody entirely — there's no key to steal because the certificate expires in minutes — but it depends on your CI/CD identity provider staying uncompromised, since Fulcio issues certificates based on whatever OIDC claims it receives. Most organizations moving to Sigstore in 2023 and 2024 did so specifically to get out of key management rather than because keyed signing was cryptographically weaker; Docker Content Trust, GPG-signed RPMs, and Java code signing with jarsigner are all still-common keyed approaches predating the keyless shift.
What standards and tools govern artifact signing today?
The dominant standards are Sigstore (cosign, Fulcio, Rekor), the CNCF Notary Project (Notation, successor to Docker Content Trust), in-toto attestations, and the SLSA framework, which reached version 1.0 in April 2023 and defines four build integrity levels where SLSA Level 2 and above explicitly require signed provenance. SLSA doesn't mandate a specific tool, but it does require that provenance metadata — what source commit, what builder, what dependencies went into an artifact — be generated and cryptographically bound to the artifact, which is why most SLSA-conformant pipelines pair signing with an in-toto attestation rather than a bare signature. Kubernetes environments enforce this at admission time through Kyverno's verifyImages policy or Gatekeeper's external data provider, both of which have supported native cosign verification since 2022. For teams without a Kubernetes runtime, the check moves earlier: package managers, container build tools, and Terraform providers increasingly ship native verify subcommands that gate a pull or install on signature validity before any code executes.
How Safeguard Helps
Safeguard extends artifact signing from a point-in-time integrity check into continuous supply chain assurance. Our platform ingests and generates SBOMs across your build pipeline, then runs reachability analysis to confirm which signed components are actually exercised in your runtime code paths — so verification effort concentrates on artifacts that matter, not every transitive dependency with a valid signature. Griffin AI correlates signing gaps, provenance anomalies, and CVE exposure across your artifact inventory to flag unsigned or mismatched builds before they reach production, and where a fix is available, Safeguard opens an auto-fix pull request to remediate the underlying dependency or pipeline configuration directly. The result is a signing program that doesn't just prove an artifact wasn't tampered with, but confirms it should have been trusted to begin with.