Why do rebases make CI verification harder?

Why rebases make CI verification less trustworthy

A rebase rewrites history by creating new commits, so the code under review can end up with different commit IDs even when the visible diff looks similar. That matters because CI results are only meaningful if they can be tied to the exact inputs tested. Once the tested tree changes, a green build no longer guarantees the current tree was what CI actually exercised.

The practical problem is not that CI becomes useless, but that the verification anchor moves. If your pipeline keys approval to branch state, label, or reviewer memory instead of an immutable commit or content digest, a rebased branch can slip in untested changes while preserving the appearance of prior validation. That is a supply-chain integrity problem as much as a workflow problem, which is why build provenance matters here; SLSA is the clearest external model for binding build evidence to the artifact or source input that was actually verified.

Rebases can also make the test surface itself drift. A rebase may replay commits in a new order, drop one, split one, or resolve conflicts differently, which means the final merged state can differ from the state that earlier CI jobs saw. In other words, the issue is not only “did tests pass,” but “did tests pass against the same content that will be merged or deployed?”

What goes wrong when CI is tied to mutable branch state

Mutable references create a verification gap: the pipeline may attest to a branch tip that no longer exists, not the exact tree that is now pending merge. If a cached result, status check, or review bot treats the branch name as the identity of the tested code, a later rebase can swap in a different history without forcing a fresh verification run. That is why commit-anchored checks are stronger than branch-anchored checks.

A second failure mode is partial reuse. Teams often reuse previous CI signals to save time, but after a rebase the reused signal may be stale even if only a few lines changed. The risk is highest when the pipeline has path-based skips, selective test execution, or artifact reuse, because those optimisations assume the input set is stable. Rebase invalidates that assumption.

When verification controls are meant to protect authentication, session handling, or access logic, the bar should be higher. The verification target should match the exact revision under test, which is consistent with the way application security verification standards expect security-relevant behaviour to be exercised against the code actually being shipped; OWASP ASVS is useful here because it frames verification around the implemented application state, not an approximate branch snapshot.

How to make rebases safer for CI and release decisions

Use immutable identifiers for the thing you tested, and require CI evidence to bind to them. That can mean recording the exact commit SHA, the resolved tree hash, or a content digest for the source inputs that produced the run. If a branch is rebased after the run, the approval should fall away automatically unless the new commit set is revalidated.

Prefer merge policies that force a fresh pipeline on the post-rebase result, especially for protected branches. If you allow rebases, make the rule explicit: a green run is only reusable when the tested commit set is still identical to the candidate tree. Where that cannot be enforced mechanically, treat the situation as an exception and require manual review of the changed inputs, not just the status badge.

What to verify: Check that your CI system records the exact source revision, not only the branch name or pull request number. Confirm that any status check, artifact, or approval is invalidated when the tested commit set changes.

Common mistake: Teams assume “the diff looks small” means prior tests still apply. With rebases, the meaningful question is whether the tested tree is still the same tree, not whether the visible changes seem minor.

Practitioner takeaway: Treat rebases as a verification invalidation event unless your pipeline can prove the tested inputs are identical to the code now under decision.

Risk and Threat Considerations

Rebase-related verification gaps can let a pipeline approve code that was never exercised in its final form. The security issue is integrity, not convenience: an attacker or careless contributor can exploit the gap to make the reviewed and tested state diverge from the merged state without obviously breaking the build.

Failure mechanism: CI evidence is attached to a mutable branch reference or stale test input, so a later rebase replaces the verified tree with a different one while the approval signal remains in place.

Impact: The release process may ship or merge code that bypassed the intended test coverage, undermining trust in both the pipeline and any downstream security gate that depends on it.

Practitioner Guidance

Decision rule: If your CI check cannot prove which exact commit or content digest it validated, do not reuse that result after a rebase. Re-run the pipeline on the post-rebase tree and invalidate any approval that was based on the pre-rebase history.

What good looks like: The merge gate, the CI report, and the release artifact all point to the same immutable source revision. If the revision changes, the evidence changes with it.

Practitioner takeaway: Rebases are acceptable only when your verification model is revision-aware; otherwise they turn “tested” into an ambiguous label rather than a reliable security signal.

Related resources from NHI Mgmt Group

• Why do VPNs make age verification harder to enforce?
• Why do CI pipelines make secret exposure harder to control than service accounts?
• Why do fragmented healthcare systems make identity verification harder?
• Why do CI/CD workflows make supply chain worms harder to contain?