GitHub extended secret scanning push protection so public forks inherit more of the parent repository’s rules.
Public forks were a soft spot in a lot of secret scanning setups. The parent repository looked locked down, then someone pushed a token to a fork and the internet quietly indexed it. GitHub says push protection now covers more of those fork paths, so a secret is harder to land in the first place.
What improved
Push protection blocks a push when it detects a known secret pattern, instead of only alerting after the fact. Extending that behavior around public forks closes a workflow attackers and accidents both used. Maintainers still need secret scanning enabled on the parent. There is no free protection for a repo that never turned the feature on.
GitHub’s change is prevention at the gate. It will not scrub a key that already shipped in history. If your access log shows a token in an old commit, rotate it. Assume paste sites and scanners already had a turn.
Maintainer checklist
Enable secret scanning and push protection on anything that accepts outside contributors. Add a CODEOWNERS path for workflow files if you have not. Tell contributors that force-pushing around the block is not a clever workaround; it is how incidents get worse.
Open source thrives on forks. It should not thrive on accidental AWS keys. GitHub tightened one of the obvious holes. Do the rotation work for anything that slipped through before today.
Org-level follow-through
Turn the same protections on for template repositories and for the empty shells people fork to start hackathon work. Those quiet repos are where tokens go to die in public. Add a scheduled Actions job that fails if secret scanning is disabled on default branches of public projects. Culture beats a single blog announcement. GitHub closed a gap; your org still has to notice when someone opens a new public repo with the defaults wrong.