Last updated on September 21st, 2026 at 08:25 am
Shipping software used to involve coding, building the code, and taking it live. Security discussions mostly ended with encrypting it in transit. Then SolarWinds happened. Then Codecov. Then a product of supply-chain break-ins came and wrote the new rules unobtrusively.
The unpleasant fact those attacks revealed: a signed binary is not the same as a safe binary. Attackers with control of a build environment are capable of generating artifacts that validate all conventional tests – matching signature, passing hash, acceptable antivirus scan – but offer something malicious.
Code signing, provenance, and software integrity validation are a combination of the solutions built to this problem. They answer three questions any security-minded team should ask before trusting any artifact: Who made this? Has it been changed? Can we answer how it was constructed?
This paper brings together the full panorama of what is, what is actively evolving, and where Software Supply Chain Security is headed; it is addressed to developers, DevSecOps engineers, and security professionals who are neither in the land of we sign our containers nor the land of we enable provenance with admission.
Table of Contents
Digital Signatures for Binary Verification: The Layer Everything Else Builds On
What Signing Actually Proves
Digital signatures use asymmetric cryptography. The artifact is signed with a private key and verified by the corresponding public key. Verification fails if the artifact changes after signing. That change is the guarantee.
Operating systems have used this for years. Gates loading of Microsoft Authenticode. In Developer ID notarization, Apple blocks unrecognized macOS apps. Android’s APK signing scheme identifies packages with developer identities. These are not features; they are trust mechanisms enforced throughout the platforms that billions of devices rely on in daily work.
Server-side and container workloads are no different: sign and verify artifacts first. Distribution package ecosystems such as Linux publish checksums with packages, enabling consumers to verify they received what they published. It is simple, it works, and it is really helpful.
What a Signature Doesn’t Tell You
This is the fault that brings down teams. A digital signature establishes two facts: that the item came from whoever used the private key, and that it is not the same as it was when the key touched it. That’s the entire guarantee.
It does not say whether the build environment had already been weakened by the time of signing. It does not say whether malicious code was introduced during the dependency stage, three phases before binary assembly. It does not establish that the signing key was indeed under controllable control, as stolen signing keys are an openly known and repeated issue. The Nvidia certificate breach showed that once an attacker has a legitimate cert, they may sign malware that appears indistinguishable from a bona fide vendor release.
This is how provenance and integrity checking sit above signing, not as a substitute. Signing addresses who signed it and whether it’s unchanged. Provenance answers how it got here.
Cosign and Container Image Signing: Where the Industry Is Actually Moving
The Key Management Problem Nobody Loves
Conventional code signing relies on the permanence of personal keys. Theoretically, these keys are stored in cloud vaults or HSMs with highly restrictive access controls. Practically, I have signed keys in several container pipelines. The business reality is messier: key state is represented as a CI environment variable, rotation windows are set by schedule, certificates live in an inventory no single person owns, and audit logs exist but go unread.
That does not make it peculiar to a team. It is a structural issue with long-lived credentials at scale. A key’s length equals its compromise window. The more access signing infrastructure has across teams, the harder access control becomes.
Sigstore’s Keyless Approach
Cosign, a component of the Sigstore project, takes a very different approach to this problem. In place of dealing with long-lived private keys, developers are authenticated by OIDC – GitHub Actions, Google, or some other identity provider. Fulcio, Sigstore’s certificate authority, issues a short-term certificate for that identity.
Rekor, the public transparency log, records the signing event forever. The outcome: perfectly private crypto keys have never existed; there is cryptographically verifiable data of all depositions of “signings,” and identity is identified with a real-world workflow or human being rather than an abstract key.
Keyless image signing via GitHub Actions OIDC
cosign sign
–oidc-issuer=https://token.actions.githubusercontent.com
ghcr.io/yourorg/yourimage:latestVerifying Signed Images
It is the signature coupled to a particular workflow identity:
cosign verify
–certificate-identity=https://github.com/yourorg/repo/.github/workflows/release.yml@refs/heads/main
–certificate-oidc-issuer=https://token.actions.githubusercontent.com
ghcr.io/yourorg/yourimage:latestMy experience showed that the certificate identity string must be identical to the precise workflow path – otherwise verification will fail, without necessarily throwing up an error notification. Test values at small scale before enforcing them in production policy gates. Cosign is fine; it simply saves an hour of debugging down the line.
The first teams to consider this workflow have noted that keyless signing can eliminate the hardest part of the workload. The certificate doesn’t need to be rotated, there are no vaults to administer access, and any signing operation is publicly recorded and verifiable without extra tooling.
Artifact Provenance and the SLSA Framework: Proving the Entire Build Chain
What Provenance Actually Is
Provenance is a signed document containing a description of how an object was built, e.g., what source repository it was built out of, what commit it was built with, what build system it was built with, what parameters it was built with, and what environment it was built with. It does not mean the artifact bears a signature. It is a verifiable history of the artifact.
A signed container image without provenance establishes the fact that the container image originated with a legitimate key. Provenance can show it was created by this exact GitHub Actions workflow on this date, with these dependencies, and with this committed content—a stronger basis for trust.
SLSA Levels Explained
The SLSA provenance model, called Supply Chain Levels for Software Artifacts, which is also known as SLSA, classifies four stages of supply chain hardening:
SLSA LevelCore RequirementLevel 1Provenance exists and documents the buildLevel 2Provenance is signed by the build service itselfLevel 3Build runs in an isolated, auditable environment with verified source
SLSA provenance is presented as an in-toto attestation: a signed envelope containing structured metadata in the form of a JSON Web Signature.
The in-toto model implements one more step forward: as per the model, each stage of a pipeline will be signed; hence, in case some necessary stage is skipped, such as a SAST scan or dependency scan, it will be caught during verification. It is not merely “is the artifact received? It is whether it came the right way.
I observed that Level 1 and Level 2 can be achieved after a few sprints, with GitHub Actions generating provenance using native SLSA. Level 3 requires more architectural commitment: hermetic builds and stricter policy gates, but the path depends on how it’s written and the machinery available.
Attaching SBOMs as Signed Attestations
A Software Bill of Materials (SBOM) lists all the components an artifact includes, including transitive dependencies. Generating an SBOM is useful. Signing it as an attestation attached to a container image makes it part of a verifiable trust chain, not a replaceable document.
Cosign works in this specific direction, and SBOM generation has become easy with tools such as Trivy:
Generate an SBOM in CycloneDX format.
trivy image –format cyclonedx –output sbom.json yourimage:latest
Attach it as a signed attestation.
cosign attest
–– predicate sbom.json
–– type cyclonedx
ghcr.io/yourorg/yourimage:latestAnyone pulling that image can now verify both its signature and its SBOM attestation — and confirm neither was tampered with after the build completed.---## VCS to Production: Tracking Trust Boundaries Across Every Stage `<h2>`### Where the Attack Surface Actually Lives `<h3>`The path from a `git push` to a running container crosses multiple distinct trust boundaries. Each one is a potential injection point:
Developer Workstation → Source Repository (VCS) → CI Build System
→ Artifact Registry → Staging → Production Cluster
The question at each phase is simple: can we assure ourselves that what came in is what came out of the last step? Without provenance attestations between steps, most teams assume it. Attackers use assumptions.
A build system that generates an image with a valid signature does not necessarily state that the source commit was clean. A registry that holds a signed image does not also indicate that the CI system was appropriate between commit and build. Those dots are joined by provenance. It creates a verifiable chain of custody from the initial line of code to the running workload.
Enforcing Trust at the Cluster Boundary
A key approach here is an admission policy engine, such as Kyverno or OPA/Gatekeeper, that enforces signature and provenance requirements during admission to Kubernetes. No smart property will be produced without a legitimate signature, effectively forming provenance attestation.
A simple Kyverno policy implementing Cosign-signed image signature:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-image-signature
spec:
rules:
- name: check-image-signature
match:
resources:
kinds: [Pod]
verifyImages:
- imageReferences: [“ghcr.io/yourorg/"]
attestors:
- entries:
- keyless:
subject: "https://github.com/yourorg/”
issuer: “https://token.actions.githubusercontent.com”I deployed Kyverno in the following setup in staging environments, and the advice is similar: use audit mode for at least one week before switching to enforce. Violations reported in audit mode do not block a deployment. Still, they expose edge cases: base images pulled directly from unofficial registries, legacy tooling that doesn’t integrate, and other issues that don’tesult in an incident.
Challenges That Haven’t Been Fully Solved Yet
Developer Adoption Friction
The tooling is solid. Records have improved significantly. Still, adoption is uneven across teams, and the gap between having Cosign available and enforcing signatures is still too wide.
Paper-based signing processes ot incorporated into CI pipelines are skipped. The living certificate inventory in a spreadsheet is not maintained. Policy gates that are never tested in staging are bypassed with exceptions that become permanent. These are not tool problems, but widespread process problems.
Integration at the CI level is the way to go; hence, signing is automatic and non-negotiable, not something developers can forget.
Verification at Scale
The easy part is producing signatures and attestations. Making them verifiably secure against hundreds of services with policy logic, revocation, and caching is actually difficult engineering. Mixed registry teams: Up until now, verification latency and cache invalidation have become operational challenges in large-scale Kubernetes clusters with images of varying provenance quality.
Regulatory Expectations Are Tightening
Both the US Executive Order 14028 and the EU Cyber Resilience Act are driving software suppliers towards verifiable provenance, signed SBOMs, and SLSA-like attestations. This is no longer theoretical. Auditors are beginning to demand evidence of the construction of software- not what version was shipped or whether a vulnerability scanner was run.
Inconsistent or missing provenance is becoming less of a compliance shortfall with merely nominal impact: audit flunks, contract fulfillment,t and, in high-assurance industries, ineligibility to hold some contracts altogether.
Where This Is All Heading
What the Next Few Years Actually Look Like
It is moving in the right direction despite an unclear timeline; npm and PyPI are already adding Sigstore-supported provenance on published packages. Signature-enforcing Kubernetes admission controllers are shifting toward an advanced configuration as the recommended baseline. SBOM is becoming more automated, rather than a manual compliance artifact.
The desired end state is this: unsigned artifacts and unprovable provenance will be operationally and regulatorily unacceptable on anything that touches production. The tools already exist. The standards are written. The next thing lagging is widespread, active implementation across the wider ecosystem.
Final Take
Code signing, provenance, and software integrity verification are not three independent practices to potentially attach at the various stages of a roadmap. They are multi-tiered layers, each reinforcing the others. Signatures handle identity and integrity.
Build chain Provenance demonstrates the build chain. Policy enforcement makes them hard gates, not optional checks that pass in an audit but fail in incidents.
To the teams starting this work: make Cosign keyless signing work on container images. Create Trivy SBOMs and provide them as attested signatures. Add a Kyverno audit policy. When done correctly, those three steps put a team far above most of the industry and set the stage for everything more advanced that comes after.
The investment is real. So is the cost of skipping it.
I’m a technology writer passionate about AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and engaging. I encourage participation I continue to research innovation and technology. Let’s connect and talk technology!
