The checkpoint that moved to after the merge.
ISO 27001:2022 A.8.25 (secure development life cycle) asks for rules for developing software and systems securely, and for those rules to be applied across the whole cycle rather than at the end of it. The guidance behind the control reaches wide: separated development, test and production environments, security requirements in specification and design, security checkpoints in projects, secure repositories and version control, developers who know what secure development means, and the same expectations for outsourced work.
Most of that is process and organisation. The part that lives in a repository is the checkpoints: the workflow that decides which checks run on a change, and when. That wiring is code, and a pull request can quietly move a checkpoint to a point where it no longer gates anything.
The shapes the same control failure takes.
A.8.25 rarely breaks with a decision to stop developing securely. It breaks when the pipeline that carries the checkpoints is reshaped for speed. The recurring shapes:
A security checkpoint moves to after the merge
A scan or security job that ran on pull requests is switched to run only on the main branch, so it reports on code that is already in instead of gating code that is about to be.
A scan is scoped away from the new code
An ignore pattern or path filter excludes a directory from security checks (generated code, a new service, an agents folder), and the exclusion grows to cover code people actually write.
A new repository ships without the checkpoints
A service is split out into its own repository, and the workflow file that ran the security checks in the monorepo is not carried over, so the new code develops outside the cycle.
Agent-written changes take a side door
A bot or coding-agent account is exempted from required checks or review to keep automated pull requests moving, so the fastest-growing source of code skips the checkpoints humans still pass through.
Security requirements drop out of the change template
The pull request template loses its security section, so design-time questions (new input, new data, new permission) are no longer asked at the point a change is proposed.
A security scan that stops running on pull requests.
The security workflow runs on every pull request and every push to main, and pull requests have been queuing behind it. To speed up review, a change drops the pull_request trigger: the scan will still run, just after merge. Nothing turns red. From now on, the first time a change is scanned is after it is already on main.
on:- pull_request:- branches: [main] push: branches: [main]jobs: security-scan:This removes the pull_request trigger from the security workflow, so the scan no longer runs before a change merges, only after it lands on main. The job still exists and still reports, which makes the change easy to miss, but the checkpoint has moved from inside the development cycle to after it. A.8.25 expects security checkpoints to be part of how software is developed (A.8.29 covers the security testing itself; the question here is where the checkpoint sits). If the scan is too slow for every pull request, scope it (changed paths, a lighter pull-request profile) rather than moving all of it past the merge.
Security reading of the same pull request
heygrc reviews this pull request against A.8.25. Aevral, an AI security reviewer from the same company, reads the same diff for security flaws and posts at most two findings as leads with evidence, on each supported pull request in repositories where it is installed.
What that contributes to A.8.25: a security check built into the development cycle, at the pull request. It is not the whole secure development life cycle: the rules, environments, repository controls, developer knowledge and outsourced work stay with you.
A.8.25 is tested on the rules, then on real changes.
An auditor starts with your documented secure development rules and then samples recent changes or projects to see whether the checkpoints those rules describe actually happened: security review or scan evidence on the pull requests, access control on the repositories, separation between environments. A workflow that moved its security scan to after the merge produces a quiet gap in that sample: the rules still say changes are checked before they merge, and for every change since the edit, the evidence says after. The edit itself is a two-line diff, which is the cheapest place to catch it.
A review, not your development life cycle.
heygrc flags changes that weaken the security checkpoints in your pipeline and cites the control so the fix happens in the pull request. It does not write your secure development rules, run your environments, or train your developers. It catches the moment a checkpoint stops gating changes, at the diff.