Crier au loup en cybersécurité

L'histoire du garçon qui criait au loup remonte à une fable où un jeune berger se moquait des autres villageois en leur disant qu'un loup attaquait le troupeau. Les villageois le croyaient au début, mais il se contentait de rire avec eux. Lorsque le jeune berger répéta sa blague, les villageois commencèrent à l'ignorer et, à un certain moment, un vrai loup vint attaquer les moutons. Le garçon « cria au loup », mais personne ne le crut plus.

Les outils de cybersécurité ont agi comme des bergers : ils ont tendance à générer de nombreuses fausses alertes, ce qui fatigue les développeurs et les pousse à ne plus y prêter attention. Cela fait perdre du temps aux développeurs et leur fait perdre confiance dans les outils. Pour travailler de manière efficiente et efficace en cybersécurité, il faut un bon filtre pour éviter ces faux positifs. C'est exactement ce que fait AutoTriage pour les vulnérabilités SAST.

Exemple de vrai positif

Voici un exemple de détection SAST. SAST signifie Tests de sécurité des applications statiques, librement traduit par : détecter des schémas dangereux dans le code source, sans exécuter le code. C'est une méthode puissante pour signaler de nombreux types de vulnérabilités.

Dans cet exemple, nous voyons AutoTriage marquer un échantillon comme « priorité très élevée à corriger ». La détection SAST indique une vulnérabilité NoSQL potentielle. Le code représente un point d'accès de connexion où les utilisateurs peuvent fournir un nom et un mot de passe. Il y a un appel à la base de données pour rechercher un enregistrement correspondant au nom et au mot de passe.

The problem here is that NoSQL allows you to insert objects like { $ne: undefined }. In that case, the match will be based on anything that is different from undefined. Imagine that an attacker would upload something like this:

{
	name: LeoIVX,  
    password: { $ne: undefined }
}

Dans ce cas, l'attaquant pourrait se connecter en tant que pape (si le pape avait un compte avec ce nom d'utilisateur sur cette plateforme logicielle), car le mot de passe correspondrait toujours à la requête.

Dans ce cas, la détection SAST était un véritable positif. AutoTriage fait plus que simplement confirmer ici : il augmente également la priorité, car cette vulnérabilité est plus facile à exploiter et a une gravité plus élevée que la détection SAST moyenne.

Lorsqu'un problème de ce type est signalé, vous devez le corriger dès que possible. Il n'y a pas de méthode plus rapide que d'utiliser l'outil AutoFix d'Aikido. Cela créera une pull request (ou merge request) en un seul clic. Dans ce cas, le résultat est :

AutoFix suggérera toujours la correction la plus simple qui résout adéquatement la vulnérabilité. Dans ce cas, le transtypage du nom et du mot de passe suffit à sécuriser le point d'accès et à s'aligner sur l'intention du développeur.

Veuillez garder à l'esprit que les mots de passe ne doivent jamais être comparés directement et que les hachages de mots de passe doivent être utilisés à la place – cet exemple a été utilisé par souci de simplicité. Le LLM utilisé par AutoFix reçoit des instructions explicites de ne corriger aucun autre problème que la vulnérabilité signalée, de sorte que les pull requests respectent la bonne pratique de résoudre un problème à la fois.

Exemple de faux positif

Comme mentionné précédemment, le véritable problème des outils SAST est le nombre de fausses alertes qu'ils produisent. Un exemple de cela peut être trouvé ci-dessous. Il y a une injection SQL potentielle où un « productName » est injecté dans une requête SQL. De plus, ce « productName » provient du corps de la requête, il est donc contrôlé par l'utilisateur. Heureusement, il existe une liste blanche (allowlist) qui vérifie si productName est « iPhone15 », « Galaxy S24 », « MacBook Pro » ou « ThinkPad X1 ». Cela garantit que productName ne peut pas contenir de charge utile d'attaque comme productName = « iPhone15 »; DROP TABLE products; - - ».

Une liste blanche (allowlist) comme celle donnée dans cet exemple est une contre-mesure efficace contre l'injection SQL. Mais les scanners hérités comme Semgrep ne parviennent pas à évaluer l'efficacité de telles listes blanches (allowlists).

Les grands modèles linguistiques (LLM) offrent une opportunité majeure ici : ils peuvent comprendre beaucoup plus le contexte du code source et filtrer les échantillons de ce type.

Le récit « No Bullsh*t Security » d'Aikido

Lorsque les éditeurs de logiciels recherchent des fournisseurs AppSec, ils comparent souvent les différentes solutions disponibles sur le marché. Une méthode typique de comparaison des fournisseurs par les entreprises moins expérimentées consiste à compter le nombre de vulnérabilités trouvées dans leur code source. Il n'est pas surprenant qu'elles aient tendance à croire que plus de vulnérabilités équivaut à de meilleurs outils. Parfois, elles choisissent leur fournisseur sur la base de cette mauvaise évaluation. Par conséquent, certaines entreprises AppSec hésitent à filtrer les faux positifs, car elles obtiendraient de moins bons résultats lors de cette comparaison souvent observée.

Chez Aikido, nous adoptons une approche différente. Notre récit « No Bullsh*t » signifie que nous voulons aider les clients autant que possible, même si cela implique quelques pertes de contrats à court terme. AI AutoTriage en est un exemple clair, car cette fonctionnalité distingue l'offre d'Aikido de celles des autres acteurs du marché.

Disponibilité

Nous avons activé cette fonctionnalité pour 91 règles SAST dans différentes langues, y compris JavaScript/TypeScript, Python, Java, .NET et PHP. D'autres règles sont ajoutées à un rythme rapide.

Cette fonctionnalité est activée pour tous, y compris les comptes gratuits. Cela dit, les comptes gratuits peuvent atteindre très facilement le nombre maximum d'appels LLM.

CI Gating

Le CI gating est le processus par lequel Aikido scanne les vulnérabilités à chaque pull request. AI AutoTriage est désormais également activé pour cette fonctionnalité, ce qui rend le flux de travail beaucoup plus pratique.

Imaginez que vous ayez introduit une vulnérabilité de path traversal dans une pull request et appliqué un AutoFix. Cette correction utiliserait typiquement une denylist de motifs avant de lire ou d'écrire le fichier. Étant donné que les denylists sont difficiles à interpréter avec des motifs codés en dur, même la version corrigée serait toujours signalée comme un problème. Ceci est désormais résolu grâce à l'application de notre AutoTriage directement dans le pipeline CI.

Conclusion

Nous avons lancé une fonctionnalité puissante pour filtrer les faux positifs SAST et aider à la priorisation des échantillons de vrais positifs. Elle est disponible pour tous, même pour les comptes gratuits. Cette fonctionnalité représente un grand pas en avant pour réduire l'effet « Cry Wolf » (le loup, le loup) en cybersécurité, aidant les développeurs à se concentrer sur ce qui compte vraiment : résoudre les vulnérabilités réelles et consacrer plus de temps à la création de fonctionnalités pour leurs clients.