Mais CVE no Fornecedor Já Não É Alarme Vermelho, É Sinal Verde
A IA tornou a descoberta de falhas de software barata, o que significa que uma contagem de CVE mede agora o rigor com que uma base de código está a ser escrutinada, não a sua má construção. Qualquer tabela de pontuação que penalize contagens elevadas está a ler o indicador ao contrário.
Há um número em todos os questionários de segurança que deixou silenciosamente de significar o que significava. A contagem de CVE de um fornecedor, o total acumulado de vulnerabilidades divulgadas publicamente, tem sido lida há duas décadas como um indicador da qualidade do código: mais falhas, pior software. Essa leitura acabou de se inverter. Os fornecedores com contagens a subir mais depressa são, cada vez mais, os que investem mais a fundo a procurar as suas próprias falhas, e os fornecedores com registos limpos são, cada vez mais, os que ninguém procurou a sério.
Siga o mecanismo. Uma contagem de divulgações não mede uma única coisa. É o produto de duas variáveis: quantas falhas existem no código e quanto esforço se dedica a procurá-las. Durante a maior parte da história do setor, a segunda variável manteve-se praticamente constante, porque a descoberta era trabalho humano caro. Investigadores qualificados eram escassos e as infraestruturas de fuzzing custavam dinheiro a sério; a triagem consumia depois horas de engenharia. Com o esforço de procura mantido, grosso modo, estável entre fornecedores, contar divulgações dizia algo, imperfeito mas algo, sobre o próprio código.
A descoberta de vulnerabilidades assistida por IA quebra esse pressuposto. Quando uma máquina consegue ler uma base de código à escala, gerar falhas candidatas e reproduzi-las sem intervenção humana, o esforço de procura deixa de ser uma constante e passa a ser a variável dominante. A contagem já não mede o alvo. Mede o holofote.
Uma contagem elevada de CVE é sinal de software mau?
Nunca foi um sinal limpo, e agora está próximo do oposto. Observe as notas de lançamento de qualquer fornecedor que ligue a descoberta à escala de máquina e deve esperar sempre a mesma forma: uma linha de base longa e plana, depois um precipício, com mais correções de segurança a chegar em duas versões do que em anos de atualizações anteriores. Nada no código piorou nesse momento. O que mudou foi que saber ficou barato.
A mudança mais profunda é que todo o processo se está a automatizar, não só a deteção. Descoberta, reprodução, triagem de gravidade, encaminhamento para o programador certo, redação da correção, escrita do teste de regressão: cada etapa que antes precisava de uma pessoa está a ser entregue a uma máquina. Isto importa porque o verdadeiro fator limitador da gestão de vulnerabilidades nunca foi quantas falhas se conseguia encontrar. Foi quantas se podia dar ao luxo de conhecer. Uma equipa de triagem humana consegue absorver algumas dezenas de relatórios credíveis por semana antes de a própria fila de espera se tornar a vulnerabilidade. Automatize o processo de ponta a ponta e a quantidade que é possível conhecer sem colapsar explode, e as contagens de divulgação sobem com ela.
É aqui que a avaliação ingénua de fornecedores inverte tudo: um questionário que desconta pontos por volume elevado de CVE está a descontar pontos exatamente pelo investimento que devia premiar.
Quem ganha quando encontrar falhas é praticamente grátis?
Praticamente grátis não é igualmente grátis para todos. A capacidade está concentrada: correr descoberta com modelos de fronteira sobre uma base de código extensa exige computação séria e acesso aos modelos mais fortes. Um fornecedor que consiga pedir essa capacidade emprestada a equipas irmãs dentro da própria empresa pode varrer continuamente. Um projeto de código aberto sem financiamento, ou um fornecedor de segunda linha sem divisão própria de IA, não pode. O resultado provável é uma divisão de segurança entre quem tem IA e quem não tem: não uma diferença na quantidade de falhas do código, mas uma diferença em quem sabe onde estão as suas falhas.
O código aberto agudiza a corrida. Quando o código-fonte é aberto, um atacante não paga a portagem da engenharia inversa; a mesma automação que permite a um defensor revelar mil falhas está disponível para um adversário assim que a capacidade estiver ao seu alcance. Isto não é um argumento contra o código aberto. É um argumento de que o indicador relevante deixou de ser quantas falhas se tem para passar a ser quem corre primeiro a passagem de deteção e com que rapidez as correções chegam. O ritmo de procura e a latência das correções carregam agora o sinal que uma contagem de CVE costumava carregar.
O efeito de segunda ordem é pior. Se os compradores continuarem a penalizar a divulgação, fazem mais do que ler mal o mercado; estão a otimizá-lo na direção errada. Um fornecedor que veja os seus clientes a pontuar contagens em bruto tem um incentivo racional para procurar menos e divulgar mais devagar. Indicadores mal construídos não se limitam a falhar a medição da diligência. Taxam-na.
O que devem fazer agora os conselhos de administração e as equipas de compras?
Reajustar a base de referência, de forma deliberada, antes do próximo ciclo contratual. Percorra todos os locais onde uma contagem bruta de vulnerabilidades tem peso decisório: pontuação de questionários, limiares no registo de risco, cláusulas contratuais acionadas por volume de divulgações, o diapositivo trimestral que o conselho vê. Cada um desses pontos penaliza agora quem é diligente e favorece quem nunca foi escrutinado. Substitua-os por perguntas que sobrevivem à inversão: o fornecedor mantém um programa de descoberta contínua, assistido por IA ou não; qual é o tempo mediano entre a descoberta e a correção publicada; existe uma política de divulgação publicada com datas auditáveis. Um fornecedor que responda bem a estas questões enquanto regista uma contagem crescente de CVE está a mostrar o seu trabalho de casa. Um com um registo imaculado e nenhuma história de deteção está a mostrar uma sala às escuras.
Essa reformulação é, antes de mais, um exercício de estratégia e só depois uma questão de ferramentas, o tipo de re-canalização de indicadores que assumimos em trabalho de estratégia técnica: decidir do que é que um número é realmente prova antes de alguém ser pago ou penalizado com base nele. E se o plano passa por apontar agentes de descoberta à própria infraestrutura, aplicam-se duas disciplinas antes da primeira varredura. A maquinaria precisa da contenção que definimos em sistemas agênticos seguros, e as decisões consequentes, gravidade, explorabilidade, quando divulgar, precisam de uma pessoa a validá-las, pelas razões defendidas em IA prática com controlo humano. Automatizar a procura não é o mesmo que automatizar o julgamento.
A contagem de falhas deixou de medir o código no dia em que as máquinas começaram a lê-lo à escala. Agora mede o holofote. Os compradores que continuam a pontuá-la à moda antiga não estão a escolher o fornecedor mais seguro da prateleira; estão a escolher o mais escuro.
Perguntas frequentes
Uma contagem elevada de CVE é má na escolha de um fornecedor de software?
Não por si só. A contagem de CVE é o produto das falhas existentes e do esforço posto a encontrá-las, e a descoberta assistida por IA tornou o esforço a variável dominante. Avalie os fornecedores pelo ritmo de deteção, pelo tempo mediano entre a descoberta e a correção, e pela transparência da política de divulgação, em vez do total bruto.
Como devem mudar os questionários de segurança agora que a IA encontra vulnerabilidades?
Elimine pontuações e cláusulas contratuais acionadas pelo volume de divulgações, porque penalizam os fornecedores que mais procuram. Pergunte antes se o fornecedor mantém deteção contínua, com que rapidez as falhas confirmadas se tornam correções publicadas, e se o seu registo de divulgação é auditável com datas.
A caça a falhas com IA ajuda tanto os atacantes como os defensores?
A capacidade é simétrica, e o código publicado em aberto remove qualquer barreira de engenharia inversa, pelo que a vantagem vai para quem correr primeiro a passagem de deteção. Os defensores só mantêm a vantagem varrendo continuamente e publicando correções mais depressa do que os adversários conseguem transformar as descobertas em armas.
Relacionado
- No Ubuntu 26.04 LTS, o Coreutils Que Sustenta as Suas Compilações Já Não É GNU
- O Prêmio da Soberania: por que a IA soberana corporativa está vencendo pelo acesso, não pela velocidade
- Os Processos por Segredos Comerciais Ganham-se Anos Antes de Alguém se Demitir. Pergunte à Faccenda Chicken.
- Security & Trust
Escrito por uma persona editorial de IA do sistema editorial proprietário da Abyshire e revisto pela nossa equipa.