Auditoría de cumplimiento de licencias mediante análisis de dependencias

La solicitud de diligencia debida para fusiones y adquisiciones llega un martes por la mañana: informe completo de cumplimiento de licencias de código abierto para todo el software, con fecha límite el viernes. El equipo legal tiene tres días para elaborar un inventario de cada componente de código abierto en todo el código fuente del producto, cada licencia aplicable y cada obligación que debe cumplirse antes de la revisión legal del comprador. Para las organizaciones que tratan el cumplimiento de licencias como una revisión manual periódica, ese martes por la mañana marca el inicio de uno de los simulacros de emergencia más costosos en el software empresarial. Para las organizaciones con una infraestructura madura de análisis de dependencias, comienza con la generación de un informe.

El software se ensambla principalmente, no se escribe. El informe Black Duck 2026 de OSSRA reveló que el 98 % de los códigos base comerciales contienen componentes de código abierto, el 87 % presenta al menos una vulnerabilidad conocida y el número promedio de vulnerabilidades por código base se ha duplicado con creces año tras año. La auditoría de cumplimiento de licencias es la disciplina que responde a una pregunta diferente pero relacionada: no solo qué componentes contienen vulnerabilidades, sino qué componentes imponen obligaciones legales sobre cómo se puede distribuir, modificar o comercializar el software. Una dependencia GPL-2.0 omitida en un producto comercial propietario no es un incidente de seguridad. Es una violación de licencia que puede requerir la divulgación del código fuente, un acuerdo legal o la retirada del producto.

La base de la auditoría de cumplimiento de licencias es el análisis de dependencias, la identificación sistemática de cada componente de software del que depende directa o indirectamente un código fuente, con la atribución completa de la licencia que rige cada componente. El análisis de dependencias no consiste en escanear el manifiesto del paquete. Es un examen estructural completo de lo que el software incluye realmente en tiempo de compilación y ejecución, independientemente de si dichas inclusiones son declaradas, transitivas, de terceros o implícitas.

Por qué el análisis de dependencias es la base

El cumplimiento de las licencias es, antes que un problema legal, un problema de dependencias. No se pueden evaluar las obligaciones de licencia de un producto de software sin antes conocer su composición: cada componente, cada biblioteca, cada fragmento de código copiado. El análisis de licencias se realiza después del inventario de dependencias. Si el inventario es incorrecto, el análisis de licencias se basa en información incompleta.

Tres preguntas que el análisis de dependencias debe responder para el cumplimiento de la licencia:

¿Qué componentes están incluidos? No solo las dependencias directas declaradas en package.json or pom.xmlPero cada dependencia transitiva que incorporan, cada biblioteca de terceros copiada en el árbol de código fuente, cada componente enlazado estáticamente compilado en el binario y cada módulo cargado dinámicamente llamado en tiempo de ejecución. Un buen motor SCA compara esos componentes con bases de datos de vulnerabilidades como NVD, verifica los metadatos de la licencia y señala exploits conocidos o riesgos legales antes de que afecten su proceso de entrega. El mismo motor también debe ser preciso a nivel de inventario, es decir, qué contiene realmente el software, para que el análisis de licencias sea confiable.

¿Bajo qué licencias se rigen? Un componente puede tener una única licencia declarada, una licencia dual con opciones, varias licencias que se aplican a diferentes archivos o una licencia que ha cambiado entre versiones. El motor de detección de licencias de FOSSA afirma tener una precisión del 99.8 %, lo cual es importante cuando su equipo legal necesita verificar las obligaciones de código abierto junto con el inventario de seguridad. La identificación de la licencia a nivel de componente es necesaria, pero insuficiente; se requiere la identificación a nivel de archivo o fragmento para componentes donde diferentes archivos tienen diferentes licencias.

¿Qué obligaciones imponen estas licencias? Una licencia permisiva (MIT, Apache-2.0) exige la atribución de la autoría. Una licencia copyleft débil (LGPL) impone obligaciones diferentes según si el componente se enlaza de forma dinámica o estática. Una licencia copyleft fuerte (GPL-2.0, GPL-3.0) puede requerir la distribución del código fuente de la obra completa. Para comprender las obligaciones, es necesario comprender los términos de la licencia, no solo su identificador.

Los cuatro tipos de dependencias que generan riesgos de licencia

No todas las dependencias son igualmente visibles ni están igualmente controladas por las herramientas existentes. La exposición de licencias proviene de cuatro tipos de dependencias distintos, cada uno de los cuales requiere diferentes métodos de detección:

1. Dependencias del gestor de paquetes (declaradas y transitivas)

La capa más visible: dependencias declaradas en archivos de manifiesto (package.json, pom.xml, requirements.txt, go.mod, Cargo.toml) y las dependencias transitivas que resuelven en tiempo de compilación. Las dependencias del gestor de paquetes son la categoría mejor cubierta; las herramientas SCA analizan los manifiestos, los archivos de bloqueo y los artefactos de compilación para enumerarlas.

La distinción crítica radica entre dependencia directa y transitiva. Una dependencia directa es la que elige el desarrollador. Una dependencia transitiva es la que requiere la dependencia directa. Un desarrollador que agrega una sola react-data-grid Un paquete para un proyecto Node.js puede importar docenas de dependencias transitivas, cada una con su propia licencia. El desarrollador no eligió esas licencias; existen en el árbol de dependencias de todos modos.

json

// package.json: 1 direct dependency declared
{
  "dependencies": {
    "react-data-grid": "^7.0.0"
  }
}

// npm lockfile resolves to 47 transitive dependencies, including:
// - react@18.2.0 (MIT)
// - clsx@1.2.1 (MIT)
// - scheduler@0.23.0 (MIT)
// - tslib@2.6.0 (0BSD)
// - ...43 more, each with its own license
// The developer declared 1 license obligation; they shipped 47.

La trampa de la licencia transitiva: El riesgo de la licencia no reside en lo que usted declaró, sino en lo que declararon sus dependencias y las de estas. Un árbol de dependencias directo y limpio con licencias permisivas puede ocultar una dependencia transitiva con licencia GPL a tres niveles de profundidad que impone obligaciones de copyleft a toda la distribución.

2. Código fuente proporcionado y copiado

El código fuente de proyectos externos se copia directamente en el repositorio, un patrón común en proyectos de C/C++, proyectos de Go sin módulos y bases de código heredadas. El código de terceros no aparece en los manifiestos del gestor de paquetes porque se agregó mediante copiar y pegar en lugar de a través de un gestor de dependencias.

El análisis a nivel de fragmentos de SCANOSS va mucho más allá de la detección basada en manifiestos, comparando fragmentos de código fuente con más de 100 millones de archivos de código abierto en la base de datos OSSKB. Este análisis es necesario para identificar código de terceros y funciones copiadas, métodos que no declaran ninguna dependencia en el manifiesto, pero que conllevan todas las obligaciones de la licencia como si el componente se hubiera incluido explícitamente.

Una función de utilidad de terceros copiada de una respuesta de Stack Overflow que se originó en código con licencia GPL conlleva la misma obligación de copyleft que una dependencia GPL directa, pero no aparece en ninguna parte del manifiesto del paquete, el archivo de bloqueo ni en ningún escaneo automatizado que lea solo las dependencias declaradas.

3. Bibliotecas enlazadas estáticamente

Las bibliotecas se compilan directamente en el binario de la aplicación en tiempo de compilación. A diferencia de las bibliotecas de enlace dinámico, que existen como archivos separados en tiempo de ejecución, las bibliotecas de enlace estático están integradas en el ejecutable. No son visibles en los manifiestos del administrador de paquetes, aparecen en las configuraciones de compilación (Makefile, CMakeLists.txt, scripts del enlazador) y en el propio binario compilado.

En el caso específico de las bibliotecas con licencia LGPL, la distinción entre enlace estático y dinámico determina la obligación de la licencia. LGPL permite el enlace dinámico sin propagación de copyleft; el enlace estático puede activar los requisitos de copyleft para la obra resultante. Se requiere una herramienta de análisis binario que examine el artefacto compilado, y no solo el manifiesto de código fuente, para identificar los componentes enlazados estáticamente y sus licencias.

4. Dependencias cargadas en tiempo de ejecución

Las bibliotecas se cargan dinámicamente en tiempo de ejecución mediante arquitecturas de complementos, enlace tardío o integraciones con motores de scripting. Estas dependencias pueden no resolverse únicamente mediante el análisis del código fuente, ya que dependen del entorno de ejecución, la configuración y la ruta de ejecución. Los controladores de bases de datos cargados mediante reflexión, los complementos de análisis descubiertos a través de mecanismos de carga de servicios y las extensiones de scripting cargadas desde rutas del sistema de archivos al inicio son dependencias en tiempo de ejecución con posibles implicaciones de licencia.

Categorías de riesgo de licencia y sus obligaciones

Las licencias de código abierto se sitúan en un espectro que va desde lo permisivo hasta lo restrictivo. Comprender en qué punto de este espectro se encuentra cada licencia determina la obligación de cumplimiento que genera:

Licencias permisivas (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC)

Obligación: Atribución, incluir el texto de la licencia y el aviso de derechos de autor en las distribuciones. No se requiere la divulgación del código fuente. Se permite el uso comercial sin restricciones. Se permite la integración en productos propietarios.

Nivel de riesgo para software comercial: Bajo. La atribución se realiza fácilmente de forma automática.

Licencias copyleft débiles (LGPL-2.0, LGPL-2.1, LGPL-3.0, MPL-2.0, EUPL-1.2)

Obligación: Se debe compartir la atribución y las modificaciones al componente licenciado. Específicamente para LGPL: el enlace dinámico generalmente cumple con la licencia sin activar el copyleft en el código que lo llama; el enlace estático puede no hacerlo.

Nivel de riesgo para software comercial: Medio. Depende del método de enlace. El enlace dinámico suele ser seguro; el enlace estático requiere una revisión legal minuciosa.

Licencias copyleft estrictas (GPL-2.0, GPL-3.0, AGPL-3.0)

Obligación: La atribución y la totalidad de la obra combinada que incluye el componente GPL deben estar disponibles bajo los términos de la GPL (divulgación del código fuente). La AGPL extiende esta obligación al software al que se accede a través de una red.

Nivel de riesgo para software comercial: Alto. Un componente con licencia GPL vinculado estáticamente a un producto comercial propietario o derivado de él puede requerir la divulgación del código fuente propietario. Este es el riesgo de licencia que genera las mayores indemnizaciones legales.

Copyleft de red (AGPL-3.0)

Obligación: Todas las obligaciones de la GPL-3.0, más: los usuarios que interactúan con el software a través de una red se consideran receptores del software, lo que activa la obligación de divulgación del código fuente incluso para productos SaaS que nunca distribuyen binarios.

Nivel de riesgo para productos SaaS: Muy alto. La licencia AGPL está diseñada específicamente para subsanar la laguna legal que existía en la licencia GPL para productos SaaS. Un producto SaaS comercial que incluya un componente AGPL debe revelar su origen a cualquier usuario que interactúe con él a través de una red.

Licencias comerciales y de propiedad.

Obligación: Definida por el acuerdo de licencia, varía desde "no redistribuir" hasta "regalías por unidad" o "licencia de puesto empresarial". Estas no son de código abierto, pero aparecen en los árboles de dependencias cuando se utilizan componentes comerciales.

Nivel de riesgo: Varía según los términos. A menudo se descubre durante la debida diligencia en fusiones y adquisiciones, cuando se enumeran las obligaciones de pago de derechos de licencia de los productos adquiridos.

Compatibilidad de licencias: The Matrix That Matters

Cuando se combinan componentes con licencias diferentes en un mismo producto de software, dichas licencias deben ser compatibles. Las combinaciones de licencias incompatibles generan riesgos legales que no pueden resolverse simplemente atribuyendo la responsabilidad; la combinación en sí misma puede infringir una o ambas licencias.

Combinado con	MIT	Apache-2.0	LGPL-2.1	GPL-2.0	GPL-3.0	AGPL-3.0
MIT	Compatible	Compatible	Compatible	Compatible	Compatible	Compatible
Apache-2.0	Compatible	Compatible	Compatible	Incompatible	Compatible	Compatible
LGPL-2.1	Compatible	Compatible	Compatible	Compatible	Incompatible	Incompatible
GPL-2.0	Compatible	Incompatible	Compatible	Compatible	Incompatible	Incompatible
GPL-3.0	Compatible	Compatible	Incompatible	Incompatible	Compatible	Compatible
Propiedad	Compatible	Compatible	Precaución	Incompatible	Incompatible	Incompatible

La incompatibilidad más importante para el software comercial radica en que Apache 2.0 y GPL 2.0 son incompatibles. Una biblioteca con licencia Apache 2.0 no puede combinarse con un componente con licencia GPL 2.0 en el mismo proyecto. Dado que muchos componentes básicos de código abierto (módulos del kernel de Linux, algunas bibliotecas Java antiguas) tienen licencia GPL 2.0 en lugar de GPL 3.0, esta incompatibilidad genera un riesgo real de incumplimiento en árboles de dependencias mixtos.

La cláusula AGPL-3.0 es la más restrictiva para el software como servicio (SaaS): prácticamente nada se combina correctamente con AGPL-3.0 en un producto comercial sin activar la obligación de copyleft de la red.

Aplicación de la política de licencias en CI/CD

El cumplimiento de las licencias, que depende de auditorías periódicas, falla en el momento de su introducción: la dependencia GPL que alguien añadió en el último sprint lleva tres semanas en producción antes de que la auditoría trimestral la detecte. La aplicación continua de la normativa en la fase de fusión es el único método que impide que las dependencias que no cumplen con los requisitos entren en el código fuente.

yaml

# GitHub Actions: license compliance gate on every PR
name: License Compliance Check

on:
  pull_request:

jobs:
  license-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install license checker
        run: npm install -g license-checker fossa-cli

      - name: Scan dependency licenses
        run: |
          license-checker --summary --excludePrivatePackages \
            --out license-report.json

      - name: Enforce license policy
        run: |
          # Block GPL-2.0, GPL-3.0, AGPL-3.0, SSPL in commercial product
          FORBIDDEN=$(license-checker --failOn \
            "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL" \
            --excludePrivatePackages 2>&1 || true)

          if echo "$FORBIDDEN" | grep -q "FAIL"; then
            echo "Forbidden license detected in dependencies"
            echo "$FORBIDDEN"
            exit 1
          fi

      - name: Generate SBOM artifact
        run: |
          # Generate CycloneDX SBOM for audit trail
          npx @cyclonedx/cyclonedx-npm \
            --output-file sbom-$(date +%Y%m%d).json

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom-*.json

Atención: La política de licencias es específica de cada organización. La lista de licencias prohibidas del ejemplo anterior refleja una política comercial común, pero el equipo legal de su organización debe definir qué licencias están permitidas, cuáles requieren revisión y cuáles están prohibidas para su tipo de producto, modelo de distribución y acuerdos con los clientes. Una biblioteca permitida en una herramienta interna puede estar prohibida en un producto distribuido a clientes.

Estándares de generación y formato de SBOM

Una lista de materiales de software (SBOM, por sus siglas en inglés) es el documento estructurado que permite auditar, compartir y verificar automáticamente el cumplimiento de las licencias. Los equipos de cumplimiento pueden confirmar las obligaciones de las licencias sin necesidad de auditorías manuales cuando una SBOM proporciona estos datos. Dos formatos dominan el mercado:

CycloneDX , desarrollado por OWASP, está diseñado para casos de uso de seguridad y cadena de suministro. Admite componentes, servicios, vulnerabilidades (VEX), fórmulas y listas de materiales de modelos de aprendizaje automático. Es el formato preferido para las listas de materiales centradas en la seguridad y el formato requerido por la mayoría de las integraciones de herramientas SCA modernas.

SPDX, mantenido por la Linux Foundation, el estándar ISO/IEC (ISO 5962:2021). Requerido por algunos estándares de contratación pública, incluidos aspectos de la EO 14028. Más enfocado en el cumplimiento de licencias que en la seguridad, con un lenguaje de expresiones de licencia más rico (las expresiones SPDX pueden capturar escenarios complejos de múltiples licencias: GPL-2.0-only AND MIT OR Apache-2.0).

La Orden Ejecutiva 14028 ya impide que los proveedores que no utilizan SBOM accedan a contratos federales, la CRA comenzará a exigir la notificación de vulnerabilidades en septiembre de 2026, y PCI DSS 4.0 ya está en manos de los auditores. O bien se utilizan SBOM o se pierden contratos.

Para los productos de software empresarial, generar ambos formatos tiene un coste mínimo, más allá de partir del mismo análisis de dependencias. El público objetivo de cada formato es diferente: los equipos de seguridad y los flujos de trabajo de gestión de vulnerabilidades utilizan CycloneDX; los equipos legales, de compras y de cumplimiento normativo suelen preferir SPDX.

El problema del código fuente heredado: sin gestor de paquetes, sin manifiesto.

Las herramientas de análisis de dependencias descritas anteriormente (escáneres SCA, analizadores de archivos de bloqueo, generadores SBOM) parten de la premisa de que las dependencias de software se gestionan mediante gestores de paquetes y se declaran en archivos de manifiesto. Esta premisa es válida para proyectos modernos de Java, JavaScript, Python, Go y Rust, pero no para entornos empresariales heredados basados ​​en COBOL, JCL y plataformas mainframe.

En un entorno de mainframe, la dependencia de software de terceros se manifiesta de tres maneras que las herramientas SCA estándar no pueden detectar:

Productos de clasificación y utilidad con licencia. Los flujos de trabajo JCL llaman a programas de utilidad, productos de ordenación (DFSORT, SyncSort/Syncsort ahora conocido como Precisely, CA Sort), generadores de informes (SAS, EASYTRIEVE) y herramientas de conversión de datos, que son software comercial con licencia y sus propios términos de licencia, contratos de mantenimiento y requisitos de cumplimiento. Estos aparecen en JCL como PGM=SORT, PGM=IEBGENER, PGM=ICETOOL, nombres de programas, no identificadores de paquetes. No hay ninguna herramienta SCA que lea package.json or pom.xml los encontrará.

Copybooks COBOL suministrados por el proveedor. Los proveedores de software externos suministran copybooks COBOL que son software con licencia. Un proveedor de software fintech que ofrece programas COBOL para el procesamiento de pagos puede suministrar copybooks que definen sus estructuras de datos propietarias. Todo programa COBOL que incluya estos copybooks utiliza software con licencia. Las obligaciones de la licencia son reales; la entrada en el gestor de paquetes no existe.

Algoritmos integrados de fuentes con licencia. Las instituciones financieras que utilizan sistemas COBOL pueden haber incorporado algoritmos con licencia, rutinas de cálculo actuarial, implementaciones criptográficas y bibliotecas de análisis numérico directamente en el código fuente COBOL. Estos pueden provenir de código fuente con licencia compilado en la base de código y no pueden identificarse mediante gestores de paquetes.

Para estos componentes, el método de detección consiste en el análisis del código fuente: se rastrean las sentencias CALL para identificar los programas llamados, se examinan las sentencias COPY para identificar los miembros incluidos y se comparan los nombres de los programas con un registro de componentes de terceros conocidos. El resultado alimenta el mismo flujo de trabajo de cumplimiento de licencias, pero requiere una herramienta que comprenda la semántica de COBOL y JCL, no solo los formatos modernos de manifiesto de paquetes.

Creación del paquete de cumplimiento listo para auditoría

Cuando el departamento legal, el departamento de cumplimiento normativo o un auditor externo solicitan pruebas de cumplimiento de la licencia, un informe de escaneo es necesario, pero no suficiente. El paquete de cumplimiento normativo listo para auditoría contiene:

• Inventario completo de dependencias, cada componente, versión y licencia, incluidas las dependencias transitivas, organizados por producto y versión.
• matriz de obligaciones de licenciaPara cada categoría de licencia presente, las obligaciones específicas (atribución, divulgación de la fuente, notificación de modificación) y cómo se cumple cada una.
• Archivo de avisos de atribución, se recopilaron avisos legales para todos los componentes que requieren atribución, en el formato requerido por cada licencia (archivo NOTICE para Apache-2.0, archivo LICENSE para MIT, etc.).
• Análisis de incompatibilidad, documentación que demuestre que no existen combinaciones de licencias incompatibles en el producto combinado, con justificación legal para cualquier caso límite.
• artefacto SBOM, archivo CycloneDX o SPDX actual, firmado y con marca de tiempo, que cubra todos los componentes en el alcance
• Documentación de políticas, la política escrita de licencias de código abierto de la organización, incluido el proceso de aprobación de nuevas licencias
• Registros de aprobación, para cualquier licencia que requiera revisión legal antes de su inclusión, la aprobación documentada y la justificación comercial
• Historial de remediación, documentación de cualquier infracción previamente identificada y las medidas adoptadas para resolverlas

En lo que respecta a la debida diligencia en fusiones y adquisiciones: los compradores solicitan cada vez más este paquete como parte de la debida diligencia técnica. Un paquete de cumplimiento impecable, sin infracciones sin resolver, acelera el proceso de diligencia. Un paquete que revela infracciones no resueltas de la GPL en un producto patentado suele resultar en un ajuste de precio, requisitos de depósito en garantía o medidas correctivas como condición para el cierre, todo lo cual es más costoso que el programa de cumplimiento que las habría evitado.

Cómo SMART TS XL Admite el cumplimiento de licencias en bases de código empresariales.

SMART TS XL, mapeo de dependencias de aplicaciones Proporciona la capa de análisis de dependencias estructurales para bases de código empresariales, en particular en entornos heredados donde las herramientas SCA estándar alcanzan sus límites.

En entornos de mainframe, el mapa de dependencias identifica cada programa llamado por cualquier otro programa (revelando las llamadas a utilidades de terceros integradas en JCL y COBOL), cada copybook incluido por cada programa (revelando las dependencias de copybooks proporcionadas por el proveedor) y cada conjunto de datos al que accede cada programa (revelando las dependencias de la capa de datos en productos de bases de datos con licencia). Este análisis genera el inventario de componentes, requisito previo para la auditoría de cumplimiento de licencias en entornos donde no existe un gestor de paquetes.

La capacidad de análisis de código estático identifica patrones de código asociados con componentes específicos de terceros: firmas de llamadas a API propietarias, convenciones de estructura de datos específicas del proveedor e implementaciones de algoritmos con licencia integradas en código fuente COBOL personalizado. Estos hallazgos complementan el inventario basado en manifiestos con las dependencias a nivel de código que el análisis de manifiestos no puede detectar.

La capacidad de análisis de impacto permite tomar medidas concretas ante los cambios en la política de licencias: si cambia la licencia de un componente, si una dependencia cambia de licencia MIT a AGPL-3.0 o si un proveedor modifica sus términos, el análisis de impacto identifica todos los programas del portafolio que dependen de ese componente, ya sea directa o indirectamente. Esto transforma un cambio de licencia, de un riesgo desconocido a un alcance de remediación definido.

La función de búsqueda empresarial permite consultar el inventario de dependencias para fines de cumplimiento normativo: encuentre en segundos todos los programas que llaman a una utilidad específica, todos los archivos de copia que incluyen un miembro específico proporcionado por un proveedor y todos los programas que dependen de un componente con licencia específico, en todo el portafolio heredado. Esta función de búsqueda es la herramienta práctica para la auditoría de fusiones y adquisiciones del martes por la mañana: una consulta en lugar de una revisión manual.

Para las organizaciones que desarrollan una cobertura integral de SBOM que abarca tanto sistemas modernos como heredados, SMART TS XL Proporciona el inventario de componentes heredados que los generadores SBOM estándar no pueden producir, complementando herramientas como Syft, FOSSA y Dependency-Track para la pila tecnológica moderna.

La auditoría que nunca debería ser una sorpresa

La auditoría de cumplimiento de licencias es una de las pocas disciplinas regulatorias donde la sanción por incumplimiento suele descubrirse no por un regulador, sino por un socio comercial, un adquirente, el equipo legal de un cliente o un distribuidor que lee los términos de la licencia y solicita pruebas de cumplimiento. El costo de este descubrimiento varía desde una situación incómoda hasta una situación crítica, dependiendo de la gravedad de la infracción y la etapa de la transacción.

El programa de análisis de dependencias que evita que este descubrimiento sea una sorpresa no es costoso en relación con el riesgo que mitiga. Requiere conocer el contenido del software, cada componente, cada dependencia transitiva, cada fragmento de código de proveedores externos, cada utilidad heredada, y verificar cada elemento con la política de licencias de la organización de forma continua, en lugar de periódica. Las herramientas existen. Los estándares (SBOM, SPDX, CycloneDX) existen. El mandato regulatorio (EO 14028, CRA, PCI-DSS 4.0) existe. El único elemento que falta, para la mayoría de las organizaciones, es la disciplina de tratar el análisis de dependencias como infraestructura, en lugar de como un ejercicio de auditoría.

La mañana del martes que comienza con un informe en lugar de un simulacro de incendio es la mañana del martes que la infraestructura de análisis de dependencias hizo posible.