Temos um ano para consertar a segurança em todo lugar
Os avanços em grandes modelos de linguagem estão intensificando o medo de que ferramentas automatizadas em breve consigam encontrar e explorar vulnerabilidades de software em escala, transformando a postura de segurança já frágil de hoje em um ambiente muito mais perigoso. Os comentadores debatem se respostas tradicionais — correção de falhas, linguagens seguras quanto à memória e verificação formal — conseguem acompanhar, ou se mudanças mais profundas são necessárias, como sistemas baseados em microkernels, redução agressiva de dependências, infraestrutura crítica isolada e regulamentação mais rígida. Muitos veem usos defensivos fortes para a IA também, mas argumentam que incentivos, governança e a complexidade do mundo real tornam improvável que as defesas avancem tão rápido ou sejam implantadas tão amplamente quanto os novos ataques automatizados.
LLMs como Aceleradores de Segurança Ofensiva
- Vários comentadores relatam LLMs encontrando vulnerabilidades reais em minutos quando apontados para bases de código em produção.
- Preocupação de que modelos locais baratos e sem censura tornem viáveis “ataques de for-loop”: varrer CT logs, repositórios de altcoins, stacks de e-commerce, etc.
- Receio de que a “cauda longa” de bugs obscuros em software corporativo e appliances se torne explorável em escala.
- Alguns acham que o prazo de “um ano” é generoso demais; outros observam que estamos em um modo parecido de “última chance de consertar a segurança” há décadas.
Usos Defensivos e Seus Limites
- LLMs podem ajudar com fuzzing, testes de propriedades, revisão de código e provas formais, mas os defensores enfrentam atrito organizacional: aprovações, testes, patches de fornecedores.
- Assimetria: atacantes precisam de apenas um exploit bem-sucedido; defensores precisam gerenciar todos os riscos continuamente.
- Sugestão de que a “segurança de base” futura pode melhorar depois que os LLMs eliminarem os frutos mais fáceis.
Sistemas, Modelos de SO e Superfície de Ataque
- Forte defesa de microkernels, sistemas de capacidades, air-gaps, diodos de dados e minimização de código confiável; Linux/Windows são vistos como fundamentalmente grandes demais e baseados em autoridade ambiente.
- Outros enfatizam o endurecimento prático do que já existe: defense-in-depth, sandboxing, zero trust, whitelisting de aplicativos, exposição de rede estrita.
Web, CMS e Inchaço de Dependências
- WordPress, plataformas de e-commerce e plugins/módulos são exemplos frequentes de segurança frágil; muitos recomendam sites estáticos ou abordagens de “headless CMS”.
- Objeções: usuários não técnicos dependem de plataformas ricas; ferramentas estáticas/JAMstack e fluxos centrados em Git ainda não atendem às suas necessidades.
Linguagens, Mitigações de Hardware e C/C++
- Muitos endossam linguagens seguras quanto à memória e recursos de hardware como memory tagging; outros argumentam que a adoção é lenta demais.
- Debate recorrente “não escreva C/C++ novo” vs. “C/C++ são bons se você for cuidadoso”; RAII em C++ é elogiado, mas a complexidade da linguagem e armadilhas de legado são criticadas.
Regulação, Incentivos e Cultura de Risco
- Observação frequente: invasões raramente têm consequências sérias, então as empresas otimizam para auditorias e conformidade de checklist, não para verdadeira resiliência.
- Alguns pedem notificação obrigatória de incidentes e responsabilização, semelhante a auditoria financeira; outros apontam a dificuldade prática de detectar e relatar todas as violações.
Riscos Mais Amplos de IA e Sociais
- A discussão deriva para preocupações com engenharia social habilitada por IA, riscos biológicos, terrorismo e cenários de “great filter”/ASI, com forte discordância sobre quão realistas ou iminentes eles são.