Committed secrets are detected before they reach the default branch
A leaked credential is live from the moment it is pushed, and rewriting history does not revoke it. Detection at the push is the difference between rotating one key and auditing everything that key could reach.
Observable check
on GitHub, gh api repos/{owner}/{repo} --jq .security_and_analysis reports both secret_scanning and secret_scanning_push_protection as enabled, read back after any write rather than inferred from one, because the repository PATCH answers 200 while silently discarding a field it will not honour; an absent security_and_analysis key means the caller is not an admin, which is unknown rather than disabled. Non-provider patterns and validity checks are GitHub Secret Protection, a paid product, and fall outside this rule. On GitLab, either GET /projects/:id/security_settings reports secret_push_protection_enabled true, which requires Ultimate, or the project's pipeline includes Jobs/Secret-Detection.gitlab-ci.yml, which is available on Free.
Where this comes from
- https://docs.gitlab.com/user/application_security/secret_detection/secret_push_protection/
- https://docs.gitlab.com/user/application_security/secret_detection/pipeline/
- https://docs.gitlab.com/api/project_security_settings/
Last read against these sources on 2026-07-28.
The GitLab sources set the tier split the rule records: push protection is Ultimate, pipeline secret detection is Free. The GitHub half has no document behind it and rests on an observation against svyatov/oss-kit: a repository PATCH setting secret_scanning_non_provider_patterns and secret_scanning_validity_checks returned 200 and left both disabled, which is what puts those two switches outside the rule and what the read-back requirement exists to catch. A GitHub document stating that the PATCH discards unavailable fields would retire the observation in favour of a source.