Security controls don’t move as fast as the software supply chains they’re meant to protect. Partial automation creates uneven enforcement across teams and release pipelines, creating the unevenness where integrity begins to break down.

DigiCert’s State of Software Supply Chain Security 2026 report shows a clear pattern: Many organizations feel mature, but the controls that prove integrity are still inconsistent or manual. Only 13% fully automate code signing, and only 13% fully automate security checks across all projects.

This is the next chapter in a larger story: Policy and intent matter. But automation is what makes security real at release velocity.

Why partial automation is a security problem, not a maturity milestone

Partial automation sounds like progress. But in practice, it creates uneven enforcement. 

One pipeline signs code regularly; another ships releases without signatures. One product line runs SAST, DAST, and SCA every build; another runs them “when there’s time.” One container workflow signs images by default; another relies on tribal knowledge to do that step.   

The State of SSC report quantifies this reality: 71% of organizations say security checks are only partially automated or ad hoc.

That’s not a tooling issue alone. It’s an enforcement issue. Attackers don’t need access to every pipeline; they just need the easiest one.

Automation is the bridge between policy and proof

Automation turns standards into defaults. Security becomes:

• Consistent when the pipeline enforces it automatically
• Auditable when the process produces evidence automatically
• Scalable when it no longer depends on individual behavior

That’s why automation shows up as a central recommendation in the report. It explicitly calls out the need to close the automation gap before regulatory deadlines take effect, including automation for signing, vulnerability scanning, and SBOM generation.

Policy defines what should happen. Automation ensures it always does.

Make automated code signing the “hero” control

If you want one automation investment that anchors integrity, start with signing. Because code signing is more than a checkbox—it’s a control that establishes provenance and reduces tampering risk.

Yet the report highlights how rare full implementation still is. Only 13% fully automate code signing, while 89% lack formal enforced code-signing policies, which increases the chance of unsigned releases or key handling mistakes.

A pragmatic path looks like this:

• Define the signing policy first. Don’t automate inconsistency.
• Make signing non-optional in CI/CD. Treat it like a release gate.
• Secure the keys. Store keys in HSMs or managed KMS and secret vaults.
• Instrument the workflow. Capture evidence automatically for audit readiness.

Tools like DigiCert Software Trust Manager can help teams operationalize signing workflows by managing certificates, keys, and policy enforcement in a way that aligns with CI/CD delivery.

Don’t automate one thing—automate the chain

Automated code signing is the anchor. But integrity breaks when the rest of the security steps are uneven.

The State of SSC report shows similar inconsistency across adjacent controls:

• Security checks: Only 13% fully automated; 71% partial or ad hoc
• SBOMs: Only 11% actively provide SBOMs today
• SBOM signing: Only 17% always sign SBOMs
• Container signing: Only 12% always sign container images

These aren’t isolated gaps; they compound. An unsigned artifact is hard to trust. An unsigned SBOM is hard to verify. And a release that “might be” signed is hard to defend in an audit.

Execution friction is the real barrier

Most organizations are blocked by execution, not intent. The State of SSC report highlights key constraints:

• 55% cite budget limitations
• 55% cite lack of internal expertise
• 53% cite integration complexity
• 41% cite developer resistance

Those are pragmatic constraints. They also explain why “partial automation” becomes the default state. The interesting signal is what teams say would help. 38% say better automation and integration capabilities would improve posture. That proves a desire for fewer manual steps—not more dashboards.

A pragmatic automation checklist that doesn’t disrupt delivery

If you’re trying to improve enforcement without slowing down release cycles, use this order of operations:

1. Start with one policy-backed control: Make automated code signing a default release requirement.
2. Automate security checks consistently: Move from “some projects” to “all pipelines.” 
3. Automate SBOM generation in CI/CD: Reduce manual effort and improve consistency.
4. Make SBOM signing non-negotiable: Integrity requires proof, not assertion. 
5. Extend signing to containers: Don’t let modern delivery skip modern integrity controls. 
6. Measure automation coverage: Treat coverage as a leading indicator, not an afterthought. 

This approach aligns with what the report calls “leaders versus laggards.” Leaders automate comprehensively, secure key storage, and embed security into development workflows. Laggards fall behind.

Automation is how you make integrity repeatable

Many organizations are prioritizing governance, vulnerability management, and compliance readiness. Those are all important. But the State of SSC report also shows CI/CD security automation ranks lower than you’d expect for something so foundational.

If your program depends on best effort, the outcome will always be uneven. If your program depends on automation, consistency will naturally follow.

To see the full set of findings and recommendations, download DigiCert’s State of Software Supply Chain Security 2026 report.