GitHub quietly upgraded repository security: more secret detectors, stronger push protection, and better CodeQL visibility

Short version: GitHub quietly raised the baseline for repository security. It added more secret detectors, made push protection more useful, and made CodeQL more informative for branches that teams actually use. This is not just another admin checkbox. It is a chance to catch leaks before a token ends up in logs, issues, or someone else’s fork.

What changed

In late March, GitHub shipped several practical security updates for teams that keep code, CI, and infrastructure in the same place.

First, Secret scanning got nine new secret types and extra validity checks for npm. In plain language: GitHub is better at distinguishing a real token from a random string, and it is more likely to catch something that previously slipped through.

Second, Push protection became stricter and more useful by default for some providers. Human translation: accidental secret commits are still possible, but the platform is more likely to say “stop, this looks like a key” before the change is pushed to the remote repository.

Third, CodeQL now shows data for all Protected branches in the security overview, not only the default branch. That matters because real-world risk often lives in release, hotfix, or maintenance branches that people check much less often.

Why ordinary teams should care

Most leaks do not look like a Hollywood incident. Nobody shows up in a hoodie. More often it is a secret in YAML, a token in a test config, a key in a PR comment, or a service account that accidentally made it into a fork.

For small and mid-sized teams the pattern is even simpler:

• repositories grow faster than discipline;
• secrets are scattered across code, workflows, docs, and issue templates;
• people often work in several branches at once;
• secure settings exist, but nobody checked them after the first enablement.

GitHub’s new changes help exactly here. They do not solve everything automatically, but they reduce the number of places where you can quietly miss a problem.

What to check in 20 minutes

Here is a short audit you can do without reviewing your entire portfolio.

1. Identify the critical repositories

Start by listing 5-10 repositories where a leak would hurt the most:

• the main product;
• infrastructure;
• CI/CD;
• automation repositories;
• any repository with access to cloud, registry, or build systems.

If you cannot make that list in two minutes, that is already a sign that the team’s risk map is not very clear.

2. Verify secret scanning

Check whether it is enabled on those repositories and whether it actually covers where your secrets live.

Pay attention to:

• repositories that fell out of coverage;
• whether the token providers you use are covered;
• whether you can see recent alerts, not just a green badge.

3. Verify push protection

Here the question is not just “is it enabled?” but whether it actually changes behavior.

Ask:

• does GitHub block pushes with secrets on the main repositories;
• do people know what to do when the block appears;
• has bypass become a normal “I’ll just skip it once” habit.

If bypass is common, the problem is probably not GitHub. It is the workflow.

4. Open CodeQL / Security Overview

Check whether you only see the default branch or whether the view includes all protected branches.

This is especially important for:

• release branches;
• hotfix branches;
• long-lived maintenance branches;
• repositories with several active lines of development.

If you only see main, part of the picture is hidden.

5. Look at the places where secrets like to hide

Classic hiding spots:

• .github/workflows/*;
• .env and sample .env files;
• README examples;
• issue templates and docs;
• test configs;
• comments in PRs or commit messages.

GitHub catches a lot, but not everything. Especially if the team tends to keep “temporary” things around longer than planned.

What not to do

• Do not treat a green badge as proof of security.
• Do not postpone protected-branch checks because “we only care about main”.
• Do not use push-protection bypass as a normal workflow path.
• Do not assume secret scanning replaces a secret manager.
• Do not leave the checks for once a year after the next incident.

When GitHub changed the rules

There is a subtle but important point: these updates only matter if your team notices them and tunes them for its own reality.

For example:

• new detectors matter if your stack really uses those providers;
• push protection matters if people know how to work without habitual bypasses;
• CodeQL matters if you look beyond the main branch and into the full branch lifecycle.

Otherwise you get the classic result: the feature exists, but the benefit does not.

Practical takeaway

In short, GitHub just made your baseline repository security a bit smarter. But it is not a replacement for process — it is a force multiplier for process.

The best next step today:

1. pick the critical repositories;
2. verify secret scanning and push protection;
3. open CodeQL for all protected branches;
4. remove places where secrets can sit without a reason;
5. agree on who responds when push protection fires.

If you do that now instead of after something leaks, GitHub finally saves you nerves instead of just generating another security report.