Para equipos PSIRT
CRACI para equipos PSIRT y responsables de seguridad de producto
La primera pregunta de cada caso de PSIRT es cuáles de nuestros productos y versiones contienen el componente vulnerable. CRACI la responde a partir de un registro de lo que realmente descargó cada build, y sigue respondiéndola a medida que se publican nuevos CVE.
Actualizado el
El problema de un responsable de PSIRT
Un responsable de seguridad de producto debe rendir cuentas de respuestas que el PSIRT no genera por sí solo. Cuando aparece un CVE en una biblioteca muy utilizada, los clientes, los directivos y, cada vez más, los reguladores hacen las mismas preguntas en cuestión de horas: ¿estamos afectados, en qué productos y versiones, desde cuándo y cuándo se corregirá?
Las respuestas dependen del inventario, y el inventario suele venir de escáneres que leen lockfiles o manifiestos a posteriori. Estos enumeran dependencias de desarrollo que nunca se distribuyen y pasan por alto paquetes que el build descargó de alguna otra forma. Así que el PSIRT pide a los equipos de ingeniería que lo comprueben a mano, y la respuesta llega en días, con salvedades.
El FIRST PSIRT Services Framework considera que un inventario de componentes del producto es esencial para identificar rápidamente los productos afectados por vulnerabilidades heredadas. Ese inventario es donde empieza CRACI. Para una visión completa de esta función, consulte qué es un PSIRT.
Lo que CRACI ofrece a un PSIRT
Un inventario registrado desde el build
CRACI ejecuta sus builds de GitHub Actions en sus propios runners y registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas, los paquetes restaurados desde cachés de CI y las dependencias que ningún lockfile enumera. Es un registrador, no un escáner. Cada SBOM incluye un estado de completitud, de modo que un registro parcial queda marcado como parcial, y las SBOM se exportan en CycloneDX o SPDX.
Monitorización continua de lo distribuido
Las SBOM monitorizadas se reevalúan continuamente a medida que se publican nuevas vulnerabilidades, y los hallazgos se agregan entre builds y repositorios. Un CVE publicado el mes que viene se coteja con las versiones que ya ha distribuido, no solo con el siguiente build. Las versiones maliciosas conocidas con un CVE publicado se señalan como cualquier otra vulnerabilidad.
Productos, versiones y periodos afectados
El historial de builds muestra cada build anterior con su SBOM y qué builds contenían una dependencia vulnerable, directa o transitiva, para que sepa durante qué periodo estuvo afectado, dentro de su periodo de retención. La vista de inventario muestra exactamente qué versiones de software están desplegadas en qué productos. Juntos convierten «¿estamos afectados?» en una simple consulta.
Componentes adquiridos
Los productos rara vez constan solo de su propio código. Se pueden añadir SBOM de proveedores, de modo que los componentes de terceros se monitorizan junto con sus propios builds.
Triaje, derivación y VEX
Los equipos de seguridad hacen el triaje de las vulnerabilidades descubiertas y las envían a los equipos responsables de la corrección, lo que encaja con el modelo de PSIRT distribuido, en el que los equipos de producto hacen la corrección. CRACI es compatible con VEX. Consulte VEX para ver cómo las declaraciones de no afectado ahorran trabajo a un PSIRT y a sus clientes.
Mantener un CVE corregido fuera de los builds posteriores
Los controles de política pueden bloquear un build según los hallazgos, incluidos los builds que contienen un CVE concreto. Una vez cerrado un caso de PSIRT, un control de política sobre ese CVE impide que la versión vulnerable vuelva discretamente en una versión posterior.
Evidencias para auditorías y clientes
La API devuelve las SBOM, las trazas de red y la procedencia de cada build, de modo que el registro que respalda un aviso o una respuesta de auditoría está disponible fuera de la interfaz. Donde se aplica el Cyber Resilience Act de la UE, CRACI también presenta las notificaciones exigidas a las autoridades en nombre del fabricante; la obligación sigue siendo del fabricante. Consulte qué es el CRA.
Dónde encaja CRACI en el proceso del PSIRT
| Etapa del PSIRT | Qué aporta CRACI |
|---|---|
| Preparación | Una SBOM por build, registrada mientras se ejecuta, con un estado de completitud |
| Descubrimiento | Reevaluación continua de las SBOM monitorizadas, incluidas las SBOM de proveedores |
| Verificación | Qué builds, versiones y productos contienen el componente, y desde cuándo |
| Corrección | Triaje y derivación al equipo responsable; controles de política que mantienen el CVE fuera de los builds posteriores |
| Lanzamiento y divulgación | Compatibilidad con VEX; exportación de SBOM; acceso por API al registro del build |
Las etapas siguen el ciclo de vida de la gestión de vulnerabilidades.
Lo que CRACI no hace
- Análisis de alcanzabilidad. CRACI muestra que un paquete vulnerable estaba en el build, no si su código llama a la función vulnerable.
- Análisis del código fuente. SAST y el análisis de secretos quedan fuera de su alcance; hay muchas buenas herramientas que lo hacen junto con CRACI.
- Sistemas de CI distintos de GitHub Actions. GitHub Actions hoy; otros sistemas de CI están en la hoja de ruta.
- Cumplimiento en su nombre. CRACI aporta las evidencias; cumplir NIS2, el CRA o cualquier otro marco sigue siendo un proceso de su organización.
CRACI para equipos PSIRT: preguntas frecuentes
¿CRACI es una herramienta PSIRT?
CRACI cubre la parte del trabajo de un PSIRT que depende de saber lo que se distribuye: SBOM del build, su monitorización continua, qué builds y productos contienen un componente vulnerable y el triaje y la derivación al equipo responsable. Su canal de divulgación y su proceso de avisos se apoyan en ese registro.
¿Cómo sabe CRACI qué hay en un producto?
Los builds se ejecutan en los runners de GitHub Actions de CRACI, y CRACI registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas, los paquetes restaurados desde cachés de CI y las dependencias que ningún lockfile enumera. Es un registrador, no un escáner. Cada SBOM incluye un estado de completitud, de modo que usted sabe cuándo el registro es parcial.
¿Puede CRACI decirnos qué versiones anteriores se vieron afectadas por un CVE?
Sí, dentro de su periodo de retención. El historial de builds muestra cada build anterior y su SBOM, y qué builds contenían una dependencia vulnerable, directa o transitiva, para que sepa durante qué periodo estuvo afectado. La vista de inventario muestra qué versiones de software están desplegadas en qué productos.
¿CRACI cubre los componentes que compramos a proveedores?
Puede añadir SBOM de proveedores, de modo que los componentes adquiridos se monitorizan junto con sus propios builds.
¿CRACI es compatible con VEX?
¿Con qué sistemas de CI es compatible CRACI?
GitHub Actions hoy. Otros sistemas de CI están en la hoja de ruta.
Vea la exposición de sus productos desde el build
Reserve una demo con sus propios builds de GitHub Actions: las SBOM que registra CRACI, los builds a los que llegó un CVE y la vista de triaje en la que trabajaría su PSIRT.
Reservar una demo