Psalm : analyse de teinte du code PHP

Parce qu'ils ne répondent pas à la même question. PHPStan vérifie ce qu'une valeur est, Psalm en mode teinte vérifie ce qu'une valeur a traversé. Le mainteneur de PHPStan a décliné en 2022 d'implémenter l'analyse de teinte (issue #8038) et aucune extension largement adoptée ne le fait. Psalm sait aussi vérifier les types, mais nous le bridons pour qu'il ne concurrence pas PHPStan : un seul type-checker, un seul analyseur de flux.

On déclare des sources, tout ce qui vient de l'utilisateur, et des sinks, tout ce qui exécute ou affiche. L'outil suit la donnée de l'une à l'autre. Si un paramètre de requête HTTP arrive dans une requête SQL sans passer par un échappement ou un paramètre lié, c'est une injection SQL prouvée, et Psalm affiche le chemin complet : le contrôleur qui lit la valeur, le service qui la transmet, la ligne du repository qui l'exécute.

Psalm connaît nativement les sinks SQL de mysqli et de PDO, mais notre code passe par Doctrine : createQuery() et le QueryBuilder. Aucun plugin ne marque ce chemin ORM comme sink, le plugin communautaire existant ne couvre que le DBAL bas niveau et ses stubs entrent en collision avec ceux du plugin Symfony. Sans notre fichier, l'analyse tourne, termine en vert et ne détecte aucune injection passant par Doctrine. C'est le pire résultat possible : un contrôle qui rassure sans contrôler.

Oui. Le projet a connu un passage à vide autour de 2023, ce qui justifie la question. La version 6.17.0 est sortie le 10 septembre 2026, la branche 7.0 est en bêta depuis fin 2025 et psalm/plugin-symfony a publié sa 5.3.0 en février 2026. Nous surveillons cette cadence comme celle de toutes nos dépendances.

Pas avec @psalm-suppress, qui n'atteint pas les remontées de teinte. On pose @psalm-taint-escape suivi du type de teinte sur la valeur que l'on considère comme assainie, par exemple après une validation stricte ou une conversion en entier. L'annotation documente pourquoi la donnée n'est plus dangereuse. Pour les remontées historiques d'un projet repris, la baseline dédiée les fige et la CI ne bloque que sur les nouvelles.

Tout ce dont les deux extrémités ne sont pas déclarées. Un sink absent des stubs n'existe pas pour lui, c'est la raison du fichier Doctrine. La présence d'une fonction dangereuse sans flux (eval, phpinfo, md5) n'est pas non plus son sujet : PHPStan la bannit via phpstan-disallowed-calls. Et les CVE des dépendances relèvent de composer audit. Trois familles, trois outils.

Oui, c'est le rôle de la baseline. On la génère une fois avec make psgb pour figer les remontées existantes, puis make psalm-ci en CI ne signale que les nouveaux flux. Il faut la générer avant d'activer le job, sinon la première exécution échoue sur l'ensemble du code. Les remontées historiques se traitent ensuite par lots, dans le cadre de la maintenance.