DevOps / SRE / Platform · 12.08.2026, 15:25 UTC
How GitLab tracks vulnerabilities through refactors and reformatting
| Schweregrad | info |
|---|---|
| Kategorie | DevOps / SRE / Platform |
| Quelle | GitLab Blog ↗ |
| Veröffentlicht | 12.08.2026 UTC |
Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.
Every day, security scans face the same problem: an agent or a developer adds a comment, reformats a file, or moves a function, and a naive vulnerability tracker suddenly reports the same finding twice. Security teams end up re-triaging issues they already dismissed, which causes futile auditing effort and erodes trust in the scan results.In 2022, we introduced advanced vulnerability tracking to tackle exactly this problem of code volatility. It is based on our Scope+Offset fingerprinting method: instead of identifying a finding by file and line number, we identify it by its narrowest enclosing scope (module, class, function) plus its line offset within that scope. That made tracking robust against code moving around the file and reduced futile re-auditing by about 30% compared to line-based tracking.But one class of edits still slipped through: non-functional changes. The offset counted every line between the scope boundary and the finding, including comments and blank lines. Add a comment above a vulnerable statement, and the offset shifts. The tracker sees a "new" vulnerability; you see a duplicate.Our improved method addresses this by simply ignoring non-functional code (comments and blank lines) when computing the fingerprint. Since these lines do not affect the program's behavior, they should not affect the identity of a vulnerability either. With this normalization in place, adding a comment or reformatting a file no longer changes the fingerprint, while the precision of the tracking remains the same as before. The details of the approach are described in our …