CEO
Diogo Goebel
Quando uma empresa é adquirida, o comprador herda tudo. Contratos, clientes, time, cultura e também o software, com todo o histórico de decisões que ninguém documentou, dependências desatualizadas e vulnerabilidades não tratadas. Esse passivo raramente aparece no valuation.
A due diligence financeira evoluiu muito nas últimas décadas. A de segurança, menos. E a de cadeia de software, que envolve mapear quais componentes estão no código, de onde vieram, quais CVEs carregam, se existe rastreabilidade de proveniência, praticamente não existe como prática estruturada na maioria das transações.
E o custo dessa lacuna está começando a aparecer.
Segundo o relatório CISO Redefined III, publicado pela FTI Consulting em março de 2026, 1 em cada 4 executivos enfrentou um incidente cibernético durante ou logo após uma transação. Entre os afetados, 42% relataram redução de valuation e 58% tiveram metas financeiras comprometidas. São números que não entram no pipeline do deal, mas aparecem no resultado depois do fechamento.
Outro dado que me chamou atenção: apenas 23% das empresas gerenciam riscos cibernéticos de forma proativa após o fechamento. O risco é herdado, mas o processo de gestão não vem junto. Some a isso o fato de que 1 em cada 4 CISOs relata pressão para fechar negócios rapidamente em detrimento da due diligence cibernética, e a equação fica clara: a velocidade do deal comprime o espaço onde os problemas ficam escondidos.
O que ainda falta nessa equação é o olhar para a cadeia de software em si.
Newsletter Quor
O que o scanner de vulnerabilidades não responde em uma due diligence
Um scanner de vulnerabilidades passa pelo binário e aponta o que está exposto hoje, mas não responde de onde veio aquela dependência, se ela tem histórico de CVEs críticas sem remediação, se existe SBOM documentando os componentes, se a proveniência do build é verificável. Essas perguntas ficam sem resposta e é nesse ponto que o haircut de valuation acontece, quando alguém mais preparado senta do outro lado da mesa.
Tem outro sinal que costuma passar despercebido: quando a empresa-alvo gasta boa parte do tempo dos seus desenvolvedores seniores corrigindo vulnerabilidades que já nasceram na imagem base, o valuation de engenharia dela é fictício. O que parece capacidade de entrega é, na verdade, time caro fazendo manutenção de dívida técnica que o comprador vai herdar.
BCB 538 e CMN 5.274: cadeia de software virou passivo regulatório
No contexto brasileiro, esse risco tem um multiplicador que ainda não está sendo precificado. BCB 538 e CMN 5.274, em vigor desde março de 2026, tornaram a cadeia de software dos fornecedores responsabilidade da instituição financeira. Uma empresa-alvo sem evidência técnica de integridade na sua cadeia de software não é só risco operacional para quem compra. É passivo regulatório que o comprador herda no momento em que assina.
Para uma instituição financeira adquirindo uma fintech ou um provedor de tecnologia, a pergunta "quais são as CVEs abertas?" passou a ser insuficiente. A pergunta que importa agora é: você consegue provar, por versão e por componente, que sua cadeia de software está em conformidade com o que o regulador exige?
Se a resposta depender de planilhas, tickets e memória institucional, o risco está precificado errado.
O que muda na prática é simples de enunciar e difícil de executar: o comprador precisa incluir na due diligence técnica a verificação de SBOM, histórico de remediação de CVEs por versão, rastreabilidade de proveniência e evidência de conformidade regulatória da cadeia de software. Não como checklist de compliance, mas como insumo obrigatório de valuation.
Enquanto isso não for padrão, quem souber fazer essa pergunta antes do fechamento vai ter vantagem. E quem não souber vai descobrir o problema depois, quando o preço já foi pago.
Com o Quor, segurança vira vantagem competitiva. Descubra como em uma demo personalizada.