Push protection bypassed into irrelevance
An organization with 3,000 repositories enabled secret scanning and push protection for all repositories six months ago. Developers now hit about 1,850 push blocks per month. 62% of blocks are bypassed, and the most common bypass reason is used in tests. Security reviews 400 open alerts concentrated in test/fixtures/*.json and documentation examples that match generic patterns. Three months ago an engineer bypassed a block for an AWS access key in a private repository; the key stayed valid for nine days until a partner notification arrived. The platform team also wants to protect a proprietary token format, acme_svc_ followed by 32 characters, used by internal services. Release engineering regularly needs to commit redacted sample configurations during incident response and wants the ability to bypass without filing a ticket, while the security team wants every bypass attributable and reviewable.
1. How do you cut the false-positive noise without weakening push protection?
Read the worked answer
Do not weaken push protection globally. Split the noise into two categories.
Test fixtures and documentation: replace real-looking values with clearly fake placeholders that do not match patterns, and add path filters to the proprietary custom pattern so acme_svc_... is not blocked under test/fixtures/. Partner-detected patterns such as AWS keys cannot be path-excluded through pattern configuration; the durable fix is changing the fixture content, because a matching key in a fixture teaches developers that bypassing is normal.
Proprietary token: define a custom pattern with a precise regex (acme_svc_[A-Za-z0-9]{32}), test it against a corpus before enabling push protection, and enable it organization-wide so coverage is uniform.
Track blocks per week, bypass rate, and the share of blocks from test paths. If the bypass rate stays above roughly 20-30%, push protection is being trained away and needs content fixes, not more warnings.
2. Design the bypass governance for release engineering.
Read the worked answer
Use delegated bypass rather than granting bypass rights to every admin. Configure the push protection bypass permission for the release-engineering team only, and enable a bypass request flow where security approves urgent cases. Keep the reason list meaningful and require free-text justification for test-data and incident-response reasons.
Every bypass emits an audit log event and appears with the committer and reason, so stream the audit log to the SIEM and alert on bypasses outside release engineering or outside business hours. Review bypasses weekly in Security Overview and revoke permission from people who no longer need it.
The trade-off is latency during incidents; pre-approve the release team and give them a documented rotation procedure. Critically, a bypass must never imply the secret is acceptable: it still has to be rotated, and the bypass only records that the push was allowed to proceed under known conditions.
3. What is the correct response to the AWS key that stayed valid for nine days?
Read the worked answer
Treat it as a credential incident, not alert triage: the key was valid for nine days, so assume it was used. Revoke or rotate it first, then query CloudTrail and provider logs for that access key ID, look for created resources or data access, and only then resolve the alert as revoked. Deleting the commit or force-pushing does not help, because the secret remains in history, forks, and caches; if the repository is ever made public, assume the key was copied.
Contain the class of problem: search the organization for the same secret, enable validity checks where the provider supports them so active secrets are labeled, and confirm push protection blocked later copies. Fix the process that allowed a nine-day gap by routing partner notifications to an on-call queue, and review the original bypass to see whether reason text and approver were captured.