Publié le par Rodolphe
Modifié le par Rodolphe
Chargement de l'article...
Cette édition du 16 octobre 2026 rassemble six actualités techniques publiées au cours des derniers jours.
Symfony 8.2 enrichit la définition des workflows et améliore la sécurité des déconnexions.
L'écosystème PHP reçoit des correctifs pour PHPUnit et publie de nouvelles données sur le traitement des vulnérabilités du langage.
Du côté de l'intelligence artificielle, GitHub généralise deux fonctionnalités consacrées à la détection et à la correction des problèmes de sécurité dans le code.
Symfony a présenté le 14 octobre une nouvelle méthode de configuration du composant Workflow. Avec Symfony 8.2, les développeurs peuvent désormais définir un workflow ou une machine à états directement dans une classe PHP, à l'aide d'attributs.
Jusqu'à présent, les workflows étaient principalement configurés dans des fichiers YAML ou PHP distincts. La nouvelle approche permet de regrouper les états, les transitions et les événements associés dans une même classe de service.
L'attribut #[AsWorkflow] déclare le workflow, tandis que #[Transition] définit les transitions possibles entre les différents états.
Les transitions peuvent être associées à des constantes PHP, ce qui permet de les référencer sans multiplier les chaînes de caractères dans le code applicatif.
Symfony prend également en charge les énumérations PHP pour représenter les états. L'attribut #[Place] permet d'associer des métadonnées à chaque valeur d'une énumération.
Un nouveau trait WorkflowTrait facilite l'utilisation du workflow depuis la classe qui le définit. Les méthodes permettant de vérifier ou d'appliquer une transition peuvent ainsi être utilisées directement.
Les développeurs peuvent également déclarer des listeners dans cette même classe, notamment avec #[AsGuardListener], pour contrôler les conditions nécessaires à l'exécution d'une transition.
Cette fonctionnalité concerne particulièrement les applications métier qui manipulent des cycles de vie complexes : commandes, validations administratives, publications, dossiers ou processus de traitement.
Symfony 8.2 reste actuellement en développement. Cette nouvelle méthode de configuration sera disponible avec la publication stable de cette version.
Sources : Symfony Blog — New in Symfony 8.2: Attribute-Based Workflows.
Symfony a annoncé le 13 octobre plusieurs évolutions du composant Security destinées à améliorer la gestion des déconnexions dans les applications web et les API.
La première nouveauté concerne les déconnexions effectuées avec une requête HTTP POST.
Une route de déconnexion accessible en GET peut être déclenchée involontairement par un navigateur, un robot de prévisualisation, un scanner de sécurité ou un proxy suivant automatiquement les liens d'une page.
Symfony 8.2 facilite l'utilisation de POST grâce à deux nouvelles fonctions Twig : logout_form() et logout_button().
La première fournit les informations nécessaires à la construction d'un formulaire de déconnexion, notamment son URL et ses champs cachés.
La seconde génère directement un bouton de déconnexion accompagné de son formulaire. Lorsque la protection CSRF est activée, le jeton nécessaire est intégré automatiquement.
Des fonctions similaires sont également introduites pour les mécanismes d'usurpation d'identité utilisés par les administrateurs.
Symfony 8.2 permet aussi de désactiver la redirection automatique après une déconnexion en configurant logout.target à null.
Cette possibilité permet notamment aux API de retourner directement une réponse JSON depuis leur contrôleur, sans nécessiter de listener spécifique.
Enfin, l'authentificateur OpenID Connect introduit dans Symfony 8.2 prend désormais en charge la spécification Back-Channel Logout.
Lorsqu'un utilisateur se déconnecte auprès de son fournisseur d'identité, celui-ci peut envoyer un jeton de déconnexion signé à l'application Symfony.
Symfony vérifie ce jeton et enregistre la session concernée comme terminée dans un cache. La déconnexion devient effective lors de la prochaine requête de l'utilisateur.
Cette fonctionnalité nécessite un firewall avec état et un cache partagé entre les serveurs de l'application.
Ces évolutions concernent particulièrement les applications utilisant une authentification centralisée, les interfaces d'administration et les API nécessitant un contrôle précis du comportement après déconnexion.
Sources : Symfony Blog — New in Symfony 8.2: Safer and More Flexible Logout.
PHPUnit 13.4.2 a été publié le 12 octobre 2026. Cette version de maintenance corrige plusieurs problèmes susceptibles d'affecter la fiabilité des résultats et les performances de certaines suites de tests PHP.
Parmi les corrections figure un problème de correspondance des arguments nommés dans les attentes des mocks.
Jusqu'à présent, certains appels à with() pouvaient comparer les arguments selon leur position plutôt que selon leur nom.
Une attente utilisant un argument nommé pouvait ainsi vérifier une valeur différente de celle réellement visée par le développeur.
PHPUnit 13.4.2 corrige ce comportement ainsi que des problèmes similaires dans les méthodes withParameterSetsInOrder(), withParameterSetsInAnyOrder() et withParameterSetsInPartialOrder().
La version corrige également une anomalie concernant les tests utilisant des mocks dont le destructeur déclenche une exception.
Dans certaines situations, le test pouvait être signalé comme ayant échoué tout en conservant un état interne indiquant une réussite.
Ce comportement pouvait perturber les mécanismes de nouvelle tentative avec #[Retry], l'option --repeat et les résultats de couverture de code.
Plusieurs corrections concernent enfin le tri des tests. PHPUnit évite désormais de recalculer inutilement certaines informations de durée ou de taille pendant les opérations de classement.
Cette publication complète PHPUnit 13.4, sorti le 2 octobre, qui avait notamment introduit une option --timeout permettant de limiter la durée totale d'une exécution.
Pour les équipes utilisant PHPUnit dans leurs pipelines CI, la version 13.4.2 améliore donc à la fois la précision des assertions et la cohérence des résultats des tests.
Sources : GitHub — PHPUnit 13.4.2 Release Notes ; The PHP Foundation — Your Tool Has a New Reader.
La PHP Foundation a publié le 14 octobre un état des lieux du fonctionnement de l'équipe chargée de la sécurité du cœur de PHP.
Le rapport apporte de nouvelles données sur le volume des signalements reçus et sur les méthodes utilisées pour les analyser.
Depuis le 1er juillet 2026, l'équipe indique avoir publié 15 identifiants CVE et clôturé 106 signalements.
Ces clôtures concernent notamment des rapports ne correspondant pas à des vulnérabilités, des doublons et des problèmes impossibles à reproduire.
Certains signalements rejetés comme vulnérabilités peuvent néanmoins conduire à des travaux de durcissement du langage.
L'équipe explique également que l'utilisation croissante des outils d'intelligence artificielle pour analyser automatiquement le code a considérablement augmenté le nombre de rapports reçus.
Pour absorber cette charge, les mainteneurs utilisent eux-mêmes davantage d'outils automatisés et de modèles IA.
La Foundation confirme notamment l'utilisation de Daybreak Red, un dispositif d'OpenAI destiné à la recherche de vulnérabilités et à la validation des possibilités d'exploitation.
Cet outil aide à vérifier certains rapports et à identifier plusieurs signalements correspondant à une même cause technique.
Les décisions restent cependant prises par des humains. Chaque vulnérabilité doit être reproduite, qualifiée et examinée par un membre de l'équipe.
Le rapport précise également que PHP dispose de sa propre autorité d'attribution des identifiants CVE depuis 2019.
Le projet peut ainsi publier ses avis de sécurité sans dépendre des délais d'attribution d'une plateforme externe.
Pour accélérer le traitement des signalements, les mainteneurs demandent de fournir un exemple PHP minimal permettant de reproduire le problème, la version concernée, l'environnement d'exécution et les résultats des outils de diagnostic.
Les rapports générés avec une IA restent acceptés, à condition que leurs auteurs aient vérifié la reproductibilité et compris les conséquences réelles du problème signalé.
Cette publication apporte des données concrètes sur l'organisation de la sécurité de PHP et sur l'évolution des méthodes de recherche de vulnérabilités.
Sources : The PHP Foundation — How the PHP Security Team Handles Your Reports.
GitHub a annoncé le 15 octobre la disponibilité générale d'AI Scan pour les pull requests.
Cette fonctionnalité utilise l'intelligence artificielle pour détecter des problèmes de sécurité dans les modifications proposées sur un dépôt.
Son principal intérêt pour les développeurs PHP réside dans sa capacité à analyser des langages et des technologies qui ne bénéficient pas actuellement d'une couverture CodeQL équivalente.
GitHub cite explicitement PHP parmi les langages pris en charge par AI Scan, aux côtés notamment de Shell, Bash, Terraform, Dockerfile et JSP.
Lorsque l'analyse de code et AI Scan sont activés, le service examine automatiquement les modifications des pull requests.
Les problèmes détectés apparaissent directement dans les onglets de conversation et de fichiers modifiés de la pull request.
Les résultats disposent d'un indicateur spécifique permettant de distinguer les alertes générées par l'IA de celles produites par CodeQL.
Chaque résultat peut comprendre une explication du risque de sécurité et une proposition de correction.
GitHub précise toutefois que les résultats d'AI Scan restent consultatifs.
Ils ne font pas échouer le contrôle de code scanning et ne peuvent pas, à eux seuls, empêcher la fusion d'une pull request au moyen des règles de protection.
AI Scan ne s'exécute pas non plus sur les pull requests provenant de forks ou créées par Dependabot.
La fonctionnalité est accessible aux dépôts publics. Pour les dépôts privés et internes appartenant à des organisations, elle nécessite GitHub Code Security ou GitHub Advanced Security.
Aucune licence GitHub Copilot n'est nécessaire. L'utilisation est toutefois comptabilisée dans les crédits IA associés à Code Security.
Pour les équipes PHP et Symfony, cette disponibilité générale apporte une nouvelle possibilité d'analyse automatisée des vulnérabilités directement dans les revues de code.
Sources : GitHub Changelog — AI Scan for Pull Requests Generally Available.
GitHub a également annoncé le 15 octobre la disponibilité générale d'Agentic Autofix pour les alertes de sécurité issues de l'analyse de code.
Cette fonctionnalité permet de confier à Copilot la préparation d'un correctif pour une vulnérabilité identifiée dans un dépôt.
Contrairement à une simple suggestion de modification, l'agent peut explorer plusieurs fichiers, analyser les dépendances entre les éléments du code et préparer une correction couvrant plusieurs parties de l'application.
Le processus comprend plusieurs étapes. L'agent commence par examiner l'alerte et les fichiers concernés.
Il génère ensuite une modification, puis relance CodeQL pour vérifier que le problème signalé n'est plus détecté.
Si nécessaire, il peut poursuivre ses modifications avant de proposer une pull request en brouillon.
Cette pull request contient un résumé du correctif, les raisons pour lesquelles il répond à l'alerte et les vérifications effectuées.
Les développeurs conservent la possibilité d'examiner les modifications et de demander des ajustements supplémentaires.
GitHub permet également de sélectionner jusqu'à 25 alertes de sécurité pour demander à Copilot de les traiter ensemble dans une même pull request.
La fonctionnalité est réservée aux alertes présentes sur la branche par défaut du dépôt. Les problèmes détectés uniquement dans une pull request ou une autre branche ne peuvent pas être directement confiés à cet agent.
Agentic Autofix est disponible pour les clients GitHub Code Security et GitHub Advanced Security utilisant GitHub Enterprise Cloud.
Son activation nécessite une politique autorisée par un administrateur d'entreprise et une méthode de facturation Copilot.
L'utilisation consomme des crédits IA du budget Code Security ainsi que des minutes GitHub Actions.
Cette fonctionnalité reste distincte d'AI Scan : Agentic Autofix s'appuie sur les alertes de code scanning et utilise CodeQL pour valider les corrections.
La prise en charge de PHP par AI Scan ne signifie donc pas que toutes ses alertes peuvent déjà bénéficier du même processus de correction agentique.
Cette publication marque une évolution importante des outils de sécurité du développement logiciel, avec le passage de la simple détection automatisée à la préparation et à la vérification de correctifs par des agents.
Sources : GitHub Changelog — Agentic Autofix for Code Scanning Alerts General Availability.
dir SocialNetwork /W
Le volume dans le lecteur C s’appelle Tyr.
Le numéro de série du volume est 2026-1017
[ bluesky ] [ facebook ] [ linkedin ] [ x ]
█