Skip to main content
Corgea utilise l’IA pour analyser les vulnérabilités potentielles et déterminer si elles sont susceptibles d’être des faux positifs. L’analyse des faux positifs tient compte de plusieurs facteurs : le contexte du code, la nature de la vulnérabilité ainsi que les conventions de code et bonnes pratiques pertinentes. Le modèle indique ensuite si la vulnérabilité est probablement « avérée » ou s’il s’agit d’un « faux positif », et justifie son évaluation. Lorsque le modèle détermine qu’une vulnérabilité est un faux positif, le raisonnement fournit une explication à cette évaluation. En associant cette analyse à l’explication de la vulnérabilité et au correctif proposé, Corgea aide les développeurs à identifier et à prioriser rapidement les vulnérabilités avérées, sans perdre de temps sur les faux positifs.

​
Exemples courants de faux positifs détectés par Corgea

Voici quelques exemples de faux positifs que Corgea peut détecter :
  • Cross-site scripting : vérifie que les entrées utilisateur sont correctement assainies ou encodées avant d’être renvoyées dans la page web, au moyen de bibliothèques ou frameworks reconnus.
  • Injection SQL : vérifie que les requêtes de base de données utilisent correctement des requêtes paramétrées ou préparées, sans inclure d’entrées utilisateur ou externes susceptibles d’être manipulées.
  • Divulgation d’informations : vérifie si les informations sensibles divulguées sont génériques ou si la divulgation se produit dans un environnement de développement.
  • Exception non détectée : Vérifie si la condition ou le statut inattendu est géré par des moyens alternatifs comme la journalisation ou la surveillance des parties non critiques de l’application.
  • Mot de passe codé en dur : Vérifie si le mot de passe codé en dur est destiné à un environnement non de production ou utilisé pour des tests automatisés.
  • Mot de passe dans le fichier de configuration : Vérifie si le stockage du mot de passe en clair est protégé par des mesures de sécurité alternatives telles que le stockage chiffré ou les contrôles d’accès.
  • Clé cryptographique codée en dur : Vérifie si la clé cryptographique codée en dur est utilisée uniquement à des fins de test.
  • Falsification de requête intersite : vérifie que des tokens anti-CSRF sont mis en œuvre et validés côté serveur, ou que le code appartient à une API pour laquelle la protection CSRF ne s’applique pas.
  • Prise en charge manquante de la vérification d’intégrité : Vérifie si la vérification d’intégrité est mise en œuvre par des moyens alternatifs comme les signatures numériques ou les validations de hachages.
  • Identifiants codés en dur : Vérifie si les identifiants codés en dur sont utilisés uniquement à des fins de test.
  • Injection de code : Vérifie si le point d’injection de code est limité à un environnement contrôlé ou si la validation des entrées et l’encodage de sortie sont appliqués.
Et bien d’autres…