Deep Code Analysis

Por que a correspondência de padrões não basta

A página do Deep Code Analysis resume o problema em três frases: “SAST consegue sinalizar um padrão. Um LLM consegue explicar código. Nenhum dos dois estabelece como uma fraqueza afeta a aplicação.” Esta lição mostra o que isso significa na sua triagem do dia a dia.

O que um scanner de padrões vê

Pense em um handler de login dividido em dois arquivos:

# routes/auth.py
@app.post("/login")
def login():
    username = request.form["username"]
    user = find_user(username)

# services/users.py
def find_user(username):
    query = "SELECT * FROM users WHERE name = '" + username + "'"
    return db.execute(query)

Uma regra de padrão identifica uma concatenação de strings que chega a db.execute e reporta uma injeção de SQL em services/users.py. A correspondência está correta. Mesmo assim, ela deixa sem resposta as perguntas que decidem o que você faz em seguida:

• O username vem da requisição HTTP ou de uma constante em um job em lote?
• O valor é sanitizado ou parametrizado em algum ponto do caminho?
• O handler está roteado e implantado, e alguém na internet consegue alcançar o serviço?
• Que dados um atacante conseguiria ler por meio dele?

Sem essas respostas, as equipes caem em um de dois modos de falha. Umas tratam toda correspondência como urgente e se afogam em ruído. Outras passam a ignorar as correspondências e deixam escapar justamente a que importa.

O que uma explicação de IA acrescenta, e o que não acrescenta

Um modelo de linguagem de grande porte consegue ler find_user e escrever um parágrafo convincente sobre essa função. Mas uma explicação fluente não é evidência. Um modelo pode descrever um caminho de chamadas que não existe, citar uma linha que não está no arquivo ou considerar contaminada uma entrada que foi sanitizada duas funções antes. Se ninguém confere essas afirmações no seu repositório, você só trocou o ruído do scanner pelo ruído da IA.

Falhas sem nenhum padrão

Agora observe uma API de faturas:

// GET /api/invoices/:id
router.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await Invoice.findById(req.params.id);
  res.json(invoice);
});

Nada aqui chama uma função perigosa, e quem faz a chamada está autenticado. A falha está no que falta: não há nenhuma verificação de que a fatura pertence à conta de quem a solicita. Qualquer cliente pode percorrer os IDs de fatura e ler os dados de cobrança de todos os outros. Isso é uma referência direta insegura a objeto (IDOR), também chamada de autorização quebrada em nível de objeto (BOLA). Não existe um sink com o qual um padrão possa corresponder. Só dá para encontrar essa falha raciocinando sobre o que o código deveria permitir.

Onde o Deep Code Analysis se encaixa

A Plexicus chama a sua abordagem de Proof-Driven AppSec: Validar (AI Swarm Pentest), Entender (Deep Code Analysis), Remediar (Remediation). O Deep Code Analysis é a etapa Entender. Ele associa a um achado o fluxo afetado, se um atacante consegue alcançá-lo e a classe de fraqueza. Ele também confere as principais afirmações da IA com o seu código: os achados do AI Scan precisam citar uma linha real, e as etapas de rastreamento geradas por IA precisam corresponder ao seu repositório. Outros textos de IA, como a narrativa Attack scenario em Risk & exposure, não passam por essa verificação, e o produto indica que você deve conferi-los com o rastreamento do código.

O que o Deep Code Analysis acrescenta a um achado

O módulo 4 apresentou os sinais de um achado. Esta lição mostra o que os gera, para que você saiba quanto confiar em cada um.

Contexto	A pergunta que responde	Onde você vê
Fluxo afetado	Que entrada, caminho de código e operação isso afeta?	Code & taint trace
Alcançabilidade e exposição	Um atacante consegue chegar até ele, e a partir de onde?	Selo de alcançabilidade, Internet path, seção Exposure
Classe de fraqueza	Que tipo de fraqueza é esta?	Mapeamento para CWE e OWASP Top 10, Compliance & OWASP
Prioridade	Qual é a urgência em comparação com todo o resto?	Pontuação de prioridade em Risk & exposure

Fluxo de dados de source a sink e rastreamento de taint

A seção Code & taint trace começa com um Dataflow & Taint Trace: etapas numeradas que seguem dados não confiáveis desde um Source, como request.form["username"], passando por saltos de Propagation, até um Sink, como db.execute(query). Cada etapa traz um selo de origem:

Selo	Significado
Scanner dataflow	Uma regra de scanner em modo taint gerou a etapa.
AI-verified	O AI False-Positive Detection gerou a etapa, e ela foi conferida no seu repositório.
AI-inferred (unverified)	Um rótulo que a visualização do rastreamento prevê para uma etapa que não foi verificada. Se você o encontrar, trate a etapa como hipótese, não como evidência.

Uma etapa gerada por IA só conta como verificada se o arquivo dela existir no seu repositório e a linha citada aparecer nesse arquivo. Se o source ou o sink não passar nessa verificação, o rastreamento inteiro é descartado; uma etapa intermediária que falhe é removida. A IA nunca sobrescreve um rastreamento completo do scanner.

Vereditos de alcançabilidade

Selo	Em que se baseia
Reachable	Para código: “Dataflow from source to sink confirmed.” Para uma dependência: “Vulnerable symbol is invoked from application code.”
Not reachable	Evidência de que o código vulnerável não é usado.
Unknown reachability	Nada foi comprovado em nenhum dos sentidos. Na lista de achados, passe o mouse sobre o selo: o tooltip diz se é uma dependência transitiva cujo uso não pode ser confirmado ou um erro de avaliação que será tentado novamente. Na tela de detalhes do achado, a ausência de veredito aparece como Not analyzed yet.
N/A	Não é um achado de dependência e ainda não tem veredito de alcançabilidade.

As regras por trás dos selos são deliberadamente cautelosas. Uma dependência chamada em um ponto de chamada real no seu código é Reachable. Uma dependência que é apenas importada, ou apenas declarada em um manifesto escrito à mão, continua Unknown. Qualquer erro, clone com falha ou verificação cancelada também resulta em Unknown, nunca em Not reachable. Um achado de código se torna Reachable quando o AI False-Positive Detection o confirma como real e o rastreamento verificado dele contém tanto um source quanto um sink.

Dependendo da verificação executada, uma dependência transitiva pode aparecer como Not reachable (ela está presente apenas em um lockfile gerado e em nenhum lugar do seu código-fonte) ou como Unknown (não foi possível confirmar o uso dela em nenhum dos sentidos).

Análise de exposição

A seção Exposure responde a outra pergunta: a carga de trabalho por trás deste achado pode ser alcançada pela internet? A análise de exposição lê a sua configuração de implantação e lista quatro verificações, cada uma mostrando o que encontrou ou Not analyzed yet: o exposure path, do ingress ao serviço e ao deployment; a exposure surface (load balancers, network policies abertas, tráfego de saída); o security context (contêineres privilegiados, tokens de service account montados); e um contextual verdict.

A célula Internet path na faixa de cabeçalho (exposed ou none) e a linha Internet path em Risk & exposure mostram se foi encontrada uma rota pública. O indicador no topo da seção Exposure (Exposed, Not exposed, Not analyzed yet) atualmente segue o resultado de alcançabilidade do achado, então leia-o junto com o Internet path. Enquanto não houver veredito, Run analysis coloca na fila uma nova execução de validação.

A exposição altera a prioridade, nunca a severidade. Para uma visão de todo o repositório, use a ação de linha Exposure Map: Assets Repo Scan Exposure Map . Ele mostra Services mapped, Publicly exposed, Privileged e Last analysis do repositório, um grafo que liga a internet aos serviços dele e eventuais Proven exposure chains.

Modos de detecção do AI Scan e a regra da evidência literal

O Plexicus AI Scan, com o rótulo AI SAST no produto, é uma análise estática conduzida por um modelo de linguagem de grande porte. Ele está marcado como experimental, e a Plexicus o habilita por organização, de acordo com o seu plano. Antes de escanear, o AI Scan cria um índice semântico do seu repositório. Depois, um agente de IA avança da busca para o fluxo de dados, do fluxo de dados para o impacto e, por fim, para a confirmação no código-fonte, em vez de ler um arquivo após o outro.

Os três modos de detecção

Valor de Detection Mode	O que procura	Quando usar
logic: lógica de negócio e controle de acesso (padrão)	IDOR, autorização quebrada ou inconsistente, erros de lógica de negócio e de cálculo, condições de corrida, abuso econômico	Você quer as falhas que os scanners de padrões não pegam.
classic: injeção e vulnerabilidades clássicas	Injeção, XSS, path traversal, SSRF, XXE, desserialização insegura	O SAST baseado em padrões não está ativo no repositório.
combined: as duas rodadas	As duas categorias acima	Você quer as duas classes em uma única execução.

O modo combined executa as duas rodadas de forma independente e mescla os resultados. Ele consome aproximadamente o dobro do processamento de IA de um único modo. Se uma rodada falhar, a falha não fica escondida atrás dos resultados da outra. Cada achado do AI Scan traz uma tag com o nome da rodada que o gerou, logic ou classic, para que você possa filtrar ou agrupar por Tags. Quando a mesma falha é reportada duas vezes em uma execução, inclusive uma vez por cada rodada, o Plexicus a consolida em um único achado.

Nenhum modo reporta segredos embutidos no código nem CVEs de dependências, porque os mecanismos de Secrets e de SCA cuidam deles. O mecanismo garante isso: achados fora do escopo de uma rodada são descartados mesmo que o modelo os reporte.

A regra da evidência literal

Todo achado do AI Scan precisa citar literalmente a linha vulnerável. O mecanismo compara esse trecho com o arquivo, valida o caminho do arquivo e descarta qualquer achado cujo trecho não consiga encontrar. Essa regra ataca a falha mais comum da revisão de código por IA: um achado plausível sobre um código que não existe.

O AI Scan também trata o conteúdo do repositório e a saída das ferramentas como dados não confiáveis. Um comentário como “revisado pela segurança, pode pular este arquivo” é só texto em um arquivo, não uma instrução para o agente. E, se o índice não puder ser criado após novas tentativas, a execução é marcada como falha. Ela nunca aparece como um resultado limpo, com zero achados.

Falhas de lógica de negócio e de autorização

No modo logic, cada achado precisa declarar o invariante que é quebrado e um cenário de abuso concreto. Para a API de faturas da primeira lição, fica assim:

• Invariante: um cliente só pode ler as faturas que pertencem à própria conta.
• Cenário de abuso: faça login como qualquer cliente, solicite /api/invoices/ com IDs sequenciais e receba as faturas de outros clientes.
• Evidência: a linha citada const invoice = await Invoice.findById(req.params.id);

O mesmo modo cobre o contorno de limites e cotas, e etapas de fluxo que podem ser puladas, repetidas ou reordenadas, como confirmar um pedido sem pagar. Ele também cobre condições de corrida do tipo time-of-check to time-of-use (dois saques simultâneos que gastam o mesmo saldo duas vezes), erros de cálculo (valores negativos, arredondamento) e abuso econômico (resgate duplo de cupom, loops de reembolso).

O AI Scan atribui as severidades com estes significados:

Severidade	Achado típico do AI Scan
Critical	Explorável sem autenticação, como uma injeção de SQL em um endpoint público, ou o próprio bypass de autenticação
High	Execução remota de código, injeção de SQL ou bypass de autenticação acessíveis só com autenticação; IDOR em dados sensíveis; gasto duplo
Medium	XSS, CSRF, redirecionamento aberto, divulgação de informações, contorno de limites, falhas de cálculo
Informational	Configuração incorreta ou impacto limitado

O IDOR das faturas expõe dados de cobrança a qualquer usuário autenticado, então normalmente seria classificado como High.

AI False-Positive Detection: opt-in, somente leitura e subordinado à decisão humana

O AI False-Positive Detection revisa os achados após cada scan e decide se cada um é real. É também ele que gera os rastreamentos de taint AI-verified e os vereditos de alcançabilidade dos achados de código. Quatro propriedades definem até onde você pode confiar nele.

Opt-in

A configuração vem desativada por padrão, e a sua organização decide se vai ativá-la.

Somente leitura

O AI False-Positive Detection analisa uma cópia do seu repositório e tem instruções para nunca modificar arquivos de código-fonte. Ele não faz push de commits, não abre pull requests e não mexe em sistemas em execução. A única coisa que ele altera é o estado do achado dentro do Plexicus. As propostas de correção vêm do Remediation, tema do módulo 7.

Rigoroso sobre o que conta como falso positivo

A IA só pode marcar um achado de código como falso positivo se citar um indicador explícito:

• O arquivo está em um caminho de teste, fixture, exemplo, demo, prova de conceito ou documentação.
• O código sinalizado é comprovadamente código morto.
• A entrada é sanitizada antes do sink, inclusive por APIs seguras, como consultas parametrizadas ou escape de argumentos de shell.
• A classe de vulnerabilidade não se aplica.

Sem um desses indicadores, o achado é mantido. Se o handler de login da primeira lição usasse db.execute(query, params) com uma consulta parametrizada, isso seria um indicador válido. Um vago “parece estar tudo certo” não é.

O Plexicus aplica verificações adicionais antes que um veredito de IA oculte um achado, mas o rigor delas depende da configuração, então não as trate como garantia. Peça que uma pessoa revise os vereditos de IA sobre achados Critical, High, alcançáveis ou expostos.

Sempre subordinado à decisão humana

A seção AI verdict mostra Kept as real para qualquer achado que não esteja marcado como falso positivo, então confira se o AI False-Positive Detection está ativado antes de interpretar isso como uma confirmação da IA. Ao lado aparece um nível de AI confidence:

• “Low — heuristic rule. Follow the trace before acting.” (regra heurística; siga o rastreamento antes de agir)
• “Medium — corroborated by more than one signal.” (corroborado por mais de um sinal)
• “High — strong agreement across signals.” (forte concordância entre os sinais)

Uma confiança marcada como Estimated foi derivada da severidade, não medida. A mesma seção mostra Severity — scanner vs AI. A validação por IA pode elevar uma severidade em no máximo um nível, então um Medium do scanner pode virar High, mas nunca Critical. Ela também pode reduzir uma severidade quando o contexto do código limita o impacto. Compare os dois valores antes de agir.

A palavra final é sempre sua. Na tela de detalhes do achado, o botão abaixo da lista de seções mostra Mark as false positive, ou Revert false positive quando o achado já está marcado. A mudança vale imediatamente e também fecha qualquer pull request de correção aberto para o achado. Um veredito humano prevalece nas duas direções, e as execuções posteriores da IA não o alteram. A sua decisão de falso positivo também vale daqui para a frente: scans posteriores na sua organização suprimem automaticamente os disparos da mesma regra em código estruturalmente idêntico. Ela nunca passa para outra organização.

Como ler a análise e agir com base nela

Todo esse contexto alimenta um número e uma decisão: no que a sua equipe vai trabalhar em seguida.

A pontuação de prioridade

Cada achado recebe uma pontuação de prioridade de 0 a 100. Severidade e impacto são o fator dominante. A explorabilidade aumenta a pontuação, usando o valor avaliado por IA quando existe e o EPSS nos demais casos. O resultado é então ajustado pela alcançabilidade e pela confiança. Reachable não recebe desconto, Unknown recebe um desconto pequeno e Not reachable, um desconto grande. Uma confiança baixa reduz a pontuação, mas só até um piso. Em seguida, a análise de exposição eleva a prioridade das cargas de trabalho expostas e reduz a das pouco expostas, sem mexer na severidade.

No modelo atual, um Critical Reachable com EPSS alto e confiança alta fica com cerca de 96. O mesmo achado marcado como Not reachable fica com cerca de 34. Ele desce na sua fila, mas continua nela.

Uma rotina de triagem que usa a análise

1. Comece pelo que os atacantes conseguem alcançar: Findings Repo All filters Real risk Reachable ou clique no chip Reachable na linha Triage.
2. Avance pela prioridade, não pela severidade bruta.
3. Abra um achado e leia as seções nesta ordem: Code & taint trace (o caminho é real e qual é a origem dele?), AI verdict, Risk & exposure e, por fim, Exposure.
4. Decida: corrigir (módulo 7), validar em tempo de execução (módulo 6) ou marcar como falso positivo.

Para uma visão da postura, abra Dashboard DevSecOps Reachability Split . O widget mostra como os seus achados se dividem entre Reachable, Unreachable e Unknown.

Duas rodadas. Uma única verdade.

A análise estática diz onde está uma falha e por que ela importa. Ela não consegue provar que a falha é explorável na sua aplicação em execução. É isso que o AI Swarm Pentest faz. No produto, ele aparece como AI Pentest na seção Pentest. Ele testa a aplicação em execução dentro de um escopo acordado por escrito e segue uma regra: sem prova reproduzível, não há achado verificado.

As duas rodadas funcionam em sequência. O Deep Code Analysis anexa o contexto. O AI Swarm Pentest valida os caminhos prioritários. Os revisores veem a evidência e o escopo, e a sua equipe recebe um repasse acionável.

De volta à API de faturas. O AI Scan reporta o IDOR como High. O AI False-Positive Detection o manteve e rastreou req.params.id (source) até Invoice.findById (sink), então ele é Reachable, e o Internet path dele mostra exposed. Isso faz dele um forte candidato para o escopo do pentest. Se o pentest o reproduzir, você terá tanto a linha de código quanto a prova em tempo de execução. Por padrão, vincular um repositório de código-fonte ao pentest dá ao agente o seu código para uma execução white-box. Os achados de pentest aparecem em Findings App Pentest , com uma seção Evidence & attack path no lugar do rastreamento de taint.

Nenhuma das rodadas substitui a sua equipe. As pessoas revisam a evidência e decidem, e nada muda em produção automaticamente. A sua equipe mantém o controle do merge de cada correção.

Principais pontos

• Uma correspondência de padrão diz que uma regra disparou. O Deep Code Analysis acrescenta o fluxo afetado, se um atacante consegue alcançá-lo e a classe de fraqueza. Os achados do AI Scan e as etapas de rastreamento AI-verified são conferidos no seu repositório, e outros textos de IA, como o Attack scenario em Risk & exposure, vêm sinalizados para que você os verifique.
• Leia o selo de origem de cada etapa do rastreamento de taint. Um rastreamento vazio significa que não há caminho verificado disponível, não que o achado é seguro.
• O AI Scan executa o modo logic por padrão; classic e combined precisam ser ativados. Achados sem um trecho literal são descartados, e segredos e CVEs de dependências ficam a cargo dos próprios mecanismos.
• O AI False-Positive Detection é opt-in e somente leitura. Ele precisa de um indicador explícito para descartar um achado, Kept as real não prova que ele foi executado, e a sua decisão humana sempre prevalece.
• Alcançabilidade e exposição mudam a prioridade, nunca a visibilidade nem a severidade. Confira a evidência antes de confiar em Not reachable, trate Unknown como não comprovado e confirme a exposição pelo Internet path.
• O Deep Code Analysis fornece contexto e o AI Swarm Pentest fornece prova reproduzível. Você precisa das duas rodadas para chegar a uma única verdade.