Custom Rules SAST

Définition

Les Custom Rules SAST (règles SAST personnalisées) sont des règles de détection de vulnérabilités écrites spécifiquement pour les patterns de code, les frameworks, ou les politiques de sécurité propres à une organisation, en complément des règles prédéfinies des outils SAST. Là où les règles standard couvrent les vulnérabilités universelles (injection SQL, XSS), les règles personnalisées permettent de détecter les patterns dangereux spécifiques au contexte de l'organisation : utilisation d'APIs internes dépréciées, violation des politiques de sécurité locales, ou patterns propres à une technologie maison. Les scénarios typiques justifiant des règles SAST personnalisées incluent : la détection de l'utilisation d'APIs internes dépréciées ou marquées "unsafe" (une fonction legacy qui effectue une requête SQL sans paramètres préparés, qu'une règle custom peut détecter à chaque appel), la vérification de l'utilisation correcte de bibliothèques de sécurité internes (s'assurer que tous les appels à la base de données passent par l'ORM de l'organisation et non des requêtes SQL directes), la détection de patterns de secrets spécifiques à l'organisation (format des clés API internes), et l'enforcement de conventions de sécurité locales (toujours utiliser le logger de sécurité interne plutôt que System.out.println). Les outils SAST modernes facilitent la création de règles personnalisées. Semgrep est particulièrement adapté : sa syntaxe YAML/patterns basée sur la structure du code source (pas du texte brut) permet de créer des règles précises sans connaissance approfondie de la théorie des compilateurs. Une règle Semgrep peut détecter, par exemple, tous les appels à db.query() avec un argument de type string construit par concaténation, signalant une injection SQL potentielle, avec une précision plus élevée qu'une règle regex naïve. La gouvernance des règles personnalisées SAST inclut : le versionnage des règles dans un dépôt dédié (règles traitées comme du code avec PR reviews), des tests unitaires pour chaque règle (cas de test "doit détecter" et "ne doit pas détecter"), et un processus de contribution permettant aux Security Champions des équipes de proposer des règles spécifiques à leur domaine.