O que os desenvolvedores front-end precisam saber sobre SBOMs em JavaScript

Principais conclusões

• Os aplicativos em JavaScript costumam incluir centenas de dependências ocultas, tanto diretas quanto transitivas.
• As SBOMs oferecem visibilidade completa da sua base de código, revelando vulnerabilidades e garantindo transparência.
• Ferramentas como o Syft e o CycloneDX simplificam a geração de SBOMs, ajudando você a reforçar a segurança e manter a conformidade.

Seu aplicativo JavaScript é uma caixa preta de dependências. Basta abrir a pasta `node_modules` para encontrar milhares de pacotes dos quais você nem sabia que possuía, alguns tão enigmáticos quanto OVNIs na tela de um radar. Em uma época de ataques cada vez mais frequentes à cadeia de suprimentos, isso não é apenas assustador — é perigoso.

Conheça as SBOMs (Software Bill of Materials): seu mapa estelar para navegar pela galáxia das dependências do JavaScript. Nesta postagem, vamos explicar o que são as SBOMs, por que os desenvolvedores front-end não podem ignorá-las e como ferramentas como o CycloneDX e o Syft permitem que você mapeie seu ecossistema, integre a segurança ao seu fluxo de trabalho e detecte vulnerabilidades antes que elas causem falhas graves.

Encontros Imediatos do Tipo JavaScript

Quando analisamos o software como um todo, vemos que há vários elementos que fazem com que tudo se encaixe. Existem pacotes, licenças, pessoas, processos etc., que se encaixam como peças de um quebra-cabeça…na maioria das vezes.

As dependências de software podem parecer tão estranhas quanto um OVNI (Objeto Voador Não Identificado) ou um UAP (Fenômeno Aéreo Não Identificado): às vezes explicáveis, muitas vezes intrigantes e sempre com a possibilidade de um encontro inesperado.

Pode haver elementos atípicos em seu código, cuja existência você talvez já saiba, e, num piscar de olhos, seu software pode ser comprometido. É aí que as SBOMs entram em cena.

Você pode pensar nisso mais ou menos assim: instale um pacote, esse pacote instala outro pacote e, então, sua nave-mãe e TODAS as suas naves filhas são destruídas.

Esse filme resume bem a situação!

Quantas dependências existem no seu aplicativo?

Tente adivinhar: seu aplicativo tem 20 dependências? 200? Ou o equivalente a uma pequena galáxia — algo em torno de mil?

Se você executar o comando ` npm ls ` no terminal, verá uma lista de dependências.

Por que não listar TODAS as dependências? Podemos fazer isso, mas isso pode sobrecarregar o terminal, já que as árvores de dependências podem ser grandes; no entanto, é possível.

Listar as dependências dessa forma mostrará não apenas as dependências diretas, mas também as transitivas.

Duas formas de dependência

Quando analisamos as dependências do nosso projeto, nos deparamos com dois tipos: um deles é a dependência direta. É aquela que você pode ver ao abrir o arquivo package.json, a árvore de dependências diretas.

Por exemplo, o Next é uma dependência direta, pois é necessário para compilar um aplicativo Next.

JSON

"dependencies": {

"react": "^19.0.0",

"react-dom": "^19.0.0",

"next": "15.3.4"

}

Depois, temos as dependências transitivas. São dependências de outras dependências que exigem uma busca mais aprofundada para serem encontradas. Normalmente, elas estão no arquivo package.json, localizado na pasta node_modules, que por sua vez está dentro da pasta do pacote.

Neste exemplo, @next/env é uma dependência transitiva do next.

JSON

"dependencies": {

"@next/env": "15.3.4"

}

O que é uma SBOM?

Uma SBOM é, essencialmente, o manifesto do seu projeto — um inventário legível por máquina que detalha cada componente, dependência e relação. Pense nela como a lista de ingredientes da sua base de código ou como a lista de passageiros de um voo, que indica exatamente quem está a bordo. Uma SBOM lista todas as dependências e versões de um projeto.

A seguir, um trecho de um texto de Tahir Balarabe publicado no Medium. Essa explicação resume tudo perfeitamente.

“Uma SBOM, ou Lista de Componentes de Software, é uma lista detalhada e legível por computador de todos os componentes de um software, incluindo dependências, metadados e relações entre os componentes.”

• https://medium.com/@tahirbalarabe2/why-every-modern-software-needs-a-software-bill-of-materials-sbom-for-security-04a4fec312c8

Você pode estar se perguntando: “Por que precisamos de uma SBOM?” Há inúmeras razões pelas quais precisamos de uma ou mais SBOMs quando estamos produzindo ou utilizando software. Uma delas é a transparência. Devemos saber o que há em nosso produto. Lançar um produto ou oferecer um produto inseguro não beneficia ninguém; isso acabará gerando problemas no futuro.

A transparência em relação ao que está presente na sua árvore de dependências ajuda a garantir sua segurança e conformidade, o que também são dois motivos muito importantes. Saber o que está presente no seu produto é uma coisa, mas garantir a segurança e a conformidade é outra.

Tipos de SBOMs

Quando falamos ou elaboramos diversas SBOMs para nosso software, temos seis tipos diferentes. Todos esses tipos se dividem em várias etapas do SLDC (Ciclo de Vida de Desenvolvimento de Software).

• SBOM de projeto
• SBOM de origem
• Gerar SBOM
• SBOM analisado
• SBOM implantado
• SBOM em tempo de execução

Para obter mais informações sobre as definições dessas SBOMs, consulte o PDF “Tipos de Lista de Materiais de Software (SBOM) ” da CISA (Agência de Segurança Cibernética e de Infraestrutura).

Uma coisa a se ter em mente ao falar sobre SBOMs é que não se trata de um arquivo de pacote nem de um arquivo de bloqueio — é algo mais abrangente. Um SBOM também fornece uma lista completa e padronizada de todos os elementos presentes no seu projeto: componentes, metadados, etc.

Grande problema no front-end

Se você está lendo isso e já instalou alguma coisa no front-end usando o npm, provavelmente já se deparou com o problema de digitar por memória muscular, porque já fez isso centenas de vezes antes. Às vezes, você pode não estar prestando atenção e simplesmente instalar o que acha que precisa. Você pode até nem copiar e colar diretamente do site do fornecedor ou do registro do npm. Isso gera muitos problemas; estamos falando de “typosquatting”.

O typosquatting também é conhecido como sequestro de URL. Trata-se de um tipo de ataque em que um invasor registra um ou mais domínios com variações ligeiramente diferentes de erros ortográficos para induzir os usuários a acessarem seu site, que geralmente é malicioso. Isso também se aplica ao gerenciamento de pacotes. Os invasores também publicam pacotes maliciosos com erros ortográficos, assim como fazem com os domínios. Um desenvolvedor pode, acidentalmente, cometer um erro de digitação e instalar um pacote malicioso em vez do correto.

Um exemplo disso seria o que se segue:

npm install express x npm install expres

Você pode ver que a segunda versão é a versão incorreta do Express e pode ser potencialmente prejudicial.

Por que as SBOMs são importantes?

Existem algumas razões pelas quais é extremamente importante ter uma SBOM:

• Visibilidade dos componentes
• Gerenciamento de vulnerabilidades
• Segurança da Cadeia de Suprimentos
• Colaboração e gerenciamento de patches
• Conformidade Regulatória

Ter visibilidade sobre nossos componentes é fundamental, especialmente quando se trata de dependências transitivas. Também queremos poder gerenciar nossas vulnerabilidades com base no que temos instalado. E não se esqueça do fator humano: compartilhar SBOMs gera confiança no cliente, comprovando que sua cadeia de suprimentos de software é transparente e segura.

Como profissionais da web e de software, se estamos criando um software que será utilizado por outras pessoas, queremos garantir que tenhamos um relacionamento sólido com nossos clientes. É fundamental garantir que as SBOMs estejam disponíveis para nossos clientes.

Instalação de uma ferramenta para gerar uma SBOM

Existem algumas maneiras diferentes de instalar diversas ferramentas para gerar uma SBOM. Nesta postagem, vamos usar o Syft, da Anchore. Abaixo estão alguns comandos para instalar o Syft no seu computador.

A maneira recomendada é usar o curl:

curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin

Você também pode instalar o pacote com o Brew:

brew install syft

Há também uma versão para Windows que pode ser instalada por meio do Chocolatey:

choco install syft -y

A Microsoft também desenvolve uma ferramenta para gerar SBOMs usando o Winget:

winget install Microsoft.SbomTool

Depois de instalar o Syft, podemos passar à geração de uma SBOM em nosso projeto.

Geração de SBOM

Existem dois formatos populares para gerar uma SBOM: SPDX e CycloneDX. Nos exemplos a seguir, estamos usando o SPDX para formatar nossa SBOM. Também estamos gerando uma SBOM em um projeto Angular, especificamente a versão 19.

Quando estiver no seu projeto, execute o comando abaixo para gerar a SBOM. Ela está em formato legível por máquina, mas vamos corrigir isso com o segundo comando que vamos executar. Você verá que há dois parâmetros no final do comando: –source-name e –source-version. Se não os passar para o comando, o terminal vai exibir uma mensagem de erro. É uma boa prática incluí-los.

syft packages dir:. -o json > sbom.json --source-name "my-js-project" --source-version "1.0"

Agora, para gerar uma versão da SBOM que possa ser lida por uma pessoa. Você pode executar um comando chamado jq para formatar a SBOM de maneira mais legível, para que possa examinar o que foi criado.

jq . sbom.json > sbom-pretty.json

Ao instalar novos pacotes, é recomendável gerar um novo SBOM para que o pacote instalado seja documentado. Abaixo está um vídeo que mostra como instalar o pacote Lucide para o Angular e regenerar manualmente o SBOM para que o novo pacote seja incluído.

Isso também pode ser feito por meio de uma GitHub Action. Quando você faz um push para o branch “main”, “dev” ou um branch de lançamento, isso aciona um fluxo de trabalho para gerar um novo artefato SBOM no formato JSON, que é armazenado no GitHub. Você decide o que fazer com esse arquivo.

Considerações finais

Uma SBOM não é mais opcional — é uma parte essencial do desenvolvimento de software moderno. Ela não se limita a informar o que está instalado; ela fornece um mapa dinâmico das dependências diretas e transitivas. Além disso, auxilia no gerenciamento de vulnerabilidades e na conscientização sobre conformidade.

A transparência é fundamental e, para muitas organizações, uma SBOM é uma forma de demonstrar compromisso com a visibilidade. Como parte de seu Suporte de Ciclo de Vida Ilimitado (ELS) para Aplicativos, por exemplo, a TuxCare fornece automaticamente uma SBOM aos seus usuários – oferecendo detalhes abrangentes sobre como cada pacote é compilado, verificado e distribuído. É assim que a TuxCare permite que os desenvolvedores que utilizam seu serviço de correções estendidas para produtos de software de código aberto em fim de vida garantam transparência e responsabilidade em seus ecossistemas de software.

Então, da próxima vez que você abrir seu projeto, gere uma SBOM, submeta-a a um verificador de vulnerabilidades e veja exatamente quais pacotes podem estar contendo exploits conhecidos. Essa é uma das maneiras mais simples e inteligentes de aprimorar a segurança do seu front-end.