Deduplication for leaked secrets in job artifacts

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

Problem to Solve

groupsecret detection is expanding to objects outside of code starting with leaked secrets in CI/CD job artifacts. If this type of leaked secret isn't resolved in the merge request, and the merge request is merged into the main branch, the finding will become a vulnerability record on the vulnerability report. This will lead to lot of duplicates if not addressed in implementation.

Example: On the first pipeline execution (P1) an artifact is created (A1), with a secret (S1). Another pipeline is run (P2) an artifact is created (A2), with a secret (S2). However, the leaked secrets S1 and S2 are the same secret but relate to a different pipeline (P1 and P2) and a different artifact (A1 and A2).

Ideal user experience

Users have one vulnerability per value of leaked secret from a job artifact.

How do we do vulnerability deduplication for code based secrets?

  • A finding is considered a duplicate of another finding when their scan type, location, and one or more of its identifiers are the same.
  • Fingerprinting for secret detection looks at the file path and line numbers; link to code.

Additional considerations

  • Secrets always require manual resolution, even when deleted from the version history (tl;dr - once leaked its always considered leaked so we can't consider removing from the repo "no longer detected")
Edited by 🤖 GitLab Bot 🤖