Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
De vez em quando, o mundo da TI é tomado por um ressurgimento de preocupações — às vezes uma tendência passageira, outras vezes uma questão significativa. Ultimamente, o termo “dívida de segurança” tem circulado pelas plataformas de notícias de TI. Este artigo tem como objetivo explicar a essência da dívida de segurança e suas implicações.
Da dívida técnica à dívida de segurança
O conceito de “Dívida Técnica” é conhecido por muitos; ele se refere aos desafios que surgem à medida que os projetos se expandem além de proporções gerenciáveis. Esse “tamanho” pode ser medido em linhas de código, módulos, funções ou outras métricas, refletindo a capacidade de uma equipe de adicionar novos recursos e, ao mesmo tempo, manter o código existente.
Por exemplo, é muito mais difícil adicionar novas funcionalidades a um aplicativo maduro do que ao mesmo aplicativo quando o desenvolvimento está apenas começando. Há menos componentes em movimento e menos interações entre as diferentes partes do código, o que torna menos provável que a adição de novos recursos prejudique os já existentes. À medida que o aplicativo evolui, cada alteração pode provocar uma interação inesperada em algum outro ponto do código. Isso significa simplesmente “você adicionou um bug”, na linguagem dos desenvolvedores. Diante de tempo e recursos limitados, os desenvolvedores precisam conciliar novos desenvolvimentos com correções de bugs, o que retarda o progresso geral. Esse acúmulo de tarefas de manutenção constitui a “dívida técnica”.
Alguns — se não todos — desses erros, quando permanecem no código por tempo suficiente, podem se transformar em problemas de segurança. Por exemplo, uma variável com estouro de sobrefluxo ou subfluxo em algum lugar pode significar simplesmente que um relatório receba um valor incorreto ou, se alguém encontrar uma maneira de acioná-la, pode levar à corrupção de memória em partes não relacionadas do aplicativo. Essa é a “Dívida de Segurança” – ou seja, os bugs de segurança que permanecem no código, às vezes por meses ou até anos, até que alguém consiga corrigi-los. Se não forem tratadas, essas vulnerabilidades podem ser exploradas antes de serem corrigidas.
Então, por que isso está voltando à moda?
O principal culpado é a complexidade. As bases de código só ficam cada vez maiores. Sempre vemos novos recursos sendo adicionados aos softwares, nunca o contrário. Isso significa que mais código é adicionado, e não removido. Nossos cérebros humanos têm dificuldade em compreender totalmente as complexidades de nossas criações digitais.
Considere a base de código do kernel do Linux, que cresceu de 2,4 milhões de linhas de código em 2001 para mais de 20 milhões em 2015. Ninguém — nem mesmo uma equipe — é capaz de compreender adequadamente todos os seus aspectos. Portanto, sempre que alguém adiciona uma nova linha de código, ela pode funcionar perfeitamente ou pode causar uma falha grave em outro lugar. Jogar uma moeda daria chances iguais.
Isso não é exclusivo do Kernel, nem mesmo de projetos dessa magnitude, nem mesmo de projetos de código aberto em geral. Esse aumento de complexidade ocorre da mesma forma em softwares proprietários de código fechado; simplesmente não temos métricas de tamanho de código para comprovar isso. Se você analisar os tamanhos dos binários para fazer uma comparação, o Windows 95 era fornecido em 13 disquetes de 1,68 MB (não é um erro de digitação; esses disquetes usavam um layout de trilha diferente para acomodar mais dados e serviam também como mecanismo de proteção contra cópias). O Windows 11 é fornecido como uma imagem ISO de aproximadamente 5 GB.
Então, sim, a base de código aumentou.
Também não é porque os desenvolvedores de repente ficaram piores. Um desenvolvedor comum talvez consiga compreender com precisão algumas dezenas de linhas de código de memória. Um bom desenvolvedor, cerca do dobro ou do triplo disso (estou sendo intencionalmente vago, pois isso é difícil de avaliar). Para todos, olhar para um código que não viam há alguns dias ou semanas é como ler uma língua estrangeira pela primeira vez, e a mudança de contexto leva tempo para acontecer.
Compreender projetos na íntegra não é mais algo que se espera. O fato de programarmos com erros é um forte lembrete disso.
É só isso?
O problema é agravado pela “complexidade oculta”, introduzida a cada biblioteca ou componente de terceiros adicionado. Um relatório recente destacou que um projeto Java médio possuía aproximadamente 150 dependências, um aumento significativo em relação ao ano anterior. Essa complexidade agrava a tarefa já desafiadora de gerenciar o código próprio.
Abordando a dívida em matéria de segurança
Todo esse código contém, por natureza, erros, muitos dos quais são problemas de segurança em si. Lidar com eles de maneira correta e oportuna é difícil. O grau de dificuldade depende de vários fatores:
- A rapidez com que são detectadas, o que, por sua vez, depende dos testes realizados no pipeline de desenvolvimento e compilação: se suas verificações de segurança ocorrerem no final de uma longa janela de mesclagem, com vários desenvolvedores fazendo commits de código durante um período prolongado, quando os alertas forem acionados, o esforço do desenvolvedor original para resolver o problema será muito maior, pois ele ou ela já não será mais capaz de lembrar o motivo pelo qual algo foi implementado daquela maneira.
- Quão abrangentes são seus testes: Você está testando apenas para problemas específicos? Talvez a análise estática esteja procurando apenas por padrões específicos, como variáveis com tipos incorretos, estouros de buffer ou uso de NULL. Outros problemas podem passar despercebidos até serem encontrados em ambiente real.
- O número total de problemas identificados: Se você tem uma grande lista de problemas de segurança pendentes a serem resolvidos, dispõe dos recursos — tempo, conhecimento e mão de obra — para corrigir todos eles? Você está estabelecendo prioridades? E se algo acontecer em outro lugar que faça com que um problema de baixa prioridade de repente se torne mais importante? Seu sistema é flexível o suficiente para reagir a isso?
A dívida de segurança envolve muitos aspectos, e este artigo aborda apenas algumas das principais questões. Seu objetivo foi alertar sobre o problema da dívida técnica se transformar em dívida de segurança quando a complexidade ultrapassa a capacidade de um desenvolvedor ou de uma equipe de gerenciá-la adequadamente.
Existem algumas táticas que podem ser empregadas ao lidar com essa questão: testes de segurança mais eficazes, testes de segurança realizados em um estágio mais precoce, testes de segurança antes do commit do código (em vez de verificar apenas depois que todos já tiverem feito o commit), revisão por pares, terceirização da verificação de bibliotecas de terceiros para uma empresa especializada, ou até mesmo a contratação de mais desenvolvedores à medida que as bases de código crescem. Isoladamente, nenhuma dessas sugestões resolverá o problema por completo, mas, juntas, elas podem conter a complexidade por mais algum tempo e mitigar seu impacto.
Observação: Se você quiser saber mais sobre o problema, o podcast “Enterprise Linux Security” tem um episódio, o 84, dedicado ao assunto. Você pode encontrá-lo em todas as plataformas de podcast ou no YouTube, com uma gravação ao vivo.
