Wie GitLab Schwachstellen über Refactorings hinweg verfolgt

Security-Scans stehen täglich vor demselben Problem: Ein Agent oder ein(e) Entwickler(in) ergänzt einen Kommentar, formatiert eine Datei neu oder verschiebt eine Funktion, und ein naiv arbeitendes Vulnerability-Tracking meldet dasselbe Finding plötzlich zweimal. Security-Teams triagieren dann Findings erneut, die sie längst verworfen hatten. Das bedeutet vergebliche Prüfarbeit und untergräbt das Vertrauen in die Scan-Ergebnisse.

Die Lücke im bisherigen Fingerprinting

2022 haben wir das erweiterte Vulnerability-Tracking eingeführt, um genau dieses Problem der Code-Volatilität anzugehen. Grundlage ist unsere Scope+Offset-Methode zum Fingerprinting: Statt ein Finding über Datei und Zeilennummer zu identifizieren, identifizieren wir es über den engsten umschließenden Scope (Modul, Klasse, Funktion) und den Zeilen-Offset innerhalb dieses Scopes. Damit wurde das Tracking robust dagegen, dass Code innerhalb einer Datei verschoben wird, und die vergebliche Nachprüfung ging gegenüber zeilenbasiertem Tracking um etwa 30 % zurück.

Eine Klasse von Änderungen blieb allerdings weiterhin problematisch: nicht-funktionale Änderungen. Der Offset zählte jede Zeile zwischen Scope-Grenze und Finding, also auch Kommentare und Leerzeilen. Kommt über einer verwundbaren Anweisung ein Kommentar hinzu, verschiebt sich der Offset. Das Tracking sieht eine neue Schwachstelle, im Ergebnis steht ein Duplikat.

Der normalisierte Offset

Unsere verbesserte Methode löst das, indem sie nicht-funktionalen Code, also Kommentare und Leerzeilen, bei der Berechnung des Fingerprints einfach überspringt. Da diese Zeilen das Verhalten des Programms nicht verändern, sollen sie auch die Identität einer Schwachstelle nicht verändern. Mit dieser Normalisierung ändert ein zusätzlicher Kommentar oder eine Neuformatierung den Fingerprint nicht mehr, während die Präzision des Trackings unverändert bleibt. Ausführlich beschrieben ist der Ansatz in unserem begleitenden Forschungsbeitrag.

Bewertet haben wir die normalisierte Methode auf einem gezielt zugeschnittenen Benchmark: 439 Quelldateien in C/C++, C#, Go, Java, JavaScript, Python und Ruby. Daraus haben wir 2.247 Commits erzeugt, von denen jeder genau einen Kommentar oder eine Leerzeile direkt vor einer bekannten Schwachstelle einfügt, und den Code beim Abspielen der Historie gescannt. Der Benchmark belastet bewusst den schlechtesten Fall: Jeder Commit ist eine nicht-funktionale Änderung unmittelbar neben einem Finding.

Auf diesem Benchmark sammelte die ursprüngliche Scope+Offset-Methode 1.361 doppelte Fingerprints an und stieg damit von 1.768 auf 3.129 eindeutige Fingerprints, ein Wachstum von 77 % gegenüber der Ausgangslage. Die normalisierte Methode blieb bei 1.768, erzeugte also kein einziges Duplikat, und senkte die Zahl der eindeutigen Fingerprints insgesamt um 43 %.

Der Benchmark ist bewusst zugunsten der normalisierten Methode gebaut, denn er provoziert genau die Schwäche, die sie beheben soll. Die 43 % markieren damit die Obergrenze des erreichbaren Effekts und nicht den Wert, der sich im Alltag einstellt.

Verfügbarkeit und Forschungshintergrund

Normalized Scope+Offset steckt in GitLab im Tracking-Algorithmus scope_offset_compressed und unterstützt C#, C/C++, Go, Java, JavaScript, Python, Ruby und PHP. Der Algorithmus nutzt den Parse-Tree weiter, den der Scanner ohnehin aufbaut, sodass die Scan-Dauer unberührt bleibt. Das Format des Security-Reports ist unverändert, wodurch sich die Methode mit beliebigen Kombinationen von SAST-Werkzeugen in heterogenen Setups verträgt.

Der Preprint unserer Studie "Vulnerability Tracking using Normalized Scope+Offset" von Julian Thome, Hua Yan, Lucas Charles, Craig Smith und Jason Leasure wird auf der 41. IEEE/ACM International Conference on Automated Software Engineering, dem ASE 2026 Industry Showcase, vorgestellt.

Hua Yan, Lucas Charles, Craig Smith und Jason Leasure haben zu diesem Beitrag und zur Studie beigetragen.