Faça a triagem do seu primeiro achado de SAST

Abra a primeira fraqueza que a WASViking encontrou no seu código-fonte, leia a evidência até o arquivo e a linha, decida o que fazer com ela e confirme que ela se encerra sozinha depois da correção.

Assim que o passo Configure o Code Security tiver produzido a primeira execução, as fraquezas que a WASViking^® encontrou no seu código-fonte ficam esperando em Findings, ao lado de tudo o que a plataforma encontrou no tráfego. Esta página acompanha uma delas da lista até o encerramento: onde encontrá-la, como ler a evidência, como registrar uma decisão e como a plataforma confirma a correção sem que ninguém reabra o ticket.

Antes de começar

• Um repositório monitorado com pelo menos uma execução concluída. A linha em Application Security → Code Security mostra Completed (concluído) em Last scan e uma contagem em WASViking SAST Findings.
• Acesso a Findings. A leitura é aberta a todos os papéis; alterar o status ou o responsável de um achado segue as permissões do seu papel.

Passo 1: abra os achados de SAST de um repositório

O caminho mais curto começa na página do Code Security. Na linha do repositório, os chips em WASViking SAST Findings indicam as classes de fraqueza encontradas (por exemplo IDOR, BOLA, BAC, Clickjacking). Clique em Open findings para cair em Findings já filtrado por esse repositório, pela categoria Broken Access Control (IDOR, BOLA, BFLA, clickjacking) e pelo status Open and active (abertos e ativos).

A partir do próprio Findings, defina Category com o mesmo valor, escolha o repositório em Repository e deixe Status em Open and active. O contador acima da tabela informa quantos achados correspondem aos filtros, e os filtros ativos aparecem como chips que você pode remover um a um.

Cada linha mostra a pontuação de risco, a severidade, o título, a categoria OWASP e o ativo. Sort vem por padrão em Severity first (severidade primeiro), então o achado a olhar primeiro está no topo.

Findings filtrado por repositório e categoria. Clicar em uma linha abre o painel com a visão geral, o resumo e a recomendação.

Passo 2: leia a evidência

Clique na linha. O painel abre à direita com tudo o que a análise sabe sobre a fraqueza.

Overview traz os campos que o restante da plataforma usa para todo achado: pontuação de risco, severidade, status, categoria, CWE, categoria OWASP, confiança, ativo, responsável, janela de SLA, data de vencimento, estado do SLA, primeira vez visto, última vez visto, número de vezes visto e o último scan que o viu. Summary descreve a fraqueza em um parágrafo, com o arquivo, a linha e o parâmetro. Recommendation é a correção para aquele código exato, não uma diretriz genérica.

Role até o bloco intitulado WASViking SAST Findings. Esta é a evidência no nível do código-fonte:

• a classe da fraqueza, depois Location (arquivo e linha), Route / function, Attacker input (o parâmetro que um atacante controla) e Language;
• Why this is exploitable (por que isto é explorável), em linguagem direta, e o cenário Attack que a reproduz;
• Vulnerable code, o trecho com a linha vulnerável destacada;
• References para as entradas do OWASP e do CWE por trás da classe, e o Audit log do achado, começando pelo scan que o criou.

Toda linha citada foi verificada contra o arquivo real antes de o achado ser criado. Se a análise não conseguiu fundamentar uma fraqueza no código, ela foi descartada, então o que você vê neste bloco está no repositório, no commit mostrado em Last scan.

O bloco de evidência: localização, rota, entrada do atacante, por que é explorável, o cenário de ataque e o código vulnerável com a linha destacada.

Uma ordem de leitura que funciona: o cenário de ataque diz se a fraqueza é alcançável na sua implantação; a rota e o parâmetro dizem qual requisição testar; o trecho diz ao desenvolvedor onde olhar.

Passo 3: decida e registre a decisão

A parte de baixo do painel traz os controles de remediação. Escolha New status, adicione um Comment (audit log) e clique em Save.

Severity override (substituição de severidade) permite aumentar ou reduzir a severidade quando o seu contexto justifica; a original fica registrada. Toda mudança vai para a seção Audit log do painel com quem fez e quando, e achados novos ou reabertos chegam ao Slack, Teams, Jira, ServiceNow ou a um webhook pelas mesmas regras de notificação de qualquer outro achado.

Passo 4: corrija o código e deixe a plataforma confirmar

Faça o push da correção para a branch padrão. Um push dispara um scan imediatamente quando o intervalo desde o último scan já decorreu; caso contrário, clique em Scan now na linha do repositório em Application Security → Code Security. O arquivo que tinha o achado aberto é revisado de novo a cada scan.

O achado se resolve sozinho quando duas revisões consecutivas do mesmo arquivo não encontram mais a fraqueza. Não há nada para clicar. Se a fraqueza voltar em um commit posterior, o mesmo achado reabre com o histórico intacto, de modo que a equipe vê uma regressão, não um item novo. O relógio de SLA e a pontuação de risco seguem as mesmas regras de um achado vindo de um scan da aplicação em execução.

Passo 5: entregue o registro

Report, na linha do repositório, gera um PDF com todos os achados abertos daquele repositório por motor, incluindo a seção de SAST com a evidência, para um responsável pelo código ou um auditor. Para uma visão de conjunto, o card WASViking SAST Findings na página do Code Security conta as fraquezas abertas em todos os repositórios monitorados.

Próximos passos

• A capacidade por inteiro: Code Security.
• Como pontuações de risco, SLAs e status funcionam para todo achado: Achados e Risk Score.
• Como encaminhar achados para as suas ferramentas: Slack e Teams, Jira, ServiceNow, Webhooks.