Em 2020, uma atualização de software de rotina de um fornecedor confiável de monitoramento de rede instalou silenciosamente um backdoor em milhares de organizações, incluindo agências federais dos EUA. O fornecedor era a SolarWinds. A atualização era assinada, versionada e vinha de uma fonte que todas as equipes de segurança haviam aprovado. Ninguém foi negligente. Ninguém deixou passar um sinal de alerta óbvio. O atacante simplesmente comprometeu o processo de build antes que o software chegasse ao cliente. Esse é o problema da cadeia de suprimentos em uma frase: aquilo em que você mais confia se torna o vetor.
O que é, de fato, a segurança da cadeia de suprimentos de software?
A segurança da cadeia de suprimentos de software se resume a uma pergunta fundamental: é possível confiar não apenas no software que um fornecedor entrega, mas em todo o processo que o produziu? A maioria dos controles de segurança se concentra no que o software faz quando está em execução: verificação de vulnerabilidades, monitoramento de anomalias, controle de acesso. A segurança da cadeia de suprimentos dá um passo atrás e pergunta se o software foi construído de forma limpa, a partir de componentes confiáveis, por meio de um processo que ninguém adulterou. É um problema totalmente diferente, e a maioria das organizações não está preparada para respondê-lo.
Toda aplicação moderna é montada a partir de dezenas, muitas vezes centenas, de peças a montante. Bibliotecas de código aberto, SDKs comerciais, sistemas de build automatizados, registros de pacotes, pipelines de implantação. Cada uma dessas peças foi criada em algum lugar, armazenada em algum lugar e passou por algum processo antes de chegar até você. Em qualquer ponto dessa cadeia, um atacante pode intervir. Ele não precisa invadir seu ambiente diretamente: basta comprometer algo em que você já confia e deixar que seu próprio processo de implantação faça o resto. Os atacantes da SolarWinds não invadiram suas vítimas. As próprias vítimas instalaram o malware, porque a atualização parecia completamente legítima.
O que a maioria das organizações não percebe é que esse risco não se encerra após a implantação inicial. Cada atualização de software, cada atualização de dependência, cada mudança no pipeline é um novo evento na cadeia de suprimentos. Um fornecedor que você avaliou minuciosamente há seis meses publicou na semana passada uma atualização que você implantou sem pensar duas vezes. A segurança da cadeia de suprimentos exige tratar o software como um ativo em mudança contínua, e não como uma decisão de compra pontual.
A superfície de ataque se divide em cinco camadas que a maioria das avaliações de risco nunca examina:
- Integridade do código-fonte: o código foi enviado por desenvolvedores autorizados, em dispositivos gerenciados, com controles de proteção de branches?
- Integridade das dependências: as bibliotecas de terceiros chegam sem modificações a partir de registros confiáveis?
- Integridade do ambiente de build: o sistema que compila o software é isolado, auditável e livre de adulteração?
- Integridade dos artefatos: o que é implantado é verificável criptograficamente como idêntico ao que foi construído?
- Integridade da entrega e das atualizações: as atualizações de software são validadas antes de serem executadas no seu ambiente?
Por que isso importa
As avaliações tradicionais de terceiros tratam o fornecedor como a unidade de risco: seus controles, suas certificações, suas políticas. Mas, em software, o fornecedor é um nó em um grafo muito maior de dependências e sistemas de build, muitos dos quais o próprio fornecedor nunca avaliou formalmente. Ao aceitar o software de um fornecedor no seu ambiente, você aceita implicitamente a postura de segurança de toda a cadeia a montante dele.
O raio de impacto aqui também é diferente do de uma violação convencional em um fornecedor. Um comprometimento típico expõe dados que o fornecedor tratava em seu nome. Um ataque à cadeia de suprimentos entrega código malicioso que é executado dentro do seu ambiente, com as permissões do processo em que se aloja, operando sob o disfarce de um software em que você confiou explicitamente, sem nenhuma conexão externa a detectar.
Do ponto de vista do atacante, a lógica econômica é impossível de ignorar. Comprometer um fornecedor ou pacote de código aberto amplamente utilizado dá acesso simultâneo a milhares de organizações a jusante, nenhuma das quais fez nada de errado. É exatamente por isso que atores estatais deslocaram investimentos para ataques à cadeia de suprimentos. A alavancagem é extraordinária.
Onde a maioria das equipes erra
A falha mais comum é a confiança equivocada: a suposição de que os controles existentes cobrem isso. A verificação de vulnerabilidades encontra falhas conhecidas no software implantado. Ela não detecta um pipeline de build comprometido. A certificação SOC 2 confirma que os controles existiam em um determinado momento. Ela não valida se o ambiente de build de um fornecedor estava limpo na terça-feira passada, quando ele publicou uma atualização. A segunda falha é a ausência de um inventário básico de software. A maioria das organizações não consegue responder a perguntas simples sobre o software em execução em seu ambiente: qual versão, quais componentes contém, quais dependências a montante carrega. Sem esse inventário, o risco da cadeia de suprimentos é essencialmente impossível de gerenciar.
Padrões comuns que deixam as organizações expostas:
- Nenhuma exigência contratual para que os fornecedores entreguem uma lista de materiais de software (SBOM), um inventário estruturado de todos os componentes que seu produto contém
- Aceitar atualizações de software de fornecedores sem nenhuma verificação de integridade
- Pipelines automatizados de build e implantação executados com credenciais amplas e de longa duração que ninguém revisa
- Tratar o risco das dependências de código aberto como um problema de engenharia, e não como uma questão de risco de terceiros
Como é uma boa prática
As organizações maduras tratam isso como um problema de integridade, e não apenas como um problema de vulnerabilidades. A gestão de vulnerabilidades reage a falhas no que já está implantado. A integridade da cadeia de suprimentos valida que o que foi construído e entregue é exatamente o que se pretendia.
Na prática, você verá:
- Exigências de SBOM nos contratos com fornecedores: os fornecedores entregam um inventário de componentes atualizado e legível por máquina a cada versão
- Assinatura de artefatos: o software é assinado criptograficamente para que o que foi construído possa ser verificado em relação ao que é implantado
- Adoção do framework SLSA: os fornecedores conseguem demonstrar um nível verificável de integridade do build, e não apenas afirmá-lo
- Análise de composição contínua: o risco das dependências é monitorado ao longo do tempo, e não apenas verificado na contratação inicial
- Credenciais de pipeline governadas: as contas automatizadas que constroem e implantam o software têm escopo definido, curta duração e são revisadas regularmente
Ferramentas
As ferramentas abaixo correspondem diretamente aos controles de risco sobre os quais um profissional de TPRM deve questionar os fornecedores.
Geração de SBOM: Anchore, Syft, Tern
Essas ferramentas produzem inventários estruturados de componentes em formatos padrão (CycloneDX, SPDX). Quando uma nova vulnerabilidade é divulgada, é possível consultar o inventário de SBOM dos fornecedores em minutos, em vez de esperar dias pela resposta de um fornecedor.
SLSA & proveniência do build: SLSA GitHub Actions, Tekton Chains, in-toto
Essas ferramentas geram atestados assinados que documentam exatamente como o software foi construído. Perguntar a um fornecedor que nível SLSA ele atingiu é uma pergunta muito mais precisa do que perguntar se ele segue um ciclo de vida de desenvolvimento seguro.
Assinatura de artefatos: Sigstore, Notary v2
O Sigstore oferece infraestrutura gratuita para assinar artefatos de software e registrar a proveniência de forma imutável. Ele muda a conversa de declarações para evidências: prova criptográfica, verificável por qualquer pessoa.
Análise de composição de software: Snyk, Black Duck, Sonatype Nexus
Essas plataformas verificam continuamente as árvores de dependências em busca de vulnerabilidades conhecidas. O sinal de maturidade é se a verificação ocorre a cada build e em produção, ou apenas durante avaliações periódicas.
Segurança do pipeline: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault
Essas plataformas garantem que as credenciais automatizadas que executam os pipelines de build e implantação não sejam estáticas, de escopo amplo ou de longa duração, que é a condição padrão na maioria dos ambientes de fornecedores se ninguém tiver tratado do assunto.
Desafios de governança
O problema da responsabilidade é real e persistente. Segurança, engenharia, compras e TPRM são responsáveis, cada uma, por uma parte disso, mas nenhuma equipe tem a visão completa. O atrito com os fornecedores agrava a situação. Exigir SBOMs ou evidências de proveniência do build é comercialmente controverso, sobretudo com fornecedores grandes e consolidados. A resposta prática é o momento contratual: exigências incluídas na assinatura do contrato têm peso real; solicitações feitas após a implantação quase nunca têm.
- Definir em contrato um padrão mínimo de SBOM: formato, frequência de entrega, campos obrigatórios
- Integrar a análise de SBOM ao processo de gestão de vulnerabilidades para identificar a exposição antes que o fornecedor a notifique
- Exigir evidências da postura de segurança de CI/CD: não uma caixa de seleção de política, mas controles documentados sobre o acesso ao build e a governança das credenciais do pipeline
- Escalonar o nível de escrutínio: fornecedores de software com código em execução no seu ambiente justificam exigências de cadeia de suprimentos significativamente maiores
Se você faz parte de uma equipe pequena
Comece pelo inventário e pela linguagem contratual. Identifique os fornecedores de software cujo código efetivamente é executado no seu ambiente e acrescente exigências de entrega de SBOM à próxima renovação. Em seguida, faça uma pergunta a cada fornecedor crítico: “Vocês podem fornecer um SBOM atualizado do produto que usamos?” A qualidade da resposta diz quase tudo o que você precisa saber.
- Usar uma ferramenta de SCA gratuita (plano gratuito do Snyk ou Syft e Grype, de código aberto) em qualquer software gerenciado internamente
- Exigir notificação em até 72 horas para qualquer atualização que afete componentes do seu ambiente
- Perguntar especificamente quais credenciais têm acesso para construir e implantar o software entregue a você
O que exigir
Os questionários padrão perguntam aos fornecedores se eles realizam análise estática ou testes de invasão. Raramente perguntam sobre proveniência do build, disponibilidade de SBOM ou integridade do pipeline.
Pergunte diretamente:
“Vocês podem fornecer uma lista de materiais de software atualizada do produto que nos entregam, atualizada a cada versão?”
“Como vocês garantem a integridade do seu pipeline de build, especificamente quanto à assinatura de artefatos e à governança das credenciais usadas no seu processo de CI/CD?”
“Que nível de maturidade SLSA vocês atingiram ou estão buscando ativamente?”
O que esperar como evidência
- Um SBOM legível por máquina, no formato CycloneDX ou SPDX, atualizado até a última versão
- Documentação das práticas de assinatura de artefatos e de gerenciamento de chaves
- Evidências de que as credenciais do pipeline são de curta duração e têm escopo restrito, e não estáticas e amplas
- Um processo definido para notificar os clientes quando um componente for afetado por uma nova vulnerabilidade
Se um fornecedor não conseguir responder com detalhes concretos (não linguagem de política, mas evidências técnicas reais), ele está operando uma cadeia de suprimentos de software que não controla totalmente.
Como comprovar
As orientações da CISA, as regras de divulgação da SEC e o Cyber Resilience Act da UE criam obrigações relacionadas ao risco de componentes de software. Organizações que não conseguem demonstrar uma governança ativa da cadeia de suprimentos enfrentam tanto exposição regulatória quanto responsabilização.
- Manter um inventário de fornecedores de software com níveis de risco e status de coleta de SBOM
- Documentar as solicitações de SBOM pendentes e os prazos de correção das lacunas
- Incluir os controles do pipeline de build e de CI/CD como itens explícitos nas avaliações de fornecedores
- Registrar os eventos de atualização de software dos fornecedores críticos e todas as etapas de validação realizadas antes da implantação
Principal conclusão
As organizações mais atingidas por ataques à cadeia de suprimentos não foram descuidadas. Tinham controles de perímetro robustos, contratos com fornecedores com cláusulas de segurança e equipes atentas. O que lhes faltava era visibilidade sobre a integridade do próprio software: como foi construído, o que continha e se o processo que o produziu era de fato confiável. Controles de acesso e governança de dados significam muito pouco se o software que os aplica foi comprometido antes de chegar. A cadeia de suprimentos não é um risco de fundo. É a camada sobre a qual todo o resto se apoia.
Em 2020, uma atualização de software de rotina de um fornecedor confiável de monitoramento de rede instalou silenciosamente um backdoor em milhares de organizações, incluindo agências federais dos EUA. O fornecedor era a SolarWinds. A atualização era assinada, versionada e vinha de uma fonte que todas as equipes de segurança haviam aprovado. Ninguém foi negligente. Ninguém deixou passar um sinal de alerta óbvio..... o artigo Insights da Associação.
#TPRM #DoNoBeLarry #VerisqAi #LiveThreat #SupplyChainRisk # #SupplyChainSoftwareRisk #Cybersecurity #TPRM #VendorRisk #ThreatIntel