Scanner de sécurité LLM pour WordPress : audit automatisé plugins & thèmes

État du terrain : WordPress, scanners existants et capacités LLM

WordPress est un cas d'usage prioritaire pour l'audit automatisé en raison d'une large adoption et d'une très grande diversité de plugins et thèmes, ce qui rend la maintenance et la qualité très hétérogènes. Sur le plan opérationnel, la littérature et les retours d'expérience des opérateurs de sécurité (références métiers comme Wordfence et Patchstack) signalent que de nombreuses compromissions impliquent des extensions ou thèmes non maintenus ou vulnérables, ce qui crée une volumétrie d'analyse difficile à couvrir uniquement avec des signatures. Les outils établis tels que WPScan, Wordfence ou Patchstack reposent majoritairement sur la corrélation de signatures, des règles heuristiques et des bases référentielles (WPVulnDB) : ils sont précis pour des vulnérabilités documentées et s'intègrent bien en CI, mais ils peinent à détecter des vulnérabilités logiques, des patterns émergents ou des mauvaises configurations non couvertes par des signatures.

Que peuvent (et ne peuvent pas encore) faire les LLM pour l'audit de code

Les LLM montrent des capacités utiles pour repérer des motifs de vulnérabilité dans du code PHP, JavaScript ou dans des fichiers de configuration, pour expliquer un problème en langage naturel et pour proposer des pistes de correction ou des patches exemples ; ils peuvent aussi aider à prioriser les findings quand le volume est élevé. En revanche, leurs limites techniques incluent des risques d'hallucinations, une variance significative selon la formulation des prompts et la sensibilité au contexte, ainsi que des garanties formelles faibles sur l'absence de régression des correctifs proposés. Dans la pratique, cela positionne les LLM comme un complément aux scanners signatures : utiles pour la détection logique et l'aide à la remédiation, mais insuffisants pour une mise en production automatique sans validation humaine définie.

Points clés à retenir

• Les LLM complètent les scanners signatures en détectant vulnérabilités logiques et en suggérant remédiations, mais nécessitent une validation humaine.
• Métriques d'acceptation recommandées : recall ≥ 70% sur dataset interne et précision ≥ 60% pour signaux actionnables, plus mesures de latence et coût par analyse.
• Arbitrage SaaS vs on‑prem : privilégier un mode hybride (pré‑filtrage local + envoi contrôlé) pour limiter l'exfiltration et respecter contraintes réglementaires.
• Pipeline CI/CD type : checkout → SBOM → scan signatures → analyse LLM → tri par score → création d'issue/PR ; gates manuels pour corrections sensibles.

Efficacité opérationnelle : périmètre auditable, précision et critères d'acceptation

Définir un périmètre d'audit réaliste est la première condition d'acceptation. Le périmètre opérationnel pertinent couvre le code PHP des plugins et thèmes, les fichiers de configuration sensibles (par exemple wp-config.php), l'analyse des hooks et actions, les assets JavaScript/CSS susceptibles d'introduire des attaques côté client, et les dépendances déclarées via composer/npm qui forment la SBOM du projet. Les plugins fermés ou propriétaires doivent être exclus ou traités selon les clauses contractuelles et la confidentialité. La priorisation pratique doit combiner popularité, niveau de maintenance (versions non mises à jour) et permissions requises sur des sites à fort risque.

Pour évaluer un scanner LLM en contexte, il faut des métriques claires : rappel (recall) sur un dataset benchmark de vulnérabilités connues, précision (precision) sur les signalements jugés exploitables, temps moyen jusqu'au diagnostic initial, et taux de faux positifs comparé aux scanners signatures. Des seuils opérationnels recommandés avant autoriser une automatisation partielle sont : recall ≥ 70% sur le dataset interne et precision ≥ 60% pour les signaux marqués « actionnable ». Au‑delà de ces valeurs, il faut aussi mesurer latence, coût par analyse et fraction d'alertes nécessitant revue humaine.

La qualité attendue des livrables conditionne l'intégration : sortie structurée en JSON accompagnée d'un résumé humain‑lisible indiquant description, gravité estimée, preuves (extraits de code), localisation précise, suggestion de correction et patch proposé. Chaque finding doit porter un score de risque et de confiance (score LLM enrichi par heuristiques) et, lorsqu'il existe, renvoyer vers une référence (CVE/WPVulnDB). L'intégration idéale alimente automatiquement le ticketing et propose des PRs pré-remplies contenant patchs et tests unitaires suggérés, tout en marquant clairement les items qui exigent une revue humaine avant fusion.

Risques, conformité et recette opérationnelle pour déploiement (SaaS vs on‑prem, CI/CD)

Plusieurs risques doivent être traités avant un déploiement en production : l'exfiltration de code et de secrets lorsque le code est envoyé à une API cloud, la responsabilité liée à des conseils erronés ou hallucinations menant à des correctifs dangereux, et des risques organisationnels liés à la dépendance fournisseur ou au drift des prompts et modèles. Ces risques imposent des contrôles contractuels et techniques avant tout envoi de code hors périmètre contrôlé.

Arbitrage SaaS vs On‑Premise et mode hybride

Le choix entre SaaS et on‑premise relève d'un arbitrage classique confidentialité/coût. Le SaaS fournit scalabilité et mises à jour du modèle sans investissement matériel, mais requiert des clauses contractuelles strictes (confidentialité du code, durée de conservation, droit de suppression, localisation des données). L'option on‑premise offre un contrôle complet des données et convient aux environnements régulés, mais implique coûts d'infrastructure GPU/TPU et compétences MLOps pour maintenir les modèles et pipelines. Un mode hybride est souvent recommandé : pré‑filtrage local (extraction de SBOM et métadonnées, anonymisation des snippets) puis envoi pondéré au service LLM, ou exécution locale pour les comptes sensibles.

Recette d'intégration en CI/CD et exploitation

Un pipeline type viable en environnement d'intégration continue commence par checkout → génération SBOM et résolution des dépendances → scan signatures (WPScan ou équivalent) → analyse statique LLM → tri automatique par score/confiance → création d'issue ou PR avec patch proposé. Les règles d'automatisation doivent inclure un seuil qui déclenche un gate manuel : par exemple, toute correction qui modifie la surface critique ou a un score de confiance inférieur au seuil doit rester en revue humaine. Pour tester la performance et la non‑régression, constituer un dataset interne de plugins vulnérables (versions historiques) et des fixtures unitaires permet d'exécuter audits continus et de mesurer recall/precision en conditions contrôlées.

Opérationnellement, instituer des SOPs de revue (qui valide, quels critères de rejet), des tests de non‑régression automatisés et une routine de red team pour injecter faux positifs/faux négatifs permet d'améliorer prompts et règles. Enfin, la contractualisation fournisseur doit couvrir la confidentialité du code, le droit d'audit, la durée de conservation des logs et des SLA de notification en cas d'incident.

Feuille de route opérationnelle et recommandations rapides

Le déploiement d'un scanner LLM pour WordPress est aujourd'hui une opportunité utile mais encadrée : les LLM complètent les scanners signatures en apportant détection logique et aides à la remédiation, mais leurs limites imposent une validation humaine et des garde‑fous contractuels et techniques. Décision rapide : évaluer la sensibilité des sites et privilégier on‑premise ou hybride pour les environnements à haut risque ; mettre en place un benchmark interne avec objectifs recall/precision avant tout rollout ; contractualiser la confidentialité et les SLA. Déployer d'abord en mode observability (alertes et suggestions), itérer 3–6 mois sur un pilote représentatif, mesurer les métriques, puis évoluer vers des actions semi‑automatiques lorsque les seuils et les SOP sont atteints. Cette approche graduelle permet de tirer parti des apports des LLM tout en maîtrisant les risques opérationnels et juridiques.