Capacidades

Code Security

Conecte os seus repositórios do GitHub ou do Bitbucket e deixe a WASViking avaliar o código-fonte continuamente com teste estático de segurança de aplicações (SAST), revisão de segurança de IA / LLM, análise de dependências, detecção de secrets e geração de SBOM, com cada risco e o seu contexto de remediação em um só lugar.

O WASViking^® Code Security é o hub de Application Security para o código-fonte por trás das suas aplicações. Você conecta uma conta do GitHub ou um workspace do Bitbucket uma única vez e escolhe os repositórios a monitorar. A partir daí, a plataforma clona por conta própria cada branch padrão e executa quatro análises sobre ela: teste estático de segurança de aplicações (SAST), análise de dependências, detecção de secrets e geração de SBOM. Tudo o que ela encontra vai para Findings com o mesmo ciclo de vida, a mesma pontuação de risco, o mesmo SLA e os mesmos alertas do restante da plataforma, e o repositório passa a ser um ativo no seu inventário, como um alvo. Nenhuma mudança no pipeline é necessária.

O problema que ele resolve

A maior parte das ferramentas de segurança de código vive dentro do pipeline. Repositórios sem pipeline, serviços legados que ninguém mais implanta e as ferramentas internas que nunca ganharam um job de CI não recebem cobertura alguma, e muitas vezes são justamente eles que guardam o código mais antigo. Mesmo onde existe um pipeline, cada ferramenta reporta no seu próprio console, de modo que a equipe faz a triagem de alertas de dependências em um lugar, de secrets vazados em outro e nunca vê as fraquezas da lógica da própria aplicação, que nenhuma base de dados de dependências e nenhum scanner externo consegue alcançar.

O Code Security transforma isso em um único movimento. A WASViking lê o código, correlaciona o que encontra com o que os seus scans já sabem sobre a aplicação em execução e registra o resultado onde a sua equipe já trabalha: a fila de Findings, a pontuação de risco, os alertas e os tickets.

O que é executado em cada repositório monitorado

Teste estático de segurança de aplicações. A WASViking lê o próprio código-fonte da aplicação. A descoberta automatizada de código classifica os arquivos que importam para a segurança, como rotas, controllers, handlers de requisição e código de autorização, e a análise os revisa em busca de fraquezas na forma como a aplicação impõe o controle de acesso e protege os seus usuários. Toda fraqueza é reportada com evidência no nível do código-fonte: o arquivo e a linha, a rota e o parâmetro envolvidos, por que ela é explorável, um cenário de ataque concreto e a correção para aquele código exato. Cada linha reportada é verificada contra o arquivo real antes de chegar a você; tudo o que a análise não consegue fundamentar no código é descartado. Todo arquivo que tem um achado aberto é revisado de novo a cada scan, e o restante do orçamento de revisão é rotacionado pelo resto do repositório, de modo que a cobertura se amplia a cada scan sucessivo. A mesma revisão cobre o código que coloca um modelo de linguagem para trabalhar; veja AI / LLM Security abaixo.
Análise de dependências. Os manifestos de dependências (npm, pip, go, composer, Maven, gem, pub) viram uma lista de componentes comparada com o OSV e com o catálogo CISA KEV, com detecção de drift em relação ao scan anterior do mesmo repositório.
Detecção de secrets. A working tree, e o histórico git da branch padrão quando o seu plano o inclui e você o ativa para aquele repositório, são analisados em busca de credenciais embutidas no código. A evidência é mascarada antes de ser armazenada.
Geração de SBOM. Cada scan produz um SBOM CycloneDX do repositório. Ele alimenta a reverificação diária do Supply Chain Intel e pode ser exportado como um SBOM Evidence Bundle assinado.

AI / LLM Security

As equipes colocam modelos de linguagem nas aplicações mais rápido do que a área de segurança fica sabendo: um chat de suporte, um copiloto dentro do admin, um agente que pode reembolsar um pedido, uma camada de recuperação sobre documentos internos. O Code Security trata esse código como parte da mesma revisão de SAST, com a mesma pergunta que já faz sobre controle de acesso: alguém que não deveria consegue alcançar algo que não deveria?

A cada scan, a WASViking primeiro descobre onde o repositório usa IA, sem chamar nenhum modelo. Ela registra os provedores e gateways com que o código conversa, os frameworks de agentes e de orquestração, quantos agentes e ferramentas estão definidos, se documentos são recuperados para dentro do prompt (RAG), se há vector stores ou servidores MCP em uso e quais nomes de modelo o código referencia. Esse perfil aparece na linha do Code Security e no histórico de execuções, para que você saiba onde a IA já vive nos seus sistemas antes que a primeira fraqueza seja encontrada.

Em seguida, a revisão lê cada arquivo que conversa com um modelo junto com os módulos que completam o seu fluxo, como a rota que alimenta o agente e o módulo que define as ferramentas dele, e reconstrói o caminho de confiança: por onde entra o conteúdo não confiável, como ele chega ao prompt, o que a saída do modelo consegue alcançar no caminho de volta e se existe uma verificação no meio. As instruções de sistema são confiáveis. O prompt do usuário, documentos recuperados, páginas buscadas, e-mails recebidos, arquivos enviados e payloads de webhook são não confiáveis. Ferramentas e ações, bancos de dados, APIs internas, secrets, pagamentos, operações de conta e dados de outros tenants são sensíveis. Um caminho de não confiável até sensível sem um controle adequado no meio é um achado.

Achado	O que a WASViking encontrou no código
Prompt Injection Exposure	O conteúdo do usuário é incorporado ao contexto de instruções sem nenhuma fronteira entre instruções confiáveis e conteúdo não confiável.
Indirect Prompt Injection	Conteúdo recuperado, buscado, enviado por upload ou recebido entra no contexto do modelo e é tratado como instrução.
Unsafe LLM Tool Execution	O modelo pode acionar uma ferramenta ou ação sensível e nenhuma verificação de autorização confirma que quem chama pode executá-la.
Sensitive Data Exposure to LLM	Secrets, dados pessoais, financeiros, de saúde ou internos são enviados ao modelo quando a operação não precisa deles.
Cross-Tenant AI Context	A recuperação, a memória ou o contexto em cache não são restritos ao tenant de quem chama, de modo que o conteúdo de um cliente pode chegar ao prompt de outro.

A severidade acompanha o que o caminho alcança, não a presença de um prompt. Conteúdo do usuário que chega ao modelo sem nada adiante é Medium. Um caminho que alcança dados sensíveis é High. Um caminho que pode acionar uma ferramenta ou ação sem nenhum gate no meio é Critical. Isso evita que um endpoint de chat que apenas devolve o que o modelo disse seja classificado como um agente que pode reembolsar pagamentos, e é o que faz o achado merecer a atenção de um desenvolvedor quando ele é Critical.

O painel de evidência mostra a classe e o seu mapeamento para o OWASP Top 10 for LLM Applications, o ponto de entrada, a entrada não confiável, a chamada ao modelo, a operação sensível, se uma verificação de autorização foi encontrada, o caminho de confiança desenhado passo a passo, por que ele é explorável, um cenário de ataque, o trecho de código com a linha sinalizada e a correção para aquele código exato. Cada linha reportada é verificada contra o arquivo real, e a mesma identidade de arquivo e handler mantém um caminho de risco como um único achado entre scans.

A revisão nunca envia prompts ao seu modelo, nunca chama os seus provedores e nunca executa o repositório. Ela lê apenas o código-fonte.

Achados que se comportam como achados

Identidade estável. A mesma fraqueza no mesmo lugar é um único achado entre scans, mesmo quando os números de linha mudam. Ele reabre em caso de regressão e se resolve sozinho quando duas revisões consecutivas do mesmo arquivo não o encontram mais.
O mesmo ciclo de vida de todo o resto. Severidade, pontuação de risco, relógio de SLA, trilha de auditoria, atribuição, webhooks e ticketing funcionam exatamente como funcionam para um achado de DAST. Uma correção é medida da mesma forma, quer a fraqueza tenha sido encontrada no tráfego ou no código.
Evidência com a qual um desenvolvedor consegue agir. O painel WASViking SAST Findings de um achado mostra a classe da fraqueza, o arquivo e a linha, a rota e o parâmetro, uma explicação direta de por que ela é explorável, o cenário de ataque, a remediação e o trecho de código com a linha vulnerável destacada. A família de controle de acesso que ele reporta hoje inclui IDOR, BOLA, BFLA, verificações de autorização ausentes e clickjacking; a família de AI / LLM cobre prompt injection, prompt injection indireto, execução insegura de ferramentas, dados sensíveis enviados ao modelo e contexto entre tenants. Novas classes são adicionadas à medida que a análise cresce.

O que você vê

Application Security → Code Security: a visão de conjunto dos repositórios. Cards com repositórios com acesso concedido, repositórios monitorados, achados abertos, WASViking SAST Findings, AI / LLM Security com quantos repositórios usam IA, componentes rastreados, execuções neste mês e franquia do plano em uso. Uma linha por repositório com os controles Monitored e Git history, o commit que foi analisado, componentes, achados abertos por severidade, os achados de SAST por classe de fraqueza com a data em que o código foi revisado pela última vez, os achados de AI / LLM por classe com o perfil de uso de IA do repositório (provedores, frameworks, agentes, ferramentas, RAG), um marcador Drift quando o conjunto de dependências mudou e KEV quando um achado está no catálogo da CISA. O painel Runs mantém o histórico de cada scan com o seu gatilho, branch, commit, duração e o que ele encontrou.
Findings: filtre por repositório e por categoria para fazer a triagem, ou pela entrada do OWASP Top 10 for LLM Applications. Todo achado de SAST abre com o seu painel de evidência.
Relatório do repositório: um PDF com todos os achados abertos de um repositório, por motor, incluindo as seções de SAST e de AI / LLM e o perfil de uso de IA, para um responsável pelo código ou um auditor.
Inventário de software: componentes em Inventory → Software Bill of Materials, correspondências diárias com advisories em Inventory → Supply Chain Intel, submissões de secrets em Application Security → Hard-coded Secrets.

Alertas e tickets

Achados novos e reabertos seguem as suas regras de notificação como qualquer outro achado: Slack e Teams, Webhooks, Jira e ServiceNow.

Seguro por design

O clone acontece em um workspace isolado e de curta duração, em um worker dedicado. Nada do repositório é executado, em nenhum momento.
As credenciais do provedor nunca chegam ao seu navegador e são armazenadas criptografadas. Cada execução usa um token de curta duração, com escopo restrito ao repositório, que é descartado quando o clone termina.
Os clones usam apenas https até o provedor, com prompts, LFS e submódulos desativados e um teto de tamanho por repositório.
O clone e todos os arquivos intermediários são excluídos ao fim da execução, inclusive quando ela falha ou atinge o tempo limite. Só ficam os dados derivados: achados com as suas evidências, a lista de componentes, as correspondências de vulnerabilidades, a evidência de secrets mascarada e o registro da execução.
Em uma organização do GitHub, a conexão só é aceita a partir de um owner, de modo que um membro que consegue ver uma instalação não consegue vincular a sua organização a outro tenant.

Disponibilidade por plano

O Code Security está incluído no plano Pro e superiores; um parceiro ou a nossa equipe pode ativá-lo em outros planos. Cada repositório monitorado conta uma unidade na franquia do plano, qualquer que seja o seu tamanho e a frequência com que é analisado. Todo repositório monitorado é analisado pelo menos uma vez por intervalo (Pro a cada 24 horas, Business a cada 4 horas, personalizado no Enterprise) e imediatamente em um push para a branch padrão quando o intervalo já tiver decorrido. Usuários Admin e Manager conectam provedores e escolhem o que monitorar; usuários Analyst leem os resultados.

Onde ele fica no portal

Application Security → Code Security: cobertura, resultados e execuções.
Settings → System Settings → Connected Repositories: a conexão com o provedor, o que ela concedeu, sincronização e desconexão.
Findings: triagem, com os filtros de repositório e de categoria.
Account → Subscription → Repositories: franquia e uso.

Configuração

Siga Configure o Code Security: conecte o GitHub ou o Bitbucket, ative Monitored nos repositórios que a WASViking deve ler, execute o primeiro scan e deixe a cadência assumir. Depois, percorra Faça a triagem do seu primeiro achado de SAST para ler a evidência, corrigir o código e confirmar que o achado se encerra sozinho.