Validate detected secrets
Problem to solve
Secrets detection can lead to a lot of false positives (our online documentation is a good example).
Intended users
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
Further details
Secrets are often based on regexps, and it's hard to tell if we're dealing with an example or a real secret being leaked.
Proposal
One good way to reduce false positives is to try validating the detected secret. Every type of secret that we support should come with a way to validate them. For example, a GitLab API token can be tested with an HTTP request. If the result is a 200, it's likely to be a real secret.
We can change the confidence of these findings to Confirmed
.
Moonshot
Validated leaking secrets should be revoked. It should be easy, depending again on the type of secret, to regenerate new tokens.
Caution: Automatically revoking tokens can also lead to outages, as many services could depend on the revoked token. If they're not clearly defined, they will instantly lose access, leading to downtimes.
Users could define in Govern in this case (revoke Confirmed
, ignore others, etc.)
Permissions and Security
Same as SAST
Documentation
Update SAST and Secrets detection doc.
Testing
TODO.
What does success look like, and how can we measure that?
- The number of
Confirmed
secrets.