A Anthropic anunciou a 8 de outubro de 2026 um serviço gratuito de análise de vulnerabilidades para projetos de código aberto, o OSS Scanner, integrado numa iniciativa mais ampla de cibersegurança que inclui também um programa dedicado a infraestruturas críticas. A novidade com maior impacto prático para quem mantém software livre é a forma como os resultados são entregues: os relatórios são gerados integralmente por modelos de inteligência artificial e enviados aos responsáveis dos projetos sem passarem por revisão humana prévia.
Resposta rápida: A Anthropic lançou o OSS Scanner, um serviço opcional e gratuito que analisa periodicamente projetos de código aberto inscritos e envia relatórios de vulnerabilidades gerados por modelos de IA, com prova de conceito e sugestão de correção. A empresa admite que os relatórios não são revistos por humanos e podem conter erros, nomeadamente na classificação de severidade. Para equipas que dependem de software livre, a recomendação é preparar desde já um processo de triagem capaz de validar relatórios automáticos sem esgotar a capacidade dos programadores.
O que é, afinal, o OSS Scanner
O serviço nasce dentro de uma iniciativa que a empresa designa por Anthropic Cyber Mission, apresentada como um compromisso de longo prazo com a defesa dos sistemas de que todos dependem e cuja primeira fase se concentra em dois domínios: infraestruturas críticas e software de código aberto. Na própria comunicação da empresa, o OSS Scanner é descrito como um serviço de adesão voluntária inspirado no OSS-Fuzz da Google, em que os projetos inscritos recebem análises periódicas gratuitas dos modelos mais capazes, com cada relatório a incluir uma prova de conceito da exploração da falha, uma explicação e uma correção sugerida quando esta existe, sendo os relatórios gerados por modelo e enviados sem revisão humana.
O serviço assenta na experiência anterior do chamado Project Glasswing, que recorreu ao Claude para encontrar vulnerabilidades em software. Segundo a empresa, nesse projeto foram analisados centenas de projetos de código aberto muito utilizados, com triagem humana das potenciais vulnerabilidades e comunicação privada aos responsáveis através de um processo de divulgação coordenada; alguns mantenedores com capacidade para fazer triagem em escala pediram acesso a tudo o que os modelos tinham encontrado, revisto ou não. A inscrição é feita pelos próprios responsáveis do projeto, através de um pedido no repositório GitHub do serviço, e os relatórios incluem um reprodutor, a identificação do momento em que o erro foi introduzido, quando possível, e uma proposta de correção.
Os números apresentados pela empresa
Os valores divulgados ajudam a perceber a escala do problema que levou à automatização total do envio. A empresa indica que, nos últimos seis meses, os seus modelos identificaram mais de 29 000 candidatos a vulnerabilidades em projetos de código aberto amplamente utilizados, dos quais cerca de 6000 foram revistos manualmente, deixando um grande volume por avaliar; em resposta, foi criado um sistema automático que envia os relatórios diretamente aos mantenedores participantes. Perto de 5000 terão sido encaminhados diretamente para equipas de projeto que o solicitaram.
| Indicador | Valor divulgado |
|---|---|
| Candidatos a vulnerabilidades (6 meses) | Mais de 29 000 |
| Revistos manualmente | Cerca de 6000 |
| Amostra avaliada por testadores de intrusão | 97 falhas de severidade alta e crítica em 48 projetos |
| Cumpriram critérios de divulgação coordenada | 85 |
| Duplicados de problemas já conhecidos | 11 |
| Inválidos | 1 |
| Taxa de verdadeiros positivos esperada | Superior a 90% (estimativa da empresa) |
Os dados de validação resultam da avaliação, por testadores de intrusão, de 97 resultados de severidade alta e crítica em 48 projetos, obtidos com uma versão inicial do analisador: 85 cumpriam os critérios de divulgação coordenada, 11 eram genuínos mas duplicavam problemas já conhecidos ou outros resultados, e um era inválido. Ainda assim, a empresa reconhece que não pode garantir que o analisador seja perfeito. Do lado dos projetos envolvidos, a avaliação divulgada é positiva: Anton Arapov, da OpenSSL Corporation, afirmou que os relatórios recebidos eram tão bons, e por vezes melhores, do que os produzidos por pessoas, sobretudo quando acompanhados de uma exploração real que permite verificação imediata.
Velocidade a mais, mãos a menos
A decisão de dispensar revisão humana é justificada pela rapidez, mas transfere o esforço de validação para quem recebe os relatórios. A própria empresa descreve a validação humana como um estrangulamento na sua investigação de vulnerabilidades, pelo que o OSS Scanner envia os resultados gerados por IA diretamente às equipas, acelerando o reporte e deixando aos mantenedores a responsabilidade de verificar e priorizar as correções. Isso significa relatórios mais rápidos, mas também que alguns conterão imprecisões, como uma classificação de severidade errada.
O contexto ajuda a explicar a controvérsia. O projeto curl, usado em milhares de milhões de dispositivos, tornou-se o caso emblemático desta tensão: o programa de recompensas por falhas, lançado em abril de 2019, foi encerrado a 31 de janeiro de 2026, depois de a taxa de vulnerabilidades confirmadas ter caído de mais de 15% para menos de 5% em 2025, com a chegada massiva de relatórios gerados por IA. Mais tarde, o responsável do projeto descreveu uma realidade diferente: os relatórios automáticos passaram a ser tecnicamente corretos, mas chegam agora a um ritmo muito superior ao anterior, criando um novo tipo de sobrecarga. Em julho de 2026, o projeto chegou a suspender a receção pública de relatórios de vulnerabilidades, evidenciando que a deteção está a crescer mais depressa do que a capacidade de triagem e correção.
A outra metade do anúncio: infraestruturas críticas
No âmbito de um novo Critical Infrastructure Defense Program, a empresa disponibiliza modelos de fronteira, engenheiros no terreno e investigação sobre ameaças a organizações já responsáveis pela segurança de infraestruturas críticas, que usarão estes recursos para identificar e corrigir vulnerabilidades nos sistemas dos seus clientes; entre os parceiros fundadores estão Accenture, Booz Allen Hamilton, CrowdStrike, Deloitte, Dragos, Hitachi, Insane Cyber, Nozomi Networks, Palo Alto Networks, PwC e Rockwell Automation. O foco é a tecnologia operacional de instalações industriais, subestações e sistemas de água, onde equipamentos concebidos para durar décadas muitas vezes não podem ser desligados para aplicar correções, deixando falhas conhecidas por resolver durante anos.
Nem tudo está esclarecido. O anúncio não detalha as condições comerciais, não indicando se os parceiros terão acesso gratuito aos modelos nem quem suporta os custos de computação, ficando também por explicar como serão testadas e aplicadas as correções sem perturbar a operação dos serviços.
| Data | Marco |
|---|---|
| Fevereiro de 2026 | Introdução do Claude Code Security, para rever bases de código e identificar vulnerabilidades |
| Primeiro semestre de 2026 | Project Glasswing usa modelos de IA para procurar falhas em software de código aberto |
| 8 de outubro de 2026 | Lançamento da Cyber Mission, com o programa para infraestruturas críticas e o OSS Scanner gratuito |
Porque é que isto importa em Portugal
Praticamente todas as organizações portuguesas, de startups a hospitais, assentam em componentes de código aberto mantidos por equipas pequenas. Qualquer alteração na forma como essas falhas são descobertas e comunicadas repercute-se na cadeia de abastecimento de software nacional, tanto na velocidade com que chegam correções como no número de atualizações a aplicar.
No plano legal, as obrigações estão a apertar em duas frentes. Por um lado, o Regime Jurídico da Cibersegurança: o Decreto-Lei n.º 125/2025 foi publicado no Diário da República a 4 de dezembro de 2025 e entrou em vigor a 3 de abril de 2026, transpondo a Diretiva NIS2, com registo das entidades abrangidas na plataforma MyCiber do CNCS e notificação inicial de incidentes com impacto significativo no prazo de 24 horas para entidades essenciais, importantes e públicas relevantes. A gestão de vulnerabilidades e a segurança da cadeia de abastecimento estão entre as medidas exigidas, pelo que saber que falhas existem nas dependências usadas deixou de ser uma boa prática e passou a ser matéria de conformidade.
Por outro lado, o Regulamento Ciber-Resiliência. Desde 11 de setembro de 2026, os fabricantes têm de reportar vulnerabilidades ativamente exploradas e incidentes graves que afetem produtos com elementos digitais; para os chamados responsáveis por software de código aberto, as obrigações de reporte aplicam-se a partir de 11 de dezembro de 2027, sendo as notificações submetidas através da Plataforma Única de Reporte criada pela ENISA. Um fluxo contínuo de relatórios automáticos pode, neste contexto, antecipar a deteção, mas também multiplicar decisões difíceis sobre o que é realmente explorável. Para as PME, a mensagem prática é simples: manter um inventário de dependências, acompanhar os avisos dos projetos que utilizam e atualizar depressa. Quando uma falha expõe dados pessoais, aplicam-se ainda as obrigações do RGPD, incluindo a notificação à CNPD nos prazos legais.
O que fazer agora
- Se mantém um projeto de código aberto, avalie a adesão ao serviço apenas se tiver capacidade real de triagem; a inscrição é voluntária.
- Trate a severidade indicada por IA como hipótese, não como facto: confirme sempre com reprodução do problema no seu ambiente.
- Defina uma política de divulgação clara e um canal único de receção, evitando dispersão entre
e-mail, plataformas de recompensas e avisos de segurança. - Nas organizações consumidoras, mantenha um
SBOMatualizado para saber que projetos afetados estão em produção. - Reveja o processo interno de notificação de incidentes, alinhando-o com os prazos do CNCS e, quando aplicável, do Regulamento Ciber-Resiliência.
Perguntas frequentes
O OSS Scanner é mesmo gratuito?
Sim. Os projetos inscritos recebem análises periódicas dos modelos mais capazes da empresa sem qualquer custo, mediante adesão voluntária e elegibilidade do projeto.
Os relatórios são verificados por pessoas antes de serem enviados?
Não. Os relatórios são gerados pelo modelo e enviados sem revisão humana, o que acelera a entrega mas implica que alguns contenham imprecisões, por exemplo na classificação de severidade.
Que fiabilidade está anunciada para estes resultados?
A empresa estima que mais de 90% dos relatórios correspondam a vulnerabilidades reais, admitindo ainda assim a ocorrência de falsos positivos. Esta estimativa é da responsabilidade da Anthropic e não foi validada de forma independente.
O que muda para uma PME portuguesa?
Tendencialmente, mais correções e mais atualizações a aplicar nas dependências utilizadas. Convém manter inventário de software, acompanhar avisos dos projetos e assegurar os prazos de notificação de incidentes previstos no regime nacional de cibersegurança.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Anthropic, pela Comissão Europeia, pela ENISA e por fontes de imprensa especializada.