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.
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:
rule_value
You may find this feature's impact on the current system here
# .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-signatureglpat-12345123451234512345 in one of the files.secret_detection CI job in the Pipeline.Vulnerabilities::FindingSignature.where(algorithm_type: 5).count.positive? indicating newly created SD finding having rule_value(i.e. 5) as the tracking algorithm.