Você está no meio de um projeto com prazo apertado e alguém do time sugere: “em vez de construir isso do zero, por que não usamos um componente pronto?” A resposta parece óbvia — vai sair mais rápido, custa menos esforço de engenharia, e tem gente especializada cuidando daquele pedacinho do sistema. O problema é que quase ninguém para pra perguntar a pergunta seguinte: quem garante que esse componente não vai virar o ponto mais frágil do seu sistema daqui a seis meses?
Essa decisão — construir internamente ou trazer algo pronto de fora — aparece o tempo todo em projeto de software, e ela tem nome técnico. Vale entender a diferença antes de discutir risco.
COTS e software de terceiros não são a mesma coisa
COTS (Commercial Off-The-Shelf) é solução pronta, empacotada, vendida pra qualquer cliente sem customização profunda. Você adapta seu processo ao produto, não o contrário. Pense em um WAF comercial, um gestor de identidade, uma suíte de CRM.
Software de terceiros normalmente é desenvolvido sob encomenda por uma empresa especializada, com mais espaço pra adaptar às suas necessidades específicas — mas também com prazo, custo e processo de integração próprios.
A diferença importa porque o nível de controle que você tem sobre cada um é diferente. Com COTS, você quase nunca vê o código-fonte e não negocia arquitetura. Com terceirizado sob medida, às vezes dá pra negociar cláusula de auditoria, acesso a repositório, ou pelo menos relatório de teste de segurança do fornecedor.
Por que vale a pena trazer algo de fora
Não é só preguiça de escrever código. Duas razões concretas sustentam essa decisão:
Prazo. Construir internamente do zero pode ser o caminho “certo” em teoria, mas na prática o cronograma raramente permite. Se o seu diferencial competitivo não está naquele componente específico — um sistema de pagamento, um motor de busca, um parser de PDF —, adotar algo pronto libera seu time pra focar no que de fato diferencia o produto.
Transferência de risco (parcial). Bug e vulnerabilidade num componente comprado passam a ser, ao menos em parte, responsabilidade contratual do fornecedor. Isso não elimina o risco pro seu sistema — se o componente falhar, o seu usuário sofre o impacto, não o fornecedor —, mas muda quem tem obrigação de corrigir e em que prazo.
Onde a decisão costuma dar errado
Aqui está o ponto que o marketing de “acelere seu delivery com soluções prontas” nunca menciona: integrar terceiro pode aumentar o risco total do sistema, não diminuir.
Erros internos versus externos se somam, não se cancelam. Mesmo desenvolvendo tudo internamente, seu time comete erro por revisão insuficiente ou processo mal definido. Ao integrar um componente externo, você não elimina essa fonte de erro — você soma uma nova. A pergunta que precisa ser respondida antes da integração é: essa solução pronta realmente reduz o risco agregado, ou só move o problema pra um lugar onde você tem menos visibilidade?
Licenciamento e SLA são onde o diabo mora. Contrato de licenciamento e SLA costumam vir em português jurídico (ou pior, em inglês jurídico) cheio de cláusula que define desde política de atualização até quem tem direito de acesso ao código-fonte em caso de falência do fornecedor. Com COTS, o código normalmente é uma caixa-preta total. Com terceirizado, às vezes dá pra negociar mais transparência — ou pelo menos uma garantia contratual de manutenção e resposta a vulnerabilidade.
Segurança e conformidade exigem verificação ativa, não confiança. Antes de assinar qualquer contrato, valem três perguntas diretas:
- O fornecedor faz teste interno e, idealmente, auditoria externa independente pra validar a segurança do produto?
- Existe alguma certificação (CMMI, ISO 27001, ou equivalente) que indique maturidade real de processo, não só marketing?
- Como o fornecedor trata vulnerabilidade descoberta depois do lançamento? Existe cronograma claro de correção, ou você só descobre o problema quando ele já foi explorado?
Se a resposta pra qualquer uma dessas for “não sei” ou “o vendedor disse que está tudo certo”, isso é sinal de alerta, não de segurança.
Um checklist antes de aprovar um fornecedor
Isso aqui não substitui revisão jurídica, mas é o mínimo que o time técnico deveria levantar antes de dar aval pra integração:
[ ] O fornecedor tem histórico público de resposta a CVE em prazo razoável?
[ ] O contrato define SLA específico para correção de vulnerabilidade crítica
(não só "melhor esforço")?
[ ] Existe cláusula de acesso ao código-fonte em caso de descontinuidade
do fornecedor (escrow)?
[ ] O componente pode ser isolado (container, sandbox, rede segmentada)
caso uma vulnerabilidade seja descoberta e o patch demore?
[ ] Alguém do seu time efetivamente testou a integração antes de ir
para produção, além de confiar na documentação do fornecedor?
Se você chegou até aqui achando que isso é trabalho demais pra “só usar uma biblioteca pronta”, pense no cenário oposto: um componente de terceiro comprometido dentro do seu sistema tem o mesmo poder de causar incidente que uma falha no seu próprio código — só que você tem muito menos controle pra corrigir rápido, porque depende do cronograma de outra empresa.
Nem tudo precisa da mesma régua
Vale dizer com honestidade: nem toda integração merece esse nível de rigor. Uma biblioteca de formatação de data, amplamente usada, com histórico de anos sem incidente grave, não pede o mesmo processo que um gateway de pagamento ou um componente de autenticação. O critério prático é: quanto mais próximo esse componente estiver de dado sensível, de autenticação, ou de superfície de ataque exposta à internet, mais rigor a avaliação exige. Aplicar processo pesado em toda dependência trivial só ensina o time a ignorar o processo quando ele realmente importa.
Onde isso se conecta com o resto da sua estratégia de segurança
Avaliar COTS e software de terceiros com critério não substitui as práticas internas de segurança — patch management, monitoramento contínuo, revisão de código continuam necessários mesmo depois que o componente está integrado. O que muda é que agora você tem uma peça do seu sistema cuja manutenção depende do cronograma de outra empresa, e isso precisa entrar no seu radar de risco com a mesma seriedade que qualquer código escrito pelo seu próprio time.
Se o assunto que te interessa aqui é como estruturar essa análise de risco de forma mais ampla — não só para fornecedores externos, mas para o projeto como um todo —, é o tema do próximo artigo aqui no blog.
