# Análisis estático: PHPStan y Psalm > PHPStan y Psalm explicados: niveles de reglas, baseline, análisis de taint y qué puede aportar el análisis estático a la seguridad de PHP y qué no. Fuente: https://phpsos.de/es/php/statische-analyse/ Actualizado: 25/10/2026 Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6 **En resumen:** el análisis estático revisa el código PHP sin ejecutarlo y encuentra así errores de tipo, variables sin definir, código muerto y llamadas sobre valores posiblemente vacíos. Las dos herramientas más extendidas son PHPStan (niveles de reglas 0 a 10) y Psalm (niveles de error 1 a 8, además de un análisis de taint para flujos de datos inseguros). Encuentran errores en su aplicación, no en el intérprete de PHP; frente a vulnerabilidades como PHP2Shell solo ayuda la actualización de PHP. ## ¿Qué es el análisis estático? Una prueba ejecuta el código y compara el resultado. El análisis estático, en cambio, lee el código como un revisor muy minucioso y deduce a partir de los tipos, los valores devueltos y las llamadas dónde puede salir algo mal. Encuentra errores también en ramas que ninguna prueba alcanza nunca. Para quienes toman decisiones, el beneficio es sencillo: los fallos que se encuentran antes de la puesta en producción cuestan una fracción de los que notan los clientes. Para los desarrolladores es un acompañante constante que se ejecuta en el entorno de desarrollo y en la canalización de CI. Si el análisis salta ante un cambio, este no se integra hasta que se corrija el fallo. Así no se acumula una herencia nueva mientras se reduce poco a poco la existente. Junto con las [pruebas con PHPUnit y Pest](https://phpsos.de/es/php/php-testen/) constituye la base de la calidad del código. ## PHPStan: niveles de reglas de 0 a 10 PHPStan se instala como dependencia de desarrollo y necesita PHP 7.4 o superior para funcionar: ```bash composer require --dev phpstan/phpstan vendor/bin/phpstan analyse src tests ``` Sin más indicaciones, PHPStan comprueba solo lo imprescindible. La exigencia se controla mediante once niveles, cada uno de los cuales incluye los inferiores: | Nivel | Qué se comprueba además (selección) | |---|---| | 0 | clases y funciones desconocidas, número incorrecto de argumentos, variables siempre sin definir | | 3 | tipos devueltos y tipos que se asignan a propiedades | | 5 | tipos de los argumentos en llamadas a funciones y métodos | | 6 | indicaciones de tipo ausentes | | 8 | llamadas a métodos y accesos a propiedades sobre valores que pueden ser null | | 10 | el tratamiento más estricto de `mixed`, también con tipos ausentes | Con `--level max` se ejecuta siempre el nivel más alto. La documentación advierte, sin embargo, de que una actualización de PHPStan puede traer entonces muchos avisos nuevos. Un hallazgo típico desde el nivel 8: ```php name(); // PHPStan: llamada sobre un valor que puede ser null } ``` ## Introducir PHPStan sin una avalancha de errores: la baseline En proyectos con muchos años, PHPStan suele notificar cientos de puntos en un nivel alto. La baseline resuelve el problema: guarda todos los avisos existentes en un archivo y, a partir de ese momento, PHPStan solo notifica los errores nuevos. ```bash vendor/bin/phpstan analyse --level 6 src tests --generate-baseline ``` El archivo generado `phpstan-baseline.neon` se incluye en la configuración: ```neon includes: - phpstan-baseline.neon parameters: level: 6 paths: - src - tests ``` Así, la herencia acumulada queda documentada de forma visible, mientras que el código nuevo debe estar limpio desde el principio. ## Psalm y el análisis de taint Psalm persigue objetivos similares a los de PHPStan. Los niveles van al revés: 1 es el más estricto, 8 el más indulgente, y el valor por defecto es 2. Psalm necesita PHP 8.2 o superior y se configura así: ```bash composer require --dev vimeo/psalm ./vendor/bin/psalm --init ./vendor/bin/psalm --taint-analysis ``` El análisis de taint es especialmente interesante para la seguridad. «Taint» significa contaminación: Psalm marca los datos procedentes de fuentes que un atacante puede controlar, como `$_GET`, `$_POST`, `$_COOKIE`, `$_REQUEST` o `php://input`. Después sigue si esos datos llegan sin protección a puntos peligrosos, los llamados sumideros: salida con `echo`, `include`, `header` o consultas SQL. Entre las categorías integradas están, entre otras, `sql`, `html`, `shell`, `include`, `eval`, `ssrf` y `unserialize`. ```php