CRACI frente a NetRise

La respuesta corta

NetRise es una empresa de análisis de binarios. Su producto Turbine analiza firmware, imágenes de contenedor y binarios de aplicaciones para producir una SBOM a partir del código compilado y encontrar riesgos en él, incluidas vulnerabilidades, secretos expuestos, errores de configuración y criptografía. Dragos anunció el 21 de septiembre de 2026 que había adquirido NetRise. CRACI es un runner de GitHub Actions que registra lo que incorpora cada build mientras se ejecuta, genera la SBOM a partir de ese registro y la monitoriza tras el lanzamiento. NetRise analiza la salida, incluido el software que usted no compiló; CRACI conserva evidencia de los builds que usted ejecuta. Para un PSIRT, ambos cubren terrenos distintos.

De un vistazo

Lo que NetRise hace bien

SBOM a partir del código compilado. NetRise Turbine produce "a complete, binary-derived SBOM from the software itself", incluidas las dependencias enlazadas estáticamente y embebidas. Cubre firmware, imágenes de contenedor y binarios de aplicaciones, hasta llegar a kernels, RTOS, controladores y firmware por debajo de la capa de aplicación. Es la forma de ver el interior del software de fabricantes de chips, proveedores de módulos y otros proveedores cuyos builds usted nunca ve.

Riesgos que un escaneo de CVE no muestra. Turbine informa de secretos, claves públicas y privadas, certificados y errores de configuración que se distribuyen dentro del artefacto, además de problemas de licencia y un inventario criptográfico para la preparación poscuántica. NetRise ZeroLens busca debilidades en el software compilado antes de que se exploten.

Priorización. Turbine comprueba si una ruta de ejecución rastreable conecta un punto de entrada en ejecución con un componente vulnerable, y muestra señales de explotabilidad como el estado en CISA KEV. NetRise afirma que la plataforma consulta continuamente la NVD, el catálogo CISA KEV, grupos de actores de amenazas y botnets para conocer la explotabilidad.

SBOM de proveedores e integraciones. NetRise admite la importación, el enriquecimiento, la normalización y la exportación de SPDX y CycloneDX, de modo que se pueden combinar SBOM de varias fuentes. Ofrece una API GraphQL para CI/CD y enumera integraciones con Jira, ServiceNow, Splunk, Armis, Brinqa, Nucleus Security, GitHub y Google Cloud.

Procedencia del código abierto. NetRise Provenance examina el origen, los mantenedores y la salud del repositorio de los componentes de código abierto, y bloquea los paquetes maliciosos y los que infringen las políticas allí donde los desarrolladores los descargan, incluidos el CI/CD y los asistentes de programación con IA.

Ahora forma parte de Dragos. El anuncio de Dragos dice que NetRise añade visibilidad del firmware y el software que se ejecutan en dispositivos de tecnología operativa, y que la dirección de NetRise lo integrará en la Dragos Platform mientras sigue atendiendo a los clientes existentes. No se revelaron las condiciones financieras.

En qué se diferencia CRACI

Un análisis de binarios trabaja hacia atrás desde lo distribuido. CRACI trabaja hacia delante desde el build, porque el build se ejecuta en CRACI.

El build es la fuente de verdad

Su workflow se ejecuta en los runners de CRACI con un cambio de una línea en runs-on. Mientras se ejecuta un job, un proxy que entiende de paquetes registra lo que descarga de las fuentes de paquetes, y los paquetes restaurados desde cachés de CI se arrastran al registro. Cada SBOM indica cuán completa es, por job y por caché: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. Para Yocto, CRACI ejecuta BitBake en runners de hasta 32 vCPU y 96 GB de RAM. En un build comparado de core-image-sato, la SBOM de CRACI contenía todos los componentes de la salida SPDX propia de Yocto, 88 más, como paquetes del host y GitHub Actions, y una package URL para cada una de las 653 versiones de crates de Rust que Yocto enumera sin ella.

Control sobre lo que el build puede alcanzar

Una política de egress en el runner decide a qué hosts puede conectarse un job. Se valida antes de que empiece el job, bloquea si falla y envía una alerta ante una infracción. Un escaneo de la salida no puede cambiar lo que el build pudo alcanzar.

De un CVE a los productos afectados

CRACI agrega las vulnerabilidades de todos los builds y repositorios y sigue reevaluando las SBOM monitorizadas a medida que aparecen avisos. El historial de builds muestra qué builds contenían una dependencia vulnerable, directa o transitiva, para que usted sepa durante qué periodo estuvo afectado, y la vista de inventario muestra exactamente qué versiones de software están desplegadas en qué productos. Los equipos de seguridad hacen el triaje de los hallazgos y envían cada uno al equipo responsable de la corrección, se admite VEX y los controles de política pueden bloquear un build que contenga un CVE concreto. La API devuelve SBOM, trazas de red y procedencia.

Lo que CRACI no hace importa tanto como lo que hace. No analiza binarios, así que no puede ver el interior de un firmware que usted no compiló ni de un blob de proveedor que su build descargue, solo que el build lo descargó y de dónde. Puede añadir SBOM de proveedores para que se monitoricen sus componentes, pero sin una SBOM necesita una herramienta de análisis de binarios como NetRise. CRACI no ofrece análisis de alcanzabilidad y no busca secretos ni errores de configuración en la salida.

Lo que un PSIRT necesita de cada uno

Un equipo de respuesta a incidentes de seguridad de producto tiene que saber qué se distribuye en cada producto, incluido el firmware de terceros, encontrar los productos afectados cuando aparece una vulnerabilidad, seguir monitorizando tras el lanzamiento, hacer el triaje de los hallazgos e indicar qué productos no están afectados, a menudo con VEX.

• Firmware y binarios de terceros que usted recibe. NetRise. El análisis de binarios es la única forma de ver su interior cuando el proveedor no envía una SBOM.
• Firmware y software que usted compila en GitHub Actions. CRACI registra cada build mientras se ejecuta y conserva el historial de qué builds contenían un componente.
• Priorizar una larga lista de hallazgos. Las señales de alcanzabilidad y explotabilidad de NetRise. CRACI muestra que un paquete vulnerable estaba en el build, no si su código lo invoca.
• Enviar un hallazgo al equipo responsable de la corrección. El triaje y el envío de CRACI funcionan sobre los builds que registra; NetRise se conecta a Jira y ServiceNow.

Consulte CRACI para equipos PSIRT y la comparativa de herramientas para PSIRT.

Cuándo usar cada uno y cuándo usar los dos

• La mayor parte de lo que distribuye procede de proveedores. NetRise. Analiza tanto el software que usted compra como el que compila.
• Compila su propia imagen de Linux o sus aplicaciones en GitHub Actions. CRACI ejecuta el build y registra sus entradas. Analizar la misma imagen en NetRise aporta una segunda visión independiente de lo distribuido.
• Gestiona flotas de tecnología operativa. NetRise, ahora dentro de Dragos, se dirige al firmware y al software que se ejecutan en esos dispositivos. CRACI es para equipos que desarrollan el software.
• Quiere limitar lo que pueden descargar los builds. CRACI. Ese control solo existe donde se ejecuta el build.

Para el CRA

El Cyber Resilience Act pide a los fabricantes que documenten los componentes de sus productos, incluida una SBOM, que gestionen las vulnerabilidades durante el periodo de soporte y que, desde el 11 de septiembre de 2026, notifiquen las vulnerabilidades explotadas activamente. NetRise aborda el CRA con SBOM de versiones generadas a partir del artefacto compilado, gestión de vulnerabilidades y verificación de parches entre versiones, y salidas de informes para la evidencia de conformidad. CRACI produce evidencia por build de lo que entró en el software que usted compila, la monitoriza y presenta las notificaciones del CRA en su nombre. CRACI automatiza una parte importante de la visibilidad y la evidencia de la cadena de suministro de software que los fabricantes necesitan para su proceso más amplio de cumplimiento del CRA; por sí solo no hace que un producto cumpla. Lea qué exige el CRA.

Añadir CRACI junto a NetRise

No hace falta sacar nada de NetRise. Traslade el job de build a un runner de CRACI con runs-on: craci, y el mismo workflow seguirá ejecutándose en GitHub Actions mientras CRACI registra el build. El ejemplo de Yocto en la documentación de CRACI muestra un workflow completo de BitBake. CRACI solo es compatible hoy con GitHub Actions, con GitLab CI y Jenkins en la hoja de ruta. Vea cómo funciona CRACI para el IoT industrial.

¿Valora más de dos herramientas? Alternativas a NetRise compara siete opciones una junto a otra.