policy name: secret_scanning
severity: HIGH
This security control checks for secrets being checked into a repository and prevents it. Turning on secret scanning detects many kinds of secrets being checked into a repository and reports it. Push protection builds on secret scanning and prevents attempts to add such secrets (and creates an alert if that is overridden).
Inserting a secret into a source code repository is unfortunately an easy mistake to make. Instructions for various services often encourage putting secrets into a repository (as it’s the “simple” way to do it, though not the secure way). Once secrets are in a repository, they become available for anyone who can view the repository (directly or via a copy). Inserting secrets into a source code repository is a mistake, since it interferes with the whole point of a secret: keeping it secret. This is such a common type of vulnerability that it is identified as the Common Weakness Enumeration (CWE) CWE-540: Inclusion of Sensitive Information in Source Code.
Like practically all tools, secret scanning is subject to false positives and false negatives. That said, secret scanning can prevent significant vulnerabilities and should be enabled.
There are two different steps, scanning and enforcement:
The GitHub documentation describes how to enable secret scanning.
In short, to enable GitHub secret scanning on a repository:
You may also choose to enable other secret scanning tools. For example, those with access to the Linux Foundation’s LFX tools should consider enabling its secret scanning tools as well.
In GitHub you can enable push protection on secret scanning for repositories and organizations. When this is enabled, secret scanning “blocks contributors from pushing secrets to a repository and generates an alert whenever a contributor bypasses the block.”
The GitHub documentation describes how to enable push protection with secret scanning.
In short, to enforce GitHub secret scanning on a repository: