En la nueva propuesta de OWASP Top 10-2025 hay un riesgo que, al parecer, desapareció de la lista: "La vulnerabilidad por uso de componentes desactualizados" (A06 en la lista de 2021).
Bueno, este riesgo no ha desaparecido, sino que evolucionó. Hoy es parte de una amenaza más amplia denominada "Fallos en la cadena de suministro de software" (propuesta A03:2025) en el original, “Software Supply Chain Failures” y que en la lista de 2013 estaba en el penúltimo lugar. Por lo tanto, tener software desactualizado cobra más relevancia como riesgo potencial.
La amenaza "Falla en la cadena de suministro de software" pone su foco en el riesgo de usar bibliotecas no parchadas (si ya fueron detectadas algunas vulnerabilidad en ellas), en las dependencias en software de código libre o open-source y en herramientas que ya no están soportadas.
El ámbito de este riesgo no está sólo en el software desactualizado sino también en las fallas de configuración en los sistemas CI/CD (integración continua/despliegue continuo), dependencias comprometidas y en infraestructura como código insegura.
Este es un cambio de foco, ya que no solo destaca el riesgo de las componentes de software desactualizadas y con vulnerabilidades conocidas sino que incluye las herramientas usadas para crear y distribuir el software, es decir, la cadena de suministro.
Ejemplos de la vulnerabilidad
- Uso de bibliotecas con CVE conocidas: Integrar versiones de Log4j anteriores a 2.15.0
Imágenes de docker antiguas con sistemas operativos sin parches de seguridad aplicados. - Dependencia de paquetes obsoletos como npm o pip que ya no tienen parches de seguridad.
- Usar herramientas de CI/CD con vulnerabilidades como Jenkins o GitHub actions.
¿Está su organización o servicio en peligro?
Si usted responde “NO” a algunas de las siguientes preguntas, está en riesgo. Dicho riesgo se incrementa cuanto más “NO” acumule.
- ¿Hace un seguimiento detallado de todas las componentes de software que usa su servicio?
¿Las componentes de su solución (sistema operativo, servidor web, aplicación, motor de base de datos, etc.) están actualizadas y libres de vulnerabilidades conocidas? - ¿Realiza revisiones periódicas en busca de vulnerabilidades?
- ¿Su proceso de cambios incluye la cadena de suministro (IDE, extensiones, repositorios, imágenes)?
- ¿Puede asegurar que en la construcción del software existen controles de acceso y privilegios mínimos?
- ¿Una persona diferente a quién escribió el código lo revisa antes de ir a producción?
- ¿Usa componentes de software que provienen de fuentes confiables?
- ¿Actualiza sus sistemas críticos de manera reactiva ante parches de seguridad urgentes, además de mantener un ciclo de actualización periódico?
- ¿Los desarrolladores prueban la compatibilidad de las actualizaciones?
- ¿Puede asegurar las configuraciones de cada parte del sistema?
- ¿Su flujo CI/CD incluye controles de seguridad en las etapas de construcción y despliegue?
Si después de este cuestionario, cree que está en riesgo según OWASP Top 10-A03, aquí van algunas recomendaciones:
- Implemente herramientas de análisis de Composición de Software (SCA). Estas herramientas permiten identificar vulnerabilidades conocidas en las dependencias de terceros. Sus funciones clave incluyen:
- Generar un SBOM (Software Bill of Materials) o inventario detallado de componentes.
- Identificar dependencias directas y transitivas.
- Detectar vulnerabilidades (CVEs) asociadas a esas dependencias.
- Proponer medidas de mitigación o parches.
- Usar herramientas como: Snyk, Sonatype Lifecycle, OWASP Dependency-Check para detectar vulnerabilidades conocidas.
- Actualice regularmente todas las dependencias, bibliotecas y las herramientas que las construyen a las últimas versiones seguras.
- Monitorear los flujos de trabajo. Usar monitores en los flujos CI/CD y verificar el código a lo largo de todo el proceso, idealmente lo más cerca posible de la puesta en producción.
