Once we have confidence in on-by-default Secret Detection scanning, we should make it possible for the server to reject commits that include secrets. This solution should bear in mind the [Always allow for deploying to production](https://about.gitlab.com/handbook/product/product-principles/#always-allow-for-deploying-to-production) product principle. For this feature, we will likely need to make certain restrictions for performance (latency) reasons and to avoid spuriously blocking commits. For example, we will almost certainly have to: - restrict detection to a subset of patterns that can be efficiently matched - limit overall possible runtime to an acceptable number of milliseconds before failing open - seriously profile and optimize the hot path, to include using Vulnerability Research project https://gitlab.com/gitlab-org/vulnerability-research/foss/go-fastregexp or similar approaches To fully operationalize the feature or enable it by default, we must have a means to bypass detection for erroneous findings or valid use cases. We should also consider how this new feature would align with the [existing feature that prevents pushing secret files based on their filename](https://docs.gitlab.com/ee/user/project/repository/push_rules.html#prevent-pushing-secrets-to-the-repository) (not their contents).