OWASP Top 10 2025 ubicó Software Supply Chain Failures en A03. El cambio es más amplio que renombrar la categoría anterior de componentes vulnerables y desactualizados: reconoce que el riesgo aparece durante la selección, obtención, construcción, promoción y distribución del software.
De componente vulnerable a falla de cadena
Una evaluación limitada pregunta si una biblioteca tiene una CVE conocida. Una evaluación de cadena también pregunta de dónde provino, quién la publicó, si el artefacto fue alterado, cómo entró al build y qué controles permitieron promoverlo.
| Visión enfocada en el componente | Visión de Software Supply Chain |
|---|---|
| ¿La versión tiene una vulnerabilidad conocida? | ¿El origen, la identidad y la integridad del componente son confiables? |
| ¿Existe una actualización disponible? | ¿El proceso puede seleccionar, probar y promover la actualización de forma segura? |
| ¿El manifiesto declara la dependencia? | ¿Las dependencias transitivas y los artefactos entregados están inventariados? |
| ¿La herramienta generó una alerta? | ¿La política puede bloquear, aprobar, registrar excepciones y producir evidencia? |
La ampliación incluye gestores de dependencias, sistemas de build, repositorios de artefactos, pipelines, herramientas de distribución y procesos de actualización. La pregunta deja de ser solamente “¿qué componente usamos?” e incluye “¿por qué camino obtuvo confianza ese componente?”.
Por qué la categoría llegó a A03
En la encuesta de la comunidad utilizada para la edición 2025, Software Supply Chain Failures ocupó el primer lugar: exactamente el 50% de los participantes la clasificó como la categoría número 1. Sin embargo, el resultado final del OWASP Top 10 no depende únicamente de la votación. OWASP combina la opinión de la comunidad con los datos enviados y el análisis editorial.
La presencia limitada en conjuntos de datos y las 11 CVE asociadas no significan que la mitad de las aplicaciones observadas tenga este problema ni que la categoría sea universalmente la tercera más frecuente. Las fallas de cadena son difíciles de representar mediante CVE porque muchas involucran procesos, confianza, identidad, infraestructura y distribución, no una vulnerabilidad aislada de código.
La posición A03 debe interpretarse como una señal de impacto y relevancia sistémica. Un compromiso en una dependencia, una cuenta de mantenedor, un pipeline o un repositorio puede propagarse a muchos consumidores antes de que exista un indicador tradicional de vulnerabilidad.
Qué cambia en el diseño de controles
1. El control comienza en la selección
Las políticas deben operar antes de la descarga o de la introducción al build. Esto incluye origen permitido, antigüedad del componente, integridad, historial del mantenedor, licencias, vulnerabilidades conocidas y señales de comportamiento malicioso.
2. El inventario incluye dependencias transitivas
Los manifiestos directos no describen toda la composición. El inventario debe reflejar dependencias transitivas y el artefacto realmente producido. Las SBOM ayudan cuando están actualizadas, vinculadas a versiones y conectadas con procesos de monitoreo y respuesta.
3. Build y promoción son fronteras de confianza
Credenciales, runners, plugins, actions, registries y repositorios pueden alterar lo que llega al usuario. La separación de funciones, el menor privilegio, la firma, la procedencia y las políticas de promoción reducen la posibilidad de que un cambio no autorizado atraviese el pipeline.
4. La actualización debe ser continua y comprobable
Actualizar rápidamente exige más que recibir una alerta. El equipo debe localizar consumidores, evaluar compatibilidad, ejecutar pruebas, reconstruir artefactos, promover la corrección y confirmar la distribución.
- 01Selecciónorigen, identidad y política
- 02Ingestiónintegridad y señales de riesgo
- 03Buildentorno, credenciales y procedencia
- 04Promociónaprobación y separación de funciones
- 05Distribuciónfirma y canal confiable
- 06Monitoreonuevas vulnerabilidades e incidentes
Cómo evaluar su entorno
- ¿Las dependencias externas entran directamente desde internet o pasan por un punto controlado?
- ¿El inventario cubre dependencias transitivas y el artefacto entregado?
- ¿El pipeline fija versiones y valida la integridad de actions, plugins e imágenes?
- ¿Las credenciales de build y publicación tienen menor privilegio y rotación?
- ¿Los artefactos reciben firma o procedencia verificable?
- ¿Las políticas de promoción bloquean riesgos y registran excepciones con responsable y vencimiento?
- ¿La organización puede localizar y reconstruir rápidamente todos los consumidores de un componente?
Responder “sí” a la existencia de una herramienta no completa la evaluación. Es necesario verificar cobertura, calidad de datos, enforcement, excepciones y capacidad de respuesta.
Fuentes y referencias
- OWASP Top 10:2025 — A03 Software Supply Chain Failures
- OWASP Top 10:2025 — introducción y metodología
- OWASP Software Component Verification Standard
¿Desea evaluar las fronteras de confianza de su CI/CD?
Xmart ayuda a evaluar arquitectura, políticas y controles para reducir la exposición en la Software Supply Chain.
