secguro / secguro-cli

0 stars 0 forks source link

deduplikation von findings #152

Open m1cm1c opened 4 months ago

m1cm1c commented 4 months ago

deduplikation in der cli-anwendung hast du gesagt soll ja erst später kommen (in der web app schon implementiert, weil sowieso notwendig um findings zwischen scans zu deduplizieren). ich möchte hier nur kurz etwas notieren, um später nicht verwirrt zu sein:

gitleaks hat einen bug, der dafür sorgt, dass im selben scan mehrfach das gleiche finding auftreten kann. beispiel auf dem wallet-projekt (mit scan --git --disabled-detectors dependencycheck,semgrep):

Finding 14:
  detector: gitleaks
  rule: generic-api-key
  match: SECRET_KEY=[zensiert]
  location: .env.dev-test-public:46:9
  historical location: .env.dev-test:46:9
  commit hash: b456c5214af21532f5b64227f5df608490c4d71c
  commit date: 2022-08-09T21:19:54Z
  author: Matthias Stumpp
  author email address: [zensiert]
  commit summary: Fix balances / top ups

[...]

Finding 23:
  detector: gitleaks
  rule: generic-api-key
  match: SECRET_KEY=[zensiert]
  location: .env.dev-test-public:46:9
  historical location: .env.dev-test:46:9
  commit hash: b456c5214af21532f5b64227f5df608490c4d71c
  commit date: 2022-08-09T21:19:54Z
  author: Matthias Stumpp
  author email address: [zensiert]
  commit summary: Fix balances / top ups
m1cm1c commented 3 months ago

ich hab ein public repo gefunden, in dem der bug aufritt (ethers), und einen bug report erstellt: https://github.com/gitleaks/gitleaks/issues/1419

m1cm1c commented 2 months ago

man sieht hier ja keine aktivität in dem referenzierten issue, weil ich nicht zu externen github-issues linken darf, daher als kommentar: das isssue wurde geschlossen, weil gitleaks in dem von mir genannten beispiel keinen fehler gemacht hat. der fehler scheint in git blame zu liegen: git blame scheint manchmal unterschiedlichen zeilen, die sogar im selben commit an 2 unterschiedlichen stellen existiert haben, demselben ursprung zuzuordnen