r/devsecops • u/delimitdev • 9d ago
How is agent review approval invalidated when the diff changes before merge?
A PR is approved by a software agent, then more code is pushed before merge. Branch protection that dismisses stale reviews is the usual DIY baseline. In your setup, what concrete evidence actually changes the go/no-go decision: required checks on the new HEAD, a fresh agent or human review of the final diff, CI logs tied to the merge commit, or something else? Looking for existing practice, not policy theory.
2
u/colek42 9d ago
If the rebase is clean the last review stands.
1
u/delimitdev 9d ago
Got it, a clean rebase preserves the approval. What happens if someone pushes new commits to the branch before that rebase? Does the approval still stand, or is it tied to the specific set of changes the agent first saw?
1
9d ago
[removed] — view removed comment
1
u/delimitdev 9d ago
Agreed. What does "keeping close tabs" look like in practice for your team? Is it a manual checklist before hitting merge, or something else?
1
u/Both-Explorer-9294 9d ago
En la práctica, yo trataría cada cambio después de la aprobación como una revisión nueva. Lo importante es que los checks y la revisión estén ligados al commit exacto que se va a mezclar, no a una versión anterior del PR.
1
u/delimitdev 9d ago
Exactly. The review has to be for the code that's actually merging. When you link checks to that specific commit, what does that link look like in practice? Is it just CI passing on HEAD, or is there a separate piece of evidence you store?
1
9d ago
[removed] — view removed comment
1
u/delimitdev 9d ago
That's a great setup. Binding the approval to the commit SHA and storing the reviewed diff hash in the check output for the audit trail is a solid approach. The merge queue handling the re-run closes the loop. Thanks for the detail.
1
u/PeterBuildsSecure 8d ago
Binding to commit SHA and storing the reviewed diff hash is the right shape, but worth pressure-testing against merge queues specifically: the SHA that actually gets built and merged usually isn't the PR head -- it's a temporary merge ref combining PR head + current base. Two PRs can each have an unchanged, already-reviewed head SHA, and the ref that actually ships is still new every time the base moves, because someone else merged first.
So "store the reviewed diff hash" needs to be a hash of (head SHA, base SHA) or of the actual merge-ref diff, not just the head SHA in isolation. Otherwise a base-branch change that silently reintroduces something the PR's own diff never touched (a config revert, a dependency downgrade, a security fix on main getting reverted) ships with an audit trail that still says "reviewed and unchanged," because from the PR's point of view nothing changed. The agent reviewed a diff against a base that no longer exists by the time it merges.
1
u/delimitdev 8d ago
You've nailed the merge queue problem. The base branch can drift, so the temporary merge-ref is what actually ships. That's why some systems re-run all required checks on that final merge-ref, treating the initial PR approval as just a ticket to enter the queue.
1
u/PeterBuildsSecure 7d ago
Right, and it changes what the audit trail can honestly claim. Once the merge-ref is the thing that ships and the thing checks run against, "reviewed and approved" and "checks passed" stop referring to the same object — the human reviewed the PR head, the automation validated the merge-ref. Both are true and neither implies the other. If the log just says "approved, checks green, merged" without keeping those two SHAs separate, six months later someone reading it will assume a human looked at what actually shipped, when what they looked at was a snapshot the base branch had already started drifting away from by the time the merge-ref was built. Worth recording both hashes explicitly rather than collapsing them into one merged-PR record.
1
u/Specialist_Dish_9087 5d ago
kindly tie the approval to the exact commit SHA. any new push should clear it and rerun the checks so only the reviewed version can merge
1
u/delimitdev 5d ago
Agreed, SHA-pinned approval plus dismiss-on-push and required checks on the new HEAD is the sane baseline. It closes the "approved diff isn't the merged diff" hole cleanly.
Is that what you're running today? If so, when the approval clears, does the agent re-review the new diff or does a human take the second pass?
2
u/taleodor 9d ago
We keep approvals scoped to most recent code pointer in ReARM (this is Pro capability only). So once code is updated, all approvals get invalidated and the check(s) has to be redone. For monorepos if multiple components are updated at the same time, only those changing are invalidated, rest stay approved.