Add tracking info to Secret Detection
What does this MR do and why?
Context
Whenever a Secret Detection finding is created for a secret and if the same secret moves within the file, a new finding gets created along with the previous one, ending up with two findings pointing at the same secret. The new findings continue to be generated until the secret is remediated. So, we decided to solve the problem following the footsteps of SAST (which faced the same problem earlier) i.e., by introducing a tracking signature in the final report and the Rails monolith will use the signature during CI builds to determine if the new findings should be created or refer to the existing findings. For more details, refer to the linked issue.
Why this MR
This MR handles the rails monolith side of business i.e., uses tracking signature info of each finding in the SD report to ensure new findings are not generated if there are findings already present in the system for the same secret.
Technically, this MR does the following:
- Introduces new tracking algorithm type:
rule_value
- Enables UUID override logic for Secret Detection
You may find this feature's impact on the current system here
Relevant Issue Numbers
How to set up and validate locally
- Update a project with Secret Detection CI configuration to point at the patched secrets analyzer image:
# .gitlab-ci.yml
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
secret_detection:
image:
name: registry.gitlab.com/gitlab-org/security-products/analyzers/secrets:vbhat-tracking-signature
- Commit a dummy secret, say
glpat-12345123451234512345
in one of the files. - Push the commit that triggers the
secret_detection
CI job in the Pipeline. - Ensure the Secret Detection report was ingested successfully
- Open GDK rails console
- Check
Vulnerabilities::FindingSignature.where(algorithm_type: 5).count.positive?
indicating newly created SD finding havingrule_value
(i.e.5
) as the tracking algorithm.