Closing the CI/CD enforcement gap before release integrity breaks

At a glance

What this is: This is an analysis of why partial automation in CI/CD creates inconsistent enforcement and weakens software integrity at release time.

Why it matters: It matters because IAM, NHI, and platform teams need release controls that are enforceable by default, not by tribal knowledge or best effort.

By the numbers:

• Only 13% fully automate code signing.
• 71% of organizations say security checks are only partially automated or ad hoc.
• 89% lack formal enforced code-signing policies.

👉 Read DigiCert's analysis of the CI/CD enforcement gap before release integrity breaks

Context

CI/CD enforcement gap is the problem here: policy exists, but release pipelines do not apply it consistently. In practice, that means one team signs code by default while another ships unsigned artifacts, or one pipeline runs security checks on every build while another treats them as optional.

For identity and supply chain governance, that inconsistency matters because software trust is only as strong as the weakest release path. The article argues that automation, not intent, turns security controls into repeatable proof at release velocity.

Key questions

Q: How should teams enforce code signing across CI/CD pipelines?

A: Teams should make signing a mandatory release control, not an optional developer step. Enforce it in the pipeline, protect the keys in HSMs or managed KMS, and block promotion when signatures are missing. The goal is to make integrity evidence automatic so the control works the same way in every team and environment.

Q: Why do partially automated security checks create release risk?

A: Partially automated checks create inconsistent enforcement, which means different pipelines operate under different trust standards. Attackers only need the weakest path, and auditors cannot rely on uniform evidence. Consistency matters more than isolated control coverage because release integrity depends on the whole delivery chain, not a few well-run projects.

Q: What do security teams get wrong about automation in software supply chains?

A: Teams often treat partial automation as progress when it is really uneven control. If manual steps still decide whether artefacts are signed, scanned, or approved, the programme depends on behaviour rather than policy. That creates drift, weak evidence, and exceptions that become the normal operating model.

Q: Who is accountable when unsigned software reaches production?

A: Accountability sits with the owners of the release process, the platform controls, and the governance team that allowed the exception path to exist. In software supply chains, release integrity is an operating model issue, not just a development issue. NIST Cybersecurity Framework 2.0 helps structure that accountability across govern, protect, and respond.

Technical breakdown

Why partial automation weakens code signing enforcement

Partial automation creates a control plane that looks mature on paper but behaves inconsistently in execution. Code signing is only effective when it is mandatory, repeatable, and enforced at the pipeline level. If signing depends on engineer memory or team-specific habit, the release process becomes fragmented and audit evidence becomes unreliable. In that model, integrity is a local practice rather than an enterprise control. Practical implication: make signing a non-optional release gate, not a discretionary step.

Practical implication: make signing a non-optional release gate, not a discretionary step.

How uneven security checks create release integrity drift

Security checks lose value when they are only partially automated across projects. SAST, DAST, SCA, SBOM generation, and image signing all depend on consistent orchestration to produce trustworthy outcomes. If some pipelines run them and others do not, the organisation cannot prove uniform control coverage, which undermines both security and compliance claims. This is less a tooling failure than an enforcement failure across the delivery system. Practical implication: standardise the control set across all pipelines and measure coverage continuously.

Practical implication: standardise the control set across all pipelines and measure coverage continuously.

Why release-time evidence matters more than policy intent

Policy defines the desired state, but automated workflows create evidence that a policy actually operated. That distinction matters in supply chain security because release integrity is judged by artefacts, signatures, and control logs, not by policy language alone. Without automation, every exception requires human justification and the audit trail becomes fragmented. Automation also reduces the chance that teams substitute tribal knowledge for formal enforcement. Practical implication: capture proof automatically at build and release time so evidence travels with the artefact.

Practical implication: capture proof automatically at build and release time so evidence travels with the artefact.

Threat narrative

Attacker objective: The attacker’s objective is to get untrusted code or artefacts into production through the least controlled release path.

1. Entry occurs through the weakest pipeline path, where attackers only need one release flow that does not enforce signing or security checks consistently.
2. Escalation happens when unsigned or insufficiently checked artefacts move through build and release stages without mandatory evidence of integrity.
3. Impact is the shipment of tampered or unverified software that is harder to trust, harder to audit, and easier to abuse in downstream environments.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Partial automation is not a maturity milestone, it is an integrity exception strategy. When release controls vary by team, product line, or pipeline, the organisation no longer has one enforcement model. It has a patchwork of local rules that attackers can route around and auditors cannot easily verify. The practical conclusion is that control consistency matters more than control presence.

Code signing is the decisive release-control test because it converts policy into proof. A signing policy that is not enforced at build and release time does not establish provenance. That leaves teams with a claim about integrity rather than evidence of integrity. Practitioners should treat signing as the control that exposes whether the rest of the pipeline is actually governed.

Identity governance now extends into software delivery because release pipelines behave like privileged actors. Build systems, signing keys, and automation credentials can all move software faster than human review cycles can observe. That makes lifecycle control, key protection, and pipeline permissions part of the same governance problem. Security teams need to evaluate release infrastructure as an identity surface, not just an engineering workflow.

Release integrity breaks first where automation stops and tribal knowledge begins. The report’s pattern is clear: when security checks are optional, evidence becomes inconsistent and assurance becomes local. That is the governance gap, not the absence of tools. The field should stop treating manual enforcement as a temporary bridge and recognise it as the point where trust degrades.

Automated security checks, SBOMs, and container signing form a chain, not a menu. Each one supports the others, and gaps compound quickly when one step remains manual. The practitioner lesson is that integrity is measured by the completeness of the chain, not by the presence of a single strong control.

From our research:

• Only 13% fully automate code signing, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, showing that detection without enforcement leaves a long-lived trust problem.
• That is why the Guide to the Secret Sprawl Challenge is the right next resource for teams trying to close the gap between policy and proof.

What this signals

Automated enforcement is now a governance requirement, not an engineering preference. Teams that still rely on manual sign-off will keep producing uneven trust outcomes, because control consistency cannot be sustained at release velocity. The practical shift is to treat pipeline enforcement as part of identity and access governance for machine actors, not as a separate DevOps concern.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, the broader software trust picture is already showing that insecure defaults scale faster than manual remediation can catch up. The lesson for practitioners is that release controls must be designed to fail closed, not merely to alert after the fact.

Release pipelines are becoming privileged identity zones. As signing keys, build credentials, and automation tokens carry more operational authority, governance has to follow them into CI/CD. Practitioners who already use the OWASP Non-Human Identity Top 10 should map pipeline enforcement to privileged machine access, not just to code quality.

For practitioners

• Make code signing a mandatory release gate Require every pipeline to sign release artefacts before promotion, and block deployment when signatures or policy evidence are missing. Treat exceptions as documented governance events, not informal workarounds.
• Standardise security checks across all pipelines Apply the same SAST, DAST, SCA, and artifact validation requirements to every project and every environment so coverage does not depend on team maturity.
• Protect signing keys as high-value identity material Store signing keys in HSMs or managed KMS and restrict access to the smallest possible set of release actors. Review key access with the same discipline used for other privileged identities.
• Generate SBOMs and signatures automatically Create SBOMs and sign them inside CI/CD so evidence is produced with the artefact, not reconstructed later for audit. This reduces manual drift and improves defensibility.
• Measure enforcement coverage, not policy intent Track how many pipelines actually enforce signing, scanning, and artifact validation. Coverage metrics show whether governance is real or only documented.

Key takeaways

• Partial automation in CI/CD creates inconsistent enforcement, which is the real source of integrity risk.
• The scale signal is stark: only 13% fully automate code signing, so most organisations still cannot prove uniform release trust.
• Practitioners should move signing, scanning, and evidence capture into the pipeline so policy becomes enforceable by default.

Key terms

• Code signing: Code signing is the process of attaching cryptographic proof to software so recipients can verify origin and integrity. In CI/CD, it turns release trust into an enforceable control instead of a human promise, and it only works when the signing step is mandatory and protected.
• Software bill of materials: A software bill of materials is a structured inventory of components, dependencies, and package relationships inside a build or release. It gives security teams a way to verify what is inside an artefact, trace exposure quickly, and support governance when supply chain trust is questioned.
• Release integrity: Release integrity is the ability to prove that software moved through the delivery pipeline without unauthorised modification or bypassed controls. It depends on consistent enforcement, signed artefacts, and auditable evidence across the build chain, not on policy statements alone.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: How to close the CI/CD enforcement gap before it ships. Read the original.