DevSecOps Code Signing: Trust the Artifact Before Release

DevSecOps code signing is not a signature step. It is a release trust system.

A signed artifact can still be unsafe. The wrong workflow may have signed it. A trusted key may have been stolen. The verifier may accept any subject from a broad issuer. The approval may name a mutable tag while production pulls different bytes. The deployment gate may never check the signature at all.

The operating question is sharper: can the organization prove that this exact artifact came from an approved build, was signed by an expected identity after required checks, passed the current verification policy, reached the intended target, and can be distrusted quickly if that chain breaks?

The DevSecOps and Secure Software Delivery hub connects signing to DevSecOps Container Security, DevSecOps Secrets Management, DevSecOps Security Gates, and software bill of materials operations. GS Consulting applies the model through DevSecOps and Software Supply Chain.

DevSecOps Code Signing: The Short Answer

Build the artifact once in a controlled environment. Record the source revision, builder identity, inputs, parameters, tests, component inventory, and provenance. Address the output by its immutable digest. Sign that digest only after required checks pass. Keep production signing authority away from untrusted branches, personal workstations, and general build steps.

At release, verify more than cryptographic validity. Check the trusted root, issuer, subject, repository, workflow, branch or tag rule, environment, artifact digest, provenance, signing time, revocation state, target, and policy version. Deny when required proof is absent or mismatched. Retain the request, result, decision, and deployment receipt as one evidence chain.

Traditional key based signing and identity based signing can both support this pattern. The control objective does not change: only an authorized identity may sign the approved bytes, and only a verifier with current policy may authorize the release.

Code Signing Has Six Connected Trust Decisions

Most weak implementations focus on the signer and ignore the rest of the path. A defensible design answers six separate questions:

1. Identity: which human or workload identity requested the signature, and under which issuer, repository, workflow, branch, and environment conditions?
2. Artifact: which exact bytes were signed, and is the digest immutable through promotion and deployment?
3. Provenance: which source, builder, inputs, parameters, and process produced the artifact?
4. Trust: which roots, certificates, keys, transparency records, and time rules make the signature acceptable?
5. Release: which target may run the artifact, who approved it, and what happens when verification fails?
6. Recovery: how quickly can the team revoke trust, find affected releases, rebuild, redeploy, and prove closure?

These are connected decisions, not independent files. A valid signature over one digest does not validate provenance for another. A scan result for a tag does not follow that tag when it moves. An approval for staging does not authorize production. Keep one stable artifact identity across the chain.

Public Guidance Defines the Trust Chain

NIST Security Considerations for Code Signing frames digital signatures as a way to establish integrity and source authentication, then examines the architecture and security problems around the signing system itself. That distinction matters. Cryptography can confirm that a signature matches an artifact and key. It cannot decide whether the signer should have had authority.

NIST SP 800-218 calls for software producers to provide integrity verification information and protect release provenance. SLSA Build Level 2 adds signed provenance generated by a hosted build platform and expects the consumer to validate authenticity. The useful unit is therefore not just a signature. It is artifact plus provenance plus verifier expectations.

Sigstore keyless signing shows one modern implementation. An ephemeral key is bound to an OpenID Connect identity through a short lived certificate, and the signing event enters a transparency log. This can remove persistent private key storage from the normal workflow. It does not remove the need to restrict the accepted issuer and subject or monitor unexpected signing events.

Kubernetes guidance recommends immutable image digests or signature verification through admission control. That is the critical consumption step. Signing without enforcement produces evidence. Verification at the release boundary produces control.

GS Artifact Trust Control Priority Index

GS Consulting built a twelve scenario model to answer a practical sequencing question: which signing failures deserve the strongest release gates and recovery exercises first? Each scenario receives a one to five rating across six factors. The base weights are consequence 25 percent, identity trust 20 percent, exposure reach 15 percent, verification reach 20 percent, recovery pressure 10 percent, and evidence duty 10 percent.

The score equals the sum of each factor rating divided by five and multiplied by its weight, then multiplied by 100. A score of 90 or more is labeled Gate before release. Scores from 80 through 89.9 are Strong control, 65 through 79.9 are Managed control, and lower scores are Basic control. These bands express GS planning judgment, not an external standard.

A stolen production signing key scores 100. An unsigned artifact admitted to production and an untrusted branch that can use the production signer both score 98. A signature that deployment never verifies scores 94. Signing a mutable tag instead of an artifact digest scores 89. A developer commit signature without release binding scores 42 because it provides far less control over the built and deployed object.

The sensitivity case shifts five percentage points toward identity trust and recovery and away from consequence and exposure. No score moves by more than two points. The leading release gates remain leading under that alternative. The workbook, source register, inputs, formulas, sensitivity results, figure data, editable SVG files, and browser rendered PNG files are retained in the article research package.

Planning caveat: the index is a GS Consulting derived planning tool based on cited public guidance and documented analyst ratings. It is not an official NIST, SLSA, Sigstore, Kubernetes, CISA, NSA, legal, audit, certification, or compliance determination. Validate duties, risk acceptance, algorithms, key protection, and evidence for the specific product, customer, contract, and deployment.

Use One Control Model From Signer to Runtime

Start with a trust policy that a verifier can execute. Name the artifact types, trusted roots, accepted issuers, permitted subjects, repositories, workflows, branches, environments, target registries, deployment destinations, time rules, and required provenance. Define whether a missing transparency record, unavailable revocation service, or stale policy causes denial, delay, or a bounded exception.

Keep roles separate where consequence warrants it. A platform owner may administer signing infrastructure. A product team may request signatures. A release authority may approve production. A security owner may change trust policy or revoke a signer. One broad administrator identity should not silently control every step.

Use the same identifiers in every record. The build result, component inventory, vulnerability decision, provenance statement, signature, approval, registry event, admission decision, and deployment receipt should all reference the same digest. That makes investigation and revocation much faster.

Constrain the Signing Identity

For a stored private key, protect the key in a service designed for restricted cryptographic use. Limit which service can request a signature, which artifact class it may sign, which environment it serves, and which operators may change policy. Log every request, approval, signature, denial, key state change, and administrative action. Rotate on a defined schedule and after any suspected exposure or trust change.

For identity based signing, constrain the certificate policy with equal care. Do not trust an issuer alone. Bind the accepted subject to the approved repository, workflow, branch or tag rule, environment, and intended audience. Confirm that untrusted change requests and forked repositories cannot reach a production signer through inherited workflow permission.

Keep test and production trust separate. A developer should be able to sign test output without producing an identity that production accepts. A build job should not read or export the private material used to sign provenance when the chosen SLSA level expects the build platform to protect it from user controlled steps.

Review every signer as authority, not inventory. For each signer, record the owner, permitted artifacts, requesting identities, consumers, trust roots, environments, rotation rule, revocation method, monitoring owner, and last recovery test.

Bind the Artifact, Provenance, and Checks

Sign the final immutable artifact. Required tests should finish before signing. Promotion should copy or reference the same bytes rather than rebuild them. If packaging, compression, metadata, or any other byte changes, the digest changes and the trust decision must be repeated.

Provenance answers where the artifact came from. Record the source revision, build platform, builder identity, top level inputs, parameters, environment, output digest, and time. Validate the provenance and signature together. A perfectly valid provenance statement about a different digest is irrelevant to the release in front of the gate.

Bind security evidence to that same object. The SBOM, vulnerability scan, policy tests, license review, malware scan, and exception decision should name the digest. Do not allow a generic project status or a tag based result to stand in for artifact evidence.

Store signatures and attestations in a durable location with controlled writes and reliable retrieval. If a registry holds them, test copy, replication, retention, garbage collection, and disaster recovery behavior. The signature should remain discoverable for the life of the supported release and any required evidence period.

Make Verification the Release Decision

Verification belongs at the point where the artifact gains consequence. Verify before registry promotion, package publication, firmware distribution, desktop installation, or workload admission according to the delivery model. Repeat verification when an artifact crosses a trust boundary or when current policy may differ from the earlier decision.

The verifier should compare the exact digest with the signature, validate the certificate or public key against current trust roots, enforce issuer and subject constraints, check relevant time and transparency evidence, validate provenance, confirm the target policy, and produce a structured result. A simple valid or invalid flag is not enough for investigation. Retain what was checked, which policy version ran, and why the decision passed or failed.

Default to denial for mandatory proof. If business continuity requires an exception path, make it explicit. Name the authority, affected digest, target, reason, compensating controls, expiry, monitoring, and closure condition. Do not let an unavailable verifier quietly turn into allow.

Test negative cases. Present a signature from the wrong repository, a correct signer with the wrong branch, a mismatched digest, expired or revoked trust, missing provenance, an unexpected builder, and an artifact signed before required checks. A control that only proves the happy path has not proved enforcement.

Treat Revocation as a Production Capability

Revocation is not a key ceremony. It is a release and operations workflow. The team must be able to identify every artifact signed by the affected key or identity, every registry that stores it, every environment that admits it, every deployment that runs it, and every customer or service that consumed it.

Maintain a tested playbook for key compromise, identity provider compromise, signing service misuse, unexpected transparency entries, trust root change, verifier defect, and provenance failure. The playbook should cover containment, trust policy update, release freeze, affected scope, rebuild, new signature, redeployment, notification, and evidence preservation.

Monitor the transparency log when the signing design uses one. Look for unexpected identities, repositories, workflows, artifact names, volume, times, and signing patterns. A public or append only record is valuable only when someone detects misuse and has authority to act.

Measure time to distrust, time to identify affected artifacts, time to stop admission, time to rebuild, and time to verify replacement. Run the exercise before a production key or identity fails.

Six Code Signing Failure Modes

Signing as decoration creates a record but no control. The deployment gate must verify the artifact and expected identity before execution. Broad signer trust turns any workflow under a trusted issuer into production authority. Constrain the complete identity claim set. Mutable references break the evidence chain when a tag points to new bytes.

Split proof occurs when the signature, provenance, scan, and approval refer to different objects. No revocation drill leaves a team unable to distrust a signer and find affected releases under pressure. Invisible signing collects events without monitoring unexpected use. Each failure is operational. None is fixed by changing the logo on a certificate.

Minimum Artifact Trust Evidence Packet

Retain eight records as a connected packet: the trust policy, artifact manifest, build provenance, signing record, verification record, release decision, trust inventory, and incident record. The packet should answer who acted, which exact artifact was involved, which policy ran, what evidence was checked, where the artifact went, and what changed after the decision.

Evidence must be trustworthy itself. Protect it from unauthorized change, keep clocks consistent, preserve correlation identifiers, record policy and tool versions, control access, and test retrieval. Screenshots can help explain a decision, but structured records are easier to search, compare, and replay.

Retention should follow product support, incident, contract, audit, and legal needs. Those obligations vary. Define the rule with the accountable security, legal, records, and program owners rather than copying a generic period.

A 90 Day Code Signing Implementation Plan

By day 30, inventory artifact types, signing keys and identities, trust roots, requesting workflows, registries, verifiers, deployment targets, and owners. Trace one production release from source to runtime. Identify any rebuild after approval, mutable reference, shared trust root, or missing verification step. Freeze new broad signing authority.

By day 60, choose the signing pattern for each artifact class. Protect stored keys or configure constrained identity based signing. Bind provenance, signature, scans, and approval to the digest. Add release verification with deny behavior. Separate test and production trust. Create an exception record with expiry and closure.

By day 90, test the wrong issuer, wrong subject, wrong branch, mismatched digest, missing provenance, revoked trust, unavailable verifier, and emergency exception. Run a signer compromise exercise. Measure affected artifact discovery and time to distrust. Review the evidence packet with release, security, platform, and incident owners.

The operating standard is simple: no artifact reaches production unless the organization can prove who signed the exact bytes, why that identity was trusted, which provenance and checks applied, which policy admitted it, and how trust will be removed when any part of that chain fails.

Sources and Suggested Future Reading

• NIST, Security Considerations for Code Signing
• NIST SP 800-218, Secure Software Development Framework version 1.1
• SLSA Build Track Basics version 1.2
• SLSA Provenance version 1.2
• Sigstore, Keyless Signing Overview
• Sigstore Security Model
• Kubernetes Security Checklist
• NSA and CISA, Defending CI/CD Environments

Frequently Asked Questions