GitHub’s March 2026 secret scanning update adds 28 new detectors, moves 39 existing detector families into default push protection, and expands validity checks to more secret types. That sounds like routine product maintenance. It is not. It is a signal that secret scanning is becoming less about headline providers and more about the ugly reality of modern SaaS sprawl.
The list tells the story: Vercel, Supabase, Snowflake connection strings, Lark, PostHog, Databricks, Pinecone, Sentry, npm. These are the tools real engineering teams glue together every day. As stacks get more composable, secret exposure risks stop looking like just AWS keys and start looking like a hundred vendor-specific credentials scattered across repos, issues, pull requests, wikis, and comments.
What changed
- 28 new detectors from 15 providers
- 39 detector types now enabled in push protection by default
- New validity checks for Airtable, DeepSeek, npm, Pinecone, and Sentry secrets
The validity-check addition is especially important. Detection is useful; prioritization is what prevents alert backlogs from becoming decorative. Knowing whether a secret is still active is the difference between a boring alert queue and an actionable one.
Goal
Use GitHub’s expanded detection coverage to reduce real exposure, not to accumulate prettier dashboards.
Prereqs
- GitHub secret scanning enabled for the repositories that support it
- Owners for credential rotation across the SaaS tools your org actually uses
- A documented path for handling both historical findings and push-protection blocks
Steps
1) Re-read your provider inventory. If your platform team still frames secret exposure mostly as cloud-provider credentials, your model is stale. The March detector list maps to the collaboration and AI tooling your developers already adopted.
2) Turn on or review push protection defaults. Blocking bad commits before they land is cheaper than incident response after the fact. The new default detector coverage means some repos will start seeing friction. That friction is the point.
3) Define a triage split between active and inactive secrets. Validity checks should change queue handling. Active credentials need immediate rotation. Inactive credentials still reflect process issues, but they are not the same fire.
4) Scan beyond code. GitHub’s secret scanning also covers issue text, pull request discussions, wikis, and other collaboration surfaces. That matters because a lot of real leaks happen while developers are trying to be helpful, not while they are writing application code.
5) Use the update as a forcing function for custom patterns. The vendor list will never exactly match your organization. If teams use internal tokens, proprietary connection strings, or structured secrets with known prefixes, custom patterns are where mature programs separate themselves from checkbox programs.
# quick verification ideas after enabling or reviewing coverage
# 1) sample a few non-production repos
# 2) check push-protection events
# 3) verify owners know the rotation path for each provider
# 4) confirm alert workflows distinguish active vs inactive secrets# the operational question is not just "did we detect it?"
# it is also "can we rotate it quickly, and do people know who owns that tool?"Common pitfalls
- Treating all alerts equally. Active tokens and historical dead tokens should not have identical SLA handling.
- Assuming push protection alone solves the problem. It prevents some new leaks; it does nothing for the years of residue already in history and discussion threads.
- Ignoring product ownership. Security tooling can find a Supabase or Vercel credential. It cannot tell you who in the org can safely rotate it without breaking prod.
- Failing to explain the new friction. Developers are much more tolerant of blocked pushes when the remediation path is obvious.
Verify
- Review whether newly defaulted push-protection detectors are active in the repos that matter.
- Sample alerts and confirm validity-check status is visible where supported.
- Test at least one remediation workflow end to end: alert, owner assignment, token rotation, closure.
- Identify at least one provider from the March list that your org uses but has no clear credential owner for yet.
Secret scanning is getting broader because software estates are getting messier. The smart move is not just to celebrate wider coverage. It is to tighten the boring rotation and ownership mechanics behind it.