O físico alemão Werner Heisenberg, em seu leito de morte, disse: "Quando eu encontrar Deus, vou lhe fazer duas perguntas: Por que a relatividade? E por que a turbulência? Eu realmente acredito que ele terá uma resposta para a primeira." É uma citação comumente atribuída erroneamente a Albert Einstein.
Mas o ponto é que os cientistas ficam extremamente desconfortáveis ao tentar modelar equações contra sistemas onde não conseguem prever o comportamento subjacente, e a turbulência na dinâmica de fluidos é um dos ambientes matemáticos mais imprevisíveis.
É onde estamos hoje com a segurança nas águas velozes da IA. O volume e a velocidade da geração de código estão criando novas pressões de retorno que estão além do raciocínio dos modelos do Velho Mundo de segurança de software. O que vai acontecer depois? Esta pode ser a primeira vez que alguém tenta explicar um problema de software falando sobre os modelos mentais em dinâmica de fluidos, mas, como engenheiro mecânico, não consigo deixar de observar os paralelos.
Como a turbulência quebra os modelos
A primeira parte importante da dinâmica de fluidos é um conceito chamado fluxo laminar, que descreve a maneira como o fluido se move através de um cano. Laminar é a abreviação de laminação, e você pode pensar em piso laminado ou camadas em um croissant.
Quando a água se move de forma laminar, ela não se move entre camadas. A água nas bordas do cano se move mais lentamente, porque está bem na superfície do cano. A água desliza por si mesma em camadas, e há um pequeno atrito que a desacelera entre os passos.
Quando você modela isso, você obtém uma curva legal — uma parábola legal que descreve esse fluxo, e é fácil prever a relação entre pressão e velocidade. O comportamento de diferentes tipos de fluido, que é conhecido como viscosidade, também é fácil de prever.
Os sistemas laminares são fantásticos porque são fáceis de modelar e entender. Você pode prever o comportamento de cada partícula de água conforme ela flui por aquele cano.
O que isso tem a ver com IA? Estamos chegando lá. Infelizmente, o fluxo laminar nem sempre acontece.
Se você começar a empurrar muita água pelo cano, se ela se mover muito rápido, ou se o cano ficar muito grande ou a viscosidade ficar muito baixa, o sistema quebra. Isso acontece com muitos sistemas complicados que são fáceis de modelar e prever, e então, de repente, eles não são mais — e então esse comportamento pode mudar rapidamente.
Quando isso acontece na água, muda para algo chamado turbulência. Com a turbulência, essa suposição legal que estamos fazendo sobre a água não cruzar entre camadas se desfaz, e agora essas partículas estão cruzando entre fluxos. Você não consegue mais processar isso, e não consegue explicar.
Quando cientistas tentam prever turbulência, suas teorias são todas baseadas em simulações de computador e experimentos para ver exatamente o que acontece. Então, mesmo que eles não consigam explicar, eles podem criar equações para modelar os cenários.
Os cientistas há muito tentam descobrir os "primeiros princípios" para modelar a turbulência, mas ainda não conseguem. Isso não significa que não podemos prever o comportamento, mas não podemos explicá-lo ou modelá-lo no nível de uma única partícula. Ainda podemos criar alguns modelos de regressão linear muito bons ou outras estruturas para determinar o que acontecerá a um sistema com uma determinada entrada de pressão. Mas as suposições mudam completamente.
A segurança do software está em fluxo de transição
Hoje, muitos desenvolvedores estão usando ferramentas de IA para ajudar a escrever software mais rápido, mas muito menos usam IA para revisar solicitações de pull e código que sua equipe está escrevendo. É semelhante à mudança do fluxo laminar para o fluxo turbulento.
O fluxo laminar é onde ainda estamos hoje na maioria dos lugares nos modelos que usamos para escrever e proteger software. Os desenvolvedores escrevem código, os desenvolvedores revisam o código e os desenvolvedores contam com a revisão de código no nível de solicitação de pull individual e linha de código quando procuram defeitos de segurança e vulnerabilidades.
Projetos de código aberto têm uma lista definida de mantenedores, e eles revisam o código dos contribuidores. Pesquisadores de vulnerabilidade descobrem novas vulnerabilidades o tempo todo. Eles recebem identificadores CVE exclusivos, e são rastreados por equipes de segurança em planilhas. É fácil de entender e simples de modelar.
Há um ditado que diz que todos os modelos estão errados, mas alguns são úteis. A verdadeira chave para esse ponto, para ir um pouco mais além, é que esses modelos e essas maneiras de pensar sobre desenvolvimento de software funcionam quando você sabe em qual regime está e sabe como modelar esses sistemas corretamente.
Mas se os desenvolvedores estão usando IA para escrever mais e mais código, mas não estão usando as mesmas técnicas para revisar esse código, agora estamos tendo mais água passando por esse cano do que podemos suportar, e essas suposições do modelo começam a desmoronar.
Na dinâmica de fluidos, quando algo começa a transitar de um modelo para outro, isso é chamado de fluxo transicional. Este é, na verdade, o tipo de sistema mais difícil de modelar e raciocinar. Essa transição também não acontece em um tempo definido. Existem algumas restrições e proporções que você pode tentar conectar e prever em qual estado você está, mas muito trabalho de engenharia é necessário para saber em qual regime você está operando e se é laminar ou turbulento.
A IA está a rebentar o cano
Quando um cano estoura, você pode ver a transição exata acontecendo de laminar para turbulência. Há um breve momento antes da explosão quando ele flui em um fluxo constante e agradável, e então bum, a explosão acontece.
É onde estamos hoje com a segurança da IA. Nem toda esperança está perdida. Ainda podemos obter bons resultados. Ainda podemos proteger sistemas. Mas definitivamente temos que começar a pensar diferente sobre os modelos, porque agora é óbvio que eles estão sendo sobrecarregados pelo novo volume e velocidade da IA.
Com a IA, a escala em que o desenvolvimento de software vai acontecer só vai aumentar. Os desenvolvedores estão escrevendo cada vez mais código usando esses sistemas. Todo código tem bugs, e alguns desses bugs têm impacto na segurança. Então, se os desenvolvedores estão escrevendo cada vez mais código, haverá cada vez mais defeitos de segurança nele.
Pesquisadores de segurança estão ficando mais produtivos na busca por bugs conhecidos sendo introduzidos em sistemas. Se eles estão encontrando mais vulnerabilidades do que as equipes podem triar e lidar, não seremos mais capazes de construir confiança e depender dos sistemas.
E o ritmo em que esses sistemas de IA estão sendo colocados em produção para processar cargas de trabalho sensíveis continua ficando mais rápido. É realmente difícil implantar sistemas com segurança, e quanto mais sensíveis os dados que eles estão acessando, é ainda mais difícil fazê-lo com segurança porque os riscos são muito maiores. As empresas estão apressando a IA nesses sistemas em um ritmo muito mais rápido do que qualquer outra coisa que já vi acontecer na minha carreira.
Quando combinamos todos esses fatores, vemos a segurança de software passando de algo laminar — onde é fácil entender, modelar e prever — para algo em que precisamos obter resultados úteis de um conjunto de dados turbulento, mesmo que não entendamos completamente cada partícula.
Precisaremos de novas técnicas. Teremos que começar a ajudar os desenvolvedores a revisar e detectar problemas de segurança apenas para acompanhar o ritmo em que novos softwares estão sendo escritos. Teremos que ajudar as equipes de segurança a lidar com novas permutações e vulnerabilidades mais rápido do que suas planilhas conseguem acompanhar, que é como a maior parte disso é gerenciada hoje.
Não há matemática simples aqui. Temos que mudar a maneira como pensamos e criar tipos de abordagens probabilísticas ou estatísticas. Teremos que adotar uma "abordagem de animais de estimação em transição para gado". Essa é outra analogia que você ouve muito em infraestrutura.
Se você tem apenas alguns sistemas ou computadores, você pode tratá-los com nomes e saber sobre cada um deles. Fazemos muito isso com vulnerabilidades hoje em dia em muitos contextos — cada um tem um identificador único, e pesquisadores de segurança lembram de muitos deles. Se essa escala se estender por 20 vezes, não seremos mais capazes de fazer isso.
Ataques de software de IA estão aumentando
Essa transição já está acontecendo, só não está distribuída uniformemente ainda.
Os desenvolvedores não conseguem mais acompanhar as revisões de código porque muitas delas vêm de pessoas em quem eles não confiam ou não conhecem, e é muito difícil detectar problemas de segurança no código que eles estão revisando agora.
Os invasores entendem que atacar sistemas é o caso de uso perfeito para um modelo de linguagem grande porque o custo de fazer algo errado é basicamente zero. Eles podem simplesmente continuar tentando repetidamente. Enquanto os defensores precisam ser perfeitos o tempo todo. E essa mudança está deixando as equipes de segurança desconfortáveis da mesma forma que os físicos ficam desconfortáveis ao discutir sistemas turbulentos.
Então o que fazemos aqui? Precisamos nos sentir confortáveis operando quando há muitas vulnerabilidades para dar nomes exclusivos, onde você não pode mais confiar em humanos capturando cada defeito de segurança em revisões de código.
Já sobrevivemos à transição para a turbulência antes
Essa corrida do ouro da IA não é a primeira vez que a indústria teve que adotar um novo fator de forma importante e aprender a confiar na segurança de componentes de software criados por outras pessoas. Fazemos isso com sucesso com código aberto há décadas.
E a infraestrutura usada para executar cargas de trabalho de IA hoje tem uma sobreposição muito próxima de 1:1 com a mesma infraestrutura que todos já estão executando — é basicamente Kubernetes com um pouco de CUDA espalhado, mais ou menos. Muitos de nós ainda temos cicatrizes de batalha de tentar implementar equipes de aplicativos Kubernetes multilocatários seguros, e isso não é mais difícil.
Brincar com kits de ferramentas de IA da fonte revela um ambiente de segurança incrivelmente rápido e turbulento. As compilações do PyTorch funcionam apenas com compilações CUDA específicas, que exigem versões superantigas do GNU Compiler Collection (GCC)/Clang para compilar. Os pacotes podem levar horas para serem construídos, mesmo em sistemas poderosos.
Também assustador: o estado dessas cadeias de suprimentos, com a maioria dos links levando a dumps aleatórios de fóruns. Se um CVE aparecesse em uma das bibliotecas nativas de baixo nível, não tenho certeza de como a indústria reagiria. A maioria dessas coisas é muito difícil de inicializar ou construir a partir do código-fonte, então seria uma bagunça.
Essas bibliotecas geralmente processam dados de treinamento completamente não confiáveis e não higienizados, e o espaço da IA como um todo parece ter regredido alguns anos na segurança geral da cadeia de suprimentos.
Ainda tenho esperança de que, a longo prazo, os defensores possam usar a IA para ajudar a lidar com esse ruído em escala e extrair melhores sinais. Mas aprendemos com décadas de estabelecimento de confiança no domínio de código aberto que você precisa começar com uma base segura e construir as coisas desde o início.
Na Chainguard, lançamos um pacote Images AI que inclui uma coleção abrangente de imagens para estágios no ciclo de vida da carga de trabalho de IA, desde imagens de desenvolvimento até ferramentas de gerenciamento de fluxo de trabalho e bancos de dados vetoriais para armazenamento de produção. Quando você aborda sua cadeia de suprimentos de software de IA do nível básico para incluir assinaturas de software, listas de materiais de software (SBOMs) e remediação de CVE, você está basicamente expandindo o tamanho dos tubos para que a explosão de suas ambições de desenvolvimento de IA mantenham as proteções de segurança.
