Software signing should be a solved problem by now. The concept is not complicated: produce a cryptographic signature that proves a piece of software came from who it claims to come from and has not been modified since. PGP has existed since 1991. Code signing certificates have been available for decades. And yet, in 2026, the majority of software artifacts shipped to production are unsigned.
Why? And what changed in the past year to start closing that gap?
The Problem With Traditional Code Signing
The historical approach to code signing required you to obtain a certificate from a Certificate Authority, protect the private key (ideally in a hardware security module), integrate the signing step into your build process, and manage certificate rotation. Each of those steps introduces friction, and friction kills adoption.
For proprietary software vendors shipping desktop applications, the economics made sense — operating systems warned users about unsigned executables, so signing was a cost of doing business. But for the much larger universe of software artifacts — container images, npm packages, Python wheels, internal microservices, infrastructure-as-code modules — the traditional model was too cumbersome.
The result: organizations signed their customer-facing binaries and left everything else unsigned. Internal services, build dependencies, deployment artifacts — all shipped without any cryptographic proof of origin or integrity.
What Sigstore Changed
The Sigstore project, which reached general availability in late 2022 and has matured significantly since, fundamentally shifted the economics of signing. Instead of managing long-lived keys and certificates, Sigstore uses short-lived certificates tied to identity providers (like GitHub OIDC tokens) and records signatures in a public transparency log.
The practical effect: signing an artifact becomes a single command in your CI/CD pipeline. No key management. No certificate rotation. No HSM procurement. The identity is your CI/CD system's workload identity, which you already have.
By early 2026, Sigstore adoption has reached meaningful scale:
- npm began requiring provenance attestations for packages published from automated pipelines.
- PyPI integrated Sigstore-based attestations as a supported option for package publishers.
- Container image signing with cosign (part of the Sigstore ecosystem) became the default recommendation in Kubernetes deployment guides.
- GitHub Actions and GitLab CI both offer native Sigstore integration, making signing a one-line workflow addition.
The Current Landscape
Despite Sigstore's progress, the overall state of software signing in 2026 is best described as "promising but incomplete."
What Is Being Signed
Container images lead adoption. The combination of cosign, Kubernetes admission controllers, and registry support has made container image signing the most mature signing workflow. Organizations that deploy to Kubernetes increasingly require signed images as a matter of policy.
Package registries are catching up. npm's provenance system, PyPI's attestation support, and Maven Central's existing PGP requirements mean that the major package ecosystems all have some form of signing available. Adoption rates vary widely — npm provenance is growing quickly because it is integrated into the publishing workflow, while Maven PGP signing remains largely a rubber-stamp exercise.
Internal artifacts remain largely unsigned. This is the biggest gap. Build outputs, deployment manifests, Terraform modules, Helm charts, and internal libraries are rarely signed, even in organizations that sign their public-facing releases. The tooling exists, but the organizational processes have not caught up.
Verification Is the Harder Problem
Signing is only half the equation. Verification — actually checking signatures before trusting an artifact — is where most organizations fall short.
Signing without verification is security theater. It is the equivalent of installing a lock on your door and never turning the key. Yet this is exactly what many organizations do: they add signing to their build pipeline because a compliance requirement demands it, and then nobody configures their deployment infrastructure to reject unsigned artifacts.
The organizations that get real value from signing are the ones that enforce verification at every trust boundary:
- Container registries that reject unsigned images
- Kubernetes admission controllers that verify signatures before scheduling pods
- Package managers configured to require provenance verification
- Deployment pipelines that verify artifact signatures before promoting to production
SLSA and the Build Provenance Connection
Software signing does not exist in isolation. It is one component of the broader software supply chain integrity framework defined by SLSA (Supply-chain Levels for Software Artifacts). SLSA connects signing to build provenance — not just proving that an artifact was signed, but proving where it was built, from what source code, using which build system.
SLSA Level 3, which requires a hardened build platform and non-falsifiable provenance, has become the benchmark for serious supply chain security programs. Achieving SLSA Level 3 means your artifacts carry cryptographic proof of their entire build history, from source commit to final binary.
In 2026, SLSA Level 3 is achievable for organizations building on GitHub Actions or Google Cloud Build, which offer built-in provenance generation. For organizations using other build systems, it requires more manual integration work, but the reference implementations have improved significantly.
Practical Guidance for Teams
If your organization has not implemented software signing, here is a prioritized approach:
Start With Container Images
Container images offer the best return on investment for signing adoption. The tooling is mature, the verification infrastructure (Kubernetes admission controllers) is well-documented, and the attack surface (image substitution, registry compromise) is well-understood.
Install cosign, add a signing step to your container build pipeline, and configure your Kubernetes clusters to require signed images. This can be done in a day and immediately raises the bar for artifact integrity.
Add Package Provenance
If you publish packages to npm, enable provenance attestations. It requires minimal configuration changes and provides downstream consumers with cryptographic proof that your package was built from a specific source repository.
For Python packages, evaluate the Sigstore attestation workflow. For Java artifacts on Maven Central, ensure your PGP signing is functional and keys are properly managed.
Implement Build Provenance
Once artifacts are signed, the next step is build provenance — generating SLSA-compliant attestations that record the build environment, source commit, and build parameters. GitHub Actions' built-in provenance generation makes this straightforward for repositories hosted on GitHub. For other CI systems, the SLSA verifier project provides tools for generating and verifying provenance.
Enforce Verification
This is the step that delivers actual security value. Configure your deployment infrastructure to reject unsigned or unverified artifacts. Start with a monitoring-only mode to identify any gaps in your signing coverage, then switch to enforcement once all legitimate artifacts are being signed.
The Road Ahead
Several developments will shape software signing adoption through the rest of 2026 and beyond:
Regulatory requirements are hardening. The EU Cyber Resilience Act and CISA's secure software development guidance both point toward mandatory software signing for products sold in their respective markets. Organizations that adopt signing now will be ahead of compliance deadlines.
Transparency logs are becoming infrastructure. Sigstore's Rekor transparency log, and similar projects, are evolving from experimental tools into critical infrastructure. The ability to audit the signing history of any artifact — who signed it, when, and from what build — is becoming a baseline expectation.
Key management is getting simpler. Sigstore's keyless signing model eliminates the hardest part of traditional code signing. As this pattern spreads to more ecosystems, the "key management is too hard" objection loses its weight.
Verification tooling is maturing. Projects like Kyverno, Connaisseur, and built-in registry verification are making policy enforcement more accessible. The gap between "we sign things" and "we verify signatures" is closing.
How Safeguard.sh Helps
Safeguard integrates with Sigstore and cosign to verify artifact signatures as part of its policy gate evaluation. When an SBOM is generated, Safeguard checks the signing status and provenance of each component, flagging unsigned dependencies and artifacts that lack verifiable build provenance. Policy gates can enforce signature requirements — blocking deployments that include unsigned container images or packages without provenance attestations. This gives teams a single enforcement point for both vulnerability management and artifact integrity, closing the gap between signing and verification.