OWASP SPVS: Lecciones aprendidas al proteger el software Pipeline

Durante años, los atacantes atacaron las aplicaciones una por una. Han cambiado de táctica: ¿por qué comprometer una aplicación cuando se puede comprometer la aplicación completa? pipeline ¿Que construye muchos? Xygeni Alerta temprana de malware (MEW) detectado 4,452 paquetes maliciosos en 2025 y 1,281 más en lo que va de 2026.Cada incidente de gran repercusión de los últimos años ha afectado a un eslabón diferente de la cadena de distribución de software:

• Vientos solares (2020): Compromiso del entorno de compilación; actualizaciones con puerta trasera enviadas a 18,000 clientes.
• Codecov (2021)Una imagen de Docker mal configurada permitió a los atacantes modificar un script de carga de bash, extrayendo secretos de CI de más de 23,000 clientes.
• CircleCI (2023): El robo de cookies de sesión en el portátil de un ingeniero se convirtió en tokens de acceso a producción; se les dijo a todos los clientes que rotaran cada Secreto.
• Puerta trasera de XZ Utils (2024) :una campaña de ingeniería social que duró varios años y que llegó a casi todas las distribuciones de Linux.
• tj-acciones (2025) — una cascada en la cadena de suministro de GitHub Actions que envenenó un componente utilizado por más de 23,000 repositorios.
• Ataques a Aqua Trivy y Checkmarx (2026) — La campaña TeamPCP convirtió dos escáneres de seguridad ampliamente utilizados en vectores de ataque y luego utilizó los datos robados. CI/CD credenciales para distribuirlas en cascada a npm, OpenVSX y PyPI.

Cada ataque explotó una parte diferente del sistema. pipeline: entorno de compilación, herramientas de CI, dependencias, credenciales de desarrollador, confianza del mantenedor, referencias mutables a artefactos. La mayoría de las organizaciones responden con control de punto, un escáner en CI, 2FA en el IdP, protección de rama en mainLo que suele faltar es una forma de preguntar. ¿Tenemos cobertura sistemática? más bien que ¿Nos acordamos de habilitar X después del último incidente?

Los proveedores de seguridad de aplicaciones están en el punto de mira, ya que comprometer una de ellas afecta a todos los clientes que confían en sus productos. La presión para pasar de controles reactivos a una postura sistemática no es teórica. Eso es precis¿Qué motivó la adopción de OWASP SPVS? standard como proyecto de máxima prioridad.

Qué es SPVS y por qué su estructura es importante.

La historia del origen es simple. En LASCON 2023, Farshad Abasi y Cameron Walters se hacían la misma pregunta: ¿dónde está el ASVS para...? pipeline¿s? OWASP ASVS había dado a la seguridad de las aplicaciones un enfoque integral y verificable. standardNo existía nada equivalente para CI/CD.

Estaba el Top 10 de OWASP. CI/CD Riesgos, que estaba orientado a la concienciación, no era comprobable; SLSA, que se centraba únicamente en la procedencia de la compilación; S2C2F, que se centraba únicamente en el consumo de dependencias; y OpenSSF Cuadro de mando, que abarcaba comprobaciones específicas del repositorio. Cada uno cubría una parte. Ninguno lo cubría todo.

La brecha: cada marco cubrió una parte importante de software supply chain security, pero ninguno proporcionó una solución verificable de extremo a extremo. standard por todo CI/CD pipeline.

Esa conversación se convirtió en dos años de trabajo, y en octubre de 2025 el grupo de trabajo SPVS publicó la versión 1.0: 127 requisitos a lo largo del ciclo de vida, Planificar, Desarrollar, Integrar, Publicar, Operar, estratificados en tres niveles de madurez: L1 Fundacional, L2 Standardy L3 Avanzado. Cada requisito se asigna a NIST SP 800-53, OWASP CI/CD Los 10 mejores y CWE.

Aquí es donde la mayoría de las organizaciones tienen dificultades. Analizan las dependencias pero ignoran la gobernanza de versiones. Firman los artefactos pero no modelan las amenazas. pipeline arquitectura. Supervisan la producción, pero no sus entornos de compilación.

Esta es la tesis que justifica el esfuerzo. Las fortalezas en una etapa no compensan las debilidades en otra. Los atacantes solo necesitan romper un eslabón. Un ciclo de vida standard Te obliga a revisarlos todos, y la progresión de L1 a L2 a L3 te permite hacerlo sin complicaciones. SPVS no reemplaza a SLSA, S2C2F, Scorecard ni Sigstore; te proporciona la estructura que te indica dónde encaja cada uno.

Adaptando el Standard a su organización

El primer paso natural es una auditoría directa de su organización e infraestructura de software en función de cada requisito. Una hoja de cálculo de Google precargada desde el sitio oficial. Requisitos de SPVS CSV funciona bien como punto de partida. Tres vistas son útiles: una matriz de requisitos con estado y propietario por control, un mapa de calor por repositorio y un dashboard del progreso por etapas y niveles. El resultado se integra de forma natural en una hoja de ruta técnica, un documento vivo que abarca todas las etapas, desde la planificación hasta la operación.

La mayoría de las organizaciones de ingeniería consolidadas se encontrarán ya en el nivel 2 cuando realicen este mapeo inicial. De hecho, esta es una buena posición: significa que la primera fase puede centrarse en subsanar deficiencias específicas en lugar de construir cimientos desde cero.

Una hoja de cálculo, sin embargo, es solo una instantánea, y SPVS exige más. La versión 1.1.7 requiere una auditoría trimestral de los administradores de VCS; las versiones 5.1.1 a 5.1.3 añaden auditorías de usuario periódicas, revisión de registros de acceso y monitorización de acceso privilegiado; varios controles de las versiones 2.1.x, 3.3.x y 4.2.x requieren una limpieza continua del flujo de trabajo YAML. Si se realiza manualmente en toda la organización, esto supone medio día de seguimiento de clics cada trimestre, con un riesgo real de omisiones silenciosas. Es el tipo de tarea que o bien se automatiza o bien solo se revisa después de que haya ocurrido algún problema.

Algunos controles de SPVS no son elementos de una lista de verificación que se complete una sola vez. Requieren una revisión periódica, evidencia de auditoría y detección de desviaciones en repositorios, usuarios, flujos de trabajo y acceso privilegiado.

La respuesta es construir o adoptar herramientas que se ejecuten bajo la identidad del propietario de la organización y produzcan un paquete trimestral estructurado: lista de administradores, protección de ramas, cobertura de CODEOWNERS, higiene YAML del flujo de trabajo con acciones fijadas, permisos explícitos, pull_request_target gating, 2FA de miembros, GitHub Apps instalados y claves de despliegue. Lo que solía ser medio día de arqueología de hojas de cálculo se convierte en un solo comando que emite JSON y Markdown. La revisión trimestral entre el CISO y los administradores de la organización se convierten en un decisSe trata de una reunión de análisis de datos, no de una reunión para recopilar información, y los hallazgos prácticos se convierten en problemas pendientes con acuerdos de nivel de servicio (SLA) basados ​​en la gravedad.

Una política de lista de permitidos, que incluya administradores y aplicaciones aprobados, así como permisos por función para repositorios y flujos de trabajo, debe estar en formato YAML en un repositorio con control de versiones, sujeto a la revisión de solicitudes de extracción (PR) del equipo de seguridad. Cualquier cambio en la lista de permitidos deja un registro de revisión, lo que genera evidencia de auditoría. El efecto es convertir controles que antes eran aspiracionales, como «deberíamos auditar trimestralmente», en controles rutinarios, como «la auditoría de este trimestre se realizó el lunes», y brindar a la organización un mecanismo repetible para la detección de desviaciones que exige el principio de extremo a extremo.

Las fricciones que debes planificar

Los controles técnicos son la parte fácil. La gente es lo más difícil.

El ejemplo más destacado es casi siempre CODEOWNERS. Agregar .github/workflows/ @your-org/security En cada repositorio suena trivial. Un archivo, una línea. Pero significa que los ingenieros que llevan años fusionando cambios en el flujo de trabajo ahora necesitan una revisión de seguridad. Incluso las personas preocupadas por la seguridad se resisten: yo escribí este flujo de trabajo, lo entiendo, ¿por qué tengo que esperar?

Se necesita una conversación sincera para comprender el porqué. Los flujos de trabajo pueden extraer credenciales, redirigir artefactos y perjudicar a los usuarios finales. Contar con una segunda opinión no implica desconfianza; es la misma lógica que la de revisar los cambios en la base de datos de producción. Tener un incidente reciente y concreto en la cadena de suministro, ya sea del sector o de su propio entorno, resulta de gran ayuda. Nada evidencia mejor un control que un ejemplo real de su ausencia.

Otras fricciones siguen la misma forma:

• Permisos explícitos: Los bloqueos en los flujos de trabajo provocan fallos en la integración continua hasta que los colaboradores comprenden los permisos con ámbito. No se trata de un problema de permisos, sino de un problema de modelo mental.
• Inmutabilidad de la etiqueta: Rompe las herramientas de lanzamiento que han estado reetiquetando silenciosamente durante años.
• firmado commits: Se generan dificultades en el proceso de incorporación hasta que las claves GPG o SSH estén configuradas correctamente en todas las estaciones de trabajo. SPVS exige esto para todos los repositorios y colaboradores, no solo para los principales.
• Sustitución de los tokens de acceso personal clásicos: La presencia de numerosos repositorios y archivos de flujo de trabajo afecta a casi todos los equipos.

El método que funciona consiste en introducir cada control con una amenaza específica que bloquea, realizar una prueba piloto en uno o dos repositorios, implementarlo con excepciones en la lista de permitidos y retirar las excepciones en un plazo definido. Los ingenieros que más se resisten suelen convertirse en sus mayores defensores una vez que comprenden la lógica.

Un punto más profundo: el principio de extremo a extremo se aplica aquí. No se puede elegir solo lo que conviene. Reforzar la fase de compilación mientras se deja la gobernanza de la versión laxa genera una falsa sensación de seguridad, que es precisamente el modo de fallo que señalan los autores de SPVS. Todas las fases deben avanzar conjuntamente, incluso cuando un control específico parezca desproporcionado de forma aislada.

Costo: Aproximadamente un mes de tiempo de ingeniería transcurrido para la Fase 1, enfocado en el cumplimiento de L2 para una organización pequeña, distribuido entre DevOps, Seguridad y revisores de ingeniería. La inversión se amortiza fácilmente. Un solo incidente en la cadena de suministro evitado cubre la inversión con creces. Las organizaciones más grandes deberían presupuestar proporcionalmente más, pero la estructura por fases de L1 a L2 a L3 significa que se genera valor antes de que el programa esté completo.

¿Qué sigue?

SPVS v1.5 está en el horizonte con controles relacionados con la IA: procedencia del código asistido por IA, guardrails Para los flujos de trabajo de CI que llaman a LLM, revise los registros generados por IA. pull requestsy defensas contra amenazas emergentes como el slopsquatting, donde los atacantes registran nombres de paquetes que los asistentes de codificación de IA alucinan, y el malware operativo generado por IA que CrowdStrike informa en la práctica. Organizaciones que ya etiquetan la IA asistida commitLos responsables de relaciones públicas y otros departamentos, en sus directrices de desarrollo interno, encontrarán que esta adaptación es gradual en lugar de un nuevo programa de trabajo.

Se espera que la versión 2.0 profundice en la supervisión en tiempo de ejecución y los requisitos del ciclo de vida de las credenciales. Una hoja de ruta organizativa razonable: cerrar las brechas L3 restantes para finales del segundo trimestre de 2026, incluyendo SLSA provenance integrado en standard CI/CDSe establecen puertas manuales para las implementaciones en producción y se utiliza un proveedor de identidad centralizado, para luego pasar al modo de mantenimiento. Cada nuevo repositorio comienza cumpliendo con los requisitos, y cada auditoría trimestral detecta cualquier desviación a tiempo.

Nuestro más sincero agradecimiento a Farshad Abasi, Cameron Walters y al grupo de trabajo OWASP SPVS. Proyectos como este facilitan el trabajo de cualquier organización que desee implementar la seguridad de la cadena de suministro de forma sistemática, en lugar de reactiva.

Puntos Clave

Algunos aspectos que se pueden aplicar más allá de nuestro contexto específico:

• Para probarlo: Descarga el archivo CSV con los requisitos de SPVS y mapea tus controles actuales en una hoja de cálculo. En un día sabrás si se ajustan a tus necesidades.
• Elige un nivel objetivo y encárgalo antes de pasar al siguiente. De L1 a L2 a L3 es una característica, no una limitación.
• El pipeline es el objetivo. Los controles centrados en la aplicación son necesarios pero no suficientes; trate la aplicación pipeline como una superficie de ataque de primera clase.
• Verificar todo pipeline, ni una sola pieza. La solidez en el análisis de dependencias no compensa una gobernanza de versiones deficiente ni los entornos de compilación no supervisados.
• Las hojas de cálculo son instantáneas; la deriva es continua. Implemente sistemas de automatización, aunque sean herramientas internas sencillas, para detectar discrepancias entre las auditorías.
• El trabajo organizativo es más difícil que el trabajo técnico. Dedique tiempo a la conversación y a la prueba piloto antes del lanzamiento, y explique la amenaza específica que bloquea cada control.

Para leer más

• OWASP: Seguro Pipeline Verificación Standard (SPVS) v1.0Página del proyecto OWASP.
• Farshad Abasi: Por qué creamos OWASP SPVSArtículos de OWASP SPVS.
• Farshad Abasi: Pipeline Los ataques están empeorando. Aquí te explicamos cómo prepararte.Artículos de OWASP SPVS.
• Farshad Abasi: OWASP SPV frente a otros marcos de gestión de la cadena de suministroArtículos de OWASP SPVS.
• OWASP: Top 10 Seguridad en CI/CD RiesgosPágina del proyecto OWASP.
• SLSA: Niveles de la cadena de suministro de artefactos de software. slsa.dev.
• OpenSSF: Tanteador. securityscorecards.dev.