Secret Detection continuous scanning

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Context

Today, secret detection runs as an analyser that needs to be explicitly configured to run in a CI pipeline.

This issue tracks the effort to migrate this approach to continuous scanning, where GitLab can proactively detect leaked secrets without user configuration, outside of a CI job, whenever code is pushed to the platform.

Proposal

This is a broad problem that can be tackled over several stages:

1. Migrating the current secret detection capability for source code out of CI jobs that need to be manually configured by the user (or with AutoDevOps). We're aiming to automatically invoke secret detection scans, asynchronously, when commits are pushed. We won't be using a pre-commit hook and won't be in the critical path for commits at this stage. We're referring to this as "continuous secret detection".
2. Improving the data model and UX for presenting secret detection findings to the user, and a suitable alerting mechanism. Note that we currently automatically revoke some kinds of leaked tokens, but we don't alert users through the GitLab platform.
3. Expanding continuous secret detection to cover other kinds of content on GitLab, like issue comments, MR descriptions, job logs etc. This is a long-term goal.