Usted ya escanea sus dependencias. Esto es lo que un escáner no puede ver.

Lo que su stack actual hace bien

Si tiene configurados el SCA y la generación de SBOM, ya ha hecho el trabajo organizativo difícil: las dependencias están controladas, los avisos llegan a los desarrolladores y hay un archivo que entregar cuando alguien lo pide. Consérvelo.

• El grafo de dependencias de GitHub y Dependabot están activados por defecto para muchos equipos. GitHub describe el grafo de dependencias como un resumen de los archivos de manifiesto y de bloqueo almacenados en un repositorio y de las dependencias enviadas para ese repositorio mediante la API de envío de dependencias. Las alertas de Dependabot se basan en él y le avisan cuando se publica un nuevo aviso o cuando cambia su grafo de dependencias.
• El SCA comercial, como Snyk, también genera SBOM. Su comando snyk sbom lee los archivos de manifiesto y sus lockfiles, y emite CycloneDX o SPDX. A septiembre de 2026, Snyk documenta que solo está disponible para clientes de sus planes Enterprise.
• Los generadores de código abierto, como Syft, Trivy y cdxgen, son gratuitos, rápidos y fáciles de añadir al CI. Syft se describe a sí mismo como una herramienta para generar una lista de materiales de software (SBOM) a partir de imágenes de contenedor y sistemas de archivos.

Estas herramientas destacan en la información rápida sobre una pull request, en la amplia cobertura de ecosistemas y en un flujo de corrección que los desarrolladores ya conocen. CRACI hoy no sustituye eso. Su seguimiento de vulnerabilidades agrega los hallazgos de builds y repositorios y reevalúa las SBOM monitorizadas a medida que aparecen nuevas vulnerabilidades. Los equipos de seguridad pueden hacer el triaje de los hallazgos y enviarlos al equipo adecuado. Los controles de política pueden bloquear un build; los webhooks de vulnerabilidades están en la hoja de ruta.

Escáner frente a registrador

Todas las herramientas anteriores son escáneres. Usted las dirige a un árbol de código fuente, un lockfile o una imagen de contenedor, y deducen qué entró. Eso funciona cuando los archivos cuentan toda la historia. Se complica cuando no lo hacen:

• El repositorio no tiene lockfile, así que las versiones se deciden en el momento de la instalación.
• El build restaura paquetes desde una caché de CI que ningún manifiesto menciona.
• Un paso del build descarga directamente una herramienta, un paquete del sistema operativo o un binario.
• Un hook de instalación de npm o un script de build de Rust descarga más código durante la instalación, la vía que usó el gusano Shai-Hulud.
• Un build de contenedor descarga una imagen base y las capas de su sistema operativo, que ningún lockfile de lenguaje enumera.
• Lo que usted distribuye es un binario compilado, y el manifiesto que lo acompaña no enumera casi nada.

CRACI es un registrador: ve el tráfico, y los escáneres no. Ejecuta el build en su propio runner compatible con GitHub Actions, y un proxy que entiende de paquetes observa el tráfico hacia las fuentes de paquetes mientras se ejecuta el job, de modo que estas dependencias ocultas acaban en la SBOM. Los paquetes restaurados desde una caché conservan su evidencia. No existe un comando craci scan ./dir, porque escanear un directorio a posteriori es justo el paso que CRACI existe para evitar.

De qué depende un escaneo

El resultado de un escáner depende de la herramienta y de aquello a lo que se dirija. Syft, Trivy, cdxgen, Microsoft SBOM Tool, la exportación del grafo de dependencias de GitHub y la CLI de Socket elaboran cada uno la lista a partir de lo que pueden leer. Los patrones siguientes proceden de cómo está documentado el funcionamiento de estas herramientas.

Ningún componente lo encuentran todas las herramientas

Cada generador decide por sí mismo qué cuenta como componente y en qué archivos confiar, de modo que el mismo checkout da a cada uno una lista distinta. La exportación del grafo de dependencias de GitHub funciona a su vez de otra forma: se construye a partir de lo que GitHub sabe del repositorio, no de los archivos que lee un escáner, y lee la rama por defecto en lugar de un commit fijado.

Sin lockfile, sin dependencias

Express 5.2.1 no incluye ningún lockfile en el repositorio. Sobre un checkout limpio, un generador que resuelve las dependencias a partir de lockfiles o de un árbol instalado no tiene ninguna de las dos cosas delante, así que ninguna de las dependencias npm declaradas en package.json llega al documento. Ninguna herramienta está rota. La variable que decide si la SBOM contiene alguna dependencia no es la herramienta. Es si alguien ejecutó antes una instalación.

Una opción cambia la respuesta

El escaneo de directorios por defecto de Syft informa de lo que un proyecto declara, no de lo que está instalado en el disco. En un checkout instalado de la misma versión de express, una opción de cataloger decide si los paquetes npm instalados aparecen o no en la lista. La misma herramienta, la misma versión, el mismo árbol.

El producto es un binario

El repositorio anthropics/claude-code en v2.1.259 no tiene ningún manifiesto de dependencias ni lockfile de ningún tipo. Su paquete npm publicado declara cero dependencias de runtime y envuelve un binario nativo precompilado mediante ocho paquetes de plataforma. @openai/codex 0.149.1 tiene la misma forma. Un lector de manifiestos casi no tiene nada que describir, mientras que el programa que se ejecuta es un binario compilado, de modo que lo que devuelve cada herramienta dice más sobre la herramienta que sobre el proyecto.

El mismo paquete, versiones distintas

Cuando dos herramientas encuentran lo mismo, no siempre coinciden en qué es. Una puede fijar una GitHub Action a un SHA de commit mientras otra indica una etiqueta de versión. Una búsqueda de vulnerabilidades basada en la versión equivocada devuelve una respuesta errónea con toda apariencia de certeza.

Dónde encaja CRACI junto a su SCA

Mantenga su SCA en las pull requests. Es el lugar adecuado para detectar una versión vulnerable antes de la fusión. Añada CRACI cuando la pregunta sea sobre el build y no sobre el diff:

• ¿Qué contenía realmente esta versión? La SBOM registrada cubre fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de presets de descarga, con las dependencias transitivas incluidas. Los mirrors de JFrog Artifactory para npm y PyPI también funcionan.
• ¿Podemos fiarnos de la lista? Cada job y cada caché tienen un estado de completitud, así que un registro incompleto se ve, en lugar de quedarse escaso sin que nadie lo note.
• ¿Nos afecta un nuevo aviso? Las SBOM monitorizadas se reevalúan a medida que se publican nuevas vulnerabilidades, y los hallazgos se agregan por builds y repositorios.

La SBOM se descarga en CycloneDX a través de la API REST pública, junto con la traza de red y la procedencia del job, así que puede alimentar cualquier herramienta que lea CycloneDX, incluido el SCA que ya utiliza. La configuración es una línea en el workflow: cambie runs-on a craci. GitHub Actions es el CI compatible hoy; GitLab CI, Jenkins y otros sistemas de CI están en la hoja de ruta.

Un inventario de qué está desplegado y dónde

La vista de inventario de CRACI muestra exactamente qué versiones de software están desplegadas en qué productos, a escala global. Cuando llega una nueva vulnerabilidad, puede ver qué productos ejecutan la versión afectada en lugar de reconstruirlo a partir de notas de versión y hojas de cálculo.

Lea más sobre la generación de SBOM durante el build y el seguimiento de vulnerabilidades.