GitHub improved enabling code scanning at scale — across many repositories at once rather than one at a time.
This is the least exciting item in a month that included four model launches, and it is probably the one with the largest effect on how many vulnerabilities ship.
Why coverage beats sophistication
Most organisations do not have a code scanning problem. They have a code scanning coverage problem — it is enabled on the repositories someone got around to, which is rarely all of them.
The repositories that get missed are the old ones, the internal tools and the ones nobody owns. Those are also where unreviewed code accumulates.
The volume argument
Agents write more code than teams did a year ago, and they write it across more repositories. Every prompt-to-app tool in this directory generates full projects, cloud agents open pull requests, and comment-triggered automations arrived on 4 August.
Scanning that is enabled per-repository by hand cannot keep up with code that is generated at that rate. This change is about matching the security process to the production rate.
What to do with it
- Get a list of repositories in your organisation without code scanning enabled — the number is usually higher than people expect
- Enable it broadly first and tune the noise afterwards; partial coverage is worse than noisy coverage
- Pair it with the 28 July Dependabot changes so both your own code and your dependencies are covered