Cisco Antares: como modelos compactos de inteligência artificial podem transformar a caça e a localização de vulnerabilidades
A inteligência artificial está provocando uma transformação profunda na segurança cibernética. Durante anos, a utilização de IA no setor esteve concentrada principalmente em tarefas como classificação de alertas, detecção de anomalias e análise automatizada de eventos. Com a evolução dos grandes modelos de linguagem, entretanto, novas possibilidades surgiram, especialmente na análise de código-fonte e na identificação de possíveis falhas de segurança.
Nesse cenário, a Cisco apresentou o Antares, uma família de modelos de linguagem pequenos e especializados em segurança, desenvolvidos especificamente para uma tarefa que pode consumir uma quantidade significativa de tempo dos profissionais de AppSec: localizar, dentro de grandes repositórios de código, os arquivos que provavelmente estão relacionados a uma vulnerabilidade conhecida.
A proposta representa uma mudança interessante na forma de aplicar inteligência artificial à segurança de software.
Em vez de tentar utilizar um modelo gigantesco para realizar todas as tarefas possíveis — interpretar código, escrever programas, corrigir falhas, responder perguntas e automatizar processos — a estratégia do Antares é mais específica.
O modelo foi concebido para atuar como um investigador auxiliar.
Ele recebe informações relacionadas a uma vulnerabilidade, uma categoria CWE ou um alerta de segurança e procura, dentro de um repositório, os arquivos que merecem prioridade na investigação.
O resultado não é apresentado como uma sentença definitiva de que determinado código é vulnerável.
O objetivo é reduzir o espaço de busca.
Essa diferença é fundamental.
Em um ambiente de desenvolvimento moderno, um projeto pode conter milhares ou até milhões de linhas de código. Uma vulnerabilidade conhecida pode estar escondida em uma função específica, em um módulo pouco utilizado ou em um componente cuja relação com o alerta de segurança não é imediatamente evidente.
O Antares procura atuar justamente nesse ponto.
A Cisco lançou os modelos Antares-350M e Antares-1B como modelos de pesos abertos, com disponibilização para a comunidade por meio do Hugging Face, e afirma que eles foram projetados para a localização de vulnerabilidades em nível de repositório. A empresa também destaca a possibilidade de execução local, uma característica relevante para organizações que não desejam enviar código proprietário para serviços externos de IA.
A iniciativa merece atenção não apenas pelo lançamento de mais uma ferramenta baseada em inteligência artificial, mas pelo conceito que representa: modelos menores, especializados e potencialmente mais baratos podem ser mais adequados para determinadas tarefas de segurança do que modelos generalistas de grande porte.
O verdadeiro problema que o Antares tenta resolver
A gestão de vulnerabilidades tradicional costuma começar com um alerta.
Uma organização recebe uma informação sobre uma falha de segurança.
Essa informação pode vir de:
-
uma base de vulnerabilidades;
-
um boletim de segurança;
-
um fornecedor;
-
um sistema de monitoramento;
-
uma equipe de pesquisa;
-
uma comunidade de segurança;
-
um relatório de incidente.
A partir desse momento, surge uma pergunta aparentemente simples:
“Nosso código possui essa vulnerabilidade?”
Na prática, a resposta pode ser extremamente difícil.
Um grande repositório pode conter centenas de componentes.
O código pode ter sido desenvolvido por equipes diferentes.
Pode existir documentação incompleta.
Funções semelhantes podem possuir nomes diferentes.
A vulnerabilidade pode depender da interação entre diversos arquivos.
O código afetado pode estar escondido em uma parte pouco conhecida da aplicação.
O analista precisa, portanto, realizar uma investigação.
Ele pode pesquisar padrões de código.
Pode utilizar ferramentas de busca.
Pode analisar chamadas de funções.
Pode consultar histórico de alterações.
Pode comparar versões.
Pode procurar referências a determinadas bibliotecas.
Pode estudar o comportamento associado à categoria CWE.
O processo pode ser lento.
O Antares tenta automatizar justamente uma parte dessa investigação inicial.
Segundo a Cisco, o modelo parte de uma descrição de vulnerabilidade e utiliza uma estratégia iterativa de exploração do repositório, procurando padrões relevantes, analisando arquivos candidatos, incorporando evidências e ajustando o caminho da busca. O resultado é uma lista priorizada de arquivos que devem ser examinados pelos profissionais responsáveis pela segurança.
Da detecção para a localização
Existe uma diferença importante entre detectar uma vulnerabilidade e localizar onde ela está.
Um scanner pode informar que determinado projeto utiliza uma versão vulnerável de uma biblioteca.
Mas essa informação não necessariamente responde a outra pergunta:
“Quais arquivos do nosso código são realmente afetados?”
Essa segunda etapa pode exigir uma análise contextual.
Imagine uma aplicação que utiliza uma biblioteca vulnerável.
O simples fato de a biblioteca estar presente não significa que todos os componentes do sistema sejam afetados.
É necessário entender:
-
onde a biblioteca é utilizada;
-
quais funções são chamadas;
-
quais dados chegam até essas funções;
-
quais caminhos de execução existem;
-
se as condições necessárias para exploração estão presentes.
É nesse espaço que ferramentas como o Antares podem oferecer valor.
O modelo não precisa resolver todo o problema.
Ele pode ajudar a encontrar o ponto onde o problema provavelmente está.
Essa é uma abordagem particularmente interessante porque reduz o trabalho repetitivo dos analistas.
Antares-350M e Antares-1B: a aposta nos modelos compactos
A proposta do Antares está diretamente relacionada ao conceito de Small Language Models, ou SLMs.
Enquanto os modelos de fronteira possuem quantidades muito maiores de parâmetros e demandam infraestrutura significativa, modelos compactos podem ser executados com custos menores.
A Cisco apresentou inicialmente duas variantes:
-
Antares-350M, com aproximadamente 350 milhões de parâmetros;
-
Antares-1B, com aproximadamente 1 bilhão de parâmetros.
A empresa também informou que uma versão de 3 bilhões de parâmetros está prevista.
A escolha por modelos relativamente pequenos não é apenas uma questão de economia.
Ela pode ter implicações estratégicas.
Modelos compactos podem ser mais fáceis de:
-
hospedar localmente;
-
executar em ambientes privados;
-
integrar a pipelines;
-
controlar;
-
monitorar;
-
adaptar;
-
utilizar em processos automatizados.
Em segurança cibernética, essa característica é particularmente importante.
Código-fonte pode conter informações extremamente sensíveis.
Enviar um repositório proprietário para uma plataforma externa de IA pode gerar preocupações relacionadas a:
-
confidencialidade;
-
propriedade intelectual;
-
compliance;
-
soberania de dados;
-
políticas internas;
-
requisitos regulatórios.
A execução local reduz parte desses riscos, desde que a infraestrutura seja corretamente protegida.
A Cisco destaca justamente esse aspecto como uma das vantagens do Antares: os modelos compactos podem operar localmente ou em ambientes internos, mantendo o código sensível dentro da infraestrutura da organização.
O modelo como investigador de código
A característica mais interessante do Antares é sua abordagem de busca.
Em uma análise tradicional, o profissional pode receber um alerta relacionado a uma determinada classe de vulnerabilidade.
Depois, precisa procurar manualmente possíveis ocorrências.
O Antares tenta reproduzir parte desse processo investigativo.
O modelo pode:
-
receber informações sobre a vulnerabilidade;
-
interpretar a categoria relacionada;
-
explorar o repositório;
-
procurar padrões relevantes;
-
analisar arquivos candidatos;
-
revisar os resultados encontrados;
-
mudar a estratégia quando uma linha de investigação não apresenta evidências;
-
priorizar os arquivos mais relevantes.
Esse comportamento se aproxima mais de uma investigação orientada por hipóteses do que de uma simples busca textual.
A Cisco descreve o sistema como inspirado no trabalho de um investigador humano, com capacidade de pesquisar, analisar evidências, mudar de direção e restringir progressivamente o conjunto de arquivos relevantes.
Essa abordagem pode ser particularmente útil quando o código possui estruturas complexas.
O uso de ferramentas simples pode ser uma vantagem
Um aspecto curioso do funcionamento descrito para o Antares é sua interação com o repositório por meio de ferramentas tradicionais de linha de comando.
Comandos como:
-
grep; -
find; -
cat;
fazem parte do cotidiano de muitos profissionais de desenvolvimento e segurança.
Isso mostra que a inovação não necessariamente está na criação de uma ferramenta completamente diferente.
A inovação pode estar na forma como a inteligência artificial utiliza ferramentas já existentes.
Um profissional humano pode pensar:
“Vou procurar primeiro por esse padrão.”
Depois:
“Esse arquivo parece relevante. Agora vou verificar suas referências.”
Em seguida:
“Esse caminho não levou a lugar algum. Vou tentar outra abordagem.”
O Antares procura reproduzir esse ciclo de investigação de forma automatizada.
CWE como linguagem de comunicação entre vulnerabilidades e código
O conceito de Common Weakness Enumeration, ou CWE, desempenha papel importante nessa arquitetura.
A CWE permite classificar tipos de fraquezas de software.
Entre as categorias conhecidas estão problemas relacionados a:
-
validação de entrada;
-
controle de acesso;
-
injeção;
-
gerenciamento de memória;
-
autenticação;
-
criptografia;
-
concorrência.
Uma vulnerabilidade pode ser descrita com base em uma categoria CWE.
O desafio é transformar essa descrição abstrata em uma busca concreta dentro do código.
O Antares procura estabelecer essa conexão.
A cadeia pode ser representada da seguinte maneira:
vulnerabilidade conhecida → categoria CWE → padrões relevantes → exploração do repositório → arquivos candidatos → revisão humana.
Essa ponte entre inteligência de vulnerabilidades e código interno é um dos aspectos mais promissores da proposta.
A relação com CVE e advisories
O ecossistema de segurança depende fortemente de informações externas.
Uma organização pode receber um aviso sobre determinada vulnerabilidade.
Esse aviso pode incluir:
-
CVE;
-
severidade;
-
produto afetado;
-
versões vulneráveis;
-
versões corrigidas;
-
categoria CWE;
-
descrição técnica.
O problema é que essas informações geralmente descrevem o problema em termos gerais.
O ambiente interno da empresa é diferente.
Cada organização possui sua própria implementação.
O mesmo componente pode ser utilizado de maneiras diferentes.
Portanto, existe uma distância entre:
“Existe uma vulnerabilidade conhecida.”
e
“Essa vulnerabilidade está presente neste arquivo específico da nossa aplicação.”
O Antares busca reduzir essa distância.
O papel do Antares dentro do AppSec
Um erro seria interpretar o Antares como uma solução completa de segurança de aplicações.
Ele não substitui:
-
SAST;
-
DAST;
-
SCA;
-
secret scanning;
-
análise de contêineres;
-
análise de infraestrutura;
-
testes de penetração;
-
threat modeling;
-
revisão de código.
A própria Cisco posiciona o Antares como complemento às ferramentas existentes.
Sua função é concentrar esforços na localização de arquivos potencialmente relacionados a vulnerabilidades conhecidas.
Essa especialização é importante.
Uma organização pode combinar diferentes camadas.
Por exemplo:
SCA identifica uma dependência vulnerável.
Antares ajuda a localizar arquivos potencialmente afetados.
SAST analisa padrões de código.
DAST verifica o comportamento da aplicação em execução.
Pentest avalia a possibilidade de exploração.
Analista valida os resultados.
Esse modelo de defesa em profundidade é muito mais consistente do que depender exclusivamente de uma única ferramenta.
O fator humano continua indispensável
Um dos pontos mais importantes da proposta é que o Antares não deve ser tratado como uma autoridade definitiva.
O modelo indica candidatos.
O especialista investiga.
Essa diferença precisa ser preservada.
Um sistema de IA pode cometer erros.
Pode indicar um arquivo que não é vulnerável.
Pode deixar de identificar um arquivo relevante.
Pode interpretar incorretamente um padrão.
Pode não compreender completamente o fluxo de dados.
Por isso, a revisão humana continua sendo necessária.
A inteligência artificial pode acelerar a triagem.
Não necessariamente substituir o julgamento técnico.
Falsos positivos e falsos negativos
Todo sistema de análise automatizada precisa lidar com dois problemas.
O primeiro é o falso positivo.
O sistema identifica um arquivo como potencialmente vulnerável, mas a análise humana conclui que não existe uma falha real.
O segundo é o falso negativo.
A vulnerabilidade existe, mas o sistema não consegue identificá-la.
Em segurança, ambos são importantes.
Um excesso de falsos positivos pode gerar fadiga de alertas.
O analista passa a ignorar resultados.
Um excesso de falsos negativos cria uma falsa sensação de segurança.
O desafio é encontrar um equilíbrio.
O Antares, portanto, deve ser visto como um mecanismo de priorização.
Ele ajuda a definir:
“Comece investigando aqui.”
Não necessariamente:
“O problema está definitivamente aqui.”
O benchmark de localização de vulnerabilidades
Para avaliar a proposta, a Cisco apresentou o chamado Vulnerability Localization Benchmark.
Segundo a empresa, o benchmark reúne 500 tarefas distribuídas por 290 repositórios, cobrindo seis ecossistemas de pacotes e 147 categorias CWE. A Cisco informou ainda que 78% das entradas possuem associação com CVE.
Esse tipo de benchmark é importante porque avaliações tradicionais de modelos de linguagem nem sempre representam problemas reais de segurança.
Um modelo pode ser excelente para escrever código.
Isso não significa necessariamente que seja bom em investigar vulnerabilidades.
A localização de uma falha exige:
-
compreensão contextual;
-
navegação pelo repositório;
-
reconhecimento de padrões;
-
análise de evidências;
-
capacidade de abandonar caminhos improdutivos.
É uma tarefa diferente de geração de código.
Resultados precisam ser interpretados com cautela
Segundo os números divulgados pela própria Cisco, o Antares-1B alcançou F1 de 0,209, precisão de 0,262 e recall de 0,224 no benchmark apresentado. A empresa afirma que o modelo superou concorrentes maiores nas mesmas condições experimentais.
Esses resultados são interessantes, mas precisam ser contextualizados.
Um F1 relativamente baixo demonstra que ainda existe espaço significativo para evolução.
Além disso, os resultados apresentados pela própria empresa responsável pelo desenvolvimento não substituem avaliações independentes.
Em segurança cibernética, benchmarks precisam ser analisados com cuidado.
É necessário verificar:
-
como os dados foram selecionados;
-
quais modelos foram comparados;
-
quais configurações foram utilizadas;
-
quais critérios definiram sucesso;
-
se os resultados podem ser reproduzidos;
-
como o modelo se comporta em ambientes reais.
A ausência de validação independente não invalida os resultados.
Mas recomenda cautela na interpretação.
O custo como fator estratégico
Um dos dados mais chamativos divulgados pela Cisco está relacionado ao custo de inferência.
Segundo a reportagem do iMasters, o benchmark completo de 500 tarefas com o Antares-1B teria custado cerca de US$ 0,71, utilizando uma GPU Nvidia H100, enquanto os números comparativos apresentados foram de aproximadamente US$ 12,50 para o GLM-5.2 e US$ 141 para o GPT-5.5 nas condições informadas. Esses valores representam custo de inferência, não o custo total de operação, que inclui infraestrutura, integração, armazenamento, manutenção e equipe.
A diferença pode ter impacto significativo.
Imagine uma organização que deseja analisar continuamente seus repositórios.
Se cada execução exigir um modelo extremamente caro, a frequência das análises será limitada.
Se o custo for reduzido, torna-se possível aumentar a frequência.
Isso abre espaço para um modelo de:
segurança contínua.
O código poderia ser analisado:
-
a cada commit;
-
a cada pull request;
-
durante o build;
-
antes da publicação;
-
após um novo alerta de vulnerabilidade.
A segurança deixa de ser uma atividade pontual.
Passa a fazer parte do ciclo permanente de desenvolvimento.
O conceito de “segurança contínua”
A velocidade de desenvolvimento de software aumentou significativamente.
Equipes modernas fazem dezenas ou centenas de alterações diariamente.
Ao mesmo tempo, vulnerabilidades são descobertas continuamente.
Isso cria um problema.
Uma análise realizada hoje pode não ser suficiente amanhã.
Um componente que era considerado seguro pode apresentar uma vulnerabilidade recém-descoberta.
Uma abordagem baseada em modelos compactos pode ajudar a executar verificações com maior frequência.
A ideia é simples:
quanto menor o custo da análise, mais vezes ela pode ser realizada.
Esse conceito é especialmente relevante em ambientes DevSecOps.
Integração com CI/CD
A integração com pipelines de desenvolvimento é outro aspecto importante.
Uma ferramenta de segurança precisa funcionar dentro do processo real de engenharia.
Não adianta criar um relatório que ninguém consulta.
O resultado precisa chegar ao fluxo de trabalho dos desenvolvedores.
A CLI do Antares oferece formatos estruturados, incluindo JSON e SARIF 2.1.0, o que facilita a integração com plataformas de desenvolvimento e sistemas de análise de código. A documentação apresentada pelo iMasters também destaca a possibilidade de utilização em fluxos de CI/CD e integração com mecanismos de análise como o GitHub Code Scanning.
Uma possível arquitetura seria:
Commit
↓
Pipeline CI/CD
↓
Análise de segurança
↓
Antares
↓
Arquivos candidatos
↓
Revisão humana
↓
Correção
↓
Novo teste
Essa integração pode reduzir o tempo entre a descoberta de uma vulnerabilidade e sua investigação.
O risco de automatizar demais
Apesar dos benefícios, existe um perigo.
Quando uma ferramenta começa a funcionar automaticamente dentro do pipeline, os desenvolvedores podem assumir que o resultado é definitivo.
Isso seria um erro.
A automação deve aumentar a capacidade humana.
Não eliminar a responsabilidade humana.
Uma organização pode configurar o pipeline para interromper um build quando determinados critérios forem atendidos.
Porém, se o modelo gerar falsos positivos, o processo de desenvolvimento pode sofrer bloqueios desnecessários.
Por outro lado, se os critérios forem excessivamente permissivos, vulnerabilidades podem passar despercebidas.
A automação precisa ser calibrada.
Execução local e proteção do código proprietário
Um dos principais argumentos a favor de modelos compactos é a possibilidade de execução dentro da própria organização.
Essa característica pode ser particularmente importante para:
-
bancos;
-
órgãos públicos;
-
universidades;
-
empresas de tecnologia;
-
indústrias;
-
organizações de defesa;
-
empresas submetidas a regulamentações.
Código-fonte pode representar propriedade intelectual.
Além disso, pode conter:
-
segredos;
-
chaves;
-
URLs internas;
-
configurações;
-
lógica de negócio.
Enviar esse conteúdo para um serviço externo pode gerar riscos.
Executar o modelo localmente reduz o perímetro de exposição.
Mas não elimina a necessidade de segurança.
A infraestrutura que hospeda o modelo também precisa ser protegida.
O próprio Antares precisa ser operado com segurança
Uma ferramenta de segurança pode se transformar em um risco se for mal configurada.
O Antares pode interagir com repositórios e executar comandos durante sua investigação.
Por isso, o ambiente de execução precisa ser isolado.
A Cisco recomenda, segundo o material divulgado, medidas como:
-
uso de contêineres isolados;
-
repositórios em modo somente leitura;
-
desativação de acesso à rede durante a análise;
-
limites de recursos;
-
timeouts;
-
logs de auditoria;
-
supervisão humana.
Essas recomendações são extremamente importantes.
O modelo deve analisar o código.
Não deve ter liberdade desnecessária para alterar o ambiente.
O princípio do menor privilégio aplicado à IA
O princípio de menor privilégio também deve ser aplicado aos agentes de IA.
Se o Antares precisa apenas ler um repositório, ele não deveria possuir:
-
permissão de escrita;
-
acesso administrativo;
-
acesso irrestrito à rede;
-
acesso a credenciais;
-
acesso a outros sistemas.
Quanto menor o privilégio, menor o impacto potencial de um eventual comprometimento.
Essa filosofia deve ser aplicada tanto ao modelo quanto ao ambiente que o executa.
Repositórios grandes representam um desafio
A própria Cisco reconhece limitações relacionadas ao tamanho dos repositórios.
Segundo as informações divulgadas pelo iMasters, o desempenho tende a cair em repositórios superiores a 10 MB sob determinadas limitações de comandos, além de apresentar dificuldades maiores em vulnerabilidades que exigem contexto distribuído por vários arquivos.
Isso é importante.
Sistemas reais podem ser extremamente grandes.
Uma aplicação empresarial pode conter:
-
milhares de arquivos;
-
múltiplas linguagens;
-
bibliotecas internas;
-
componentes de terceiros;
-
código legado.
Um modelo que funciona bem em um projeto pequeno pode enfrentar dificuldades em uma infraestrutura complexa.
Por isso, estratégias de particionamento e priorização podem ser necessárias.
Vulnerabilidades complexas são mais difíceis de localizar
Algumas falhas apresentam padrões muito claros.
Outras dependem de condições distribuídas.
Uma vulnerabilidade pode exigir:
-
múltiplas funções;
-
diferentes módulos;
-
configurações específicas;
-
interações entre processos;
-
condições de concorrência;
-
estados específicos.
Nesses casos, localizar o arquivo vulnerável é muito mais difícil.
A ferramenta pode encontrar um arquivo relacionado.
Mas isso não significa que encontrou a causa raiz.
O analista precisa compreender o fluxo completo.
O desafio dos dados de treinamento
Outro ponto importante é a atualidade das informações.
Segundo a reportagem do iMasters, os dados de treinamento utilizados pelo modelo possuem corte em 10 de abril de 2025. Isso significa que vulnerabilidades descobertas posteriormente não fazem parte diretamente do conhecimento incorporado durante o treinamento.
Essa limitação não é exclusiva do Antares.
É uma característica comum dos modelos de linguagem.
Por isso, modelos de segurança precisam ser utilizados em conjunto com fontes atualizadas.
Entre elas:
-
bases de CVE;
-
advisories;
-
feeds de fornecedores;
-
bancos de CWE;
-
informações de threat intelligence.
O modelo pode ajudar a interpretar e localizar.
Mas não deve ser a única fonte de conhecimento.
IA não substitui SAST, SCA ou DAST
Uma visão madura de segurança precisa combinar tecnologias.
SAST analisa o código-fonte.
SCA identifica dependências vulneráveis.
DAST avalia aplicações em execução.
IA especializada pode ajudar a priorizar e investigar.
Pentest procura caminhos reais de exploração.
Threat modeling analisa riscos arquiteturais.
Nenhuma dessas abordagens elimina completamente as demais.
O futuro provavelmente será híbrido.
A inteligência artificial será mais uma camada dentro de um ecossistema de segurança.
A importância da explicabilidade
Em segurança, não basta indicar um resultado.
O analista precisa entender o motivo.
Uma ferramenta que diz:
“Arquivo X é vulnerável.”
é menos útil do que uma ferramenta que apresenta:
“Arquivo X foi priorizado porque contém padrões relacionados à CWE Y e está conectado ao fluxo Z.”
O Antares fornece, segundo a Cisco, a lista de arquivos candidatos acompanhada do histórico de exploração do terminal que levou ao resultado. Essa característica pode ajudar o analista a compreender como a ferramenta chegou à recomendação.
Essa transparência é importante para aumentar a confiança.
O futuro da caça automatizada a vulnerabilidades
A evolução do Antares aponta para uma tendência maior.
A inteligência artificial está começando a atuar em tarefas especializadas de segurança.
O futuro pode envolver agentes capazes de:
-
acompanhar advisories;
-
identificar componentes afetados;
-
localizar código potencialmente vulnerável;
-
abrir tickets;
-
sugerir testes;
-
verificar correções;
-
acompanhar a remediação.
Entretanto, cada etapa precisa ser cuidadosamente controlada.
Quanto maior a autonomia, maior o risco.
Uma IA que apenas recomenda um arquivo apresenta um risco relativamente limitado.
Uma IA que modifica automaticamente código de produção apresenta um risco muito maior.
A autonomia deve crescer de forma proporcional à capacidade de validação.
O paradoxo da IA na segurança
Existe um paradoxo interessante.
A inteligência artificial está sendo utilizada para encontrar vulnerabilidades mais rapidamente.
Ao mesmo tempo, atacantes também estão utilizando IA para descobrir e explorar falhas.
Isso cria uma corrida tecnológica.
Defensores precisam aumentar a velocidade de identificação.
Atacantes também.
Nesse cenário, a vantagem pode pertencer à organização que consegue automatizar mais etapas sem perder qualidade de controle.
Antares e a democratização da segurança baseada em IA
Um dos aspectos mais relevantes do projeto é a tentativa de reduzir a barreira de entrada.
Modelos gigantes podem ser caros.
Infraestruturas de IA podem ser complexas.
Pequenas equipes de segurança podem não possuir recursos suficientes.
Modelos compactos podem mudar esse cenário.
Uma universidade.
Uma empresa de pequeno porte.
Uma organização pública.
Um projeto open source.
Todos podem, potencialmente, utilizar ferramentas de análise baseadas em IA sem depender exclusivamente de serviços externos de alto custo.
Essa democratização pode contribuir para melhorar a segurança do ecossistema como um todo.
Código aberto e pesos abertos: oportunidades e responsabilidades
É importante distinguir conceitos.
Um projeto pode disponibilizar seu código.
Um modelo pode disponibilizar seus pesos.
Isso não significa necessariamente que todos os componentes sejam totalmente abertos da mesma maneira.
No caso do Antares, a Cisco apresenta os modelos como open-weight, e o iMasters informa que os modelos são distribuídos sob licença Apache 2.0, com processo de solicitação para acesso aos arquivos.
A abertura pode permitir:
-
auditoria;
-
pesquisa;
-
adaptação;
-
experimentação;
-
melhoria comunitária.
Mas também exige responsabilidade.
Organizações devem avaliar:
-
origem dos modelos;
-
integridade dos arquivos;
-
cadeia de fornecimento;
-
segurança das dependências;
-
atualização das versões.
Um modelo de IA também faz parte da cadeia de software.
Conclusão
O lançamento do Antares representa uma evolução interessante na aplicação de inteligência artificial à segurança de software.
Sua principal contribuição não está em prometer substituir ferramentas tradicionais ou eliminar a necessidade de especialistas.
Está em atacar um problema específico e recorrente: reduzir o tempo necessário para localizar, dentro de grandes bases de código, os arquivos que merecem investigação quando existe uma vulnerabilidade conhecida.
Essa abordagem é particularmente relevante porque a segurança de aplicações enfrenta um problema de escala.
O volume de código cresce.
As dependências aumentam.
As vulnerabilidades são descobertas continuamente.
Os profissionais especializados continuam limitados.
Nesse contexto, uma ferramenta capaz de acelerar a primeira etapa da investigação pode representar um ganho operacional significativo.
O Antares também evidencia uma tendência importante: modelos especializados e compactos podem apresentar vantagens práticas sobre modelos generalistas muito maiores quando aplicados a tarefas específicas de segurança.
A possibilidade de executar modelos localmente também merece destaque. Para organizações que trabalham com código proprietário ou dados sensíveis, manter a análise dentro da própria infraestrutura pode reduzir riscos relacionados à exposição de informações. A Cisco destaca justamente a capacidade de execução local como um dos benefícios da arquitetura compacta do Antares.
Entretanto, é fundamental evitar expectativas exageradas.
O Antares não elimina a necessidade de SAST, SCA, DAST, testes de segurança, análise de dependências, threat modeling ou revisão especializada.
Também não deve ser tratado como uma autoridade definitiva sobre a existência de uma vulnerabilidade.
Seu papel mais adequado é o de acelerador de triagem e investigação.
O modelo aponta caminhos.
O analista confirma.
O sistema ajuda a reduzir o espaço de busca.
O especialista toma a decisão.
Essa divisão de responsabilidades é provavelmente o caminho mais seguro para a adoção de IA em segurança cibernética.
Outro ponto que merece atenção é a necessidade de validação independente dos resultados divulgados. Os benchmarks apresentados pela Cisco são relevantes como demonstração inicial, mas organizações que pretendem adotar a tecnologia devem realizar seus próprios testes utilizando seus repositórios, linguagens, arquiteturas e padrões de desenvolvimento. Os números de desempenho publicados não devem ser interpretados automaticamente como garantia de eficácia em qualquer ambiente.
No cenário mais amplo da cibersegurança, o Antares aponta para uma transformação que tende a se aprofundar.
A inteligência artificial não será apenas utilizada para escrever código.
Ela também será empregada para questionar o código.
Para procurar suas fraquezas.
Para acompanhar vulnerabilidades recém-descobertas.
Para priorizar investigações.
E, potencialmente, para atuar continuamente dentro do ciclo de desenvolvimento.
A grande vantagem competitiva não estará necessariamente em possuir o maior modelo de IA.
Pode estar em possuir o modelo mais adequado para cada problema.
No caso da segurança de software, essa especialização pode significar uma mudança importante: em vez de esperar que uma equipe humana percorra manualmente enormes quantidades de código em busca de uma possível vulnerabilidade, sistemas especializados poderão realizar a primeira triagem continuamente, direcionando o conhecimento humano para os pontos onde sua experiência realmente faz diferença.
O Antares, portanto, deve ser compreendido menos como uma substituição do profissional de segurança e mais como uma nova camada de amplificação de sua capacidade.
Em um cenário no qual os atacantes utilizam automação e inteligência artificial para aumentar a velocidade de suas operações, transformar a análise de vulnerabilidades em um processo contínuo, econômico e integrado ao desenvolvimento pode deixar de ser uma vantagem tecnológica.
Pode se tornar uma necessidade de sobrevivência digital.
Referências bibliográficas
-
Cisco Blogs — Cisco Foundation AI. Introducing Antares: Highly Efficient Open Weight AI Models for Vulnerability Localization. Publicação oficial da Cisco sobre os modelos Antares-350M e Antares-1B, sua arquitetura, finalidade, benchmark e possibilidade de execução local. Acessar a publicação oficial da Cisco sobre o Antares
-
iMasters. Cisco libera Antares em código aberto e mira a caça a vulnerabilidades. Reportagem utilizada como referência para informações sobre o funcionamento da ferramenta, integração com CI/CD, formatos de saída, limitações e resultados divulgados. Acessar a matéria original do iMasters
