TL;DR: Partial automation is leaving release integrity uneven, with DigiCert’s State of Software Supply Chain Security 2026 report finding only 13% fully automate code signing and only 13% fully automate security checks across all projects. When policy is manual at release velocity, attackers only need the easiest pipeline, not every pipeline.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: Partial automation in CI/CD leaves release integrity inconsistent because signing, security checks, SBOM generation, and image controls are still applied unevenly across pipelines.
Why it matters: For IAM, NHI, and platform teams, the issue is not policy intent but whether release controls are enforced automatically enough to produce trustworthy evidence at build and ship time.
By the numbers:
- Only 13% fully automate code signing, according to DigiCert.
- Only 13% fully automate security checks across all projects, according to DigiCert.
- 71% of organizations say security checks are only partially automated or ad hoc, according to DigiCert.
- Only 11% actively provide SBOMs today, according to DigiCert.
Context
CI/CD enforcement gap is the disconnect between what release policy requires and what pipelines actually enforce. In this article, that gap matters because integrity controls are still applied unevenly across teams, projects, and release paths, leaving software trust dependent on manual behavior instead of repeatable automation.
The article’s core claim is that maturity claims are not enough if signing, security checks, SBOM generation, and image signing are inconsistent. For identity and supply chain practitioners, the governance question is whether release controls behave as defaults or as optional steps that can be bypassed when delivery pressure rises.
Key questions
Q: What breaks when CI/CD access is not tightly governed?
A: Build and deployment systems become an easy path to bypass application defenses. If tokens, service accounts, or deployment credentials are over-privileged, an attacker or careless operator can alter what gets shipped, inject malicious changes, or expose sensitive data. Least privilege and credential rotation are essential in those environments.
Q: Why does manual release enforcement increase supply chain risk?
A: Manual enforcement depends on timing, attention, and consistent human follow-through, all of which deteriorate when teams release quickly or operate across many pipelines. If a control can be skipped, delayed, or applied only to some projects, the attacker does not need to defeat every workflow. They only need the one with the lowest enforcement pressure.
Q: How do teams know whether release integrity controls are actually working?
A: They should look for consistent automated coverage across signing, security checks, SBOM generation, and image signing, not just policy documents. If evidence is produced automatically at every release path, the control is working as designed. If teams still rely on exceptions or tribal knowledge, integrity remains uneven.
Q: Should security teams prioritise signing before other CI/CD improvements?
A: Yes, when release integrity is the immediate concern, signing is the best anchor control because it establishes provenance and creates a clear release gate. Other controls still matter, but signing gives the programme a point where trust can be proven rather than assumed. Without that gate, surrounding controls are harder to defend.
Technical breakdown
Why partial automation breaks release integrity
Partial automation creates a control plane with different enforcement rules in different pipelines. One release path may sign artifacts and run security checks every build, while another relies on manual steps, tribal knowledge, or delayed review. That inconsistency matters because integrity is not proven by policy language. It is proven when the pipeline itself consistently enforces signing, scanning, and evidence collection at release speed. When control execution depends on people remembering the step, the release process becomes variable instead of trustworthy.
Practical implication: define which release controls must be pipeline-enforced, not developer-enforced.
Why code signing is the anchor control for CI/CD trust
Code signing establishes provenance by binding an artifact to a controlled signing process, which makes tampering easier to detect and unsigned releases easier to block. In CI/CD, signing only helps when it is mandatory, automated, and backed by protected key handling. If teams can ship unsigned output or treat signing as an optional exception, the signing policy is not actually governing release behavior. The control must sit at the release gate, not as a downstream audit decoration.
Practical implication: move signing to a hard release gate and protect signing keys in managed infrastructure.
How SBOMs, container signing, and security checks compound the control gap
The article shows that release integrity is a chain, not a single checkbox. SBOMs describe what was built, SBOM signing protects that evidence, container signing extends trust to deployable images, and security checks reduce known flaws before shipping. When any one of those steps is manual or intermittent, the chain weakens. The result is not just lower assurance, but weaker auditability and less defensible release evidence across the whole delivery path.
Practical implication: automate the full evidence chain, not just one integrity step.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Release integrity now fails at the enforcement layer, not the policy layer: this article shows that many organisations already know what should happen, but their pipelines do not make it happen consistently. The governance problem is not a lack of standards. It is that integrity controls still rely on human execution in places where release velocity eliminates the chance for reliable manual enforcement. Practitioners should treat consistency as the real maturity test.
Automated code signing is the decisive control point for software trust: when signing is optional, integrity becomes a best-effort claim rather than a verifiable property. That matters because code signing is the mechanism that turns provenance into something the pipeline can prove, not just assert. The report’s numbers show that many teams still have not crossed that threshold, so the control gap remains operational, not theoretical.
SBOM generation and SBOM signing are part of the same trust chain, not separate hygiene tasks: a signed artifact without a signed SBOM leaves visibility incomplete, while an unsigned SBOM leaves the evidence layer easy to dispute. This article shows why release governance has to be designed as a chain of proof. Practitioners should stop thinking about isolated controls and start thinking about integrity continuity across build, attest, and release.
CI/CD enforcement gap: the key failure mode is not missing security intent, but uneven enforcement across pipelines, products, and teams. That creates a release environment where the weakest workflow sets the real security baseline. For identity and platform leaders, the implication is clear: if one release path can bypass signing or scanning, the programme has a governance exception, not a governance model.
Release velocity changes the control design target: controls that depend on time, attention, or exception handling will fail as delivery scales. This is why automation is not an optimisation after the fact. It is the mechanism that makes trust repeatable enough to govern. The practitioner takeaway is to judge release controls by whether they produce proof automatically, not by whether they exist on paper.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Governance teams should stop treating partial automation as a transition state and start treating it as a control failure. When some pipelines enforce signing and scanning while others do not, the programme has inconsistent trust boundaries, which is exactly where release integrity becomes negotiable.
CI/CD enforcement gap: the practical problem is not that organisations lack security policies. It is that the pipeline does not convert those policies into default behavior everywhere, so release trust still depends on where and how the build runs.
For practitioners
- Define mandatory pipeline-enforced controls Classify code signing, security checks, SBOM generation, and image signing as non-optional release gates rather than discretionary build steps.
- Make signing a hard release gate Require every releasable artifact to pass automated code signing before promotion, with no manual bypass path for routine delivery.
- Protect signing keys in managed systems Store signing material in HSMs or managed key services and restrict human access to the smallest possible operating set.
- Automate SBOM creation and signing Generate SBOMs in the pipeline, sign them as evidence, and tie both outputs to the same release record for auditability.
- Measure control coverage across all pipelines Track how many build paths actually enforce signing and security checks so that partial automation is visible as a risk, not a success metric.
Key takeaways
- Partial automation is not a halfway point to maturity when release integrity depends on the same control behaving differently across pipelines.
- The article’s evidence shows that only 13% fully automate code signing and only 13% fully automate security checks across all projects.
- The fix is to make signing, scanning, SBOM generation, and image controls mandatory in the pipeline so trust is proven at release time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Release signing depends on protected credentials and keys that cannot be left loosely governed. |
| NHI-02 — Secret Leakage | CI/CD pipelines often expose signing keys, tokens, and build secrets if controls are manual or uneven. | |
| NHI-05 — Overprivileged NHI | Release pipelines need only the minimum permissions required to sign, scan, and attest artifacts. | |
| Recommendation — Treat signing keys as governed credentials and restrict their lifetime, storage, and use. Scan build systems for exposed secrets and revoke any credentials that should not be reusable. Reduce pipeline and signing privileges to the smallest set needed for release enforcement. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article’s risk model is supply chain compromise through the weakest pipeline and its credentials. |
| Recommendation — Map CI/CD compromise paths to credential access and lateral movement across build systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Signing keys and pipeline credentials require lifecycle management, rotation, and revocation controls. |
| Recommendation — Apply authenticator management to signing credentials and revoke stale access promptly. | ||
Key terms
- Release Integrity: Release integrity is the assurance that the software a team ships is the same software it documented and approved. It depends on immutable build references, protected signing material, and reliable verification so downstream teams can trust the release record.
- Pipeline Enforcement: Pipeline enforcement is the mechanism by which security and governance rules are applied automatically during build and release. For CI/CD, it matters because controls only create trust when they run by default across every workflow, not when teams remember to apply them.
- 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 an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org