Dependência oculta

Uma dependência oculta (hidden dependency) é código, um pacote ou um ficheiro que um build transfere e usa, mas que nenhum lockfile ou manifesto lista. Como a maioria das ferramentas SBOM parte dessas listas, as dependências ocultas faltam na maioria das SBOM, e foi precisamente por aí que passaram vários ataques à cadeia de abastecimento recentes. Na engenharia de software em geral, a expressão também designa um acoplamento não declarado entre módulos; aqui trata-se do sentido ligado à cadeia de abastecimento.

Dependências ocultas comuns

• Hooks de instalação. O npm executa os scripts preinstall, install e postinstall de um pacote durante npm install (documentação do npm). O que esses scripts transferem nunca aparece em package-lock.json. Foi o caminho seguido pelo worm Shai-Hulud.
• Scripts de build. O Cargo compila e executa o build.rs de um crate imediatamente antes de o construir (Cargo Book). Alguns scripts de build transferem nesse momento uma biblioteca C ou um binário pré-compilado, e o Cargo.lock não o regista.
• Imagens base. Num build de contentor, a imagem base e as suas camadas de sistema operativo vêm de um registo, não do lockfile de qualquer linguagem. Veja SBOM de imagens Docker.
• Passos de CI. As actions de configuração e os instaladores curl | sh de um workflow obtêm ferramentas diretamente de um URL, sem lockfile, sem versão fixada nem hash, a menos que o autor os acrescente.

O código incluído no repositório (dependências incorporadas) é outra forma de os componentes escaparem aos manifestos, mas não é obtido durante o build. «Phantom dependency» significa outra coisa: em JavaScript, um pacote que o seu código usa sem o declarar, disponível apenas graças ao hoisting.

Porque as ferramentas SBOM as ignoram

As ferramentas baseadas no lockfile leem a lista declarada no lockfile, por isso só veem o que está declarado. Os scanners de resultado examinam o artefacto final e deduzem o que lá entrou, o que no código compilado como Rust não passa de adivinhação. Nenhum deles vê o que o build obteve pelo caminho. A lista completa do que cada abordagem ignora, incluindo caches e ferramentas de build, está em geradores de SBOM open source. Uma dependência oculta é uma lacuna na completude da SBOM que a própria SBOM não consegue revelar.

Fixar versões também não resolve: um lockfile pode ser perfeito e o hook de instalação que ele fixa pode, ainda assim, transferir algo novo. Os builds que obtêm conteúdos durante o build são também uma das razões por que um build reprodutível é difícil de alcançar.

Como encontrá-las

• Leia o registo do build à procura de transferências: o resultado de npm install e cargo build, e as linhas de curl ou wget.
• Compare uma SBOM gerada a partir do lockfile com os pacotes que o passo de instalação reporta.
• Procure na sua SBOM um pacote que sabe estar na sua imagem base, como libc6. Se não estiver lá, faltam as camadas da imagem.
• Procure curl e wget nos seus workflows.

A resposta fiável é registar o que o build recebe realmente pela rede, em vez de o reconstruir depois.

CRACI

O CRACI vê o tráfego que entra em cada build, por isso regista as dependências ocultas que as ferramentas baseadas no lockfile ignoram. Quando não conseguiu ver tudo, por exemplo porque um job permitiu tráfego que contorna o seu proxy sensível a pacotes, o estado de completude do job indica-o. A sua política de egress decide também que anfitriões um build pode alcançar, pelo que um curl | sh para um anfitrião que a política não permite falha. Veja SBOM do momento do build.