Remediation: do achado verificado à mudança revisada

“Detectar não é corrigir”: o que é uma mudança revisável e por que sua equipe mantém o controle do merge

Um achado diz que algo está errado. Ele não muda uma única linha do seu código. Entre uma coisa e outra existe um trabalho que os scanners não fazem. Alguém precisa escrever a correção e verificar se ela elimina a causa raiz sem quebrar nada. Depois, a mudança precisa passar pela revisão da sua equipe.

Remediation é a etapa Remediar do Proof-Driven AppSec. O AI Swarm Pentest valida o que é explorável (módulo 6), e o Deep Code Analysis explica como uma fraqueza afeta sua aplicação (módulo 5). Remediation transforma esse conhecimento em uma mudança que sua equipe pode revisar. Comece pelos achados que já passaram pela triagem (módulo 4), de preferência os que têm evidências, como um achado de pentest confirmado ou um caminho de código alcançável, para que o tempo de revisão vá para riscos reais.

O que uma mudança revisável contém

No Plexicus, uma remediação de código é uma proposta de mudança para um ou mais achados. Não é um commit na sua branch principal nem um simples ticket pedindo “por favor, corrija”. Ela tem quatro partes:

• Um diff. As linhas exatas adicionadas e removidas, arquivo por arquivo.
• Uma explicação e um título. A IA os escreve para quem vai revisar, dizendo o que mudou e por quê. Eles se tornam a descrição e o título do pull request.
• Um selo de verificação. Ele informa se a correção foi testada e com qual resultado.
• Um destino. A mudança vai para uma nova branch no seu repositório, com um pull request contra a sua branch base. No GitLab, é um merge request.

Pense em uma injeção de SQL em um handler de login, em que o handler concatena o endereço de e-mail enviado em uma string de query. Uma mudança revisável substitui a concatenação por uma query parametrizada naquele handler e explica por quê. Ela chega como um pull request que seus revisores podem ler ao lado das evidências do achado. Ela não reescreve sua camada de acesso a dados, e nada chega à sua branch principal até que alguém da sua equipe faça o merge.

Por que sua equipe mantém o controle do merge

O Plexicus nunca faz o merge de um pull request de remediação. O merge acontece no seu SCM, sob as suas proteções de branch, revisões obrigatórias e CI, e é feito por pessoas da sua equipe. Há três motivos.

• Código escrito por IA pode estar errado ou incompleto. A tela de revisão traz um aviso que pede que você valide a sugestão de acordo com o contexto e os requisitos do seu projeto.
• O contexto é da sua equipe. Pense em um IDOR em uma API de faturas, em que qualquer cliente logado consegue ler a fatura de outro cliente mudando o ID. Uma correção pode adicionar uma verificação de propriedade. Só a sua equipe sabe se o pessoal do suporte ainda deve poder abrir todas as faturas.
• Responsabilização. A descrição do pull request indica o usuário que o abriu, e o seu SCM registra quem aprovou e quem fez o merge. O Plexicus registra as solicitações de remediação no Audit Log da organização, e a seção Activity de cada achado mostra quando uma remediação foi gerada e quando o pull request dela foi criado.

Quais achados podem ser corrigidos no código

O Plexicus só consegue aplicar um patch em algo que esteja em um repositório. O que o painel de detalhes do achado oferece depende da origem do achado.

Achado	O que o painel de detalhes oferece
Um achado que aponta para um arquivo em um repositório conectado	Create AI Remediation
Um achado de registry de contêiner cuja imagem está vinculada a um repositório de código-fonte	Remediate in repo
Um achado cujo tipo de remediação é Issue, por exemplo quando não há uma linha de código-fonte para alterar	Create Issue
Um achado de AI Pentest	Nenhuma correção de código, a menos que o pentest tenha um repositório de código-fonte vinculado; confirme com a Plexicus se as correções de pentest estão disponíveis na sua versão
Uma configuração incorreta de cloud, um achado de postura do SCM ou uma imagem de registry não vinculada a um repositório	Nenhuma ação de remediação

Se um AI Pentest não tiver repositório vinculado, o Plexicus informa que a remediação exige um repositório de código-fonte vinculado e que você pode configurá-lo nas configurações do pentest.

Criar uma remediação por IA: verificações, estratégias de correção e progresso em tempo real

As verificações que o Plexicus executa primeiro

O Plexicus confirma que o trabalho pode dar certo.

1. Conexão de IA. Ele testa a conexão de IA da sua organização, seja a padrão do Plexicus, seja a sua própria (aula 5).
2. Conexão com o SCM. Ele valida seu token de controle de código-fonte. Se o token não for mais válido, o Plexicus pede que você reconecte seu controle de código-fonte.
3. Acesso ao repositório. Ele confirma que o repositório está acessível.
4. Veredito de falso positivo. Um achado que ainda aguarda a revisão de falso positivo, ou que a análise por IA marcou como falso positivo, não pode ser remediado. O tooltip informa isso, e o servidor também aplica essa regra. Reverter a marcação de falso positivo feita pela IA (módulo 4) remove o bloqueio.
5. Uma pessoa por vez. Se um colega já estiver remediando o achado, o botão fica desativado com “Another user is working on this finding”.

Repositórios de demonstração em sandbox pulam as verificações do SCM e podem gerar correções, mas não abrir pull requests nem issues. Se a sua cota mensal de uso de IA tiver acabado, o botão fica desativado (aula 5).

Como o Plexicus escolhe uma estratégia de correção

Você não escolhe a estratégia. O Plexicus a escolhe com base no achado.

Situação	Estratégia	Como a mudança é produzida
Uma pessoa marcou o achado como falso positivo	Comentário de supressão	Um comentário inline que silencia aquela regra naquele local
Um achado de dependência com uma versão corrigida conhecida na mesma versão major	Atualização de versão da dependência	Uma edição determinística no manifesto, sem IA escrevendo código
Todo o resto, incluindo atualizações de dependência que cruzam uma versão major	Agente de correção por IA	Uma mudança de código escrita pelo agente

O comentário de supressão segue uma decisão humana. Quando alguém marca um achado como falso positivo (módulo 4), o Plexicus solicita uma mudança que adiciona esse comentário. Dependendo do seu provedor de controle de código-fonte, ela chega como um pull request para sua equipe revisar, sem consumir sua cota de uso de IA.

A atualização de versão da dependência cobre os manifestos mais comuns, incluindo npm, Composer, requirements.txt, Gemfile, arquivos TOML, go.mod, Gradle e .csproj. A versão proposta é conferida no registry de pacotes; se não puder ser verificada, a remediação traz o aviso “review before merging”. Um salto de versão major pode mudar a API da biblioteca, por isso vai para o agente de correção por IA. Nenhuma IA escreve a atualização, mas ela ainda conta na sua cota de uso de IA.

O que o agente de correção por IA faz e o que não faz

O agente trabalha em um clone novo da branch configurada do repositório. O escopo dele é deliberadamente restrito:

• Ele corrige apenas o problema reportado, no arquivo e na linha reportados.
• Ele só mexe em outro arquivo quando a correção exige, como um helper compartilhado.
• Ele é instruído a não refatorar, não corrigir outros problemas que perceber, não editar arquivos de teste e não fazer commit. O Plexicus captura o resultado como um git diff.

Instruções não são garantias, então confira se o diff vai além do achado.

Para classes comuns de vulnerabilidade, o agente recebe o padrão de codificação segura da linguagem do arquivo: injeção de SQL (CWE-89), cross-site scripting (CWE-79), injeção de comandos do sistema operacional (CWE-78), path traversal (CWE-22) e arquivos temporários inseguros (CWE-377). Isso o orienta para uma query parametrizada em vez de um filtro baseado em blocklist. Para um segredo exposto, o agente move o valor para uma variável de ambiente, e a revisão acrescenta orientações para configurar uma solução de gerenciamento de segredos.

Quando uma remediação cobre vários achados, eles são agrupados por arquivo, alguns por sessão de IA, e os grupos são executados um após o outro. Os grupos concluídos são entregues mesmo que um grupo posterior exceda o tempo limite.

Acompanhar o progresso

O terminal em tempo real transmite cada etapa, do clone do repositório até “Generating fix…” e uma linha por grupo de arquivos, chegando a “Fix captured” e a um resultado final. Quando a correção fica pronta, o modal de revisão se abre automaticamente. View AI Remediation reabre o modal depois.

Se uma correção ainda estiver em execução após 15 minutos, o Plexicus mostra “This remediation is taking longer than expected.” e oferece Create Remediation Again. Se a geração falhar, você vê “Failed to create remediation” e um botão Try Again. Uma tentativa que falhou nunca impede uma nova tentativa.

Revisar a correção e abrir o pull request

O modal de revisão é onde entra o seu julgamento. Leia-o como leria o pull request de um colega, com as evidências do achado ao lado.

O que o modal de revisão mostra

• O título do achado e um selo de verificação.
• Um resumo da mudança: linhas adicionadas, linhas removidas e o número de arquivos.
• Um diff unificado para cada arquivo. Qualquer linha gerada que pareça corrompida aparece riscada e marcada com “Possibly corrupt generated line — review before applying.”
• Uma seção recolhível, Why this fix — reasoning & verification, com a explicação escrita pela IA.
• O aviso sobre IA e as branches de origem e de destino que o pull request vai usar.

A explicação é escrita no idioma de scan e relatório da sua organização (Scan & Report Language), que um Admin define em Settings Platform .

Como ler o selo de verificação

A verificação da correção é opcional. Sua organização a ativa com o toggle Fix verification em Settings Platform , e a disponibilidade depende do seu plano. Quando ela está ativa, uma segunda sessão de IA é executada em uma cópia isolada e descartável do repositório. Essa sessão escreve um teste de segurança focado no achado e o executa contra o código corrigido.

Selo	O que significa
Fix verified	O teste isolado foi executado e passou contra o código corrigido
Fix not tested	Nenhum teste de verificação foi executado para esta correção
Fix unverified	A correção foi aplicada, mas o teste excedeu o tempo limite, então ela não está comprovada
Verification failed	O teste constatou que a vulnerabilidade ainda é explorável
Verification error	Não foi possível executar o teste

A verificação apenas anota a correção. Ela nunca altera o diff que você revisa.

O que conferir antes de abrir o pull request

• Causa raiz, não sintoma. No handler de login, a correção é uma query parametrizada. Escapar aspas no campo de e-mail não é.
• Comportamento. No IDOR das faturas, confirme que a nova verificação de propriedade corresponde às suas regras reais de autorização.
• Dependências. Leia o changelog da nova versão e verifique se o seu lockfile precisa ser regenerado.
• Segredos. Mover um segredo para uma variável de ambiente interrompe o vazamento no código, mas o valor antigo continua comprometido. Faça a rotação dele.

Editar e depois abrir o pull request

Com as funções padrão, usuários Admin e Cyberoper podem editar o código gerado antes de existir um pull request. Use Edit Pull Request ou, em uma correção com vários arquivos, Edit e depois Save em cada arquivo. Depois que existe um pull request ou uma issue, a edição é bloqueada com “A pull request has already been created — editing is locked.” A partir daí, você altera o código na branch, no seu SCM.

Quando a mudança estiver pronta, um Admin ou Developer clica em Pull Request (Merge Request no GitLab) na parte de baixo do modal. O Plexicus clona a branch configurada e cria uma nova branch cujo nome começa com Plexicus-AI-Remediation-. Ele aplica o diff, faz o push e abre um pull request contra a branch base. O título e a descrição vêm da remediação, e a descrição termina com “Created by:” e o endereço de e-mail do usuário que o abriu. Um banner confirma “Pull request created” com um link See PR, e o botão no achado passa a ser See Pull Request.

Pull requests de remediação funcionam no GitHub, GitLab, Bitbucket Cloud, Azure DevOps, Gitea e Forgejo. O Azure TFVC não tem pull requests. Se o push falhar, o Plexicus explica o motivo: o repositório é um espelho somente leitura, o token precisa de acesso de escrita ou o token é inválido.

Para achados remediados como issue, o modal oferece Create Issue, além de Send Webhook se houver um webhook de issues configurado. Se uma integração de tickets estiver configurada para acompanhar pull requests, o ticket também é atualizado (módulo 9).

Status	O que significa aqui
Ready to Fix	Uma remediação foi gerada e aguarda revisão
Fix Submitted	Um pull request ou merge request foi aberto
Issued	Uma issue foi aberta em vez de um pull request
Fixed	O seu SCM informou o merge do pull request ou o fechamento da issue vinculada

Remediação em massa em vários achados

Corrigir os achados um a um não dá conta quando um scan reporta 40 pacotes vulneráveis em um serviço. A remediação em massa aplica o mesmo fluxo a uma seleção e acompanha a execução inteira em um só lugar. A disponibilidade da remediação em massa depende do seu plano.

Iniciar uma execução em massa

Em Findings , marque pelo menos dois achados, abra as ações em massa e escolha Remediate. Uma solicitação aceita até 100 achados. As ações em massa que você vê dependem da sua função (módulo 4); com as funções nativas, Developers só podem usar Create Pull Request em achados cuja remediação já foi gerada.

O Plexicus agrupa a seleção por repositório e depois por estratégia de correção, assim como faz com um único achado (aula 2). Em cada repositório, comentários de supressão, atualizações de versão de dependências e correções por IA viram, cada um, uma remediação própria, e só as correções por IA passam pelos grupos de arquivos do agente de correção por IA. Os achados remediados como issue recebem, cada um, uma issue própria escrita pela IA. O modal tem duas opções:

• Automatically create pull requests. Ativada por padrão. Quando está desativada, as correções param em Ready to Fix e nenhum push é feito.
• Pull request mode se aplica às correções por IA. Em qualquer um dos modos, cada repositório recebe um pull request para elas. Single PR registra cada grupo de remediação como um commit próprio, para que os revisores possam percorrer a mudança arquivo por arquivo, e deixa de fora os grupos que falharam ou não mudaram nada. One PR per remediation, o padrão, entrega as mesmas correções em um único commit. Atualizações de dependências e comentários de supressão sempre recebem um pull request próprio.

Clique em Remediate para começar. Achados que já têm uma remediação são ignorados. Achados que ainda aguardam a revisão de falso positivo, ou que a análise por IA marcou como falso positivo, ficam bloqueados, assim como acontece na remediação de um único achado.

Acompanhar a execução

O toggle Findings Bulk remediation status da barra de ferramentas abre o painel Bulk Remediation Progress. Cada execução passa por quatro fases: Queued, Generating fixes, Creating pull request e Completed. Uma execução aparece como Running, Completed ou Incomplete.

Cada grupo de remediação, ou seja, alguns achados no mesmo arquivo, mostra o próprio status. Estes são os que você verá com mais frequência:

Status do grupo	Significado
Queued	Aguardando o motor de remediação
Processing (com uma porcentagem)	O agente de correção por IA está trabalhando neste grupo
Succeeded	O grupo produziu uma mudança
Failed	A sessão de IA encontrou um erro ou excedeu o tempo limite
Skipped (no changes)	O grupo não produziu nenhuma mudança, e os achados dele ficam como estavam

Cada grupo tem o próprio terminal em tempo real, e View Pull Request leva você ao resultado. O painel continua disponível depois que você recarrega a página, e toda a equipe pode vê-lo. Um colega pode acompanhar uma execução que você iniciou sem precisar pedir atualizações. No modo Single PR, os achados de um grupo que falhou ou não produziu mudança mantêm o status.

Como montar um lote viável para seus revisores

Uma execução em massa vale o que valem os pull requests que ela gera. Mantenha os lotes coesos por repositório, por equipe responsável e por classe de problema. Por exemplo, selecione os 25 achados de dependências vulneráveis no serviço de pagamentos em vez de 25 achados sem relação entre si em seis repositórios. Um lote focado dá a uma equipe um pull request que ela reconhece e consegue revisar de uma vez. Um lote misturado produz pull requests pelos quais ninguém se sente responsável.

Configuração e uso de IA: cota, sua própria IA e o que nunca acontece automaticamente

Sua cota de uso de IA

As ações de IA consomem uma única cota mensal da sua organização. Isso inclui correções por IA, atualizações de versão de dependências, issues escritas pela IA e a análise de falsos positivos por IA. Executar scans de repositórios não consome essa cota, mas a análise com IA pode consumir, então confira o medidor antes de um scan grande com IA. A cota é renovada no dia 1º de cada mês do calendário (UTC), não na sua data de faturamento. As sessões de AI Pentest (módulo 6) e as conversões de filtros por IA têm contadores próprios. O tamanho da sua cota depende do seu plano.

Quando há dados de uso disponíveis, o menu do seu perfil mostra um medidor de uso e um link Manage billing & usage. Dependendo do seu plano, Settings Billing , uma página chamada Billing & Usage, mostra quanto do seu limite foi usado neste mês e a data em que a cota é renovada, ou Unlimited. Na página Billing, a barra fica âmbar em 75% e vermelha em 90%, e o Plexicus avisa você nos dois momentos. Quando a sua versão inclui, uma página Usage em Settings detalha o uso por ação, com o histórico completo.

Quando a cota acaba, Create AI Remediation fica desativado com uma mensagem de que o limite mensal foi atingido, o Remediate em massa fica desativado e a página Findings mostra um banner com Upgrade plan. As ações de IA voltam a funcionar quando a cota é renovada.

Traga sua própria IA (BYO-AI)

Dependendo do seu plano, você pode executar a IA do Plexicus nos seus próprios endpoints de modelo em vez dos modelos padrão do Plexicus.

Slot	Para que é usado	O que você informa
Fast model	É executado em todos os achados para validação e enriquecimento, então lida com grande volume	API key, Base URL, Model
Smart model	Gera correções e análise profunda, com volume menor e impacto maior	API key, Base URL, Model
Embeddings endpoint	Constrói o índice pesquisável do seu código antes de cada scan com IA	API key e Base URL; o modelo de embeddings é fixo e aparece somente para leitura

Cada slot aceita um endpoint padrão de chat completions ou de embeddings do seu provedor de IA, autenticado com uma chave de API, incluindo um gateway auto-hospedado. Não há seletor de provedor. Save BYOAI configuration testa e salva os três blocos juntos, e o endpoint de embeddings é obrigatório, porque uma configuração parcial quebraria todos os scans com IA. As chaves armazenadas nunca são exibidas de novo; deixe um campo de chave em branco para mantê-la. As Base URLs são verificadas contra server-side request forgery antes de um teste de conexão. Reset to Plexicus default limpa os três blocos. Com BYO-AI, o medidor de uso mostra Unlimited, porque a inferência roda com a sua própria chave e na sua conta junto ao seu provedor de IA.

Para onde vai o seu código

Os recursos de IA enviam o contexto de código relevante para o endpoint de modelo configurado: os modelos padrão do Plexicus ou o seu próprio endpoint, com BYO-AI. Cada remediação é executada em um job isolado e de curta duração. O agente só pode escrever no workspace clonado e não recebe nenhuma das outras credenciais da plataforma. A verificação é executada em uma cópia descartável, que é excluída em seguida. O código dos clientes não é usado para treinar modelos de IA, e os dados do SaaS ficam na UE por padrão.

O que nunca acontece automaticamente

Principais pontos

• Uma remediação é uma proposta: um diff, uma explicação, um selo de verificação e um pull request em uma nova branch. O Plexicus nunca faz o merge. Quem faz é a sua equipe, no seu SCM.
• Antes de iniciar uma correção, o Plexicus verifica a conexão de IA, o token do SCM, o acesso ao repositório e o veredito de falso positivo. Depois, escolhe entre um comentário de supressão, uma atualização de versão da dependência ou o agente de correção por IA.
• Revise o diff e a explicação “Why this fix” como faria com qualquer pull request. Um selo Fix verified comprova que o teste direcionado passou, não que nada mais quebrou.
• Edite enquanto a remediação ainda é uma proposta. Depois que o pull request existe, a edição é bloqueada, e Fix Submitted só vira Fixed quando o seu SCM informa o merge.
• A remediação em massa agrupa até 100 achados por repositório e por estratégia de correção. Escolha de forma deliberada se quer pull requests automáticos e qual modo de pull request usar, e acompanhe a execução no painel Bulk Remediation Progress.
• As ações de IA consomem uma cota mensal de uso de IA, exibida em Settings Billing e no menu do seu perfil. Com BYO-AI, você direciona os slots Fast, Smart e Embeddings para endpoints do seu próprio provedor de IA.