TL; DR : Aussi étrange que cela puisse paraître, voir quelques faux positifs signalés par un scanner de sécurité est probablement un bon signe et certainement mieux que de n’en voir aucun. Expliquons pourquoi.

Introduction

Les faux positifs ont fait une apparition quelque peu inattendue dans nos vies ces dernières années. Je fais bien sûr référence à la pandémie de COVID-19, qui a nécessité des campagnes massives de tests afin de contrôler la propagation du virus. Pour mémoire, un faux positif est un résultat qui apparaît positif (pour le COVID-19 dans notre cas), alors qu’il est en réalité négatif (la personne n’est pas infectée). Plus communément, on parle de fausses alertes.

En sécurité informatique, nous sommes également souvent confrontés à des faux positifs. Demandez à l’équipe de sécurité derrière n’importe quel SIEM quel est son plus grand défi opérationnel, et il y a de fortes chances que des faux positifs soient mentionnés. Une récente rapport estime que jusqu’à 20 % de toutes les alertes reçues par les professionnels de la sécurité sont des faux positifs, ce qui en fait une grande source de fatigue.

Pourtant, l’histoire derrière les faux positifs n’est pas aussi simple qu’il y paraît au premier abord. Dans cet article, nous préconiserons que lors de l’évaluation d’un outil d’analyse, voir un taux modéré de faux positifs est plutôt un bon signe d’efficacité.

De quoi parle-t-on exactement ?

Avec analyse statique en sécurité applicative, notre préoccupation première est de capter tous les vrai vulnérabilités en analysant le code source.

Voici une visualisation pour mieux saisir la distinction entre deux concepts fondamentaux de l’analyse statique : la précision et le rappel. La loupe représente l’échantillon qui a été identifié ou sélectionné par l’outil de détection. Vous pouvez en savoir plus sur la façon d’évaluer la performance d’un processus statistique ici.

Voyons ce que cela signifie d’un point de vue technique :

• en réduisant les faux positifs, nous améliorons la précision (toutes les vulnérabilités détectées représentent en fait un problème de sécurité).
• en réduisant les faux négatifs, on améliore le rappel (toutes les vulnérabilités présentes sont correctement identifiées).
• à 100 % de rappel, l’outil de détection ne manquera jamais une vulnérabilité.
• à 100 % de précision, l’outil de détection ne déclencherait jamais de fausse alerte.

Autrement dit, l’objectif d’un scanner de vulnérabilité est d’ajuster le cercle (dans la loupe) aussi près que possible du rectangle de gauche (éléments pertinents).

Le problème est que la réponse est rarement claire, ce qui signifie que des compromis doivent être faits.

Alors, qu’est-ce qui est le plus souhaitable : maximiser la précision ou le rappel ?

Lequel est le pire, trop de faux positifs ou trop de faux négatifs ?

Pour comprendre pourquoi, prenons les deux extrêmes : imaginons qu’un outil de détection n’alerte ses utilisateurs que lorsque la probabilité qu’un morceau de code donné contienne une vulnérabilité est supérieure à 99,999 %. Avec un seuil aussi élevé, vous pouvez être presque certain qu’une alerte est bien un vrai positif. Mais combien de problèmes de sécurité passeront inaperçus à cause de la sélectivité du scanner ? Beaucoup.

Maintenant, au contraire, que se passerait-il si l’outil était réglé pour ne jamais manquer une vulnérabilité (maximiser le rappel) ? Vous l’aviez deviné : vous seriez bientôt confronté à des centaines voire des milliers de fausses alertes. Et là réside un plus grand danger.

Comme Ésope nous l’avait prévenu dans sa fable Le garçon qui criait au loup, quiconque ne fait que répéter de fausses affirmations finira par ne pas être écouté. Dans notre monde moderne, l’incrédulité se matérialiserait par un simple clic pour désactiver les notifications de sécurité et rétablir la tranquillité, ou simplement les ignorer si la désactivation n’est pas autorisée. Mais les conséquences pourraient être au moins aussi dramatiques que dans la fable.

Il est juste de dire que la fatigue d’alerte est probablement la principale raison pour laquelle l’analyse statique échoue si souvent. Non seulement les fausses alarmes sont à l’origine de l’échec de programmes de sécurité applicatifs entiers, mais elles causent également des dommages beaucoup plus graves, tels que l’épuisement et la participation.

Et pourtant, malgré tous les maux qui leur sont imputés, vous auriez tort de penser que si un outil ne porte pas de faux positifs, alors il doit apporter la réponse définitive à ce problème.

Comment apprendre à accepter les faux positifs

Pour accepter les faux positifs, nous devons aller à l’encontre de cet instinct de base qui nous pousse souvent vers des conclusions précoces. Une autre expérience de pensée peut nous aider à illustrer cela.

Imaginez que vous soyez chargé de comparer les performances de deux scanners de sécurité A et B.

Après avoir exécuté les deux outils sur votre benchmark, les résultats sont les suivants : Le scanner A n’a détecté que des vulnérabilités valides, tandis que le scanner B a signalé à la fois des vulnérabilités valides et non valides. À ce stade, qui ne serait pas tenté de tirer une première conclusion ? Il faudrait être un observateur assez avisé pour demander plus de données avant de se décider. Les données révéleraient très probablement que certains secrets valides rapportés par B avaient été silencieusement ignorés par A.

Vous pouvez maintenant voir l’idée de base derrière cet article : tout outil, processus ou entreprise prétendant être complètement libre de faux positifs devrait sembler suspect. Si tel était vraiment le cas, il y aurait de fortes chances que certains éléments pertinents soient ignorés en silence.

Trouver l’équilibre entre précision et rappel est une question subtile et nécessite beaucoup d’efforts de réglage (vous pouvez lire comment les ingénieurs de GitGuardian améliorent le précision du modèle). Non seulement cela, mais il est également tout à fait normal de le voir échouer de temps en temps. C’est pourquoi vous devriez vous inquiéter davantage de l’absence de faux positifs que d’en voir quelques-uns.

Mais il y a aussi une autre raison pour laquelle les faux positifs pourraient aussi être un signal intéressant : la sécurité n’est jamais « tout blanc ou tout noir ». Il y a toujours une marge où « nous ne savons pas », et

où l’examen et le triage humains deviennent essentiels.

« En raison de la nature du logiciel que nous écrivons, nous obtenons parfois des faux positifs. Lorsque cela se produit, nos développeurs peuvent remplir un formulaire et dire : « Hé, c’est un faux positif. Cela fait partie d’un cas de test. Vous pouvez ignorer cela. » — La source.

Il y a une vérité plus profonde : la sécurité n’est jamais « tout blanc ou tout noir ». Il y a toujours une marge où « nous ne savons pas », et où l’examen et le triage humains deviennent essentiels. En d’autres termes, il ne s’agit pas seulement de chiffres bruts, mais aussi de comment ils seront utilisés. Les faux positifs sont utiles de ce point de vue : ils permettent d’améliorer les outils et d’affiner les algorithmes afin que le contexte soit mieux compris et pris en compte. Mais comme une asymptote, le 0 absolu ne peut jamais être atteint.

Il y a cependant une condition nécessaire pour transformer ce qui semble être une malédiction en un cercle vertueux. Vous devez vous assurer que les faux positifs peuvent être signalés et intégrés dans l’algorithme de détection aussi facilement que possible pour les utilisateurs finaux. L’un des moyens les plus courants d’y parvenir consiste simplement à offrir la possibilité d’exclure des fichiers, des répertoires ou des référentiels du périmètre analysé.

Chez GitGuardian, nous sommes spécialisés dans détection secrète. Nous avons poussé l’idée d’améliorer toute découverte avec autant de contexte que possible, conduisant à des cycles de rétroaction beaucoup plus rapides et allégeant autant de travail que possible.

Si un développeur essaie de commettre un secret avec le côté client ggshield installé en tant que hook de pré-commit, le commit sera arrêté à moins que le développeur le signale comme un secret à ignorer. A partir de là, le secret est considéré comme un faux positif, et ne déclenchera plus d’alerte, mais uniquement sur son poste de travail local. Seul un membre de l’équipe de sécurité ayant accès au tableau de bord GitGuardian est en mesure de signaler un faux positif pour toute l’équipe (ignorance globale).

Si un secret divulgué est signalé, nous fournissons des outils pour aider l’équipe de sécurité à les expédier rapidement. Par exemple, le livre de jeu d’auto-guérison envoie automatiquement un e-mail au développeur qui a commis le secret. Selon la configuration du playbook, les développeurs peuvent être autorisés à résoudre ou à ignorer l’incident eux-mêmes, ce qui allège la charge de travail laissée à l’équipe de sécurité.

Ce ne sont là que quelques exemples de la façon dont nous avons appris à adapter les processus de détection et de remédiation aux faux positifs, plutôt que de nous focaliser sur leur élimination. En statistiques, cette obsession a même un nom : cela s’appelle le surajustement, et cela signifie que votre modèle est trop dépendant d’un ensemble de données particulier. Faute d’intrants réels, le modèle ne serait pas utile dans un environnement de production.

Conclusion

Les faux positifs provoquent une fatigue d’alerte et font dérailler les programmes de sécurité si souvent qu’ils sont désormais largement considérés comme un pur mal. Il est vrai que lorsque vous envisagez un outil de détection, vous voulez la meilleure précision possible, et avoir trop de faux positifs cause plus de problèmes que de ne pas utiliser d’outil en premier lieu. Cela étant dit, ne négligez jamais le taux de rappel.

Chez GitGuardian, nous avons conçu un large arsenal de générique filtres de détection pour améliorer le taux de rappel de notre moteur de détection de secrets.

D’un point de vue purement statistique, avoir un faible taux de faux positifs est plutôt bon signe, c’est-à-dire que peu de défauts traversent le filet.

Lorsqu’il est sous contrôleles faux positifs ne sont pas ce mal. Ils peuvent même être utilisés à votre avantage puisqu’ils indiquent où des améliorations peuvent être apportées, tant du côté de l’analyse que du côté de la remédiation.

Comprendre pourquoi quelque chose a été considéré comme « valide » par le système et avoir un moyen de s’y adapter est essentiel pour améliorer la sécurité de votre application. Nous sommes également convaincus que c’est l’un des domaines où la collaboration entre les équipes de sécurité et de développement brille vraiment.

Enfin, rappelez-vous : si un outil de détection ne signale pas n’importe quel faux positifs, courez. Vous allez avoir de gros ennuis.