Achados, priorização e triagem

Onde ficam os achados: as abas Repo, SCM, Cloud, Registry e App Pentest

Todo resultado de scanner no Plexicus é convertido para um formato comum de achado e depois enriquecido com mapeamentos e pontuações, além de um veredito de IA quando o AI False-Positive Detection está ativado. Tudo isso vai parar em uma única página: Findings . Essa página é dividida em cinco abas, uma para cada tipo de ativo que você pode testar.

Aba	O que você encontra ali	De onde vem o ativo
Repo	Achados de código vindos de scans de repositório: fraquezas no código, dependências vulneráveis, segredos embutidos no código e configurações de infraestrutura como código ou de contêiner declaradas no repositório	Assets, Repo Scan
SCM	Achados de postura sobre a configuração do seu controle de código-fonte, e não sobre o código que ele contém	O seu provedor de controle de código-fonte conectado
Cloud	Achados sobre a configuração das contas de nuvem, identidade e acesso e recursos expostos, verificados com base em benchmarks	Assets, Cloud Assessment
Registry	Achados de imagens de contêiner descobertas nos seus registros conectados, filtráveis por imagem, tag e conexão de registro	Assets, Registry Audit
App Pentest	Achados gerados pelas execuções de AI Pentest, com a evidência e o caminho de ataque que os comprovaram	A seção Pentest

Uma injeção de SQL em um handler de login aparece em Repo, assim como uma imagem base vulnerável declarada no Dockerfile de um repositório. Uma biblioteca de sistema vulnerável dentro de uma imagem armazenada no seu registro de contêiner conectado aparece em Registry. Um IDOR em uma API de faturas que o AI Pentest reproduziu contra o seu alvo autorizado aparece em App Pentest. Na interface do produto, o AI Swarm Pentest aparece como “AI Pentest” na seção Pentest.

O que todas as abas têm em comum

As abas compartilham uma única tabela, um único sistema de filtros e uma única tela de detalhes, então as habilidades de triagem deste módulo valem em todas elas. Campos que só fazem sentido para um tipo de ativo, como Region nos achados de nuvem, ficam ocultos nas abas em que não se aplicam.

Nos scans nativos, o campo Tool mostra o mecanismo do Plexicus que gerou o achado, como plexicus-sast ou plexicus-iac; os resultados importados mostram o formato de origem da importação, como sarif. O módulo 3 aborda quais mecanismos existem e o que cada um cobre.

Recursos extras da aba Repo

A aba Repo tem dois controles extras na barra de ferramentas:

• Upload Scan importa resultados de um scanner externo para um repositório que você escolher. Ele aceita SARIF 2.1.0 e vários formatos de scanners comerciais, e os achados importados entram na aba Repo ao lado dos nativos.
• Add Repository inicia o mesmo fluxo que você usa em Assets, para que você adicione um repositório sem sair de Findings.

Columns to show permite adicionar e reordenar colunas da tabela, como Priority, Reachability, EPSS, CWE, Issue Owner ou Confidence. O layout é salvo por usuário.

Anatomia de um achado

Clique em qualquer linha para abrir o achado em um painel de detalhes sobre a lista. Pressione K ou J para ir ao achado anterior ou ao próximo sem fechar o painel.

A faixa do cabeçalho mostra Severity, CVSS 3.1, Priority, EPSS, Reachability, Internet path e Occurrences. Abaixo dela vêm as seções Code & taint trace (Evidence & attack path nos achados de pentest), AI verdict, Risk & exposure, Exposure, Compliance & OWASP, Activity (quando a sua função permite ver a trilha de auditoria) e Metadata & notes. Risk & exposure também traz um cenário de ataque gerado por IA; confira esse cenário com o rastreamento antes de agir com base nele.

Referência: os sinais de um achado

Campo	O que ele informa	Como interpretar
Severity (scanner)	A severidade bruta reportada pela ferramenta	Critical, High, Medium, Low ou Informational
Severity	A severidade após a validação por IA	Pode subir no máximo um nível acima do rótulo do scanner. Um veredito de falso positivo da IA a reduz para Informational sem alterar a severidade do scanner. Compare as duas em “Severity — scanner vs AI”.
Priority	O quão urgente o achado é no seu contexto, de 0 a 100	Combina severidade e impacto com a explorabilidade (EPSS ou uma estimativa da IA). Sofre um desconto forte quando o código não é alcançável, um desconto leve quando a alcançabilidade é desconhecida, e é atenuada por uma confiança baixa. Pontuações de 90 ou mais aparecem em vermelho. A pontuação vem de uma fórmula fixa, e não de um julgamento da IA; fraquezas de alto impacto, como injeção de SQL, injeção de comandos do sistema operacional, path traversal, SSRF e credenciais embutidas no código, recebem um bônus.
AI confidence	O quanto os sinais concordam que o achado é real, de 0 a 100	Low abaixo de 40, Medium de 40 a 74, High a partir de 75. Um selo “Estimated” significa que o valor foi derivado da severidade, e não medido.
Reachability	Se o código vulnerável é de fato alcançado	Reachable, Not reachable, Unknown reachability ou N/A
Internet path	Se uma rota pública alcança a carga de trabalho afetada	exposed ou none (None found em Risk & exposure). Altera a prioridade, nunca a severidade.
Seção Exposure	As verificações de implantação que a análise de exposição executou para a carga de trabalho	Uma etiqueta indica Exposed, Not exposed ou Not analyzed yet; o módulo 5 explica como interpretá-la junto com Internet path
EPSS	A probabilidade de a vulnerabilidade ser explorada em ambiente real	Preenchido apenas para achados que têm um CVE; nos demais, “No data”
CVSS	A pontuação padrão de severidade e o vetor	CVSS 3.1 na faixa do cabeçalho; v3 e v4 como colunas e filtros. Pode aparecer como estimated (AI) ou estimated (severity).
CWE / OWASP	A classe de fraqueza e a categoria correspondente do OWASP Top 10	Mapeado automaticamente a partir do CWE, com uma breve justificativa, e também para o OWASP CI/CD Top 10 e para os controles de compliance que você ativou
Issue Owner	O desenvolvedor a quem o código é atribuído	Preenchido a partir do blame do arquivo afetado no seu SCM; nos filtros, ele se chama “Assigned to”
Class	Problema explorável ou observação de postura	Vulnerability ou Hardening
Occurrences	Quantas instâncias existem	Conta as instâncias do mesmo problema no repositório

Alcançabilidade na prática

Em um achado de dependência, Reachable significa que o símbolo vulnerável é invocado a partir do código da sua aplicação. Em um achado de código, significa que foi confirmado um fluxo de dados do source até o sink. Unknown pode vir com um sufixo: “transitive”, quando não é possível confirmar a alcançabilidade em uma dependência transitiva, ou “evaluation error”, quando a verificação falhou e será repetida.

Como ler o rastreamento de taint

O Dataflow & Taint Trace mostra etapas numeradas com os rótulos Source, Propagation e Sink, e marca Cross-File quando uma etapa passa de um arquivo para outro. Em uma injeção de SQL em um handler de login, o source pode ser o parâmetro do nome de usuário, uma etapa de propagação pode ser o helper que o concatena em uma string de consulta, e o sink pode ser a chamada da consulta bruta. Cada etapa traz um selo de origem: Scanner dataflow, AI-verified ou AI-inferred (unverified). O painel só mostra um caminho quando o source e o sink foram verificados no repositório. Um rastreamento vazio significa que ainda não existe um caminho verificado, ou que nem o AI False-Positive Detection nem uma regra de scanner em modo taint geraram um caminho para este achado. O módulo 5 aborda como esses rastreamentos são construídos.

Status e o ciclo de vida dos achados

O status de um achado indica em que ponto ele está no fluxo de remediação. Enquanto o enriquecimento por IA ainda está em andamento, um achado novo fica oculto na lista padrão. Essa etapa não tem rótulo próprio; um achado aberto diretamente já aparece como AI-Analysed. Os rótulos que você vê são:

Status	O que significa	Como um achado chega lá
AI-Analysed	O enriquecimento terminou: as pontuações e os mapeamentos estão prontos, além do veredito de IA se o AI False-Positive Detection estiver ativado	Pronto para a sua triagem
Needs Input	O template de remediação precisa de informações suas	O botão de remediação oferece Enter details
Ready to Fix	Uma remediação foi gerada, ou o achado foi enviado aos desenvolvedores	Depois que uma remediação é gerada, ou depois de Send to Dev Team
Fix Submitted	Um pull request (um merge request no GitLab) foi aberto com a correção	Depois que uma remediação é enviada ao seu SCM
Issued	Uma issue foi criada para o achado	Usado quando o tipo de remediação é Issue
Fixed	A correção foi incorporada	O webhook do seu SCM informa que o pull request da remediação recebeu merge ou que a issue vinculada foi fechada

Fixed depende da sua equipe: são os seus revisores que decidem se e quando fazer o merge.

Flags ao lado do status

Falso positivo. Há duas formas de concluir que um achado não é real. O AI False-Positive Detection é uma configuração opcional da organização em Settings Platform , desativada por padrão e disponível conforme o seu plano; ele executa uma rodada de IA após cada scan. Você também pode decidir por conta própria com Mark as false positive no painel de detalhes do achado. Uma marcação humana fecha os pull requests de correção abertos do achado, exclui as remediações geradas para ele, atualiza as contagens do repositório e registra o veredito como humano. Ela também abre um pull request que adiciona um comentário de supressão inline para aquela regra, sem descontar da sua cota de uso de IA (módulo 7). O veredito fica guardado apenas dentro da sua organização: scans posteriores suprimem automaticamente a mesma regra quando ela dispara em código estruturalmente idêntico. Com as funções nativas, Admin e Cyberoper podem marcar falsos positivos; usuários com a função Developer, não.

Revert false positive desfaz a marcação: o achado volta para AI-Analysed e a Severity é redefinida para a severidade do scanner. Os falsos positivos ficam ocultos na lista padrão, então guarde o link de qualquer achado que você talvez precise revisitar.

Os vereditos automáticos passam por verificações extras antes de ocultar um achado, mas não trate essas verificações como uma garantia. Se a sua organização ativar o AI False-Positive Detection, combine como os vereditos de IA sobre achados Critical, High, alcançáveis ou expostos vão passar pela análise de uma pessoa. Um achado que ainda aguarda a revisão de falso positivo não pode ser remediado por enquanto, e o botão de remediação avisa isso.

Mitigado. Mark as mitigated ativa a flag Mitigated Externally do achado. Use quando o risco é tratado fora do código, por exemplo por uma regra de WAF. Ela não altera o status do fluxo de trabalho, e o achado continua na sua lista. Depois que você usa a opção, o botão desaparece e a flag não pode ser desfeita pelo console, então tenha certeza antes de clicar. O Plexicus não tem um status separado para aceitar o risco ou adiar o achado; registre o controle compensatório no seu ticket.

Duplicata e subachado. Essas marcações são definidas pelo Plexicus, e não por você. As duplicatas são explicadas em Nova detecção, mais abaixo, e os subachados, na próxima lição.

Solicitar revisão

Quando o status de um achado é Ready to Fix, um usuário com a função Developer vê Request review no painel de detalhes. Essa ação envia uma notificação Review Request, e os revisores as encontram em Notifications Review Requests , acessível pelo sino do cabeçalho.

Nova detecção

Um novo achado no mesmo repositório, arquivo e linha, com o mesmo CVE ou tipo de achado, é marcado como Duplicate do achado anterior, e o achado que permanece fica com a pior severidade entre os dois. Dependendo da configuração da sua organização, um scan posterior que detecte um achado que estava Fixed ou Issued pode reabri-lo: o achado passa de novo pela análise e é registrado como reaberto.

Re-Scan em Assets Repo Scan apaga os achados de um repositório e os status deles (módulo 2); use Relaunch scan no Activity Center para mantê-los. As marcações de falso positivo feitas por pessoas são lembradas e aplicadas de novo quando o mesmo código, sem alterações, é escaneado.

Quando a sua função permite ver a trilha de auditoria, a seção Activity do achado lista o histórico dele, do mais recente para o mais antigo: mudanças de status, remediações geradas, criações ou atualizações, solicitações de remediação em massa e exportações, cada item atribuído a Pipeline ou a User.

Como encontrar o que importa: chips, barra de consulta, filtros, visualizações e o filtro de IA

Ninguém lê todos os achados. A barra de ferramentas oferece cinco maneiras de colocar os achados certos em primeiro lugar.

A barra de consulta e os chips de triagem

A barra de consulta pesquisa títulos de achados, CVEs, pacotes e arquivos. Ao lado dela, os chips de Triage aplicam filtros com um clique, cada um com uma contagem em tempo real: Critical, High, Medium, Reachable, EPSS ≥ 0.5, Vulnerability e New 7d. Combinar Critical, High e Reachable é uma forma rápida de ver o trabalho real e urgente. New 7d mostra o que chegou nos últimos sete dias. Os chips Reachable, EPSS, Vulnerability e New 7d somam a sua condição a qualquer filtro que já esteja ativo, então restringem a visualização atual em vez de substituí-la.

Os chips de severidade filtram pela Severity (scanner); para filtrar pelo valor validado por IA, use Severity em All filters.

Filtros agrupados

All filters abre o modal Filters, em que os campos são agrupados pela pergunta que respondem:

• What to look at first: Severity, Severity (scanner), Priority, Finding confidence, Class e Finding status
• Real risk: Reachable, EPSS, CVSS v3, CVSS v4 e Occurrences
• Weakness type: CWE, CVE, OWASP Top 10, Type e Category
• Compliance: Regulation, Control e Control category, limitados às regulamentações que a sua organização ativou
• Where it lives: Repository, File, Language e campos de localização semelhantes
• Dependencies: Library e Library version
• Scanner: Tool, Rule e Provider
• Team & flow: Assigned to, Tags, Remediation type e Fixing effort
• Container registry: campos de imagem, exibidos na aba Registry

Cada valor pode ser incluído ou excluído. Clique no nome do campo de uma etiqueta na barra de consulta para alternar o operador entre is e is not, ou entre in e not in. O botão de aplicar mostra “View N findings”, e a contagem é atualizada conforme você ajusta, então você nunca aplica um filtro às cegas.

Visualizações salvas e links compartilhados

Quando o filtro estiver certo, salve-o: Findings Views Save view , dê a ele um nome como “Triagem diária” e clique em Save. Depois, aplicar uma visualização salva leva um clique. A URL sempre carrega o filtro atual, então Copy link compartilha exatamente a mesma visualização com um colega.

O filtro de IA em linguagem natural

Dependendo do seu plano, o ícone de varinha na barra de consulta abre “Describe what you want to see”. Digite um pedido como “critical injection findings in the payments repo from the last week” e clique em Build filter. O Plexicus transforma a frase em um filtro estruturado. Cada pedido usa uma conversão de filtro de IA. As conversões têm uma cota mensal própria, separada da cota de uso de IA consumida pelas correções e pela análise de falsos positivos. Confira o filtro gerado antes de agir com base nos resultados e salve-o como visualização para reutilizá-lo.

O que fica oculto por padrão, e por quê

A lista padrão oculta cinco tipos de achados:

• Falsos positivos, porque se concluiu que não são reais
• Duplicatas, porque o achado que permanece já as representa
• Subachados: achados de dependência da mesma biblioteca, versão e CVE no mesmo local são agrupados sob um achado principal, e corrigir o achado principal também corrige os subachados. A tela de detalhes de um subachado mostra Go to Parent Finding.
• Achados excluídos
• Achados ainda em enriquecimento, porque a prioridade e o veredito de IA deles ainda não estão prontos

Achados não alcançáveis nunca ficam ocultos por padrão. A alcançabilidade reduz a prioridade deles, mas um veredito estático é evidência, não prova de segurança, então o achado continua visível. Se quiser tirá-los de uma visualização específica, filtre por Reachable você mesmo.

Como agir sobre os achados: responsáveis, tickets, remediação, relatórios e exportações

A triagem só compensa quando todo achado relevante termina com um responsável e um próximo passo.

Responsáveis

O Issue Owner de cada achado de código vem do blame do arquivo afetado no seu SCM. Use o filtro “Assigned to” para montar uma fila para um desenvolvedor ou verificar o volume de trabalho de uma pessoa.

Para repassar trabalho aos desenvolvedores de forma explícita, selecione os achados e use Send to Dev Team. Isso se aplica a achados que já têm uma remediação gerada: eles são atribuídos aos usuários com a função Developer, passam para Ready to Fix e registram quem solicitou a revisão. Usuários com a função Developer veem apenas os achados atribuídos a eles.

Ações em massa e funções

As ações em massa exigem pelo menos duas linhas selecionadas, e o que você vê depende da sua função:

Função	Ações em massa
Admin	Remediate, Send to Dev Team, Create Pull Request
Cyberoper (operador de segurança)	Remediate, Send to Dev Team
Developer	Create Pull Request, habilitada apenas quando a seleção inclui um achado Ready to Fix

Tickets

No cabeçalho do painel de detalhes, Create Ticket oferece as integrações de tickets ativas da sua organização: Jira abre um formulário de ticket, ServiceNow registra um incidente e Webhook envia o achado para o webhook de issues que você configurou. Se nada estiver configurado, o menu leva à página de integrações de tickets. O módulo 9 aborda como configurá-las.

Como iniciar a remediação

Cada achado tem um tipo de remediação. Pull request significa uma mudança de código; o botão mostra Create AI Remediation. Issue é usado quando não há linha de código-fonte para alterar, para artefatos maliciosos e para provedores sem pull requests; o botão mostra Create Issue. O link do rodapé “Open in”, seguido do nome do seu provedor e do número da linha, leva direto ao arquivo no seu SCM.

Achados de Cloud e SCM não têm botão de remediação, porque não há arquivo de repositório para alterar. Um achado de Registry oferece Remediate in repo depois que a imagem é vinculada a um repositório de código-fonte.

Para vários achados de uma vez, selecione-os e escolha Remediate. O Plexicus os agrupa por repositório, e você escolhe se quer Automatically create pull requests e qual modo de pull request usar (Single PR ou One PR per remediation, o padrão). O módulo 7 explica os dois modos e o painel Bulk remediation status. A remediação por IA consome a sua cota de uso de IA.

Em qualquer um dos casos, o Plexicus prepara uma mudança revisável e nunca faz push para produção; a sua equipe mantém o controle do merge. O módulo 7 aborda a remediação em profundidade.

Relatórios e exportações

Você precisa de	Use	O que você recebe
Um relatório compartilhável da visualização atual	Download e depois PDF	Gerado em segundo plano; um aviso diz “We’ll email you when it’s ready” e, em seguida, chega uma notificação Report Ready
Achados em formato legível por máquina	Download e depois JSON	Um arquivo SARIF 2.1.0 (findings.json) da aba e dos filtros atuais, baixado na hora. Por padrão, inclui apenas achados com status AI-Analysed (módulo 8).
Um único achado para um ticket ou uma revisão	Download report, no painel de detalhes	Esse achado como um documento SARIF
O inventário dos seus repositórios	Download, em Assets, Repo Scan	repositories.csv

As duas exportações da lista respeitam a aba e os filtros ativos. As exportações em JSON ficam registradas na trilha de auditoria. A leitura de achados pela API REST é abordada no módulo 9.

Como medir o progresso no Dashboard

O módulo 2 apresentou as abas e os filtros do Dashboard; esta lição aborda os widgets que acompanham o progresso da triagem. A triagem é um hábito diário, e Dashboard mostra se ele está funcionando.

O que os totais contam

Os totais do Dashboard refletem o trabalho em aberto. Eles excluem duplicatas, subachados, falsos positivos, achados excluídos e achados já marcados como Fixed. Os achados da classe Hardening ficam separados dos números de vulnerabilidades. É por isso que uma boa semana de triagem faz os números caírem: marcar falsos positivos e fazer o merge de correções tiram achados da contagem em aberto.

Os widgets que respondem “estamos melhorando?”

Widget	Aba	O que mostra
Risk Posture Score	CISO	Uma pontuação de 0 a 100 em que mais alto é pior, calculada a partir dos achados em aberto ponderados pela severidade, com peso maior para os achados alcançáveis. Mostra uma linha de apetite a risco, uma tendência e uma dica como “Fix N findings to reach appetite”. Por enquanto, a linha de apetite é fixa e não pode ser configurada.
New vs Fixed	CISO	Achados criados por dia comparados com achados que chegaram a Ready to Fix, Fix Submitted, Issued ou Fixed, datados pela remediação
Top Risky Repositories	CISO	Repositórios classificados por uma pontuação de risco calculada a partir da severidade e do EPSS dos seus achados, com uma seta de tendência. O tooltip mostra a pontuação e as contagens de Critical e High. É um retrato do momento atual, então o filtro de repositório se aplica, mas o período não.
MTTR / Remediation Velocity	DevSecOps	Duas linhas, em dias: Time to attempt, da data de um achado até o início de uma remediação, e Time to fix, dessa remediação até a sua conclusão
Aging Buckets	DevSecOps	Achados em aberto por severidade em quatro faixas de idade: menos de 7 dias, 7–30 dias, 30–90 dias e 90 dias ou mais
Reachability Split	DevSecOps	Achados por severidade, divididos em Reachable, Unreachable e Unknown

Outros widgets incluem Total Findings, Supply Chain, Internet exposure, Scanner Coverage e as visões de OWASP. Em Total Findings, Prioritized Vulnerabilities conta os achados em aberto com prioridade de 80 ou mais.

Como ler o MTTR

As duas linhas do MTTR apontam para gargalos diferentes. Um Time to attempt longo significa que os achados esperam antes que alguém comece uma correção, o que é um problema de triagem ou de definição de responsáveis. Um Time to fix longo significa que as remediações foram iniciadas, mas demoram para ser concluídas; compare-o com o Time to attempt para ver se o trabalho trava antes ou depois do início da remediação.

New vs Fixed compara as chegadas com os achados que receberam uma remediação. Se New ficar acima de Fixed por semanas, a remediação não está acompanhando o ritmo dos novos achados.

O Plexicus não acompanha SLAs nem prazos; use Aging Buckets e MTTR para ver quanto tempo os achados ficam em aberto.

Principais pontos

• Os achados ficam em cinco abas (Repo, SCM, Cloud, Registry e App Pentest) que compartilham uma única tabela, um único sistema de filtros e uma única tela de detalhes.
• A severidade diz o quão grave um achado pode ser; a pontuação de prioridade de 0 a 100 diz o quão urgente ele é aqui, ajustada pela explorabilidade, pela alcançabilidade, pela confiança e pela exposição.
• Os status vão de AI-Analysed a Fixed. Falso positivo e Mitigated Externally são flags, e uma marcação humana de falso positivo pode ser revertida.
• Falsos positivos, duplicatas, subachados, achados excluídos e achados ainda em enriquecimento ficam ocultos por padrão. Achados não alcançáveis apenas perdem prioridade.
• Salve os seus melhores filtros como visualizações, compartilhe-os com Copy link e dê a todo achado relevante um responsável, um ticket ou uma correção revisável.
• Os totais do Dashboard contam apenas o trabalho em aberto. Use New vs Fixed, MTTR, Aging Buckets e Risk Posture Score para acompanhar o progresso.