Observa News – Revista da Observabilidade

Supply Chain: que falar desse cara que mal conheço e já considero pacas?

Supply Chain: que falar desse cara que mal conheço e já considero pacas?

Se em algum momento você escreveu um depoimento no Orkut, vai reconhecer essa famosa frase.

Existe uma semelhança entre Supply Chain (ou cadeia de suprimentos) e Orkut: o quanto isso é antigo.

Em 2017, enquanto ainda sentíamos saudades do Orkut, o CCleaner — ferramenta de otimização de computadores — havia sido comprometido, e o tema de segurança na cadeia de suprimentos de software entrou definitivamente no radar da indústria.

O Orkut dispensa apresentações (sim, não vou explicar).

Vamos dar um duplo clique na cadeia de suprimentos; nesse caso, iremos focar em software.

Uma cadeia de fornecimento de software é composta por componentes, bibliotecas, ferramentas e processos usados para desenvolver, construir e publicar um artefato de software.

Cada aplicação — seja ela um app para celular ou uma ferramenta SaaS — utiliza componentes como bibliotecas, códigos e bancos de dados, independentemente da linguagem de programação.

Esses componentes são, em sua grande maioria, de código aberto (open source), ou seja, qualquer desenvolvedor pode utilizá-los.

Não precisamos recriar a roda: para gerar um PDF, por exemplo, não é necessário escrever um código do zero. Podemos utilizar uma biblioteca pronta, o que garante agilidade e escalabilidade.

Mas isso nos leva a algumas perguntas:

  • Como comprometer um sistema cujo código ninguém acessa diretamente?
  • Um projeto open source com centenas de milhares de avaliações realmente é seguro?

Um caso recente que ilustra bem o problema

Neste ano, um dos casos mais relevantes de ataque à cadeia de suprimentos envolveu o Axios, uma das bibliotecas JavaScript mais utilizadas para realizar requisições HTTP, distribuída através do NPM (Node Package Manager), principal repositório de pacotes para aplicações Node.js.

Nesse incidente, os atacantes comprometeram a conta de um dos mantenedores e publicaram versões maliciosas da biblioteca.

Essas versões não continham código malicioso diretamente no Axios — o que tornava o ataque ainda mais difícil de detectar.

Em vez disso, foi introduzida uma dependência oculta (plain-crypto-js) responsável por executar um script de instalação (postinstall) que instalava um Remote Access Trojan (RAT) durante o npm install.

Do ponto de vista do desenvolvedor, tudo parecia normal:

  • o build não falhava;
  • não havia erros visíveis;
  • o processo era concluído com sucesso.

No entanto, naquele momento, o malware já havia sido executado, com capacidade de exfiltrar credenciais, tokens e outras informações sensíveis do ambiente.

Esse caso reforça um ponto essencial:

Não basta confiar na popularidade ou na reputação de uma biblioteca — é necessário ter visibilidade e controle sobre quais dependências são instaladas, executadas e integradas ao fluxo de desenvolvimento.

Esse tipo de ataque poderia ser mitigado com:

  • validação de dependências (SCA);
  • visibilidade via SBOM;
  • análise de logs da pipeline.

E é exatamente aqui que observabilidade e segurança se encontram.

Não basta monitorar o que acontece em produção — é preciso enxergar o que está sendo instalado, executado e integrado desde o primeiro npm install até o deploy.

A observabilidade da cadeia de suprimentos começa na pipeline.

Bala de prata? Não. Mas existem boas práticas

Quer uma notícia? O Orkut não vai voltar.

Casos como o do Axios — e muitos outros — podem ser evitados.

Existem medidas que ajudam a reduzir o risco. Ferramentas, quando bem configuradas e utilizadas corretamente, auxiliam bastante.

Mas não existe bala de prata.

Cultura de Segurança da Informação

Isso inclui conscientização, políticas de segurança e processos.

É fundamental estabelecer políticas claras para:

  • uso de dependências (whitelisting / aprovação);
  • revisão obrigatória de código (incluindo dependências);
  • uso seguro de CI/CD.

Plano de resposta a incidentes

O plano deve ser executado, testado e continuamente melhorado para cenários como:

  • inclusão de bibliotecas maliciosas;
  • comprometimento de pipeline CI/CD;
  • uso indevido de tokens ou credenciais.

Análise de Composição de Software (SCA)

A SCA serve para identificar bibliotecas:

  • vulneráveis;
  • desatualizadas;
  • descontinuadas;
  • comprometidas por malware.

Além disso, é importante implementar bloqueio de builds com dependências vulneráveis ou não aprovadas.

Ferramentas como o Datadog Software Composition Analysis permitem integrar essa visibilidade diretamente na pipeline, com contexto de runtime.

Ou seja: você sabe não apenas o que está instalado, mas também o que está efetivamente em uso.

Inventário de bibliotecas com SBOM (Software Bill of Materials)

Com isso, você sabe exatamente:

  • o que está rodando dentro do software;
  • o que existe nos repositórios;
  • quais componentes realmente estão sendo executados em produção.

O SBOM enriquecido com dados de runtime vai além de uma lista estática: ele reduz ruído e ajuda a priorizar o que realmente importa.

Conclusão

Quanto mais cedo essas práticas são incorporadas ao ciclo de desenvolvimento, menor o risco e maior a capacidade de reação.

Porque, no fim das contas, a pergunta não é:

“A minha aplicação é segura?”

A pergunta correta é:

“Eu sei exatamente o que está rodando, de onde veio e o que está fazendo?”

Se você não consegue responder isso com confiança, talvez seja hora de começar a olhar para a sua cadeia de suprimentos com os mesmos olhos com que olha para o ambiente de produção:

  • com observabilidade;
  • com controle;
  • e, por que não, com um pouco de saudade do Orkut.

Tales Casagrande
Cybersecurity | Co-host of the A Culpa é de Sec Podcast

Referências

Observa