Secret Scanning, Push Protection, Custom Patterns, Bypass Controls, and Incident Response: Configuration, Design Choices, and Tradeoffs

1. Built-in pattern, generic detection, or custom pattern?

Start by asking whether GitHub already knows the credential format. Provider patterns receive the strongest platform integration because GitHub can attach provider metadata, partner notification, validity checks, or push-protection support when that specific pattern supports them. Adding a custom regex that duplicates a mature provider pattern creates a second rule with different identity and false-positive behavior.

A custom pattern is internal security code. Give it test fixtures, an owner, change review, an expected false-positive rate, and a rollback plan. Current GitHub supports dry runs before publication; treat that as the observation phase of a policy rollout, not a cosmetic preview.

2. Block, direct bypass, delegated approval, or exemption?

Blocking is the default for real secrets because the cost of stopping a commit is usually far lower than rotating a production credential. A bypass exists for exceptional non-secrets and constrained workflows; it should not become the normal path for “the build is urgent.”

3. Repository enforcement versus organization-wide enforcement

Repository-level controls are appropriate for learning, pilots, and repositories with unusual requirements. Organization-wide security configurations reduce drift and make ownership clearer, but an overly broad pattern or exemption can also cause organization-wide disruption. Centralization increases both consistency and blast radius.

4. History rewrite after revocation: security benefit versus operational damage

Once a credential is revoked, it cannot authenticate even if an old commit remains discoverable. That often removes the urgent security risk. Rewriting history may still be justified when the exposed material is not revocable, contains regulated/private data that must be removed, causes scanners/users to repeatedly rediscover sensitive content, or policy/legal requirements demand removal.

5. Detection policy is not secret-storage policy

Push protection reduces accidental commits; it does not authorize storing credentials in files that happen not to match a pattern. Production systems still need secret managers, short-lived identities, environment separation, least privilege, and rotation. Unknown formats, encoded values, transformed secrets, or unsupported token versions can evade pattern-based controls. The policy should therefore say “no secrets in source” rather than “anything push protection allows is safe.”

Likewise, validity checks are a prioritization tool. If a high-value credential is credibly exposed, rotate it even if validity metadata is unknown or stale. A prevention system should fail safe around uncertainty rather than wait for a perfect detector.

6. Worked scenario: choose a policy for Atlas Relay

Atlas Relay has 40 repositories, a proprietary deployment token formatted AR_DEPLOY_ plus 32 base32 characters, a migration bot, and a security team of three. Most repositories are private; one documentation repository is public. Evaluate the choices rather than copying a universal answer.

Knowledge check

Summary

Secret policy balances detector coverage with developer friction. Prefer maintained built-in patterns, treat custom patterns as tested platform code, make bypass authority narrower than write authority, centralize only after a pilot, and rewrite history only when it adds real risk/compliance value after revocation.

Next you will diagnose the common ways teams defeat these controls through sequencing, noise, scope mistakes, and incomplete rotation.

Official references

• GitHub security features
• Custom patterns
• Delegated bypass
• Enable delegated bypass
• Secret scanning detection scope
• Remove sensitive data