O pedido de due diligence para fusões e aquisições chega numa terça-feira de manhã: relatório completo de conformidade com as licenças de código aberto para todos os softwares, com prazo de entrega na sexta-feira. A equipe jurídica tem três dias para elaborar um inventário de cada componente de código aberto em toda a base de código do produto, cada licença aplicável e cada obrigação que deve ser cumprida antes da análise jurídica do adquirente. Para organizações que tratam a conformidade com as licenças como um exercício manual periódico, aquela terça-feira de manhã marca o início de um dos exercícios de emergência mais dispendiosos no setor de software empresarial. Para organizações com infraestrutura madura de análise de dependências, tudo começa com a geração de um relatório.
O software é, em sua maior parte, montado, não escrito. O relatório Black Duck 2026 OSSRA constatou que 98% das bases de código comerciais contêm componentes de código aberto, 87% possuem pelo menos uma vulnerabilidade conhecida e o número médio de vulnerabilidades por base de código mais que dobrou ano a ano. A auditoria de conformidade de licenças é a disciplina que responde a uma questão diferente, porém relacionada: não apenas quais componentes contêm vulnerabilidades, mas quais componentes impõem obrigações legais sobre como o software pode ser distribuído, modificado ou comercializado. Uma dependência não identificada da GPL-2.0 em um produto comercial proprietário não é um incidente de segurança. É uma violação de licença que pode exigir a divulgação do código-fonte, um acordo judicial ou a retirada do produto do mercado.
A base da auditoria de conformidade de licenças é a análise de dependências, a identificação sistemática de cada componente de software do qual uma base de código depende direta ou indiretamente, com a atribuição completa da licença que rege cada componente. A análise de dependências não é uma simples leitura do manifesto do pacote. Trata-se de um exame estrutural completo do que o software realmente inclui em tempo de compilação e em tempo de execução, independentemente de essas inclusões serem declaradas, transitivas, fornecidas por terceiros ou implícitas.
Alteração de licença? Saiba o impacto.
SMART TS XL Gera o inventário de componentes para software de mainframe que os geradores SBOM padrão não conseguem alcançar.
SAIBA MAIS…Por que a análise de dependências é fundamental
A conformidade com a licença é, antes de ser, um problema de dependências. Não é possível avaliar as obrigações de licenciamento de um produto de software sem antes saber do que ele é composto: cada componente, cada biblioteca, cada trecho de código copiado. A análise da licença é uma consequência do inventário de dependências. Se o inventário estiver incorreto, a análise da licença será baseada em uma visão incompleta.
Três perguntas que a análise de dependências deve responder para garantir a conformidade com a licença:
Quais componentes estão incluídos? Não apenas as dependências diretas declaradas em package.json or pom.xmlMas cada dependência transitiva que eles trazem, cada biblioteca de terceiros copiada para a árvore de código-fonte, cada componente vinculado estaticamente compilado no binário e cada módulo carregado dinamicamente chamado em tempo de execução. Um bom mecanismo de SCA cruza referências desses componentes com bancos de dados de vulnerabilidades como o NVD, verifica os metadados da licença e sinaliza exploits conhecidos ou riscos legais antes que eles impactem seu pipeline de entrega. O mesmo mecanismo também deve ser preciso no nível de inventário, ou seja, no que realmente está presente no software, para que a análise de licença possa ser considerada confiável.
Sob quais licenças eles são regidos? Um componente pode ter uma única licença declarada, uma licença dupla com opções, múltiplas licenças aplicáveis a diferentes arquivos ou uma licença que mudou entre versões. O mecanismo de detecção de licenças da FOSSA afirma ter 99.8% de precisão, o que é importante quando sua equipe jurídica precisa verificar as obrigações de código aberto juntamente com o inventário de segurança. A identificação da licença no nível do componente é necessária, mas insuficiente; a identificação no nível do arquivo ou trecho de código é necessária para componentes em que diferentes arquivos possuem licenças diferentes.
Que obrigações impõem essas licenças? Uma licença permissiva (MIT, Apache-2.0) impõe requisitos de atribuição. Uma licença copyleft fraca (LGPL) impõe obrigações diferentes dependendo se o componente é vinculado dinamicamente ou estaticamente. Uma licença copyleft forte (GPL-2.0, GPL-3.0) pode exigir a distribuição do código-fonte de toda a obra combinada. Compreender as obrigações requer compreender os termos da licença, e não apenas o identificador da licença.
Os quatro tipos de dependências que criam exposição de licença
Nem todas as dependências são igualmente visíveis ou igualmente controladas pelas ferramentas existentes. A exposição da licença resulta de quatro tipos distintos de dependência, cada um exigindo métodos de descoberta diferentes:
1. Dependências do gerenciador de pacotes (declaradas e transitivas)
A camada mais visível: dependências declaradas em arquivos de manifesto (package.json, pom.xml, requirements.txt, go.mod, Cargo.toml) e as dependências transitivas que elas resolvem no momento da compilação. As dependências do gerenciador de pacotes são a categoria mais bem coberta; as ferramentas SCA examinam manifestos, arquivos de bloqueio e artefatos de compilação para enumerá-las.
A distinção crucial reside entre dependência direta e transitiva. Uma dependência direta é aquela escolhida pelo desenvolvedor. Uma dependência transitiva é aquela que a dependência direta exige. Um desenvolvedor que adiciona uma única dependência direta é aquele que a dependência direta exige. react-data-grid Um pacote adicionado a um projeto Node.js pode importar dezenas de dependências transitivas, cada uma com sua própria licença. O desenvolvedor não escolheu essas licenças. Elas existem na árvore de dependências independentemente disso.
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.A armadilha da licença transitiva: o risco da licença não está no que você declarou, mas sim no que suas dependências declararam e no que as dependências delas declararam. Uma árvore de dependências diretas limpa, com licenças permissivas, pode ocultar uma dependência transitiva licenciada sob a GPL em três níveis de profundidade, que impõe obrigações de copyleft a toda a distribuição.
2. Código-fonte fornecido e copiado
O código-fonte de projetos externos foi copiado diretamente para o repositório, um padrão comum em projetos C/C++, projetos Go sem módulos e bases de código legadas. O código de terceiros não aparece nos manifestos do gerenciador de pacotes porque foi adicionado por meio de copiar e colar, em vez de usar um gerenciador de dependências.
A análise em nível de trecho de código do SCANOSS vai muito além da detecção baseada em manifesto, comparando fragmentos de código-fonte com mais de 100 milhões de arquivos de código aberto no OSSKB. A análise em nível de trecho de código é necessária para identificar código de terceiros e funções copiadas, abordagens que não declaram dependência no manifesto, mas acarretam todas as obrigações de licença como se o componente tivesse sido explicitamente incluído.
Uma função utilitária incluída no pacote, copiada de uma resposta do Stack Overflow que se originou em código licenciado sob a GPL, possui a mesma obrigação de copyleft que uma dependência direta da GPL, mas não aparece em nenhum lugar no manifesto do pacote, no arquivo de bloqueio ou em qualquer verificação automatizada que leia apenas as dependências declaradas.
3. Bibliotecas Estaticamente Vinculadas
Bibliotecas compiladas diretamente no binário do aplicativo durante a compilação. Ao contrário das bibliotecas vinculadas dinamicamente, que existem como arquivos separados em tempo de execução, as bibliotecas vinculadas estaticamente são incorporadas ao executável. Elas não são visíveis nos manifestos do gerenciador de pacotes, mas aparecem nas configurações de compilação (Makefile, CMakeLists.txt, scripts de vinculação) e no próprio binário compilado.
Especificamente para bibliotecas licenciadas sob a LGPL, a distinção entre vinculação estática e dinâmica determina a obrigação da licença. A LGPL permite a vinculação dinâmica sem a propagação do copyleft; a vinculação estática pode acionar requisitos de copyleft sobre a obra combinada. Uma ferramenta de análise binária que examine o artefato compilado, em vez de apenas o manifesto de origem, é necessária para identificar componentes vinculados estaticamente e suas respectivas licenças.
4. Dependências carregadas em tempo de execução
Bibliotecas carregadas dinamicamente em tempo de execução por meio de arquiteturas de plugins, vinculação tardia ou integrações com mecanismos de script. Essas dependências podem não ser resolvidas apenas pela análise do código-fonte, pois dependem do ambiente de execução, da configuração e do caminho de execução. Drivers de banco de dados carregados por meio de reflexão, plugins de análise sintática descobertos por meio de mecanismos de carregamento de serviços e extensões de script carregadas de caminhos do sistema de arquivos na inicialização são todos exemplos de dependências de tempo de execução com potenciais implicações de licença.
Categorias de risco de licenciamento e suas obrigações
As licenças de código aberto variam em um espectro que vai do permissivo ao restritivo. Compreender a posição de cada licença nesse espectro determina a obrigação de conformidade que ela cria:
Licenças permissivas (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC)
Obrigações: Atribuição, inclusão do texto da licença e do aviso de direitos autorais nas distribuições. Divulgação do código-fonte não é obrigatória. Uso comercial permitido sem restrições. Integração em produtos proprietários permitida.
Nível de risco para software comercial: Baixo. A atribuição é fácil de ser feita automaticamente.
Licenças copyleft fracas (LGPL-2.0, LGPL-2.1, LGPL-3.0, MPL-2.0, EUPL-1.2)
Obrigação: A atribuição e as modificações feitas no componente licenciado devem ser compartilhadas. Especificamente para a LGPL: a vinculação dinâmica geralmente satisfaz a licença sem acionar o copyleft no código que a utiliza; a vinculação estática pode não satisfazer.
Nível de risco para software comercial: Médio. Depende do método de vinculação. A vinculação dinâmica geralmente é segura; a vinculação estática requer uma análise jurídica cuidadosa.
Licenças copyleft fortes (GPL-2.0, GPL-3.0, AGPL-3.0)
Obrigação: A atribuição, juntamente com a obra completa que inclui o componente GPL, deve ser disponibilizada sob os termos da GPL (divulgação do código-fonte). A AGPL estende essa obrigação a softwares acessados por meio de uma rede.
Nível de risco para software comercial: Alto. Um componente licenciado sob a GPL, vinculado estaticamente a um produto comercial proprietário ou derivado dele, pode exigir a divulgação do código-fonte proprietário. Este é o risco de licenciamento que gera os maiores acordos judiciais.
Copyleft de rede (AGPL-3.0)
Obrigação: Todas as obrigações da GPL-3.0, mais: os usuários que interagem com o software por meio de uma rede são considerados como tendo recebido o software, o que aciona a obrigação de divulgação do código-fonte mesmo para produtos SaaS que nunca distribuem binários.
Nível de risco para produtos SaaS: Muito alto. A AGPL foi especificamente criada para eliminar a "brecha do SaaS" na GPL. Um produto SaaS comercial que inclua um componente AGPL deve divulgar seu código-fonte a qualquer usuário que interaja com ele por meio de uma rede.
Licenças proprietárias e comerciais
Obrigação: Definida pelo contrato de licença, varia de "proibição de redistribuição" a "royalties por unidade" e "licença empresarial". Esses componentes não são de código aberto, mas aparecem nas árvores de dependências quando componentes comerciais são utilizados.
Nível de risco: Varia conforme os termos. Frequentemente descoberto durante a due diligence em fusões e aquisições, quando as obrigações relativas às taxas de licenciamento dos produtos adquiridos são enumeradas.
Compatibilidade de licenças: A matriz que importa
Quando componentes com licenças diferentes são combinados em um único produto de software, as licenças devem ser compatíveis. Combinações de licenças incompatíveis criam riscos legais que não podem ser resolvidos apenas por atribuição, pois a própria combinação pode violar uma ou ambas as licenças.
| Combinado com | MIT | Apache-2.0 | LGPL-2.1 | GPL-2.0 | GPL-3.0 | PLFA-3.0 |
|---|---|---|---|---|---|---|
| MIT | Compatível | Compatível | Compatível | Compatível | Compatível | Compatível |
| Apache-2.0 | Compatível | Compatível | Compatível | Incompatível | Compatível | Compatível |
| LGPL-2.1 | Compatível | Compatível | Compatível | Compatível | Incompatível | Incompatível |
| GPL-2.0 | Compatível | Incompatível | Compatível | Compatível | Incompatível | Incompatível |
| GPL-3.0 | Compatível | Compatível | Incompatível | Incompatível | Compatível | Compatível |
| Proprietário | Compatível | Compatível | Cuidado | Incompatível | Incompatível | Incompatível |
A incompatibilidade mais relevante para software comercial: Apache-2.0 e GPL-2.0 são incompatíveis. Uma biblioteca licenciada sob Apache-2.0 não pode ser combinada com um componente licenciado sob GPL-2.0 no mesmo projeto. Como muitos componentes fundamentais de código aberto (módulos do kernel Linux, algumas bibliotecas Java mais antigas) são GPL-2.0 em vez de GPL-3.0, essa incompatibilidade cria um risco real de conformidade em árvores de dependências mistas.
A cláusula AGPL-3.0 é a mais restritiva para SaaS: essencialmente, nada se integra perfeitamente à AGPL-3.0 em um produto comercial sem acionar a obrigação de copyleft de rede.
Implementando a política de licenças em CI/CD
A conformidade com licenças que depende de auditorias periódicas falha no momento da introdução: a dependência GPL adicionada no último sprint já está em produção há três semanas antes de ser detectada pela auditoria trimestral. A aplicação contínua de regras no ponto de integração (merge gate) é a única abordagem que impede a entrada de dependências não conformes no código-fonte.
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-*.jsonAtenção: a política de licenciamento é específica para cada organização. A lista de itens proibidos no exemplo acima reflete uma política comercial comum, mas a equipe jurídica da sua organização deve definir quais licenças são permitidas, quais devem ser analisadas e quais são proibidas para o seu tipo de produto, modelo de distribuição e contratos com clientes específicos. Uma biblioteca permitida em uma ferramenta interna pode ser proibida em um produto distribuído ao cliente.
Geração de SBOM e padrões de formato
Uma Lista de Materiais de Software (SBOM, na sigla em inglês) é o artefato estruturado que torna a conformidade com as licenças auditável, compartilhável e verificável por máquina. As equipes de conformidade podem confirmar as obrigações de licenciamento sem auditorias manuais quando uma SBOM fornece esses dados. Dois formatos dominam o mercado:
O CycloneDX , desenvolvido pela OWASP, foi projetado para casos de uso em segurança e cadeia de suprimentos. Ele suporta listas de materiais (BOMs) de componentes, serviços, vulnerabilidades (VEX), fórmulas e modelos de aprendizado de máquina. É o formato preferido para BOMs com foco em segurança e o formato exigido pela maioria das integrações de ferramentas modernas de análise de cadeia de suprimentos (SCA).
SPDX, mantida pela Linux Foundation, a norma ISO/IEC (ISO 5962:2021). Exigida por algumas normas de compras governamentais, incluindo aspectos da Ordem Executiva 14028. Mais focada na conformidade com a licença do que na segurança, com uma linguagem de expressão de licença mais rica (as expressões SPDX podem capturar cenários complexos com múltiplas licenças). GPL-2.0-only AND MIT OR Apache-2.0).
A Ordem Executiva 14028 já impede que fornecedores que não utilizam o padrão SBOM (Software-Based Manufacturing Office) participem de contratos federais, a CRA (Community Reinvestment Act) começará a exigir relatórios de vulnerabilidade em setembro de 2026 e o PCI DSS 4.0 já está nas mãos dos auditores. Ou você está enviando o padrão SBOM ou está perdendo negócios.
Para produtos de software corporativos, produzir ambos os formatos custa pouco além de gerar a partir da mesma análise de dependências. O público-alvo de cada um difere: equipes de segurança e fluxos de trabalho de gerenciamento de vulnerabilidades utilizam o CycloneDX; equipes jurídicas, de compras e fluxos de trabalho de conformidade regulatória geralmente preferem o SPDX.
O Problema do Código Legado: Sem Gerenciador de Pacotes, Sem Manifesto
As ferramentas de análise de dependências descritas acima — scanners SCA, analisadores de arquivos de bloqueio, geradores SBOM — operam sob a premissa de que as dependências de software são gerenciadas por meio de gerenciadores de pacotes e declaradas em arquivos de manifesto. Essa premissa é válida para projetos modernos em Java, JavaScript, Python, Go e Rust. Contudo, ela não se aplica a ambientes corporativos legados construídos em plataformas COBOL, JCL e mainframe.
Em um ambiente mainframe, a dependência de software de terceiros se manifesta de três maneiras que as ferramentas SCA padrão não conseguem detectar:
Produtos licenciados para classificação e utilização. Os fluxos de trabalho JCL chamam programas utilitários, produtos de classificação (DFSORT, SyncSort/Syncsort, agora conhecido como Precisely, CA Sort), geradores de relatórios (SAS, EASYTRIEVE) e ferramentas de conversão de dados, que são softwares comerciais licenciados com seus próprios termos de licença, contratos de manutenção e requisitos de conformidade. Estes aparecem no JCL como PGM=SORT, PGM=IEBGENER, PGM=ICETOOL, nomes de programas, não identificadores de pacotes. Nenhuma ferramenta SCA que leia package.json or pom.xml irão encontrá-los.
Copybooks COBOL fornecidos pelo fornecedor. Fornecedores de software terceirizados fornecem copybooks COBOL que são softwares licenciados. Um fornecedor de software fintech que oferece programas COBOL para processamento de pagamentos pode fornecer copybooks que definem suas estruturas de dados proprietárias. Todo programa COBOL que inclui esses copybooks está usando software licenciado. As obrigações de licenciamento são reais; a entrada no gerenciador de pacotes não existe.
Algoritmos incorporados de fontes licenciadas. Instituições financeiras que utilizam sistemas COBOL podem ter incorporado algoritmos licenciados, rotinas de cálculo atuarial, implementações criptográficas e bibliotecas de análise numérica diretamente no código-fonte COBOL. Esses elementos podem ter se originado de fontes licenciadas que foram compiladas na base de código e não podem ser identificados por gerenciadores de pacotes.
Para esses componentes, o método de descoberta é a análise do código-fonte: rastreamento de instruções CALL para identificar os programas chamados, exame de instruções COPY para identificar os membros incluídos e comparação dos nomes dos programas com um registro de componentes de terceiros conhecidos. O resultado alimenta o mesmo fluxo de trabalho de conformidade de licenças, mas requer uma ferramenta que entenda a semântica de COBOL e JCL, e não apenas os formatos modernos de manifesto de pacote.
Construindo o Pacote de Conformidade Pronto para Auditoria
Quando o departamento jurídico, de conformidade ou um auditor externo solicita comprovação de conformidade com a licença, um relatório de verificação é necessário, mas não suficiente. O pacote de conformidade pronto para auditoria contém:
- Inventário completo de dependênciasCada componente, versão e licença, incluindo dependências transitivas, organizados por produto e versão.
- Matriz de obrigações de licençaPara cada categoria de licença presente, as obrigações específicas (atribuição, divulgação da fonte, notificação de modificação) e como cada uma delas é cumprida.
- Arquivo de avisos de atribuição, compilou avisos legais para todos os componentes que exigem atribuição, no formato exigido por cada licença (arquivo NOTICE para Apache-2.0, arquivo LICENSE para MIT, etc.)
- Análise de incompatibilidadeDocumentação que comprove a incompatibilidade de combinações de licenças no produto final, com justificativa legal para quaisquer casos extremos.
- Artefato SBOM, arquivo CycloneDX ou SPDX atual, assinado e com carimbo de data/hora, abrangendo todos os componentes no escopo
- Documentação da política, a política de licença de código aberto escrita da organização, incluindo o processo de aprovação para novas licenças
- Registros de aprovaçãoPara qualquer licença que exija análise jurídica antes da inclusão, é necessária a aprovação documentada e a justificativa comercial.
- Histórico de remediação, documentação de quaisquer violações previamente identificadas e das medidas tomadas para resolvê-las
Especificamente para a due diligence em fusões e aquisições: os compradores solicitam cada vez mais este pacote como parte da due diligence técnica. Um pacote de conformidade sem pendências ou violações não resolvidas acelera o processo de due diligence. Um pacote que revela violações não resolvidas da GPL (Licença Geral de Propriedade Intelectual) em um produto proprietário geralmente resulta em ajuste de preço, exigência de depósito em garantia ou remediação como condição para o fechamento do negócio, todos mais caros do que o programa de conformidade que os teria evitado.
Como SMART TS XL Suporta a conformidade com licenças em bases de código corporativas.
SMART TS XL'S mapeamento de dependências de aplicativos Fornece a camada de análise de dependência estrutural para bases de código corporativas, especialmente em ambientes legados onde as ferramentas padrão de SCA atingem seus limites.
Para ambientes mainframe, o mapa de dependências identifica todos os programas chamados por todos os outros programas (revelando chamadas de utilitários de terceiros incorporadas em JCL e COBOL), todos os copybooks incluídos por todos os programas (revelando dependências de copybooks fornecidos pelo fornecedor) e todos os conjuntos de dados acessados por todos os programas (revelando dependências da camada de dados em produtos de banco de dados licenciados). Essa análise produz o inventário de componentes que é a condição prévia para a auditoria de conformidade de licenças em ambientes onde não existe um gerenciador de pacotes.
A funcionalidade de análise estática de código identifica padrões de código associados a componentes específicos de terceiros: assinaturas de chamadas de API proprietárias, convenções de estrutura de dados específicas do fornecedor e implementações de algoritmos licenciados incorporadas em código-fonte COBOL personalizado. Essas descobertas complementam o inventário baseado em manifesto com as dependências em nível de código que a análise de manifesto não consegue alcançar.
A capacidade de análise de impacto torna as alterações nas políticas de licenciamento acionáveis: se a licença de um componente for alterada, se uma dependência passar da licença MIT para a AGPL-3.0 ou se um fornecedor modificar seus termos, a análise de impacto identifica todos os programas no portfólio que dependem desse componente, direta ou indiretamente. Isso transforma um evento de alteração de licença de um risco desconhecido em um escopo de remediação definido.
A funcionalidade de busca corporativa permite consultar o inventário de dependências para fins de conformidade: encontre, em segundos, todos os programas que chamam um utilitário específico, todos os copybooks que incluem um componente fornecido por um fornecedor específico, todos os programas que dependem de um componente licenciado específico, em todo o portfólio legado. Essa funcionalidade de busca é a ferramenta prática ideal para a auditoria de fusões e aquisições de terça-feira de manhã: uma consulta em vez de uma revisão manual.
Para organizações que estejam construindo uma cobertura abrangente de SBOM (Sistema de Gerenciamento de Operações de Base) que abranja sistemas modernos e legados, SMART TS XL Fornece o inventário de componentes legados que os geradores SBOM padrão não conseguem produzir, complementando ferramentas como Syft, FOSSA e Dependency-Track para a pilha tecnológica moderna.
A auditoria que nunca deveria ser uma surpresa
A auditoria de conformidade de licenças é uma das poucas disciplinas regulatórias em que a penalidade por não conformidade é frequentemente descoberta não por um órgão regulador, mas por um parceiro comercial, um adquirente, a equipe jurídica de um cliente ou um distribuidor que lê os termos da licença e solicita comprovação de conformidade. O custo dessa descoberta varia de constrangedor a existencial, dependendo da gravidade da violação e da fase da transação.
O programa de análise de dependências que impede que essa descoberta seja uma surpresa não é caro em relação ao risco que mitiga. Ele exige o conhecimento do conteúdo do software, de cada componente, de cada dependência transitiva, de cada trecho de código fornecido, de cada utilitário legado, e a verificação contínua, em vez de periódica, de cada um deles em relação à política de licenciamento da organização. As ferramentas existem. Os padrões (SBOM, SPDX, CycloneDX) existem. O mandato regulatório (EO 14028, CRA, PCI-DSS 4.0) existe. A única peça que falta, para a maioria das organizações, é a disciplina para tratar a análise de dependências como infraestrutura, e não como um exercício de auditoria.
A manhã de terça-feira que começa com um relatório em vez de um simulado de incêndio é a manhã de terça-feira que a infraestrutura de análise de dependências tornou possível.
