Herramientas de seguridad de CI/CD, comparadas

Cada comparativa explica lo que el otro producto hace bien, en qué se diferencia CRACI y cuándo usaría ambos. Para todas las categorías, consulte todas las comparativas.

Por qué el pipeline necesita sus propias herramientas de seguridad

Un pipeline de CI/CD guarda credenciales, descarga código de internet y produce los artefactos que ejecutan sus clientes. Eso lo convierte en un objetivo por sí mismo. Un atacante que pueda cambiar lo que descarga un build, o lo que produce, no necesita tocar su código fuente. Los escáneres de código no se crearon para eso, porque leen el repositorio, no el build.

Las herramientas de seguridad de CI/CD cierran esa brecha desde distintas direcciones. Unas comprueban cómo está configurado el pipeline, otras vigilan lo que ocurre en el runner mientras se ejecuta un job, y otras controlan el propio runner. Saber a qué grupo pertenece una herramienta dice más que su lista de funcionalidades, porque decide qué puede ver y qué puede detener.

Tipos de herramientas de seguridad de CI/CD

Escáneres que leen su código

El análisis estático (SAST), el escaneo de secretos y el análisis de composición de software (SCA) leen el repositorio: archivos fuente, manifiestos y lockfiles. GitHub Advanced Security, por ejemplo, combina el code scanning de CodeQL con el escaneo de secretos y la push protection, y las alertas de Dependabot a partir de GitHub Advisory Database. Estas herramientas encuentran problemas antes de que se ejecute un build. No ven lo que el build descargó realmente ni a dónde se conectó.

Herramientas que refuerzan el pipeline en torno al build

Las herramientas de postura y gobernanza comprueban la configuración del pipeline. Cycode monitoriza las políticas de seguridad, las configuraciones y la gobernanza de CI/CD. StepSecurity mantiene un inventario de las acciones de terceros que usted utiliza, con workflows de aprobación para las nuevas, y abre pull requests que fijan las acciones a SHA de commit y establecen permisos de mínimo privilegio para GITHUB_TOKEN. Estas herramientas hacen que el pipeline sea más difícil de usar indebidamente, pero trabajan sobre la definición del build y no sobre el build mientras se ejecuta.

Agentes que vigilan el runner

Los agentes de runtime se ejecutan dentro del job en los runners que usted conserva. StepSecurity Harden-Runner monitoriza las conexiones salientes, los procesos y las escrituras de archivos, vincula cada uno al paso del workflow que lo causó y puede bloquear el egress fuera de una lista de permitidos. Cimon de Cycode monitoriza la ejecución de procesos, el egress de red y el acceso a archivos a nivel de kernel con eBPF, produce una SBOM observada en runtime y firma procedencia SLSA. Los agentes funcionan en muchos sistemas de CI y en runners alojados, porque se añaden a una infraestructura que ya existe.

Runners que controlan y registran el build

CRACI adopta el último enfoque: sustituye el runner. Los jobs se ejecutan en CRACI con runs-on: craci, y las ejecuciones siguen apareciendo en GitHub. La política de egress forma parte del runner, se valida antes de que empiece el job y, si falla, bloquea. Un proxy que entiende de paquetes registra cada paquete que descargó el job, incluidos los restaurados desde cachés de CI, de modo que cada job produce una SBOM con un estado de completitud, una traza de red y datos de procedencia.

Comparación directa

«No indicado» significa que no hemos podido confirmarlo en las páginas públicas del proveedor. Para ver el detalle de cada columna, consulte CRACI frente a StepSecurity, CRACI frente a Cycode y CRACI frente a GitHub Advanced Security.

Qué herramienta cubre cada riesgo de CI/CD

El OWASP Top 10 CI/CD Security Risks es la lista más utilizada de lo que puede fallar en un pipeline. Sus diez riesgos son:

1. CICD-SEC-1: Insufficient Flow Control Mechanisms
2. CICD-SEC-2: Inadequate Identity and Access Management
3. CICD-SEC-3: Dependency Chain Abuse
4. CICD-SEC-4: Poisoned Pipeline Execution (PPE)
5. CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)
6. CICD-SEC-6: Insufficient Credential Hygiene
7. CICD-SEC-7: Insecure System Configuration
8. CICD-SEC-8: Ungoverned Usage of 3rd Party Services
9. CICD-SEC-9: Improper Artifact Integrity Validation
10. CICD-SEC-10: Insufficient Logging and Visibility

Ninguna herramienta cubre por sí sola los diez. Estos son los cuatro en los que se aplican los controles de CRACI:

En CICD-SEC-7, CRACI cubre el runner. La configuración de sus repositorios y de su organización de GitHub sigue siendo responsabilidad suya. Para ser claros con el resto: CRACI no aborda la gestión de identidades y accesos (CICD-SEC-2) ni la higiene de credenciales (CICD-SEC-6), y no gobierna el control de flujo, los permisos del pipeline ni los servicios de terceros (CICD-SEC-1, 5 y 8). El escaneo de secretos, como Secret Protection de GitHub o la detección de secretos de Cycode, y las herramientas de postura anteriores están pensados para eso.

Cómo elegir una herramienta de seguridad de CI/CD

• Sustituir sus runners o conservarlos. Si quiere conservar los runners alojados por GitHub, los runners autoalojados u otro sistema de CI, un agente es la forma de añadir controles de runtime. Si está dispuesto a cambiar el runner, un runner como CRACI aporta control de egress y un registro del build sin ningún agente que desplegar.
• Modo de auditoría hoy. Harden-Runner y Cimon pueden observar el tráfico antes de bloquear nada. El modo de monitorización o dry-run de CRACI está en su hoja de ruta.
• Análisis forense a nivel de proceso. Si durante un incidente necesita saber qué proceso escribió qué archivo, eso lo cubre un agente que monitorice procesos y archivos. CRACI no monitoriza procesos ni escrituras de archivos.
• SBOM y evidencia para el CRA. Si necesita una SBOM a nivel de paquete de cada build, procedencia y evidencia para el Cyber Resilience Act, fíjese en qué registra cada herramienta y si sigue monitorizando lo que se distribuyó. CRACI registra la SBOM mientras se ejecuta el build, reevalúa las SBOM monitorizadas a medida que aparecen nuevas vulnerabilidades y exporta las SBOM en CycloneDX o SPDX.
• Plataformas de CI y sistemas operativos. CRACI es compatible hoy con GitHub Actions, con GitLab CI y Jenkins en la hoja de ruta, y ejecuta Linux en x86-64 y ARM64, con Windows y macOS en la hoja de ruta. Si compila en otros sistemas de CI o necesita runners Windows o macOS ahora, compruebe primero la cobertura de los agentes.
• Código y secretos. Los escáneres de código fuente y secretos cubren un terreno que ningún runner cubre. CRACI no tiene SAST ni escaneo de secretos, así que planifíquelos por separado.

Un agente en el runner frente a ser el runner

Un agente se añade a una infraestructura que ha diseñado otro. En los runners alojados por GitHub lo instala un paso al inicio de cada job, y su alcance depende de lo que esa infraestructura permita. Eso es lo que permite a los agentes cubrir a la vez runners alojados, flotas autoalojadas y varios sistemas de CI, y es una ventaja real cuando sus builds están repartidos entre todos ellos.

Un runner que aplica la política por sí mismo funciona al revés. En CRACI, la política de egress se valida antes de que empiece el job, rechaza los campos desconocidos y, si falla, bloquea, de modo que una política que no se puede aplicar no produce una ejecución sin protección. Sus fuentes están tipadas por ecosistema, con 24 presets de fuentes de software integrados y fuentes personalizadas para npm, PyPI, apt, apk, el proxy de Go, Nix, Cargo, registros OCI y Git, de modo que el registro es de paquetes, no solo de hosts. En los jobs que se ejecutan en CRACI, sustituye a los agentes de runtime en lugar de ejecutarse junto a ellos. Lea más sobre la integración con CI/CD y la generación de SBOM durante el build, o reserve una demo para ver un job de GitHub Actions ejecutándose bajo una política de egress.

CRACI comparado con cada herramienta

• CRACI frente a StepSecurity Un agente en su runner frente a ser el runner.

Lado a lado

Varias herramientas en una página, para cuando elige una categoría y no un producto concreto.

• Comparativa de Herramientas de seguridad de la cadena de suministro de software Apiiro, Cycode, OX, Legit, Socket, Chainguard, StepSecurity y más.

Otras categorías

• Plataformas de CI/CD y runners
• Análisis de composición de software
• Seguridad de la cadena de suministro de software
• Gestión de SBOM
• Cumplimiento del CRA
• Seguridad embebida y de producto
• PSIRT y seguridad de producto
• Código abierto y soluciones propias
• IA y seguridad