Sin proveedor emitiendo parches,
no hay gestión de vulnerabilidades.
Los tres marcos que más aparecen en auditorías de organizaciones que operan aplicaciones PHP (PCI-DSS, ISO 27001 y las disposiciones de la CNBV en instituciones financieras mexicanas) comparten un mismo requisito de fondo: demostrar que las vulnerabilidades del stack tecnológico se identifican y se corrigen en un tiempo razonable. Un runtime PHP sin soporte oficial no puede cumplir esa parte, porque ya no existe ningún proveedor emitiendo esos parches, independientemente de qué tan bien mantenido esté el código de la aplicación por encima.
Distintos nombres,
el mismo requisito de fondo.
- Exige desarrollar y mantener sistemas y aplicaciones seguros
- Incluye la aplicación oportuna de parches de seguridad conocidos
- Un runtime EOL no puede demostrar "parches oportunos": no hay quién los emita
- Control de gestión de vulnerabilidades técnicas (A.8.8 en la versión 2022)
- Exige identificar y remediar vulnerabilidades del software en uso
- Un contrato de soporte documentado es evidencia directa ante el auditor
- Las disposiciones de seguridad de la información exigen gestión de vulnerabilidades
- Y actualización documentada de componentes tecnológicos críticos
- Un runtime PHP sin soporte demostrable es una brecha típica en este tipo de revisión
Lo que pregunta el equipo de cumplimiento.
¿Por qué un auditor marca PHP EOL como hallazgo crítico?
Porque un runtime sin soporte oficial no puede demostrar que las vulnerabilidades descubiertas después de su fin de vida se corrigen. Eso incumple directamente el requisito de gestión de vulnerabilidades de PCI-DSS e ISO 27001.
¿Qué requisito específico de PCI-DSS afecta a PHP sin soporte?
El Requisito 6, sobre desarrollar y mantener sistemas seguros con parches oportunos. Un runtime EOL no puede cumplir esa parte porque no hay proveedor emitiéndolos.
¿Cómo documentamos soporte continuo si estamos en una versión EOL?
Con un contrato de soporte comercial como ZendPHP, que emite parches con retroactividad y un SLA documentado: evidencia concreta ante el auditor, sin migrar el código.
¿Esto aplica también a instituciones reguladas por la CNBV*?
Sí. Las disposiciones de seguridad de la información de la CNBV exigen gestión de vulnerabilidades y actualización de componentes tecnológicos. Un runtime PHP sin soporte demostrable es exactamente el tipo de brecha que revisan.
*La CNBV (Comisión Nacional Bancaria y de Valores) es el regulador del sector financiero en México. Para instituciones en España, los marcos equivalentes de referencia suelen ser el Banco de España y la normativa DORA de la UE.
¿Necesitas evidencia documentada
de soporte para tu próxima auditoría?
Calcula el costo y el argumento financiero, o agenda una llamada técnica directamente.
Descargar Calculadora de ROI → ← Ver más recursos