Siga ZDNET: Adicione-nos como fonte preferencial no Google.
Principais conclusões da ZDNET
- A implantação contínua faz com que os modelos de segurança antigos pareçam obsoletos.
- Os backlogs de vulnerabilidade sobrecarregam as equipes de desenvolvimento.
- A segurança dos aplicativos precisa avançar em direção à criação de código.
Durante todo o tempo que passei me exercitando em esteiras, sempre as achei um pouco desmoralizantes. Você bate e bate repetidamente, mas não chega a lugar nenhum. É muito esforço. Você sempre sua um pouco, mas no last das contas se sente insatisfeito. Esse sentimento é reforçado no dia seguinte, quando você tem que fazer tudo de novo.
Em muitos aspectos, a segurança dos aplicativos é como uma esteira. Depois que a codificação é concluída, as equipes de segurança (ou clientes) encontram falhas. As ferramentas de verificação também encontram falhas, muitas vezes resultando em relatórios que parecem intermináveis. Os programadores são constantemente afastados de novos desenvolvimentos para reaprender o que escreveram, localizar bugs, corrigi-los e lançar correções.
Além disso: 77% dos gerentes de TI dizem que seus agentes de IA estão fora de controle – 5 maneiras de controlar os seus
Mas então, como na esteira, o ciclo se repete quando novos códigos, novas dependências e novas vulnerabilidades aparecem. Porque, é claro, eles vão.
Esse processo frustrante costuma ser chamado de ciclo de encontrar e consertar. As equipes de segurança e controle de qualidade usam scanners de vulnerabilidade e testes de penetração. Quando problemas são encontrados, como acontecerá, os desenvolvedores trabalham a partir dos relatórios de bugs, configuram filas de triagem e, às vezes, dedicam períodos de tempo para sprints de correção.
Encontrar e consertar não é tanto uma estratégia de desenvolvimento, mas uma resposta reativa ao código de remessa. A esperança é que as falhas de segurança (todas as falhas, na verdade) possam ser identificadas e corrigidas após o lançamento, mas antes que causem danos graves ou antes que seus clientes apareçam à sua porta com forcados e tochas, exigindo código confiável.
Algumas falhas de segurança são encontradas tão profundamente em códigos mais antigos que não é prático corrigi-las. Mudança de código após mudança de código foi colocada em uma base já instável e comprometida. Chegar à causa raiz exigiria destruir tudo, o que sem dúvida quebraria ainda mais.
Além disso: perguntei a 5 líderes de dados sobre como eles usam IA para automatizar – e acabar com os pesadelos de integração
É aí que entra em jogo outra prática consagrada, mas abaixo do superb, defender e adiar. Em vez de consertar códigos vulneráveis e profundamente arraigados, os programadores e as equipes de segurança adicionam paredes de proteção ao seu redor. Firewalls, proteções de tempo de execução, monitoramento, controles de compensação, segmentação, restrições de acesso e mitigações de emergência reduzem um pouco a exposição, enquanto a fraqueza subjacente do aplicativo permanece sem solução.
Mas pelo menos há alguma defesa em vigor, certo? Certo?
Aqui está a questão. As práticas de encontrar e consertar e defender e adiar nunca desaparecerão completamente. Não importa quão boas sejam nossas melhores práticas, a vida encontrará um caminho. Sempre haverá um comportamento inesperado. Dada a natureza não determinística dos grandes modelos de linguagem, essa possibilidade é ainda mais verdadeira na period da IA.
Além disso: quase metade dos profissionais de segurança cibernética querem desistir – eis o porquê
As práticas de encontrar e consertar e defender e adiar não são mais suficientes. O desenvolvimento de software program avança muito rápido, especialmente porque os desenvolvedores usam mais assistência de IA para criar novas versões e novos recursos na velocidade da máquina.
Lançamentos mais rápidos, correções mais lentas
Antigamente, o software program entregava atualizações e novas versões periodicamente. Grandes lançamentos eram lançados uma vez por ano. Atualizações, talvez, uma vez por trimestre. Mas agora, com CI/CD (integração contínua/implantação contínua), a palavra-chave é “contínuo”.
Cada ajuste, cada dash, cada correção de bug, cada atualização de dependência, cada alteração na configuração da nuvem, cada nova integração de API e cada sessão de codificação assistida por IA podem quebrar coisas e introduzir novos problemas de segurança mais rápido do que as equipes de segurança tradicionais conseguem revisá-los.
Além disso: essas quatro vulnerabilidades críticas de IA estão sendo exploradas mais rápido do que os defensores conseguem responder
E esse foco nem sequer considera a mitigação. Quando as equipes de segurança revisam o código, seja ele assistido por IA ou não, muitas vezes revelam centenas ou milhares de problemas que precisam ser corrigidos. Os problemas estão sendo encontrados mais rápido do que os desenvolvedores conseguem consertar de forma realista.
Pior ainda, a maioria das correções afasta os desenvolvedores da inovação e do desenvolvimento de novos códigos, resultando em uma mudança de contexto dolorosa e que prejudica a produtividade. É por isso que a maioria dos softwares tem uma fila de problemas e vulnerabilidades não resolvidos que precisam ser priorizados, redefinidos, aceitos, adiados ou ignorados regularmente.
De acordo com Para o provedor de plataforma de segurança Edgescan, os problemas de rede levam em média 54 dias para serem corrigidos. Os aplicativos da net levam quase 75 dias para serem corrigidos. O problema é pior nas grandes empresas. De acordo com a análise da Edgescan, 45% das vulnerabilidades de grandes empresas permanecem sem correção após um ano inteiro.
Esta situação não é boa. O software program pode criar problemas para os usuários. As vulnerabilidades podem ser exploradas por invasores, bots e grupos criminosos. Vulnerabilidades conhecidas, mas não corrigidas, são tão populares que as informações sobre elas são vendidas a outras pessoas que desejam invadir sistemas.
Além disso: as maiores ameaças de IA vêm de dentro – 12 maneiras de defender sua organização
Quando se trata de violações, Relatório de incidente de violação de dados de 2025 da Verizon determinou que 20% dos agentes de ameaças obtiveram acesso inicial aos sistemas através de vulnerabilidades de código, um aumento de 34% em relação ao ano anterior. Os outros dois principais métodos de acesso foram abuso de credenciais (22%) e ataques de phishing (16%).
Em outras palavras, corrigir vulnerabilidades pode ter bloqueado 20% de todos os ataques de violação, mas o sucesso não é tão simples.
Aqui está outra estatística que reforça esse problema. Empresa de análise de segurança VulnCheck relatado que, “32,1% dos KEVs tinham evidências de exploração no dia ou antes do dia em que o CVE foi emitido, um aumento de 23,6% em 2024.”
Resumindo, os bandidos sabiam das vulnerabilidades, KEV significa vulnerabilidades exploradas conhecidas, antes que os fornecedores soubessem que elas precisavam ser corrigidas. CVEs (vulnerabilidades e exposições comuns) são o mecanismo frequentemente usado para notificar e rastrear a resolução de vulnerabilidades conhecidas.
Basicamente, a estatística VulnCheck relatou que quase um terço de todas as vulnerabilidades estavam nas mãos de malfeitores e eram exploradas ativamente antes que os desenvolvedores que poderiam consertar as vulnerabilidades descobrissem sobre elas.
Não podemos simplesmente corrigir mais rápido
Infelizmente, não podemos simplesmente exigir que os desenvolvedores corrijam o código com maior velocidade ou produtividade. Além dos limites físicos dos codificadores humanos, ou mesmo do desempenho aprimorado, mas dos limites práticos, de nossos senhores da IA, existem preocupações práticas.
Os sistemas empresariais têm dependências, requisitos de tempo de atividade, quadros de controle de alterações, restrições regulatórias, compromissos com os clientes, integrações frágeis e equipes que podem não possuir o código vulnerável.
Além disso: lançando IA? 5 táticas de segurança que sua empresa não pode errar – e por quê
Sistemas menores podem depender de componentes ou elementos fora de seu controle. Por exemplo, acordei uma manhã esta semana e descobri que cinco dos meus websites legados não estavam mais funcionando. Esses websites estavam funcionando perfeitamente. Eles estavam inalterados há pelo menos sete anos.
O operador de hospedagem alterou uma versão de um sistema de software program crítico sem aviso prévio e alguns dos meus códigos personalizados pararam de funcionar. Levei alguns dias para me atualizar sobre o que meu código fazia e, em seguida, localizá-lo e corrigi-lo. E isso foi com a ajuda do OpenAI Codex.
Depois, há a questão do cansaço da priorização. Quando cada vulnerabilidade se torna crítica, é como se nada fosse essential. Você já teve um dia em que priorizou sua lista de tarefas e percebeu que tinha 30 tarefas de alta prioridade? Eu vejo você balançando a cabeça. Nesse ponto, é simplesmente opressor e nenhum problema se destaca.
Além disso: a IA tornará a segurança cibernética obsoleta ou o Vale do Silício está confabulando novamente?
Mesmo as verificações de vulnerabilidades baseadas em IA não ajudarão você a lidar com o desafio. Superferramentas, como Anthropic Mythos, ou ferramentas ainda mais acessíveis, como Claude Safety ou Segurança do Códicerealmente não consigo resolver o problema. Um painel cheio de descobertas pode criar a aparência de controle, enquanto as práticas de engenharia subjacentes continuam a produzir as mesmas categorias de defeitos.
É neste ponto que os operadores de TI muitas vezes tentam a abordagem de defesa e adiamento usando ferramentas como firewalls de rede ou de aplicativos, sistemas de detecção e prevenção de intrusões, detecção e resposta de endpoints, segmentação de rede, limitação de taxa, registro e monitoramento, autoproteção de aplicativos em tempo de execução ou até mesmo aplicação de patches virtuais.
Estes “controlos compensatórios” são por vezes essenciais, mas podem tornar-se um substituto permanente para a resolução das causas profundas. Essa prática é perigosa porque cercar software program fraco com uma estrutura de ferramentas de segurança não resolve o problema subjacente: código fraco.
A correção após o fato não é apenas insegura, é muito cara. Sim, às vezes é necessário (como quando, uma década depois de escrever uma linha de código usando os padrões da época, um lançamento de sistema operacional muito posterior o quebrou). Mas codificar defensivamente e fazer correções enquanto o código authentic está sendo desenvolvido é muito menos demorado e doloroso do que identificar, fazer triagem, corrigir, validar, implantar e monitorar correções emblem após o lançamento.
O desenvolvimento moderno mudou a equação do risco
É difícil precisar exatamente quando as práticas de “desenvolvimento moderno” começaram, porque cada pessoa tem uma perspectiva diferente. Mas é justo dizer que os ciclos de vida de desenvolvimento mudaram quando passamos do envio de atualizações em disco para a criação de serviços centrados na nuvem. Depois, a prática mudou novamente nos últimos anos, quando o desenvolvimento assistido pela IA se tornou uma força transformadora.
O fato é que nossa abordagem ao desenvolvimento de software program é diferente da época em que encontrar e consertar period o jeito do mundo. O risco de aplicação agora permeia todo o ciclo de vida do software program: escolhas de design, práticas de codificação, seleção de dependências, tratamento de segredos, controles de identidade, pipelines de construção, configurações de implantação e exposição em tempo de execução.
Além disso: por que os agentes empresariais de IA podem se tornar a maior ameaça interna
Como venho discutindo no ano passado, A IA mudou radicalmente os prazos de lançamentoacelerando cronogramas e reduzindo cronogramas. Infelizmente, esse aumento na velocidade pode ampliar a lacuna entre a criação de código e a revisão de segurança. No mínimo, o quantity de código produzido aumentou à medida que o tempo para criar o código diminuiu.
O tempo de teste, por outro lado, não diminuiu. Estou trabalhando em um aplicativo para Mac no Claude Code há cerca de quatro meses. O processo actual de escrita de código leva cerca de 20 minutos em cada sessão. Mas como meu código usa IA no dispositivo para análise sofisticada de documentos, o teste leva horas em cada sessão.
Meu tempo de codificação reduziu-se a um mero erro de arredondamento, mas o tempo de teste agora ocupa a maior parte do meu tempo de desenvolvimento. Ainda assim, sem ter IA para o processo inicial de escrita do código, provavelmente não teria tempo de terminar este projeto, sempre que isso acontecesse.
Além disso: 7 técnicas de codificação de IA que uso para enviar produtos reais e confiáveis - rápido
O principal problema é que o código gerado pela IA não é necessariamente um código seguro. Empresa de monitoramento de IA Snyk relatou que 56,4% dos desenvolvedores frequentemente encontraram problemas de segurança em código gerado por IA, enquanto 80% ignoraram ou contornaram as políticas organizacionais de segurança de código de IA.
Mudando onde começa a segurança do aplicativo
Neste artigo, analisamos o que acontece à medida que a produção de software program acelera, mas a segurança continua sendo um problema posterior: a esteira acelera. Mais código significa mais problemas, que são encontrados mais rápido do que os desenvolvedores conseguem voltar e fazer as correções.
Para ser claro, nunca seremos capazes de abandonar as práticas de encontrar e consertar ou defender e adiar. Coisas acontecem. Sempre precisaremos empregar varredura, correção, monitoramento e defesa de tempo de execução até certo ponto. Mas estas práticas deveriam ser migradas para uma rede de segurança de segundo nível.
Os backlogs de vulnerabilidades parecem um processo gerenciável ou uma fila interminável em sua organização? Deixe-nos saber nos comentários abaixo.
Você pode acompanhar as atualizações diárias do meu projeto nas redes sociais. Certifique-se de se inscrever meu boletim informativo semanal de atualizaçãoe siga-me no Twitter/X em @DavidGewirtzno Fb em Facebook.com/DavidGewirtzno Instagram em Instagram.com/DavidGewirtzno Bluesky em @DavidGewirtz.come no YouTube em YouTube.com/DavidGewirtzTV.
