Su plataforma de SOC 2 demuestra que el control funciona. CRACI registra qué contenía el build.

La configuración de la que trata esta página

Muchos equipos de SaaS acaban con el mismo esquema. Un generador como Syft o Trivy produce una SBOM en el CI, un escáner de vulnerabilidades vigila los repositorios y una plataforma de automatización del cumplimiento se conecta a GitHub y a la cuenta de nube para recopilar evidencia para SOC 2. Funciona. Los auditores lo aceptan, y nadie se pasa la semana anterior a una auditoría haciendo capturas de pantalla.

Esas plataformas hacen esto bien. Vanta dice que "connects read-only to your cloud, identity, code, and device tools" y "automatically pulls evidence, maps it to controls", con más de 1.200 pruebas automatizadas que se ejecutan cada hora. Drata se conecta a "cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more" para recopilar evidencia y asignarla a los controles de SOC 2. Si el objetivo es un informe SOC 2 limpio, es la herramienta adecuada para ese trabajo.

Esta página trata de una pregunta más concreta: qué dice esa evidencia sobre la propia SBOM.

Qué pregunta realmente una comprobación de SOC 2

Los exámenes SOC 2 informan según los AICPA Trust Services Criteria. El criterio más cercano a las SBOM es el CC7.1:

"To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities."

AICPA, 2017 Trust Services Criteria, CC7.1

El criterio describe un resultado. Deja el método, y la profundidad del inventario de componentes que lo respalda, en manos de usted y de su auditor. Por eso una prueba automatizada suele preguntar si el control está implantado y en funcionamiento: si hay un escáner conectado, si se ejecutó, si los hallazgos se gestionaron conforme a su política. Es una pregunta razonable, y es la casilla que se marca.

Lo que la comprobación no pregunta es si la SBOM en la que se basa el escaneo enumeraba todo lo que contenía la versión. Una vulnerabilidad en un componente que la SBOM nunca enumeró no se puede cotejar con nada, de modo que el escaneo sale limpio y el control sigue en verde.

Dónde se separan una comprobación en verde y una SBOM completa

Los generadores de SBOM trabajan con los archivos que tienen delante, y su propia documentación muestra dónde deja eso lagunas:

• En expressjs/express 5.2.1, que no incluye ningún lockfile en el repositorio, un generador que resuelve las dependencias a partir de lockfiles no tiene nada que resolver. Aun así puede devolver un documento que enumere cualquier otra cosa que reconozca, como GitHub Actions y archivos de workflow, y ninguna de las dependencias npm declaradas en package.json.
• Distintos generadores devuelven listas distintas a partir del mismo checkout, porque cada uno decide por sí mismo qué cuenta como componente. La exportación del grafo de dependencias de GitHub se aleja aún más: se crea a partir de lo que GitHub sabe del repositorio y lee la rama por defecto en lugar del commit fijado.
• El campo de proveedor de la NTIA sale vacío en la mayoría de los documentos, porque la mayoría de los generadores no tienen ninguna fuente para él.

Ninguna de esas herramientas está rota. Cada una leyó los archivos a los que se la dirigió, y cada una produjo un documento válido en un formato estándar, según lo programado. Para una prueba de cumplimiento, el control funcionó. Aun así, la SBOM no describía el software.

Qué aporta CRACI a la evidencia

CRACI sustituye el runner de GitHub Actions. Usted cambia runs-on a craci, y las ejecuciones siguen apareciendo en la interfaz de GitHub. La SBOM se genera dentro de ese runner mientras ocurre el build: un proxy que entiende de paquetes observa el tráfico hacia las fuentes de paquetes, de modo que el registro refleja lo que el job descargó y no lo que un archivo dice que debería descargar.

La completitud se indica, no se supone

Cada job y cada caché reciben uno de cinco estados de completitud: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. La evidencia de dependencias viaja con las cachés, de modo que los paquetes restaurados desde una caché caliente se arrastran al registro en lugar de desaparecer sin aviso. Cuando un registro está incompleto, lo dice.

Eso coincide con la dirección que siguen las normas. Los elementos mínimos de SBOM de 2026 de CISA y sus socios piden a los autores de SBOM que "explicitly state whether the information is unknown to the SBOM author" en lugar de dejar campos en blanco sin más.

Evidencia en formatos que aceptan los auditores

Las SBOM se exportan en CycloneDX o SPDX, incluidas las vulnerabilidades encontradas en sus componentes. La API REST pública devuelve la SBOM, la traza de red del job y los datos de procedencia, de modo que los mismos registros pueden ir allí donde guarde su evidencia de auditoría.

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 aparece 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.

Conserve la plataforma de SOC 2

CRACI no es una plataforma de automatización del cumplimiento ni sustituye a una. No gestiona políticas, revisiones de acceso, comprobaciones de dispositivos ni cuestionarios de proveedores. Ambas responden a preguntas distintas. Su plataforma de cumplimiento demuestra que un control existe y funciona. CRACI registra lo que incorporó el build y si ese registro está completo.

La diferencia crece cuando vende software en la UE. El Cyber Resilience Act exige a los fabricantes identificar y documentar los componentes elaborando una lista de materiales de software en un formato de uso común y legible por máquina que abarque, como mínimo, las dependencias de primer nivel de los productos (anexo I, parte II). El anexo VII sitúa la SBOM en la documentación técnica y permite que una autoridad de vigilancia del mercado la solicite. Un informe SOC 2 da fe de cómo su organización gestiona sus controles. Una SBOM del CRA describe un producto concreto. Nuestra introducción al CRA cubre el calendario, y la página de cumplimiento del CRA cubre lo que CRACI automatiza. CRACI automatiza una parte importante de la visibilidad y la evidencia de la cadena de suministro que necesita un proceso más amplio de cumplimiento del CRA; por sí solo no le hace cumplir.

Cómo probarlo sin tocar su auditoría

1. Elija un repositorio cuya SBOM ya alimente su evidencia de SOC 2.
2. Dirija su workflow de lanzamiento a CRACI cambiando runs-on a craci.
3. Compare la SBOM registrada con la que genera hoy, componente por componente, y compruebe el estado de completitud del job.
4. Decida si la diferencia debe formar parte de su evidencia.

Puede leer más sobre la generación de SBOM durante el build y la evidencia para el CRA, o ver cómo documentamos nuestros propios controles en nuestra página de seguridad.