StepSecurity frente a CRACI

La respuesta corta

StepSecurity es una plataforma de seguridad de la cadena de suministro de software que cubre cuatro puntos de control: máquinas de desarrollo, registros de paquetes, repositorios de código y CI/CD. Su producto de CI/CD, Harden-Runner, es un agente que vigila cada conexión saliente, proceso y escritura de archivos de un job, vincula cada uno al paso del workflow que lo causó y puede bloquear el egress hacia todo lo que no esté en una lista de permitidos. Enterprise cuesta $16 por desarrollador colaborador al mes, y los repositorios públicos en runners alojados por GitHub son gratuitos.

CRACI sustituye el propio runner: su política de egress la aplica la plataforma del runner y se valida antes de que empiece el job, y ese mismo job produce una SBOM a nivel de paquete. Este es el solapamiento más cercano de CRACI con un proveedor de seguridad, porque ambos restringen a qué puede acceder un build. La diferencia está en dónde reside el control. Harden-Runner protege los runners que usted conserva, incluidos los alojados por GitHub. La política de CRACI viene incluida por ser el runner, y registra paquetes en lugar de solo destinos.

De un vistazo

«No indicado» significa que no hemos podido confirmarlo en las páginas públicas de StepSecurity.

Lo que StepSecurity hace bien

Harden-Runner

• Visibilidad a nivel de paso. Cada conexión saliente, operación de archivos y ejecución de procesos se asocia al paso, job y workflow exactos en los que ocurrió. El nivel Enterprise añade los argumentos de los procesos, las rutas de escritura de archivos y alertas por correo electrónico, Slack, Microsoft Teams o su SIEM.
• Primero auditar, luego bloquear. En el modo egress-policy: audit, Harden-Runner crea una línea base de las llamadas salientes normales de cada job y señala cualquier novedad. Después puede pasar al modo de bloqueo con una lista de endpoints permitidos. Una lista global de bloqueo de dominios maliciosos conocidos, mantenida por StepSecurity, se aplica incluso en el modo de auditoría.
• Detección de manipulaciones. Alerta de cambios inesperados en el código fuente durante el build.
• Amplia cobertura. Compatibilidad completa en runners Linux alojados por GitHub, modo de auditoría en Windows y macOS alojados por GitHub y, en el nivel Enterprise, máquinas virtuales autoalojadas, bare metal y Actions Runner Controller. StepSecurity también indica GitLab CI, Azure DevOps y runners de terceros como Blacksmith, Depot y Namespace. En los runners autoalojados, el agente se integra en la imagen del runner, así que los workflows no necesitan cambios.
• Trayectoria. StepSecurity afirma que Harden-Runner detectó la vulneración de tj-actions/changed-files (CVE-2025-30066) y el paquete npm comprometido axios, y que protege más de 25 millones de ejecuciones de workflows a la semana. El agente del nivel Community es de código abierto con licencia Apache 2.0.

Dónde funciona Harden-Runner

La matriz de compatibilidad de StepSecurity para GitHub Actions, a septiembre de 2026:

No es compatible cuando un job completo se ejecuta en un contenedor en runners alojados por GitHub, ni en ubuntu-slim. En Actions Runner Controller, solo se admiten jobs de Linux.

El resto de la plataforma

• Gobernanza de Actions: un inventario de las acciones de terceros y los workflows reutilizables que utiliza, workflows de aprobación para los nuevos, y StepSecurity Maintained Actions como sustitutos directos revisados.
• Secure Registry: periodos de espera para las nuevas versiones de paquetes, bloqueo de versiones conocidas como comprometidas, protección contra typosquatting y listas de bloqueo para toda la organización, con una sola política para portátiles y CI.
• Code Repo Security: comprobaciones de pull requests y Orchestrate Security, que abre pull requests que fijan las acciones a SHA de commit, establecen permisos de mínimo privilegio para GITHUB_TOKEN y despliegan configuraciones de Dependabot.
• Dev Machine Guard: un inventario de agentes de programación con IA, servidores MCP, extensiones de IDE y paquetes en las máquinas de desarrollo.

En qué se diferencia CRACI

Ser el runner, no un agente en él

En los runners alojados por GitHub, Harden-Runner lo instala un paso que usted añade como primer paso de cada job, y su alcance depende de lo que permita la infraestructura de GitHub. Nada de esto es un defecto del producto; es consecuencia de ejecutarse en una infraestructura ajena.

La política de CRACI forma parte del runner. 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. Las ejecuciones siguen apareciendo en GitHub, y mover un job consiste en cambiar su etiqueta runs-on.

Paquetes, no solo destinos

La lista de permitidos de Harden-Runner es una lista de endpoints, y sus datos de red muestran con qué hosts contactó cada paso. Las fuentes de CRACI están tipadas por ecosistema, con 24 presets de fuentes de software integrados, fuentes personalizadas para npm, PyPI, apt, apk, el proxy de Go, Nix, Cargo, registros OCI y Git sobre HTTPS y SSH, y reglas explícitas de TLS, TCP, UDP e ICMP. Un proxy que entiende de paquetes registra qué paquetes descargó cada job, incluidos los restaurados desde cachés de CI, y produce una SBOM en CycloneDX o SPDX con un estado de completitud por job y por caché.

Después del build

• Los datos de procedencia se obtienen de la API junto con las SBOM y las trazas de red. CRACI no firma la procedencia y no reivindica ningún nivel SLSA.
• La monitorización reevalúa las SBOM de lo que usted distribuyó a medida que aparecen nuevas vulnerabilidades, y los equipos de seguridad hacen el triaje de los hallazgos y los envían a los equipos responsables de la corrección.
• El inventario muestra exactamente qué versiones de software están desplegadas en qué productos, a escala global, de modo que una nueva vulnerabilidad se asocia directamente a los productos que ejecutan la versión afectada.

Precio

A septiembre de 2026, el nivel Community de StepSecurity es gratuito para repositorios públicos ilimitados en runners alojados por GitHub. El nivel Enterprise cuesta $16 al mes por desarrollador colaborador, es decir, cualquiera que haya contribuido a un repositorio protegido en los últimos 90 días, e incluye Dev Machine Guard y Secure Registry. Dev Machine Guard por sí solo cuesta $8 por dispositivo al mes. Los repositorios privados y los runners autoalojados necesitan Enterprise, ambos niveles de pago tienen una prueba gratuita de 14 días y StepSecurity ofrece descuentos por volumen. Harden-Runner protege runners que usted ya paga, así que los minutos de runner son un coste aparte.

CRACI solo cobra por los minutos de build: $0.002 por vCPU-minuto ($0.004 para un runner de 2 vCPU por defecto), medido por segundo, sin cuota mensual. Como CRACI es el runner, ese precio cubre tanto la capacidad de cómputo como la evidencia. Consulte los precios de CRACI para ver las condiciones actuales.

Cuál encaja mejor

StepSecurity encaja mejor cuando

• Quiere conservar los runners alojados por GitHub, incluidos Windows y macOS.
• Utiliza runners autoalojados, GitLab CI o Azure DevOps.
• Quiere observar el tráfico en modo de auditoría antes de bloquear nada.
• Necesita visibilidad de procesos y archivos para la respuesta a incidentes.
• Su proyecto de código abierto se ejecuta en runners alojados por GitHub y necesita una opción gratuita.

CRACI encaja mejor cuando

• Quiere el runner y la política de egress en un solo lugar, sin ningún agente que desplegar.
• Necesita una SBOM a nivel de paquete de cada build, con un estado de completitud.
• Quiere monitorizar lo que se distribuyó.
• Necesita evidencia para el CRA, o residencia de datos en la UE con el plan Enterprise de CRACI.

A qué renuncia al mover jobs a CRACI

Para ser claros: CRACI aún no tiene modo de auditoría ni de monitorización (está en la hoja de ruta), no monitoriza procesos ni escrituras de archivos, aún no funciona en runners alojados por GitHub ni en otros sistemas de CI (GitLab CI y Jenkins están en la hoja de ruta), las listas de bloqueo de paquetes solo están en su hoja de ruta, y sus alertas cubren únicamente las infracciones de política, sin integración con Slack, Teams ni SIEM. Si esas son sus prioridades, StepSecurity las cubre hoy.

Secure Registry, Code Repo Security y Dev Machine Guard de StepSecurity protegen puntos que CRACI no toca: el registro del que proceden sus paquetes, sus repositorios y los portátiles de desarrollo. No dependen del runner, así que no les afecta dónde se ejecuten sus jobs.

Para el Cyber Resilience Act

El Cyber Resilience Act pide a los fabricantes que conozcan los componentes de sus productos, gestionen sus vulnerabilidades y conserven evidencia. StepSecurity se centra en prevenir y detectar ataques a la cadena de suministro, y sus datos de runtime ayudan cuando se investiga un incidente en el CI. CRACI automatiza una parte importante de la visibilidad y la evidencia de la cadena de suministro de software que las empresas necesitan para su proceso más amplio de cumplimiento del CRA: SBOM generadas durante el build y exportadas en CycloneDX o SPDX, seguimiento de vulnerabilidades y procedencia a través de la API. Consulte la evidencia para el CRA.

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 ejecutándose bajo una política de egress en CRACI.

Preguntas sobre StepSecurity

¿Qué es StepSecurity?

StepSecurity es una plataforma de seguridad de la cadena de suministro de software. Su producto más conocido, Harden-Runner, es un agente que monitoriza el egress de red, la integridad de archivos y la actividad de procesos en los runners de CI/CD y puede bloquear el egress fuera de una lista de permitidos. La plataforma también cubre registros de paquetes (Secure Registry), repositorios de código (Code Repo Security), máquinas de desarrollo (Dev Machine Guard) e inteligencia de amenazas.

¿Cuánto cuesta StepSecurity?

A septiembre de 2026, el nivel Community es gratuito para repositorios públicos ilimitados. Enterprise cuesta $16 por desarrollador colaborador al mes, entendiendo por desarrollador colaborador a cualquiera que haya contribuido a un repositorio protegido en los últimos 90 días, e incluye Dev Machine Guard y Secure Registry. Dev Machine Guard por sí solo cuesta $8 por dispositivo al mes. Ambos niveles de pago tienen una prueba gratuita de 14 días, y los minutos de runner son un coste aparte.

¿Harden-Runner es gratuito?

Sí, para repositorios públicos en runners alojados por GitHub. Los repositorios privados y los runners autoalojados, incluidos los runners autoalojados de repositorios públicos, necesitan el nivel Enterprise. El agente del nivel Community es de código abierto con licencia Apache 2.0.

¿Qué runners admite Harden-Runner?

Runners Linux alojados por GitHub en modo de auditoría y de bloqueo, runners Windows y macOS alojados por GitHub en modo de auditoría y, en Enterprise, máquinas virtuales autoalojadas, bare metal y Actions Runner Controller. StepSecurity también indica GitLab CI, Azure DevOps y runners de terceros como Blacksmith, Depot y Namespace. No es compatible cuando un job completo se ejecuta en un contenedor en runners alojados por GitHub, ni en ubuntu-slim.

¿Cuál es la diferencia entre StepSecurity y CRACI?

Harden-Runner es un agente que usted añade a los runners que conserva. CRACI es el runner: su política de egress la aplica la plataforma del runner, se valida antes de que empiece el job y, si falla, bloquea, y cada job produce además una SBOM a nivel de paquete con un estado de completitud. StepSecurity va por delante en modo de auditoría, monitorización de procesos y archivos, y cobertura de runners y CI.

¿Puede CRACI sustituir a Harden-Runner?

Para jobs de GitHub Actions en Linux, sí: mover un job a CRACI le da control de egress desde el propio runner, de modo que ese job no necesita ningún agente. Renuncia al modo de auditoría (en la hoja de ruta de CRACI), a la monitorización de procesos y archivos, y a la cobertura de runners alojados por GitHub, de Windows, de macOS y de runners ajenos a GitHub.

¿StepSecurity genera una SBOM?

Harden-Runner registra los destinos, procesos y archivos con los que interactuó un job, no una SBOM del build a nivel de paquete. CRACI registra qué paquetes descargó cada job, incluidos los restaurados desde cachés de CI, y exporta CycloneDX y SPDX.