GitHub published a secret scanning update on 5 November 2026. It is a small, practical release, but it lands at a time when more code is written by AI tools and more code means more chances for an access key to end up where it shouldn’t.

What the changelog says

• Fewer false positives for cloud keys. The AWS (aws_access_key_id, aws_session_token, aws_temporary_access_key_id), Google Cloud Storage and Alibaba Cloud key-ID detectors no longer flag an unpaired match when filtering removes all the qualifying companion secrets.
• Tighter matching for OpenVSX tokens, Pydantic Logfire tokens and Tencent Cloud secret IDs, so unrelated IDs, placeholders and public browser tokens are not treated as secrets.
• A new partner and detector. SpaceX joined the secret scanning partner programme, with a new starlink_public_api_v2_secret detector. When one of its secrets is found in a public repository, GitHub tells SpaceX so it can be revoked or rotated.

The interpretation

Secret scanning only helps if people trust the alerts. Every false alarm teaches a team to ignore the next one. Cutting noise on the most common cloud providers makes the real alerts more likely to be acted on.

The wider point: a leaked key is one of the most common and most expensive mistakes in software, and AI-generated code does not remove it. An assistant will happily write a working example with a real credential in it if one is in front of it.

So what

If you commission software, ask your supplier whether secret scanning is switched on for your repositories, who sees the alerts, and how fast a leaked key is rotated. These are cheap to turn on and expensive to skip. BuildApps builds this into delivery for custom software development and AI-assisted development. To talk it through, start a project.

← All research