Comment GitLab suit les vulnérabilités dans les refactorisations et les reformatages

Chaque jour, les scans de sécurité se heurtent au même problème : un agent ou un développeur ajoute un commentaire, reformate un fichier ou déplace une fonction, et un outil de suivi des vulnérabilités peu sophistiqué signale soudainement le même résultat deux fois. Les équipes de sécurité se retrouvent à réexaminer des problèmes qu'elles avaient déjà écartés, ce qui génère des efforts d'audit inutiles et érode la confiance dans les résultats des scans.

En 2022, nous avons introduit le suivi avancé des vulnérabilités pour résoudre précisément ce problème de volatilité du code. Cette approche repose sur notre méthode d'empreinte Scope+Offset : au lieu d'identifier un résultat par son fichier et son numéro de ligne, nous l'identifions par sa portée englobante la plus étroite (module, classe, fonction) et son décalage de ligne au sein de cette portée. Cette méthode a renforcé le suivi face aux déplacements de code dans le fichier et a réduit les réexamens inutiles d'environ 30 % par rapport au suivi basé sur les lignes.

Mais une catégorie de modifications a tout de même échappé au contrôle : les modifications non fonctionnelles. Le décalage comptabilisait chaque ligne entre la limite de portée et le résultat, y compris les commentaires et les lignes vides. L'ajout d'un commentaire au-dessus d'une instruction vulnérable modifiait le décalage. L'outil de suivi détectait alors une « nouvelle » vulnérabilité, et vous vous retrouviez face à un doublon.

Notre méthode améliorée résout ce problème en ignorant simplement le code non fonctionnel (commentaires et lignes vides) lors du calcul de l'empreinte. Puisque ces lignes n'affectent pas le comportement du programme, elles ne devraient pas non plus affecter l'identité d'une vulnérabilité. Grâce à cette normalisation, l'ajout d'un commentaire ou le reformatage d'un fichier ne modifie plus l'empreinte, tandis que la précision du suivi reste identique. Les détails de cette approche sont décrits dans notre article de recherche associé.

Nous avons évalué la méthode normalisée sur un benchmark ciblé : 439 fichiers sources en C/C++, C#, Go, Java, JavaScript, Python et Ruby. Nous avons généré 2 247 commits, chacun insérant un seul commentaire ou une seule ligne vide directement avant une vulnérabilité connue, puis analysé le code au fil de l'historique rejoué. Ce benchmark met délibérément à l'épreuve le pire des cas : chaque commit est une modification non fonctionnelle placée juste à côté d'un résultat.

Sur ce benchmark, la méthode Scope+Offset d'origine a accumulé 1 361 doublons d'empreintes, soit une croissance de 77 % par rapport à la valeur de référence. La méthode normalisée n'a produit aucun doublon et a réduit le nombre d'empreintes uniques de 43 % au total.

Normalized Scope+Offset est disponible dans GitLab sous le nom d'algorithme de suivi scope_offset_compressed, avec prise en charge de C#, C/C++, Go, Java, JavaScript, Python, Ruby et PHP. Il réutilise l'arbre syntaxique que le scanner construit déjà, de sorte que la durée de scan n'est pas affectée. Le format du rapport de sécurité est inchangé, ce qui assure sa compatibilité avec toute combinaison d'outils SAST (test statique de sécurité des applications) dans une configuration hétérogène.

La prépublication de notre étude « Vulnerability Tracking using Normalized Scope+Offset » par Julian Thome, Hua Yan, Lucas Charles, Craig Smith et Jason Leasure sera présentée lors de l'ASE 2026 Industry Showcase.

Hua Yan, Lucas Charles, Craig Smith et Jason Leasure ont contribué à cet article et à cette étude.