Fixed Detectors, Moving Code: How Well Do Static Security Analyzers Hold Up over a Decade of C/C++ Evolution?

Junhua Tang; Zhengsong Zhang. Haipeng Cai

Résumé IA · arXiv: 2611.03742v1 · cs.CR

Fixed Detectors, Moving Code: How Well Do Static Security Analyzers Hold Up over a Decade of C/C++ Evolution?

Junhua Tang, Zhengsong Zhang. Haipeng Cai

Article original Soumis à arXiv le 02 Nov. 2026 Licence : NONEXCLUSIVE-DISTRIB 1.0 Aussi en : en

Comment lire ce résumé ? Guide illustré

L’essentiel

Les performances temporelles des analyseurs SAST dépendent du détecteur et de la couverture; les scores agrégés peuvent refléter des alertes incidentes ou des analyses dégradées plutôt qu’une meilleure détection.

Question

Les analyseurs SAST conservent-ils leur efficacité lorsque le code C/C++ évolue, et quels facteurs expliquent les variations observées? L’étude cherche aussi à distinguer les changements temporels des effets de composition des projets, des défauts de couverture et des échecs d’exécution.

Méthode

Les auteurs évaluent 20 000 cas vulnérables ou corrigés, issus de 1 116 projets et datés de 2016 à 2025, avec sept conditions de détection: trois versions de CodeQL, trois d’Infer et une configuration Semgrep. Ils comparent les populations annuelles, des paires d’années appariées par projet et étiquette (45 paires, 100 répétitions), puis des trajectoires au sein de 202 projets; ils examinent aussi des cas de forte baisse à partir des correctifs et des résultats d’exécution.

Résultats

Résultat Les F1 globaux vont de 0,066 à 0,478, tandis que les AUROC fondés sur les nombres d’alertes restent proches du hasard, entre 0,495 et 0,526.
Voir le passage dans l’article
Under our changed-file case-label scoring, the overall F1 of these tools ranges from 0.066 to 0.478, yet every overall count-based AUROC lies between 0.495 and 0.526.
Résultat Pour CodeQL R2024, la différence moyenne de F1 entre année tardive et année précoce est négative pour chacun des neuf écarts temporels étudiés.
Voir le passage dans l’article
Across the full project-matched year-pair analysis, the mean later-minus-earlier F1 for CodeQL R2024 is negative at every source-year gap, whereas Infer v1.1 and v1.3 are positive at every gap.
Interprétation des auteurs Les hausses de F1 des versions récentes de CodeQL s’accompagnent de hausses parallèles du rappel et du taux de faux positifs, sans meilleure séparation des étiquettes.
Voir le passage dans l’article
For CodeQL, higher F1 in newer releases is accompanied by nearly parallel increases in recall and false-positive rate, rather than better vulnerable/fixed separation.
Résultat Dans les cas de baisse sélectionnés, seule une faible part des alertes d’Infer ou de CodeQL touche une ligne modifiée par le correctif; aucun positif Semgrep n’atteint le correctif étiqueté.
Voir le passage dans l’article
In the selected drops, only 6 of 39 CodeQL findings and 2 of 620 Infer findings touch a changed repair line, no Semgrep positive reaches the labelled repair, and 11 of 20 Semgrep vulnerable/fixed groups are scored on disjoint files.
Résultat Un statut d’exécution réussi peut masquer une analyse dégradée, comme le montrent les diagnostics de parsing ou de délai d’attente enregistrés par Semgrep.
Voir le passage dans l’article
78.96% of Semgrep cases carry parser or timeout diagnostics although every run reports success.

Limites

Les résultats des comparaisons entre versions ne permettent pas d’isoler l’effet propre de la version du moteur, car plusieurs composantes du détecteur changent ensemble.
Voir le passage dans l’article
Because engine, rules, extraction, and recovery change together, our comparisons across releases are descriptive. They do not isolate a pure engine-version effect, and we never read them as an estimate of what a version upgrade does.
Les études de trajectoires reposent sur des cohortes restreintes et des pentes descriptives, qui ne constituent pas des tests de significativité par projet.
Voir le passage dans l’article
These slopes are descriptive summaries rather than per-project significance tests; some project-year cells are small, which is why we report the nested $\geq$5-year cohort and the underlying support alongside slope directions.
Les cas extrêmes examinés qualitativement ne permettent pas d’estimer la fréquence des mécanismes observés dans l’ensemble du corpus.
Voir le passage dans l’article
The selected cases are extremes, so the table describes which mechanisms exist, not how often they occur.

Portée

Les auteurs soutiennent que la durabilité temporelle des outils SAST doit être évaluée pour une condition de détection fixe, en contrôlant la composition des projets et en reliant les alertes aux correctifs. Il faut aussi documenter la couverture, les analyses dégradées, les échecs et les coûts, car un score agrégé seul peut donner une image trompeuse de la détection.

Rédigé par une IA à partir de l’article. Les passages cités sont vérifiés mot pour mot dans le texte analysé ; le reste peut contenir des erreurs.

Mots clés générés par l'IA : analyse statique sécurité logicielle vulnérabilités évaluation temporelle faux positifs

Pour aller plus loin

Résumé Complet
Résumé vulgarisé
Article de blog
Abstract original

L’article étudie la durabilité des analyseurs statiques de sécurité dans le temps. Il cherche à déterminer si un détecteur continue de repérer les vulnérabilités à mesure que les programmes évoluent, tout en analysant le code dans des conditions de coût acceptables. Les auteurs soulignent qu’un score élevé ne signifie pas nécessairement qu’un outil détecte mieux les défauts : des alertes sans rapport avec les réparations peuvent être comptabilisées comme des détections, tandis que des problèmes de compilation, d’extraction ou d’analyse peuvent rendre les résultats incomplets sans que le statut du programme l’indique. L’étude porte sur 20 000 cas vulnérables ou corrigés, issus de 1 116 projets C/C++ et couvrant des années de code allant de 2016 à 2025. Elle compare sept configurations : trois versions de CodeQL (2021, 2024 et 2026), trois versions d’Infer (1.1, 1.2 et 1.3) et une configuration de Semgrep comprenant 170 règles. Les auteurs comptabilisent les alertes dans les fichiers modifiés, puis calculent notamment la précision, le rappel, le score F1, le taux de faux positifs et l’aire sous la courbe ROC (AUROC) à partir du nombre d’alertes. L’évaluation comprend également trois analyses : les populations annuelles, des paires d’années appariées selon le projet et les étiquettes « vulnérable » ou « corrigé », ainsi que les trajectoires observées au sein des mêmes projets. Enfin, les auteurs examinent les baisses de score en les confrontant aux correctifs, à l’emplacement des alertes, aux règles utilisées et aux journaux d’exécution. Les scores F1 globaux vont de 0,066 pour Infer 1.1 à 0,478 pour Semgrep. Pourtant, les AUROC calculées à partir du nombre d’alertes restent proches du hasard, entre 0,495 et 0,526. Pour CodeQL, le score F1 passe de 0,123 avec la version 2021 à 0,208 avec la version 2024, puis à 0,292 avec la version 2026. Toutefois, le rappel et le taux de faux positifs augmentent presque parallèlement. Les nouvelles versions signalent donc davantage de cas vulnérables, mais aussi davantage de cas corrigés, sans mieux distinguer les deux catégories. Infer 1.2 obtient les meilleurs résultats de sa famille, avec un score F1 de 0,177 et une AUROC de 0,526, devant les versions 1.1 et 1.3. Semgrep affiche le score F1 le plus élevé, mais son rappel (0,465) est inférieur à son taux de faux positifs (0,479), et son AUROC s’établit à 0,495. Une seule règle générique portant sur l’utilisation de `memset` génère 63 % des alertes admissibles et s’applique presque aussi souvent aux cas vulnérables qu’aux cas corrigés. Les analyses temporelles produisent des résultats contrastés. Dans les comparaisons appariées, CodeQL 2024 présente un changement moyen de F1 négatif pour chacun des neuf écarts temporels, atteignant −0,162 pour l’écart le plus important. Ce profil ne traduit toutefois pas une baisse régulière d’une année à l’autre.

Les analyseurs de sécurité suivent-ils l’évolution du code C/C++ ?

Un analyseur statique de sécurité peut-il continuer à repérer des vulnérabilités à mesure que les programmes changent ? C’est la question au cœur de l’étude « Fixed Detectors, Moving Code: How Well Do Static Security Analyzers Hold Up over a Decade of C/C++ Evolution? », écrite par Junhua Tang, Zhengsong Zhang et Haipeng Cai. Les auteurs évaluent non seulement les détections, mais aussi la capacité des outils à distinguer les versions vulnérables des versions corrigées, sans rendre les analyses trop coûteuses ou incomplètes.

Mesurer la qualité au-delà du nombre d’alertes

Les scores habituels peuvent donner une image trompeuse de l’efficacité d’un analyseur. Un outil peut produire davantage d’alertes et sembler repérer plus de vulnérabilités, alors qu’il signale également beaucoup de code déjà corrigé. De plus, des échecs de compilation, d’extraction ou d’analyse peuvent rendre les résultats incomplets, sans que le statut final du programme reflète clairement le problème.

Pour examiner ces limites, l’étude porte sur 20 000 cas vulnérables ou corrigés provenant de 1 116 projets C/C++. Les exemples couvrent des années de code allant de 2016 à 2025. Les auteurs comparent sept configurations : trois versions de CodeQL (2021, 2024 et 2026), trois versions d’Infer (1.1, 1.2 et 1.3), ainsi qu’une configuration de Semgrep dotée de 170 règles.

Les alertes sont comptabilisées dans les fichiers modifiés. À partir de ces comptes, les chercheurs calculent notamment la précision, le rappel, le score F1, le taux de faux positifs et l’aire sous la courbe ROC (AUROC). Ils complètent les mesures par des comparaisons entre populations annuelles, des paires d’années appariées selon le projet et l’étiquette « vulnérable » ou « corrigé », ainsi que l’observation de l’évolution au sein des mêmes projets.

Des F1 plus élevés, mais une distinction toujours faible

Les scores F1 globaux varient de 0,066 pour Infer 1.1 à 0,478 pour Semgrep. À première vue, cet écart pourrait suggérer des différences nettes de performance. Pourtant, les AUROC fondées sur le nombre d’alertes restent proches du hasard : elles se situent entre 0,495 et 0,526. Autrement dit, compter les alertes ne permet généralement pas de bien séparer les cas vulnérables des cas corrigés.

CodeQL illustre particulièrement bien la différence entre produire davantage de détections et mieux reconnaître une vulnérabilité. Son F1 progresse de 0,123 avec la version 2021 à 0,208 avec la version 2024, puis à 0,292 avec celle de 2026. Mais le rappel et le taux de faux positifs augmentent presque en parallèle. Les versions récentes signalent donc plus de cas vulnérables, tout en alertant aussi plus souvent sur des cas corrigés. Le gain de volume ne s’accompagne pas d’une meilleure séparation entre les deux catégories.

Infer 1.2 est la version la plus performante de sa famille, avec un F1 de 0,177 et une AUROC de 0,526, devant Infer 1.1 et 1.3. Même ce meilleur résultat demeure modeste, et il ne traduit qu’une faible capacité de discrimination selon les mesures étudiées.

Le cas de Semgrep : une règle très influente

Semgrep obtient le F1 global le plus élevé, mais ses autres indicateurs invitent à nuancer ce résultat. Son rappel est de 0,465, tandis que son taux de faux positifs atteint 0,479. Son AUROC, à 0,495, est légèrement inférieure au niveau du hasard. Ainsi, le score F1 le plus élevé ne signifie pas que l’outil distingue efficacement les versions vulnérables des versions corrigées.

Une règle générique portant sur l’utilisation de memset représente 63 % des alertes admissibles. Elle s’applique presque aussi souvent aux cas vulnérables qu’aux cas corrigés. Ce constat montre comment une règle très active peut gonfler le nombre d’alertes sans fournir une information utile sur la présence d’un défaut.

Des tendances temporelles à interpréter avec prudence

Les analyses du temps ne dessinent pas une trajectoire simple. Dans les comparaisons appariées, CodeQL 2024 affiche un changement moyen de F1 négatif pour chacun des neuf écarts temporels étudiés. La baisse atteint −0,162 pour l’écart le plus important. Toutefois, ce profil ne correspond pas à une diminution régulière d’une année à l’autre.

Les auteurs cherchent aussi à comprendre les baisses de score en examinant les correctifs, l’emplacement des alertes, les règles déclenchées et les journaux d’exécution. Cette démarche est importante : une variation de performance ne peut pas être interprétée correctement sans vérifier si elle provient d’un véritable changement de détection ou de problèmes intervenus pendant l’analyse.

Ce que l’étude nous apprend

Le message principal est simple : un nombre élevé d’alertes, ou même un F1 supérieur, ne suffit pas à démontrer qu’un analyseur repère mieux les vulnérabilités. Il faut aussi vérifier s’il différencie les versions vulnérables des versions corrigées, si ses alertes sont pertinentes et si l’analyse s’est déroulée sans échec caché.

Pour évaluer des outils destinés à évoluer avec des bases de code réelles, les équipes devraient donc regarder au-delà d’un score unique. La précision, le rappel, les faux positifs, la capacité de discrimination et les journaux d’exécution apportent des informations complémentaires. L’étude souligne ainsi un défi durable de la sécurité logicielle : maintenir des détecteurs utiles alors que le code, les correctifs et les projets continuent de changer.

Créé le 09 Nov. 2026

Cette synthèse vous a-t-elle été utile ?

Note : 0

Posez des questions sur cet article à notre assistant IA

Comment discuter avec cet article ? Guide illustré

Comparer avec le PDF

Vous pouvez aussi discutez avec plusieurs papiers à la fois ici.

Instructions pour utiliser l'assistant IA ?

Outils pour cet article

Expliquer autrement 1 réécriture gratuite restante aujourd'hui

Enregistrer dans une collection Regroupez des articles en collections pour les comparer, les interroger et les exporter. Continuer avec Google Créer un compte gratuit Se connecter

Exporter BibTeX · RIS (Zotero, Mendeley, EndNote) · Obsidian (Markdown) · Notion (Markdown)

Outils avancés Premium

Pour suivre un domaine de près : alertes de citations, diapositives de journal club, comparaison des versions et envoi vers Zotero. Découvrir Premium

Zotero

Alertes de citation Guide des alertes de citations

Qui travaille dessus ? Les personnes et institutions qui publient sur son sujet

Lettre hebdomadaire Présenté dans « Informatique hors IA cette semaine » du 9 novembre 2026. Informatique hors IA cette semaine : des preuves aux épreuves du réel

Journal club Premium+ Des slides pour le présenter Proposer pour le journal club

Versions Ce qui a changé entre les versions

En parler en public Premium+ Kit presse : communiqué, questions, détecteur de hype Guide du kit presse

Avertissement : Notre outil de synthèse basé sur l'IA et l'assistant virtuel fournis sur ce site Web peuvent ne pas toujours fournir des résumés complets ou des réponses exactes. Nous vous encourageons à examiner attentivement et à évaluer le contenu généré pour vous assurer de sa qualité et de sa pertinence par rapport à vos besoins.

Fixed Detectors, Moving Code: How Well Do Static Security Analyzers Hold Up over a Decade of C/C++ Evolution?

L’essentiel

Question

Méthode

Résultats

Limites

Portée

Pour aller plus loin

Definitions

Les analyseurs de sécurité suivent-ils l’évolution du code C/C++ ?

Mesurer la qualité au-delà du nombre d’alertes

Des F1 plus élevés, mais une distinction toujours faible

Le cas de Semgrep : une règle très influente

Des tendances temporelles à interpréter avec prudence

Ce que l’étude nous apprend

Posez des questions sur cet article à notre assistant IA

Outils pour cet article

Outils avancés Premium

Les articles autour de celui-ci

Les articles les plus proches

Les travaux antérieurs sur lesquels il s’appuie

Aller plus loin

Citer cet article (BibTeX)