Quelques minutes suffisent à Semgrep pour scanner l’intégralité du code source d’une extension premium avant achat. Une revue humaine sérieuse du même code demande facilement plusieurs heures. Cette différence de coût, à elle seule, explique pourquoi tant d’agences se contentent aujourd’hui d’un scan automatisé avant d’installer une extension chez un client — sans toujours mesurer ce que cette rapidité leur fait perdre en couverture réelle.
Les deux approches ne visent d’ailleurs pas exactement le même objectif. Comprendre où chacune excelle, et où chacune échoue, permet de construire un processus d’audit qui ne repose pas sur un seul outil.
Ce que Semgrep détecte efficacement
Semgrep fonctionne par règles de correspondance syntaxique : il compare le code source à des motifs connus, indépendamment du contexte métier. Sur une extension WordPress, cela couvre remarquablement bien les motifs suivants :
- Une requête SQL construite par concaténation directe sans passer par
$wpdb->prepare() - Une sortie affichée sans fonction d’échappement appropriée (
esc_html(),esc_attr()) - Un appel à
unserialize()sur une donnée potentiellement issue d’une entrée utilisateur - L’absence de vérification de nonce sur un traitement de formulaire sensible
Ces motifs se répètent d’une extension à l’autre, ce qui rend Semgrep particulièrement rentable : une fois les règles écrites (ou reprises d’un ensemble communautaire existant), le scan s’exécute en quelques secondes sur des milliers de lignes de code.
Ce que Semgrep ne voit jamais
Un scan par motifs syntaxiques ignore complètement l’intention métier du code. Une faille de logique métier — un contrôle de prix contournable, une étape de validation d’identité qui peut être sautée en modifiant l’ordre des requêtes, un abonnement qui reste actif après un remboursement mal géré — ne correspond à aucun motif de code dangereux détectable par une règle générique. Le code peut être syntaxiquement irréprochable, échapper correctement ses sorties, préparer correctement ses requêtes, et contenir malgré tout une faille exploitable dans son enchaînement logique.
Ce qu’une revue humaine apporte que l’outil ne peut pas
Une personne qui lit le code d’une extension de paiement échelonné, par exemple, peut se poser une question qu’aucun outil syntaxique ne formule : que se passe-t-il si l’utilisateur interrompt le parcours après la troisième étape sur cinq ? Le montant déjà validé reste-t-il cohérent avec le montant final ? Cette capacité à suivre un raisonnement métier de bout en bout, à travers plusieurs fichiers et plusieurs hooks, reste hors de portée d’un scan automatisé, aussi sophistiqué soit-il.
Comparatif synthétique
| Critère | Semgrep | Revue humaine |
|---|---|---|
| Temps requis | Quelques minutes | Plusieurs heures |
| Détection de motifs connus | Excellente | Variable selon l’expérience |
| Détection de faille de logique métier | Quasi nulle | Bonne à excellente |
| Reproductibilité | Totale | Dépend de la personne |
| Coût par extension supplémentaire | Marginal | Constant |
Un ordre d’exécution qui optimise les deux
Faire passer Semgrep en premier permet d’éliminer rapidement les extensions dont le code présente des motifs élémentaires dangereux, sans mobiliser de temps humain sur un cas déjà disqualifiable. La revue humaine se concentre alors sur les extensions qui passent ce premier filtre, avec un temps consacré spécifiquement aux zones à plus fort enjeu métier : gestion des paiements, des identités, des rôles.
semgrep --config=p/wordpress ./extension-a-auditer/ --json > rapport-semgrep.json
Un scan automatisé qui ne remonte aucun résultat ne signifie jamais qu’une extension est sûre : cela signifie seulement qu’elle ne contient aucun des motifs déjà connus de l’outil.
Notre verdict
Opposer Semgrep et la revue humaine relève d’un faux dilemme : les deux couvrent des risques différents et complémentaires. Pour une extension gratuite à faible enjeu, un scan automatisé suffit généralement à écarter les cas les plus évidents. Pour une extension premium destinée à gérer des paiements ou des données sensibles chez un client, la revue humaine reste incontournable sur les zones critiques, avec Semgrep en filtre préalable pour ne pas y consacrer un temps disproportionné sur l’ensemble du code.
