En el hostil y siempre cambiante mundo de la ciberseguridad, la historia de la vulnerabilidad CVE-2024-6387 nos ofrece una lección crucial sobre la importancia de la gestión del código y la revisión constante de la seguridad. Esta vulnerabilidad, fue identificada en 2006, y reintroducida (imaginamos que por error) en el código fuente de OpenSSH en 2020, concepto que se denomina “Regresión” (de ahí que se le llame a esta vulnerabilidad RegreSSHion), causando consternación entre los expertos y usuarios por igual.
¿Cómo es posible que un fallo identificado hace casi dos décadas vuelva a surgir en el software moderno?
Para entender este fenómeno, debemos considerar varios factores clave en SSDLC (Secure Software Development Life Cicle):
Gestión del Código y Control de Versiones: En 2006, la vulnerabilidad fue documentada y parcheada, pero los sistemas de control de versiones y la gestión del código no siempre aseguran que los parches sean permanentes. En algún momento entre la identificación original y 2020, el código vulnerable fue reintroducido, posiblemente debido a la fusión incorrecta de ramas de código o la reutilización de componentes antiguos que no se actualizaron adecuadamente (¡¡no pensemos mal, por favor!!).
Desarrollo de Software y Ciclo de Vida del Código: A medida que el software evoluciona, el ciclo de vida del código implica numerosas actualizaciones, mejoras y correcciones. En grandes proyectos, es fácil que las modificaciones pasadas se pierdan en el mar de cambios continuos, especialmente si no hay un seguimiento riguroso y una documentación exhaustiva.
Cadena de suministro / Dependencias de librerías de terceros: El desarrollo moderno a menudo depende de múltiples bibliotecas y componentes de terceros. Si una vulnerabilidad se encuentra en uno de estos componentes y no se gestiona correctamente, puede ser reintroducida al actualizar o cambiar dependencias sin la debida diligencia.
Auditorías y Revisiones de Seguridad: Aunque las auditorías de seguridad son esenciales, no siempre garantizan la detección de todas las vulnerabilidades, especialmente si la auditoría no se centra en revisar el historial completo del código. La reintroducción de CVE-2024-6387 subraya la necesidad de auditorías exhaustivas y continuas, así como de procesos automatizados que alerten sobre la reaparición de fallos conocidos.
Herramientas usadas para auditar código
Hace un tiempo en sesiones de consultoría de implantación del Esquema Nacional de Seguridad con un cliente, conocí un par de herramientas de análisis de código que considero que son una maravilla y un “MUST” en todos los equipos de desarrollo y que probablemente hubieran hecho saltar las alarmas en alguno de los multiples Pull Requests que habrá sufrido el código desde 2020.
SNYK
SNYK es una herramienta especializada en la seguridad del código y las dependencias. Su enfoque principal es la detección y corrección de vulnerabilidades en tiempo real, lo que permite a los desarrolladores integrar la seguridad directamente en su flujo de trabajo de desarrollo.
Análisis de Dependencias: SNYK escanea las dependencias del proyecto y alerta sobre cualquier vulnerabilidad conocida, incluyendo aquellas que podrían haber sido reintroducidas accidentalmente.
Monitoreo Continuo: Ofrece monitoreo continuo, lo que significa que incluso después de la integración inicial, SNYK seguirá analizando el código y las dependencias en busca de nuevas vulnerabilidades.
Corrección Automática: Propone soluciones y actualizaciones de seguridad para las vulnerabilidades detectadas, ayudando a los equipos a resolver problemas rápidamente.
SonarQube
SonarQube es una plataforma robusta para la inspección continua de la calidad del código, que incluye análisis de seguridad, detección de bugs, y evaluación de la calidad del código en general.
Detección de Vulnerabilidades y Bugs: SonarQube puede identificar problemas de seguridad y bugs en el código, incluyendo patrones de vulnerabilidades que podrían reaparecer.
Revisiones de Código Automatizadas: Ayuda a mantener estándares de codificación consistentes mediante revisiones automatizadas, lo que reduce la probabilidad de que el código inseguro sea reintroducido.
Historial y Comparación de Código: SonarQube mantiene un historial de las revisiones de código y permite comparar cambios, lo que es crucial para identificar cuándo y cómo una vulnerabilidad reintroducida pudo haber ocurrido.
Integración en el Ciclo de Vida del Desarrollo
Para maximizar la eficacia de estas herramientas, es fundamental integrarlas en el ciclo de vida del desarrollo de software (SDLC). Aquí hay algunas prácticas recomendadas:
Integración Continua (CI/CD): Integrar SNYK y SonarQube en las tuberías de CI/CD para asegurar que el código sea analizado automáticamente en cada commit y build.
Gestión de Cambios y Pase a producción: Establecer un proceso robusto y riguroso que requieran la aprobación de los análisis de seguridad antes de fusionar cualquier código nuevo.
Formación y Capacitación: Asegurar que los desarrolladores estén capacitados en el uso de estas herramientas y en la interpretación de los resultados para tomar las acciones correctivas necesarias. NOTA: Os sorprendería la cantidad de desarrolladores que audito que tienen conocimientos Bajos o Nulos en Ciberseguridad… Como mínimo saber interpretar estas herramientas, es vital.
Conclusión final
Herramientas como SNYK y SonarQube son vitales para prevenir la reintroducción de vulnerabilidades como la CVE-2024-6387. Al proporcionar análisis continuo, detección automática de vulnerabilidades y bugs, y soluciones correctivas, estas herramientas ayudan a mantener la integridad y seguridad del código a lo largo del tiempo. Integrarlas eficazmente en el ciclo de vida del desarrollo de software y asegurar que los equipos estén bien entrenados en su uso es fundamental para crear y mantener software seguro y de alta calidad.
