Clientes endurecem o DevSecOps: fornecedores são verificados em cada etapa do build

Em dezembro de 2020, a atualização trojanizada do SolarWinds Orion chegou a cerca de 18 000 clientes da empresa. O episódio mostrou à indústria que o ponto vulnerável pode não ser o produto, mas o caminho que ele percorre até chegar ao cliente. O mercado russo chega à mesma conclusão. De acordo com o TAdviser, os clientes adotam um zero trust cada vez mais profundo em relação aos fornecedores de TI e exigem um "pipeline estéril" de desenvolvimento, com verificação repetida do código. A base da abordagem é o DevSecOps, ciclo de criação de software em que a segurança faz parte de cada etapa, em vez de ser acrescentada antes do lançamento.

De onde vem a desconfiança

O modelo clássico era simples. O fornecedor escreve o código, entrega o build e o cliente faz a homologação. Tudo o que acontece dentro da empresa contratada permanece uma caixa-preta. Mas o fornecedor é feito de notebooks de desenvolvedores, bibliotecas de terceiros, repositórios em nuvem e sistemas de CI, e qualquer um desses elementos pode ser comprometido.

Os exemplos são conhecidos. A vulnerabilidade Log4Shell, do fim de 2021, mostrou como uma única biblioteca de logging vai parar em milhares de produtos cujos donos nem suspeitam disso. O backdoor no arquivador XZ Utils (CVE-2024-3094), descoberto em 2024, foi plantado por meio de uma longa campanha de engenharia social contra o mantenedor do projeto. O princípio de zero trust, formalizado na NIST SP 800-207, determina que cada participante e cada ação sejam verificados. Agora ele passa a ser aplicado ao desenvolvimento.

Como é o "pipeline estéril"

O texto do TAdviser trata de uma tendência, não de um padrão único, e por isso o conjunto de medidas varia de cliente para cliente. Um ambiente típico tem este formato:

• ambiente de build isolado, sem acesso à internet e com um conjunto limitado de dependências externas;
• análise estática de código (SAST) a cada commit e análise dinâmica (DAST) em ambientes de teste;
• análise de composição (SCA): inventário de componentes de terceiros e busca por vulnerabilidades conhecidas;
• SBOM, a lista de todos os componentes do build, como artefato obrigatório da entrega;
• varredura de repositórios em busca de segredos: chaves, tokens, senhas;
• revisão de código obrigatória por uma segunda pessoa e assinatura dos artefatos gerados;
• nova verificação dos códigos-fonte e do build no lado do cliente.

A palavra-chave aqui é "repetida". O mesmo código é analisado no fornecedor, depois no cliente e, às vezes, também por um laboratório independente. Cada camada pega o que a anterior deixou passar. E cada uma parte do princípio de que a anterior pode ter sido comprometida.

O custo para o fornecedor

Para quem presta o serviço, isso significa custos maiores e reestruturação de processos. São necessários ambientes de build dedicados, licenças de ferramentas de análise, especialistas em desenvolvimento seguro e uma disciplina que times pequenos muitas vezes não têm. Saem ganhando os integradores maduros, que já têm o DevSecOps incorporado à produção. Estúdios menores terão de se adaptar ou migrar para segmentos com requisitos menos rígidos.

Há também o outro lado. Verificações repetidas atrasam os lançamentos, e parte dos alertas dos analisadores é falso positivo, que, sem triagem, vira ruído. O cliente que exagera no controle acaba pagando com prazo.

Por onde começar

O cliente deve registrar em contrato os requisitos de desenvolvimento seguro: formato do SBOM, periodicidade das varreduras, direito de auditoria e procedimento de resposta a vulnerabilidades encontradas. Faz sentido separar os fornecedores pela criticidade dos sistemas e não aplicar o controle máximo de forma igual em todos os casos.

Para o fornecedor, vale começar pelo básico: ativar a varredura de segredos e dependências no CI já existente, tornar a revisão de código obrigatória e aprender a gerar o SBOM automaticamente. Esses passos custam menos que os demais e já respondem às principais perguntas dos auditores. Quem se preparar antes de o requisito aparecer em uma licitação terá vantagem sobre quem começar depois.