CI evidence, not faster reruns, is the real bottleneck

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Testifysec's blog post: CI reruns are expensive because teams trust execution after the fact instead of requiring evidence before a push is allowed to proceed.

Why it matters: IAM and platform teams should read this as a governance problem, because agent-driven development increases the volume of retries while weak evidence controls let unverified work keep consuming pipeline time.

Context

CI pipelines are often treated as a technical convenience, but the governance gap is that teams assume a successful run is enough proof to trust the next step. In practice, repeated retries, merge races, and cold-start rebuilds mean the pipeline keeps spending time on work that may not deserve to proceed.

This becomes more visible when agent-assisted development increases the number of pushes and checks, because the control problem shifts from execution speed to evidence quality. CI/CD pipeline identity security matters here because the decision to admit a change depends on who or what produced the run, what it actually proved, and whether that proof still applies after rebasing or retried execution.

Key questions

Q: How should teams stop CI from accepting unverified green runs?

A: Require CI to treat a green run as valid only when the run is backed by signed evidence for the exact checks, inputs and environment that produced it. A release gate should verify the attestation or execution record, not just the final status badge, so an unverified rerun, replayed log or tampered result cannot pass.

Q: Why do rebases make CI verification harder?

A: Rebases change commit IDs and can alter the input set that CI sees, so a previously green result may no longer prove the current code path was tested. Verification should bind the run to tested inputs or content digests, otherwise the pipeline can approve a different tree than the one that was actually checked.

Q: How do CI caches differ from evidence in a release gate?

A: CI caches store reusable build outputs, dependencies, or intermediate files to speed up subsequent pipeline runs, while evidence in a release gate is the auditable record of execution used to prove what ran, what changed, and who approved it. Cache content can be discarded or rebuilt. Evidence must be immutable, tied to a specific build, and retained for review.

Q: What should teams do when agent-driven pushes increase CI retries?

A: Add rate limits, protected branches, queueing and change controls around the agent’s write path, then require CI to deduplicate retries by commit hash and run ID. If an agent-driven push causes repeated runs, treat that as a workflow-control failure and narrow the agent’s authority to submit only through approved, idempotent paths.

Technical breakdown

Why cold-start CI keeps repeating the same work

A cold CI run has no durable memory of what was already verified elsewhere, so every push replays the same checks from scratch. Caching helps only when the same machine, inputs, and trust boundary remain in place. Once the runner is ephemeral, the cache state, execution context, and proof of what actually ran become separate problems. That is why faster containers or alternate runners reduce runtime but do not change the governance question: whether the next stage can trust the result that just came back. Read How to find secrets in CI logs and build artefacts.

Practical implication: Treat execution speed as secondary to proof portability, because the next gate only benefits if the earlier run can be trusted outside its original machine.

Why signed build evidence changes the trust model

Signed evidence turns CI from a transient event into an auditable control point. Instead of trusting a green exit code, the consuming gate checks what was run, what inputs it used, and whether the record was bound to the relevant change. That matters because a run can pass while the intended tests were skipped, changed, or never invoked. Evidence that survives outside the original runner lets later policy decisions distinguish a genuine pass from a merely successful command invocation.

Practical implication: Require the gate to evaluate signed run evidence, not only job status, before it admits a change to the next stage.

How commit-based evidence breaks on rebases

Commit-bound proof is fragile because a rebase creates a different commit even when the human intent is unchanged. That means the evidence for the earlier commit no longer covers the new object that will land. Binding evidence to input digests is stronger because it tracks the substance of the change rather than just the Git object identifier. This is the key architectural shift: evidence needs to follow the verified inputs, not merely the commit hash that happened to carry them.

Practical implication: Anchor verification to the inputs that were tested, so rebases do not force unnecessary full reruns when the relevant content is unchanged.

Threat narrative

Attacker objective: The objective is to get an unverified or incorrectly verified change through the pipeline while hiding the fact that the required checks never provided trustworthy evidence.

1. Entry begins with a developer or agent pushing a change into CI, where the pipeline accepts the request and starts work on a fresh runner.
2. Escalation occurs when the workflow can present a green result without having executed the intended checks, or when the same commit is retried repeatedly without new evidence.
3. Impact is wasted runner time, false confidence in unverified changes, and a trust gap between the command that ran and the change that ultimately lands.

Breaches seen in the wild

• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Evidence quality is the control point, not runner speed: CI becomes governable only when the pipeline can prove what actually ran, not merely that a job ended with exit 0. Faster infrastructure reduces latency, but it does not answer whether the result was produced by the intended checks. Practitioners should treat proof of execution as the primary boundary, because without it every green run is just an assertion.

Commit identity is too weak for verification: A commit hash records version control history, not the semantic identity of the tested inputs. Once a change is rebased, the old proof no longer maps cleanly to the new object, even if the human intent is the same. The implication is that governance based only on commit-level approval is already misaligned with modern CI behavior.

Trusted reruns create identity drift in the pipeline: A workflow that reruns until it succeeds encourages the system to trust repetition rather than evidence. That is not just inefficient; it teaches the organisation that repeated execution is equivalent to verified execution. The better model is a governed evidence chain, where the pipeline admits only runs whose inputs, outputs, and policy state all line up.

CI/CD pipeline identity needs attested state, not just authZ: The identity problem here is not merely who can trigger the pipeline, but what proof the pipeline carries forward after it runs. Once agents can initiate more pushes and more retries, the trust model needs to follow the evidence artifact instead of the transient job. Teams that keep relying on job status alone will keep paying for the same uncertainty twice.

Ephemeral execution demands lifecycle governance for evidence: The workflow, not just the credential, needs a lifecycle. If the record that just passed cannot be reused, validated, or revoked with clear policy semantics, then the organisation is still governing by runtime optimism. The practical implication is that CI evidence should be managed as a governed identity object with scope, validity, and expiry.

What this signals

Evidence-bound CI will become the practical default for teams that rely on agents: once agents can generate more pushes, the cost of trusting every retry rises faster than the cost of verifying the run once. The governance shift is from post-run acceptance to pre-admission proof, because repeated execution is no longer a reliable signal of correctness.

Organizations that keep using job completion as the trust signal will see more false confidence, not just more spend. The next maturity step is to govern the artifact that proves the run, because pipeline scale without evidence discipline simply multiplies uncertainty.

Trusted pipeline state: the useful unit of control is the signed record that a specific check ran against specific inputs. That record can survive reviewer changes, rebases, and retries in a way that a green status badge cannot.

For practitioners

• Define evidence as a release prerequisite Require signed proof of the relevant test run before a change can move past the repository gate, and make the gate reject missing or partial evidence.
• Bind verification to tested inputs Store the digest or equivalent content fingerprint for the inputs actually tested, so rebases and rewritten commits do not force unnecessary reruns when the substance is unchanged.
• Reject green runs without required checks Block changes that report success but omit the specific test class the policy requires, including cases where the workflow is configured to skip validation entirely.
• Separate retry economics from trust decisions Track red push attempts, rerun volume, and gate refusals as governance signals, not just cost metrics, so the team can see where evidence is failing to keep up with agent-driven retries.

Key takeaways

• The core problem is not CI speed alone, but the absence of trustworthy evidence that the right checks actually ran.
• The article shows that green job status, cached output, and repeated reruns can all fail as proof unless the record is bound to the tested inputs.
• Practitioners should move the trust decision to admission time, where signed execution evidence can block incomplete or unverified changes before they consume more pipeline capacity.

Related NHI Mgmt Group resources: CI/CD Pipeline Identity Security Guide · GitHub and GitHub Actions Security Guide · How to find secrets in CI logs and build artefacts · Dual control and four-eyes approval for privileged and agent actions

Key terms

• CI Evidence: CI evidence is the record that proves a pipeline run happened and what it ran against. It usually includes logs, attestations, run IDs, commit references, artefact hashes and signatures, so a release gate can verify execution rather than trusting a green status alone.
• Content Digest: A content digest is a fixed-length hash of data, code or a file. It changes when the content changes, so practitioners use it to compare inputs, detect tampering and bind build artefacts or pipeline runs to a specific version of material.
• Ephemeral Runner: A disposable build executor that exists only for a single job or short-lived task. Ephemeral runners reduce the chance that credentials, state, or malicious changes persist across builds, which makes them a key control for pipeline isolation and supply chain resilience.
• Merge Queue: A merge queue is a system that orders approved pull requests for integration and revalidates them in sequence before landing. It reduces merge races, repeated rebases, and wasted CI runs when several changes are ready at once, which makes it useful in busy repositories with heavy automation.

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.