Verificar todo el software PipelineLa fricción, los éxitos y las lecciones aprendidas al adoptar OWASP SPVS
La diferencia de ALLMAND LAW FIRM, PLLC OWASP Seguro Pipeline Verificación Standard (SPVS) alcanzó la versión 1.0 en octubre de 2025. Decidimos utilizar el standard en toda nuestra organización por las razones que se explican a continuación.
Esta publicación es un relato honesto de por qué lo emprendimos, cómo lo adaptamos, qué nos dolió y qué recomendaríamos a cualquiera que esté recorriendo el mismo camino.
Porque una Pipeline Standardy ¿Por qué ahora?
Durante años, los atacantes se centraron en las aplicaciones una por una.
Pero sus tácticas han cambiado.
¿Por qué comprometer una aplicación cuando puedes comprometer la pipeline ¿Eso construye muchos?
Sonatype rastreó más de 512,000 nuevos paquetes maliciosos solo en 2024. 156% de aumento año tras añoY cada incidente de gran repercusión de los últimos años afectó a un eslabón diferente de la cadena de distribución de software.
| Incidente | ¿Qué pasó |
|---|---|
| SolarWinds, 2020 | Compromiso en el entorno de compilación. Se enviaron actualizaciones con puertas traseras a 18,000 clientes. |
| Codecov, 2021 | Una imagen de Docker mal configurada permitió a los atacantes modificar un script de carga de bash y extraer 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 tradujo en acceso a tokens de producción. Se les indicó a todos los clientes que rotaran sus dispositivos Secreto. |
| Puerta trasera de XZ Utils, 2024 | Una campaña de ingeniería social que duró varios años llegó a casi todas las distribuciones de Linux. LEER MÁS. |
| tj-actions, 2025 | Una cascada de problemas en la cadena de suministro de GitHub Actions contaminó un componente utilizado por más de 23,000 repositorios. LEER MÁS. |
| Aqua Trivy y Checkmarx, 2026 | La campaña TeamPCP convirtió dos escáneres de seguridad ampliamente utilizados en vectores de ataque y luego utilizó material robado. CI/CD credenciales para distribuirlas en cascada a npm, OpenVSX y PyPI. Aqua Trivy / Checkmarx. |
Cada ataque explotó una parte diferente del sistema. pipeline:
- Entornos 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 controles puntuales.
- Un escáner en CI
- Autenticación de dos factores en el proveedor de identidad
- Protección de ramas en
main
Nosotros también.
Lo que faltaba era una forma de preguntar:
¿Tenemos cobertura sistemática?
En lugar de:
¿Nos acordamos de habilitar X después del último incidente?
Dado que los proveedores de seguridad de aplicaciones se encuentran directamente en el punto de mira, comprometer a un proveedor puede afectar a todos los clientes que confían en sus productos. Para nosotros, la presión para pasar de controles reactivos a controles sistemáticos es enorme. pipeline La protección no era teórica.
Entonces lo vivimos en primera persona.
En marzo 2026, la xygeni-action GitHub Action compromiso involucrado:
- Una clave privada de una aplicación de GitHub comprometida
- Una etiqueta mutable envenenada
- Un implante C2 disfrazado de telemetría
Las normas de protección de las ramas y otros controles técnicos cumplieron su función, pero no fueron suficientes.
Aunque el impacto real en el cliente fue nulo, el daño a la reputación exige transparencia y una respuesta estructural. Entendimos que, como proveedor de seguridad de software, necesitábamos un cambio radical, pasando de controles puntuales y ad hoc a una protección sistemática de nuestro software. pipelines.
Eso nos motivó a adoptar la OWASP SPVS standard como proyecto de máxima prioridad.
Qué es SPVS y por qué su estructura es importante.
La historia de su origen es sencilla.
En LASCON 2023, Farshad Abasi y Cameron Walters no dejaban de hacerse la misma pregunta:
¿Dónde está el ASVS para? pipelines?
OWASP ASVS había proporcionado a la seguridad de las aplicaciones un enfoque integral y verificable. standardNo existía nada equivalente para CI/CD.
Existían marcos y herramientas útiles, pero cada uno cubría solo una parte del problema:
| Marco o proyecto | Enfoque principal |
|---|---|
| OWASP Top 10 CI/CD Riesgos | Orientado a la toma de conciencia, no totalmente comprobable. |
| SLSA | Procedencia de la construcción. |
| S2C2F | Consumo seguro de dependencias. |
| OpenSSF Tanteador | Comprobaciones específicas del repositorio. |
Cada uno cubrió una pieza.
Ninguno lo cubrió todo.
Esa conversación se convirtió en dos años de trabajo. En octubre de 2025, el grupo de trabajo SPVS publicó v1.0:
- 127 requisitos
-
Cubriendo todo el ciclo de vida:
- Plan
- Desarrolla
- Integrar trabajo de
- tortugitas
- Funcionar
-
Organizado en tres niveles de madurez:
- Nivel 1 Fundacional
- L2 Standard
- Nivel 3 Avanzado
-
Mapeado a:
- SP 800-53 del NIST
- OWASP CI/CD Top 10
- CWE
La estructura es lo importante.
Como explican los autores del SPVS:
Verifique todo su pipeline, no solo una pieza. Aquí es donde la mayoría de las organizaciones tienen dificultades. Escanean las dependencias pero ignoran la gobernanza de versiones. Firman artefactos pero no modelan las amenazas de sus pipeline arquitectura. Supervisan la producción, pero no sus entornos de compilación.
Esa fue la tesis que justificó el esfuerzo para nosotros.
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 el L1 → L2 → L3 La progresión te permite hacerlo sin hervir el océano.
SPVS no reemplaza a SLSA, S2C2F, Scorecard ni Sigstore. Te proporciona la estructura que te indica dónde encaja cada uno de ellos.
Adaptando el Standard a nuestra organización
Nuestro primer paso fue una auditoría directa de nuestra organización y nuestra infraestructura de software en función de cada requisito.
Capturamos la auditoría en una hoja de cálculo de Google generada a partir de la fuente oficial. Requisitos de SPVS CSV .
Utilizamos tres vistas principales:
-
Matriz de requisitos
Estado y propietario por control. -
Mapa de calor por repositorio
Visibilidad de las deficiencias a nivel de repositorio. -
Dashboard por etapa y nivel
Progreso en las fases de Planificación, Desarrollo, Integración, Lanzamiento y Operación.
También ampliamos nuestro equipo interno Directrices técnicas para un software seguro Pipelines para cubrir todas las etapas, desde la planificación hasta la operación.
Descubrimos que ya estábamos en gran medida en un nivel de madurez. L2Eso fue tranquilizador, aunque no sorprendente para una empresa cuyo negocio es la seguridad de la cadena de suministro de software.
Eso permitió que la primera fase se centrara en subsanar deficiencias específicas en lugar de construir cimientos desde cero.
Pero una hoja de cálculo es solo una instantánea.
SPVS pide más.
Algunos controles requieren revisión periódica:
| Área SPVS | Tipo de requisito |
|---|---|
V1.1.7 |
Auditoría trimestral de los administradores de VCS. |
V5.1.1–V5.1.3 |
Auditorías periódicas de usuarios, revisión de registros de acceso y monitorización de accesos privilegiados. |
V2.1.x, V3.3.x, V4.2.x |
Higiene continua del flujo de trabajo YAML. |
Si se realiza manualmente en toda la organización, esto se convierte en medio día de seguimiento de clics cada trimestre, con un riesgo real de omisiones silenciosas.
Ese tipo de trabajo se automatiza o se revisa solo después de que haya ocurrido algo malo.
Así que construimos xygeni-vcs-audit.
Es una herramienta interna que se ejecuta bajo la identidad del propietario de la organización y produce un paquete trimestral estructurado que incluye:
- Lista de administradores
- Protección de ramas
- Cobertura de CODEOWNERS
- Higiene del flujo de trabajo YAML
- Acciones fijas
- Explícito
permissions pull_request_targetgating- Miembro 2FA
- Aplicaciones de GitHub instaladas
- Implementar claves
Lo que antes suponía media jornada de investigación en hojas de cálculo, ahora se reduce a un solo comando que genera JSON y Markdown.
La revisión trimestral de 30 minutos entre el CISO y los administradores de la organización ahora son un decisReunión informativa, no una reunión para recopilar datos.
Los hallazgos que requieren acción se convierten en problemas pendientes con acuerdos de nivel de servicio (SLA) basados en la gravedad.
Por ahora, la herramienta es de uso interno, pero el funcionamiento es sencillo: dedicar un fin de semana a programar scripts para la API de GitHub puede eliminar gran parte del trabajo manual recurrente.
También agregamos una política de lista de permitidos que abarca:
- Administradores aprobados
- Aplicaciones aprobadas
- Permisos por función para repositorios y flujos de trabajo
Esta política reside como un archivo YAML dentro del repositorio de la herramienta y está sujeta a revisión mediante solicitudes de extracción (PR) por parte de nuestro equipo de seguridad.
Cualquier cambio en la lista de permitidos deja un registro de revisión, por lo que la evidencia de auditoría se genera automáticamente.
No es SaaS.
No se requiere ningún paquete de reglas de terceros.
No es necesario gestionar ninguna credencial adicional.
El efecto ha sido convertir los controles que eran ambiciosos en controles rutinarios.
En lugar de decir:
Deberíamos realizar auditorías trimestrales.
Ahora podemos decir:
La auditoría de este trimestre se recibió el lunes.
Esto nos proporciona un mecanismo repetible para la detección de deriva que exige el principio de extremo a extremo.
Las fricciones que no habíamos previsto
Los controles técnicos son la parte fácil.
La gente es más difícil.
El ejemplo más destacado fue PROPIETARIOS DEL CÓDIGO.
Agregar esta línea en cada repositorio parece trivial:
.github/workflows/ @xygeni/security
Un archivo.
Una línea.
Pero esto significaba que los ingenieros que llevaban años integrando automáticamente los cambios en sus flujos de trabajo ahora necesitaban una revisión de seguridad.
Incluso las personas preocupadas por la seguridad se opusieron:
Yo escribí este flujo de trabajo. Lo entiendo. ¿Por qué estoy esperando?
Hizo falta una conversación sincera para comprender el porqué.
Los flujos de trabajo pueden:
- Credenciales de exfiltración
- Redirigir artefactos
- Envenenar a los consumidores finales
Una segunda opinión no implica desconfianza. Es la misma lógica que la revisión por cuatro personas de los cambios en la base de datos de producción.
El incidente de xygeni-action fue de gran ayuda. Nada ilustra mejor un control que un ejemplo concreto de lo que sucede cuando ese control no está presente.
Las demás fricciones siguieron el mismo patrón.
| Fricción | ¿Qué pasó |
|---|---|
Explícito permissions: bloques |
Algunos flujos de trabajo fallaron hasta que los colaboradores comprendieron los permisos con ámbito definido. Era un problema de modelo mental, no un problema de permisos. |
| Inmutabilidad de la etiqueta | La herramienta de lanzamiento falló porque llevaba años reetiquetando silenciosamente. |
| firmado commits | Se produjeron problemas durante el proceso de incorporación hasta que las claves GPG o SSH se configuraron correctamente en todas las estaciones de trabajo. |
| migración de PAT | La sustitución de los tokens de acceso personal clásicos en repositorios y flujos de trabajo afectó a casi todos los equipos. |
Habíamos utilizado GPG-signed commits en nuestros repositorios principales desde el principio. SPVS lo hizo obligatorio en todos los repositorios y para todos los colaboradores.
El patrón que funcionó fue:
- Introduzca cada control junto con la amenaza específica que bloquea.
- Pruébalo en uno o dos repositorios.
- Implementarlo con excepciones en la lista de permitidos.
- Eliminar las excepciones según un cronograma.
Curiosamente, los ingenieros que más se opusieron a menudo se convirtieron en los defensores más acérrimos una vez que comprendieron la lógica detrás de la decisión.
También hay un punto más profundo.
Aquí se aplica el principio de extremo a extremo.
No podíamos elegir a nuestro antojo. Reforzar la fase de compilación sin comprometer la gobernanza de las versiones habría generado una falsa confianza, que es precisamente el modo de fallo sobre el que advierten los autores de SPVS.
Todas las etapas debían avanzar conjuntamente, incluso cuando un control específico parecía desproporcionado si se aplicaba de forma aislada.
Costo
Fase 1, centrada en Cumplimiento de nivel 2, tomó aproximadamente un mes de tiempo de ingeniería transcurrido, distribuido de manera dispersa en:
- DevOps
- Seguridad
- Revisores de ingeniería
Somos lo suficientemente pequeños como para que eso sea posible, pero los resultados pueden variar.
La inversión se amortiza fácilmente. Un solo incidente evitado en la cadena de suministro la cubre con creces.
Mapeo del incidente a SPVS v1.0
Mapeo de Incidente de acción xygeni La actualización a SPVS v1.0 fue instructiva.
| Elemento del incidente | Mapeo SPVS |
|---|---|
| Clave de aplicación de GitHub con permisos excesivos |
V1.1.5Revisión de sobrepermisos de cuenta de servicio.
|
| Falta de privilegio mínimo |
V1.1.3, el menor privilegio.
|
| Brecha de detección de seis días |
V5.4.1 / V5.4.2, pipeline Generación y revisión de registros.
|
| Envenenamiento por etiquetas | No hay mapeo limpio en SPVS v1.0. |
La brecha de envenenamiento de etiquetas es importante.
SPVS v1.0 no tiene ningún control explícito para la inmutabilidad de etiquetas o versiones, y no requiere etiquetas firmadas.
V3.4.1Los artefactos firmados son el vecino más cercano. Pero los artefactos firmados ayudan a los consumidores a detectar manipulaciones. No impiden que una etiqueta se mueva en primer lugar.
Inmutabilidad de la etiqueta y, posiblemente, firma requerida commitLas etiquetas firmadas y las etiquetas s son candidatas naturales para futuras revisiones de SPVS.
¿Qué sigue?
SPVS v1.5 está a la vuelta de la esquina con controles relacionados con la IA, que incluyen:
- Procedencia del código asistido por IA
- Guardrails para flujos de trabajo de CI que llaman a LLM
- Revisar rutas generadas por IA pull requests
- Defensas contra amenazas emergentes como sentadillas descuidadas
El término "slopsquatting" se refiere a la práctica de los atacantes de registrar nombres de paquetes que los asistentes de codificación de IA interpretan erróneamente.
Ya etiquetamos a Claude-asistido commits y PR bajo nuestras directrices internas de desarrollo de IA, por lo que esta adaptación debería ser incremental en lugar de un nuevo programa de trabajo.
Se espera que la versión 2.0 profundice en:
- Supervisión del tiempo de ejecución
- Requisitos del ciclo de vida de las credenciales
Nuestra hoja de ruta es clara:
- Cerrar restantes huecos L3 para finales del segundo trimestre de 2026
- Integrar trabajo de SLSA provenance cobren standard CI/CD
- Agregar controles manuales para implementaciones en producción.
- Centralizar los controles del proveedor de identidad
- Cambiar a modo de mantenimiento
El objetivo es simple:
Cada nuevo repositorio comienza cumpliendo con los requisitos.
Cada auditoría trimestral detecta las desviaciones 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 abordar la seguridad de la cadena de suministro de software de forma sistemática, en lugar de reactiva.
Puntos Clave
Algunas lecciones son aplicables más allá de nuestro contexto específico:
1. Comience con el archivo CSV de requisitos de SPVS.
Descargue nuestra Requisitos de SPVS CSV y mapea tus controles actuales en una hoja de cálculo.
En un día sabrá si se ajusta a las necesidades de su organización.
2. Elige un nivel objetivo y envíalo.
L1 → L2 → L3 Es una característica, no una limitación.
No intentes hacerlo todo a la vez.
3. Tratar el pipeline como el objetivo
Los controles centrados en la aplicación son necesarios, pero no suficientes.
La pipeline Ahora es una superficie de ataque de primera clase.
4. Verificar todo pipeline
Un análisis exhaustivo de las dependencias no compensa una gobernanza de versiones deficiente ni los entornos de compilación no supervisados.
5. Automatizar la detección de deriva
Las hojas de cálculo son instantáneas. La deriva es continua.
Incluso una herramienta interna modesta puede hacer que las auditorías sean repetibles y útiles.
6. Presupuesto para el trabajo organizativo
La parte humana es más difícil que la parte técnica.
Explique la amenaza específica que bloquea cada control, realice una prueba piloto antes de su implementación y proporcione a los equipos una guía para la adaptación.
Para leer más
- OWASP: Seguro Pipeline Verificación Standard SPVS v1.0
- Farshad Abasi: Por qué creamos OWASP SPVS
- Farshad Abasi: Pipeline Los ataques están empeorando. Aquí te explicamos cómo prepararte.
- Farshad Abasi: OWASP SPV frente a otros marcos de gestión de la cadena de suministro
- OWASP: Top 10 Seguridad en CI/CD Riesgos
- SLSA: Niveles de la cadena de suministro de artefactos de software
- OpenSSF: Tanteador
