# GitHub AI Scan now detects PHP vulnerabilities in pull requests: should you add it to your CI/CD? > GitHub AI Scan now supports PHP: how it works, its limitations and cost, Symfony and WordPress examples, and how to integrate it into a secure CI/CD pipeline. AI & cybersecurity ## GitHub AI Scan now detects PHP vulnerabilities in pull requests: should you add it to your CI/CD? Since October 15, 2026, GitHub AI Scan has been reviewing PHP pull requests. Find out what it detects, its limitations and cost, and how to integrate it into a Symfony or WordPress CI/CD pipeline. ![AI-Assisted-Secure-Code-Review.webp](https://sdx-development.com/media/News/AI-Assisted-Secure-Code-Review.webp?v=1792429012) [AI & cybersecurity](https://sdx-development.com/en/news/ai-cybersecurity)Published on 19 October 2026 Depuis le **15 octobre 2026**, GitHub AI Scan for pull requests est disponible en version générale. Sa promesse est particulièrement intéressante pour les équipes PHP : signaler des vulnérabilités lors d’une pull request, y compris dans des langages et fichiers non pris en charge par CodeQL. Pour un projet **Symfony, WordPress personnalisé ou PHP natif**, c’est une couverture supplémentaire bienvenue. Mais une alerte générée par l’IA ne bloque pas une fusion et ne remplace ni les tests, ni l’analyse statique, ni une revue de code sérieuse. Voici ce qu’il faut réellement en attendre et où le placer dans une chaîne CI/CD. À retenir ## Un filet de sécurité supplémentaire, pas un feu rouge automatique AI Scan examine les changements des pull requests, notamment en PHP et dans les Dockerfiles. Il explique les risques et peut proposer un correctif. Mais ses alertes sont consultatives : conservez des contrôles CI obligatoires et une validation humaine pour autoriser la fusion. **Dans cet article** [La nouveauté](https://sdx-development.com/en/news/ai-cybersecurity/github-ai-scan-php-security-pull-requests-cicd#annonce)[PHP et CodeQL](https://sdx-development.com/en/news/ai-cybersecurity/github-ai-scan-php-security-pull-requests-cicd#php)[3 exemples](https://sdx-development.com/en/news/ai-cybersecurity/github-ai-scan-php-security-pull-requests-cicd#exemples)[Activation et prix](https://sdx-development.com/en/news/ai-cybersecurity/github-ai-scan-php-security-pull-requests-cicd#activation)[CI/CD](https://sdx-development.com/en/news/ai-cybersecurity/github-ai-scan-php-security-pull-requests-cicd#cicd)[Protocole de test](https://sdx-development.com/en/news/ai-cybersecurity/github-ai-scan-php-security-pull-requests-cicd#test)[Limites](https://sdx-development.com/en/news/ai-cybersecurity/github-ai-scan-php-security-pull-requests-cicd#limites)[Verdict](https://sdx-development.com/en/news/ai-cybersecurity/github-ai-scan-php-security-pull-requests-cicd#verdict) ## Ce que GitHub a annoncé le 15 octobre 2026 GitHub a annoncé la **disponibilité générale d’AI Scan for pull requests** le 15 octobre 2026. Cet outil de sécurité s’ajoute au *code scanning* de GitHub et complète CodeQL sur les langages et frameworks qu’il ne couvre pas aujourd’hui. Les exemples explicitement cités par GitHub incluent PHP, Shell/Bash, les configurations Terraform HCL, les Dockerfiles, JSP pour Java et Blazor pour C#. Une fois le code scanning activé et le paramètre AI Scan autorisé, l’analyse démarre automatiquement sur les pull requests éligibles, à leur création puis après les nouveaux commits. Les résultats s’affichent dans *Conversation* et *Files changed*, à côté des alertes CodeQL, avec une indication « AI » pour identifier leur origine. Chaque signalement explique le problème et le risque ; certains s’accompagnent d’une suggestion de correction via Copilot Autofix. **Aucun abonnement GitHub Copilot n’est requis** pour utiliser AI Scan. Il ne faut toutefois pas confondre « intégré à GitHub » et « équivalent à une vérification bloquante » : par conception, les résultats d’AI Scan sont **informatifs**. Ils ne mettent pas en échec le contrôle de code scanning et ne peuvent pas, à eux seuls, empêcher la fusion au moyen d’un ruleset. ## Pourquoi cette annonce compte pour PHP, Symfony et WordPress La distinction entre AI Scan et CodeQL est déterminante pour les équipes PHP. **CodeQL ne prend pas en charge le langage PHP** dans sa liste officielle de langages analysés. Il peut analyser d’autres parties d’un dépôt hybride — par exemple du JavaScript ou du TypeScript — mais pas transformer les fichiers PHP en une analyse CodeQL native. AI Scan ouvre donc une autre voie de détection directement dans la revue des changements. | Outil | Rôle principal | Pour un dépôt PHP | | --- | --- | --- | | AI Scan | Détection IA sur les changements des pull requests éligibles | Couvre des scénarios PHP ; résultats consultatifs | | CodeQL | Analyse statique dédiée aux langages officiellement pris en charge | Pas d’analyse native PHP ; utile sur d’autres langages présents | | PHPStan / Psalm | Analyse statique, types et cohérence du code PHP | Complément technique précieux, selon sa configuration | | PHPUnit, tests d’intégration | Vérification du comportement et des régressions | Contrôles automatisables et potentiellement bloquants | | Revue humaine | Compréhension du métier, des autorisations et de l’architecture | Indispensable pour qualifier le risque réel | AI Scan ne prétend pas certifier un projet Symfony ou WordPress entier. Il étudie des **modifications proposées**, avec du contexte éventuel provenant du dépôt. Les problèmes historiques situés hors de ces changements ne deviennent pas automatiquement un inventaire d’alertes : GitHub précise que l’analyse complète du dépôt n’est pas prise en charge par AI Scan. ## Trois exemples concrets de risques à rechercher dans une pull request PHP Les extraits suivants sont des **cas pédagogiques** destinés à construire un essai reproductible. Ils illustrent des erreurs classiques, mais **ne constituent pas des détections effectivement observées** avec AI Scan. Il faut tester les résultats avant de conclure à la couverture d’une règle ou à la pertinence d’une correction. ### 1. Injection SQL : concaténer une entrée utilisateur dans une requête Premier scénario : une méthode de recherche récupère un identifiant envoyé dans la requête HTTP puis le concatène dans du SQL. En présence d’une entrée non maîtrisée, la requête peut être modifiée. Voici un anti-exemple minimal : ``` $id = $_GET['id'] ?? ''; $sql = "SELECT * FROM customers WHERE id = " . $id; $rows = $pdo->query($sql)->fetchAll(); ``` La correction attendue passe par une **requête préparée et des paramètres liés**, et non par un simple nettoyage de chaîne : ``` $id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT); if ($id === false || $id === null) { throw new InvalidArgumentException('Identifiant invalide'); } $stmt = $pdo->prepare('SELECT * FROM customers WHERE id = :id'); $stmt->bindValue(':id', $id, PDO::PARAM_INT); $stmt->execute(); $rows = $stmt->fetchAll(); ``` Dans Symfony, la même exigence s’applique aux requêtes DQL ou SQL personnalisées : utiliser des paramètres plutôt que construire une expression à partir de valeurs issues de la requête. Avec WordPress, préférer les API prévues et, lorsqu’une requête SQL personnalisée est nécessaire, utiliser ` $wpdb->prepare() ` correctement. ### 2. WordPress et Symfony : authentification ne signifie pas autorisation Deuxième scénario : une pull request ajoute une route d’administration WordPress ou un endpoint Symfony qui reçoit un identifiant de ressource. Un utilisateur authentifié peut-il modifier une ressource qui ne lui appartient pas ? C’est typiquement une question de **contrôle d’accès cassé**, parfois invisible au premier coup d’œil. Pour un plugin WordPress, un *nonce* réduit certains risques de requêtes intersites mais **ne remplace pas une vérification de permission** : il faut aussi contrôler les capacités de l’utilisateur avec ` current_user_can() `, puis vérifier les droits sur la ressource concernée. Dans Symfony, les attributs de sécurité, les voters et les contrôles d’accès au niveau de l’objet doivent correspondre à la politique métier réelle. Un scanner peut attirer l’attention sur un garde-fou absent, mais seule une revue tenant compte du rôle, du propriétaire de la ressource et des parcours utilisateur peut décider si l’accès est légitime. ### 3. Dockerfile : une configuration qui augmente le risque d’exécution Troisième scénario : la pull request modifie le Dockerfile d’une application PHP. Une image trop permissive, l’usage permanent du compte root, le téléchargement de binaires sans contrôle d’intégrité ou l’inclusion de secrets dans l’image sont autant de signaux à examiner. ``` FROM php:8.3-fpm WORKDIR /var/www/html COPY . . # Aucun USER non privilégié défini ici : vérifier le modèle # d'exécution réel, les permissions et la configuration du déploiement. ``` La présence ou l’absence d’une instruction ` USER ` ne suffit pas à prouver la sécurité d’une image : il faut aussi contrôler les permissions sur les volumes, l’utilisateur effectif du processus, la gestion des secrets, les mises à jour et la configuration de l’orchestrateur. C’est un bon exemple où **un indice produit par l’IA doit déboucher sur une vérification opérationnelle**. ## Comment activer GitHub AI Scan et quel est son prix ? GitHub distingue les dépôts selon leur propriétaire et leur visibilité. L’activation nécessite le **code scanning** et le réglage effectif « AI Scan on pull requests ». En organisation, ce réglage dépend des politiques d’entreprise et d’organisation ; un administrateur de dépôt ne peut pas toujours l’activer seul si la politique supérieure l’interdit. | Dépôt | Accès annoncé | Point d’attention | | --- | --- | --- | | Public, organisation | Accessible sans licence de committer actif | Crédits IA et budget à surveiller | | Public, compte personnel | Accessible | Crédits IA facturés au compte applicable | | Privé ou interne, organisation | GitHub Code Security ou Advanced Security requis | Licence applicable + crédits IA consommés | | Privé, compte personnel | Non disponible selon la documentation | Ne pas compter sur cette fonctionnalité | **Attention à la formule « gratuit pour les dépôts publics » :** elle signifie ici qu’aucune licence de committer actif n’est nécessaire pour cet accès, **pas que chaque analyse IA est nécessairement sans coût**. Les analyses éligibles consomment des *Code Security AI Credits*. GitHub documente les crédits inclus éventuels, la consommation mesurée et les budgets plafonnés ; lorsque le budget strict ne permet plus d’utiliser des crédits, les résultats ne peuvent plus être produits. Aucun tarif universel par pull request ne peut donc être donné sans consulter les conditions de facturation applicables au compte. 1. Dans l’organisation, vérifier les politiques de sécurité, les droits et le type de licence des dépôts privés. 2. Activer le code scanning du dépôt, puis le paramètre **AI Scan on pull requests** au niveau permis par l’entreprise ou l’organisation. 3. Vérifier le compte de facturation, les crédits disponibles et définir un budget de consommation avant un déploiement large. 4. Ouvrir une pull request éligible contenant des modifications PHP ou Dockerfile et examiner les signalements dans *Conversation* et *Files changed*. L’activation d’AI Scan ne nécessite **ni configuration par défaut de CodeQL, ni build préalable de l’application**. Une analyse CodeQL en attente ou en échec n’empêche pas AI Scan de fonctionner lorsque toutes ses conditions propres sont réunies. ## Où intégrer AI Scan dans une chaîne CI/CD PHP ? La place la plus pertinente est **au moment de la revue de pull request**, après les vérifications automatisées et avant l’approbation humaine. AI Scan améliore la qualité de la discussion sur le risque ; il ne doit pas être présenté comme une étape capable de rendre la fusion impossible. Architecture recommandée ## Deux niveaux de contrôle complémentaires **Contrôles obligatoires :** lint, analyse statique PHP, tests, contrôle des dépendances et revues requises. **Signal complémentaire :** alertes AI Scan examinées dans la pull request. L’autorisation finale reste fondée sur des checks configurés comme obligatoires et sur la validation des personnes responsables. Pour un dépôt Symfony ou un WordPress personnalisé, un premier workflow GitHub Actions peut exécuter les tests qui existent réellement dans le projet. Voici une **base adaptable** : elle suppose un ` composer.lock ` présent et une suite PHPUnit configurée ; elle n’active pas AI Scan, puisque celui-ci se règle dans les paramètres GitHub. ``` name: Qualite PHP on: pull_request: jobs: tests: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: shivammathur/setup-php@v2 with: php-version: '8.3' coverage: none - run: composer validate --strict - run: composer install --no-interaction --prefer-dist --no-progress - run: composer audit --locked - run: vendor/bin/phpunit ``` Adaptez la version PHP, les extensions, la commande des tests et les outils installés au dépôt. Ajoutez PHPStan ou Psalm, les tests d’intégration et des règles de sécurité propres au projet. Pour un WordPress personnalisé, pensez aussi aux contrôles des plugins, aux rôles et capacités, aux endpoints AJAX/REST et aux pratiques spécifiques à l’écosystème. Dans les règles de protection des branches, rendez **obligatoires les jobs de CI qui doivent réellement passer** et prévoyez une revue de code pour les modifications sensibles. Un accord d’équipe peut imposer la lecture des alertes AI Scan, mais il s’agit d’un **processus humain**, pas d’un statut bloquant natif d’AI Scan. ## Comment comparer AI Scan, CodeQL et une revue humaine sans inventer de benchmark Un test utile demande un dépôt de démonstration contrôlé, jamais une vulnérabilité injectée dans une application de production. Préparez trois branches de test, chacune avec une seule modification volontairement risquée et un correctif attendu : **SQL construit par concaténation**, **contrôle d’accès insuffisant** et **Dockerfile à examiner**. Ouvrez des pull requests internes au dépôt, non issues de forks. 1. **Noter l’éligibilité :** type de dépôt, code scanning activé, politique AI Scan, budget disponible et fichier réellement modifié. 2. **Observer AI Scan :** une alerte apparaît-elle ? Est-elle pertinente ? Le fichier, la ligne et l’explication sont-ils utiles ? Une correction est-elle proposée ? 3. **Comparer CodeQL :** confirmer que le code PHP n’est pas pris en charge par CodeQL et, pour un dépôt mixte, vérifier séparément les éventuels résultats sur JavaScript/TypeScript ou autres langages compatibles. 4. **Comparer les contrôles habituels :** analyser les sorties PHPStan/Psalm, les tests, l’audit des dépendances et le retour d’un reviewer PHP. 5. **Valider chaque correction :** écrire un test de non-régression, vérifier les autorisations et évaluer les éventuels effets de bord. Documentez les résultats dans une matrice simple : « scénario », « AI Scan a signalé », « autre outil a signalé », « confirmé par revue » et « correction vérifiée ». Une absence d’alerte sur un cas ne démontre pas que la catégorie n’est jamais détectée ; une alerte sur trois cas ne prouve pas non plus une couverture fiable en production. Le but est de **mesurer l’utilité réelle dans votre contexte**, sans annoncer un taux de détection fondé sur un échantillon insuffisant. ## Les limites à connaître avant de généraliser AI Scan 01 ### Pas de blocage natif Une alerte AI Scan ne fait pas échouer le check de code scanning et ne peut pas être une condition bloquante de merge via les rulesets. 02 ### Pas toutes les pull requests Les contributions venant de forks et les pull requests créées par Dependabot sont exclues de l’analyse AI Scan. 03 ### Pas d’audit intégral Les signalements concernent les pull requests, pas un examen complet et récurrent de l’historique ou de tout le dépôt. 04 ### Erreurs et coût possibles Les faux positifs existent ; catégories, langues et conditions de facturation doivent être suivies dans la durée. Il faut ajouter une précaution propre aux correctifs automatiques : **ne jamais appliquer une suggestion sans lire le diff et relancer les tests**. Une modification qui supprime une alerte peut introduire une régression fonctionnelle, une autre faiblesse ou une mauvaise interprétation des règles métier. Le cas Dependabot mérite une vigilance particulière : puisque ces pull requests ne sont pas analysées par AI Scan, gardez les vérifications des dépendances, les mises à jour et les autres mécanismes de sécurité associés à votre dépôt. AI Scan n’est pas un substitut à un audit de dépendances. ## Faut-il activer GitHub AI Scan sur ses projets PHP ? **Oui, à titre de protection complémentaire lorsque le dépôt est éligible et que le budget est maîtrisé.** Pour une équipe Symfony, un éditeur de plugins WordPress ou une application PHP métier, le gain attendu est pragmatique : attirer l’attention des reviewers sur des changements sensibles que la couverture CodeQL native ne traite pas en PHP. La priorité reste toutefois la même : requêtes paramétrées, contrôle des droits objet par objet, gestion des secrets, analyse statique, tests automatisés, revue des modifications critiques et déploiement à privilèges minimaux. L’IA peut aider à détecter et à expliquer ; **elle ne fournit ni une preuve d’absence de vulnérabilité, ni une autorisation de mise en production**. La bonne décision n’est donc pas « remplacer la sécurité CI/CD par AI Scan », mais **« ajouter AI Scan au flux de revue sans affaiblir les garde-fous existants »**. Commencez sur un dépôt pilote, évaluez les alertes et le coût réel, puis étendez l’usage si les retours des développeurs sont suffisamment utiles. Sources officielles et méthode 3 références Les fonctionnalités, limites et conditions d’accès ci-dessus s’appuient sur la documentation et l’annonce GitHub consultées en octobre 2026. Les exemples PHP et le protocole de test sont des propositions pédagogiques : aucun résultat de scan réel n’est revendiqué. - [GitHub Changelog — AI Scan for pull requests generally available (15 octobre 2026)](https://github.blog/changelog/2026-10-15-ai-scan-for-pull-requests-generally-available/). - [GitHub Docs — AI Scan for pull requests : disponibilité, facturation, détection, limitations et activation](https://docs.github.com/en/code-security/concepts/code-scanning/ai-powered-security-detections). - [GitHub Docs — Code scanning with CodeQL : langages pris en charge](https://docs.github.com/en/code-security/concepts/code-scanning/codeql/codeql-code-scanning). AI & CYBERSECURITY ## Reliable AI agents start with a controlled security framework. Architecture, permissions, sandboxing and human validation turn automation into a useful capability without exposing your production systems. - Clearly defined scope and permissions - Isolated execution and controlled sensitive actions - Integrated testing, traceability and human validation [Secure your AI project](https://sdx-development.com/en/contact)[Explore AI & RAG](https://sdx-development.com/en/ai-rag-automation) --- [View the HTML page](https://sdx-development.com/en/news/ai-cybersecurity/github-ai-scan-php-security-pull-requests-cicd)