Code Security

Conecte os seus repositórios do GitHub, do Bitbucket ou do GitLab 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, um workspace do Bitbucket ou um grupo do GitLab 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.

Provedores de código-fonte suportados

O Code Security se conecta às edições em nuvem dos três provedores mais usados. A tabela mostra o que cada conexão pede e como ela se comporta, para que a sua equipe de segurança possa aprová-la antes de alguém conectar.

O GitLab não oferece uma permissão mais restrita que api para adicionar um webhook, então é isso que a aplicação pede; a WASViking a usa apenas para listar os projetos e gerenciar o webhook de push que adiciona em cada projeto monitorado. Cada permissão da tabela é o mínimo que o provedor permite para ler o código e receber eventos de push; no GitHub, Members: read serve apenas para confirmar que quem conecta uma organização é o dono dela.

GitHub Enterprise Server, Bitbucket Data Center e Server, GitLab self-managed e Azure DevOps não são suportados hoje. Para código hospedado neles, os gates de pipeline executam as verificações de dependências e de secrets a partir do seu próprio CI.

Linguagens suportadas

• O teste estático de segurança de aplicações revisa Python, JavaScript, TypeScript (incluindo JSX e TSX), PHP, Ruby, Go, Java, Kotlin, C#, Scala, Groovy, Rust e Elixir. Os handlers de rota são reconhecidos quer o framework os declare com anotações, decorators, atributos, chamadas de router ou registros em linha, como nas minimal APIs do ASP.NET.
• O AI / LLM Security cobre as mesmas linguagens e segue os imports entre módulos em JavaScript, TypeScript e Python para completar cada fluxo.
• A análise de dependências lê manifestos e lockfiles de npm, pip, go, composer, Maven, gem e pub.
• A detecção de secrets lê todos os arquivos de texto do repositório, qualquer que seja a linguagem.

Para concentrar a revisão no código que trata requisições e aplica controle de acesso, o SAST deixa de fora testes, documentação e exemplos, saídas de build, código de terceiros e vendorizado, migrations, arquivos estáticos e arquivos minificados ou empacotados.

O que é executado em cada repositório monitorado

1. 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. Ela também lê o que a revisão da aplicação pula de propósito, suítes de teste, fixtures, helpers, documentação e ferramentas, em busca de credenciais escritas no código, dados pessoais usados como massa de teste e ganchos que contornam um controle de segurança da aplicação sob teste; veja Source Exposure abaixo. Os workflows do GitHub Actions do repositório passam pelas verificações de pipeline CI/CD.
2. 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.
3. 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.
4. 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.

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.

Source Exposure

Uma suíte de testes também é código-fonte, e ela guarda o que o código da aplicação toma cuidado para não guardar: a senha da conta de QA com que ela faz login, o token estático que ela envia a um endpoint interno, os identificadores que usa como massa de teste e o mecanismo de que depende para passar por um captcha ou por um código de uso único. Essas linhas são commitadas, clonadas por todo desenvolvedor e indexadas por toda ferramenta com acesso ao repositório. A revisão Source Exposure as lê.

Como funciona. Detectores determinísticos percorrem o clone inteiro, diretórios de teste incluídos, e propõem candidatos: um literal atribuído a um nome com cara de secret em código, configuração, arquivos de ambiente ou uma tabela de documentação com coluna de senha; um identificador que passa nos próprios dígitos verificadores (CPF, CNPJ, número de cartão de pagamento por Luhn) e não é um valor de teste conhecido; uma linha que cita um controle de segurança (captcha, MFA, OTP, código de verificação, autenticação) ao lado de uma pista de bypass, skip, override ou obtenção; o segredo de assinatura da própria aplicação (sessão, cookie, JWT, SECRET_KEY do Django e do Flask, secret_key_base do Rails, APP_KEY do Laravel) escrito como literal, qualquer que seja o valor. Placeholders, templates e valores que um teste envia de propósito para serem rejeitados nunca viram candidatos, exceto o segredo da própria aplicação, em que um valor como dev ou changeme é a própria fraqueza. A revisão então confirma ou rejeita cada candidato a partir do código ao redor e explica os confirmados. Os valores são mascarados antes de chegar à revisão e nunca aparecem na evidência; o que você vê é o valor mascarado e o arquivo e a linha.

Um mecanismo de bypass usado a partir de sessenta page objects é um único achado, ancorado no arquivo que o documenta ou implementa, com o número de arquivos que o usam. Uma credencial mantém a sua identidade entre scans pelo valor, então um valor rotacionado é um achado novo e o antigo se encerra.

Repositórios feitos de testes. A WASViking traça o perfil de cada clone: quantos arquivos de código ele tem, quantos ficam em diretórios de teste, quais runners de teste o manifesto cita. Um repositório que é uma suíte de automação de testes recebe esse rótulo na página do Code Security, porque a sua revisão da aplicação lê pouco por desenho (handlers não ficam em diretórios de teste) e a revisão de Exposição no código é a que o cobre.

Backend data access

Um número crescente de aplicações não tem servidor próprio: uma única página no navegador conversa diretamente com um backend-as-a-service (Supabase, Firebase, Appwrite, PocketBase, Hasura, Parse) com uma chave pública embarcada na própria página. Nesse modelo a fronteira de acesso é a camada de políticas do backend (row level security, security rules), e a única coisa que o código do cliente consegue mostrar é o que ele pede e se em algum momento faz login de um usuário. A WASViking lê isso.

Como funciona. A descoberta é offline: ela lista as tabelas, views, funções, coleções e buckets que o cliente lê e grava, toda chamada de login ou de sessão e as chaves encontradas em código e configuração, distinguindo uma chave publicável (esperada em uma página) de uma chave de serviço (nunca esperada ali) pela forma e, em uma chave no formato JWT, pela claim de role. Uma função remota conta como escrita quando o nome diz isso (salvar, fechar, excluir e os equivalentes em inglês e espanhol). Uma revisão por provedor de backend então lê os trechos ao redor dessas chamadas e responde o que é alcançável só com a chave pública. Um usuário escolhido em uma lista dentro da página, um nome digitado em um formulário ou um papel lido dos próprios dados não é uma sessão: o backend continua vendo o papel anônimo.

Esses achados ficam na mesma família de controle de acesso da revisão da aplicação, então contam no tile de SAST e abrem o mesmo painel de evidência: o backend, os recursos cobertos, as operações, o que o cliente mostra sobre sessões, o tipo de dado e os arquivos envolvidos. Um achado por backend e classe, ancorado em um ponto de chamada, mantém a sua identidade entre scans para qualquer linha a que a chamada se mova. Um fluxo de login que condicione as chamadas o encerra no scan seguinte.

O que a revisão não consegue ver são as políticas do próprio backend. Um achado aqui diz que o cliente não dá ao backend nenhum usuário para distinguir; se as políticas compensam isso é a pergunta a responder no backend.

Enviar um projeto (.zip)

Nem toda base de código fica em um provedor que a WASViking conecta: um repositório em outro SCM, uma cópia vinda de uma rede isolada, um projeto de terceiro que você está avaliando, ou um trial em que ninguém quer conceder uma conta ainda. Para esses casos, envie o projeto como zip. Na página do Code Security, Upload a project (.zip) pede um nome de projeto e o arquivo; achados e relatórios ficam arquivados sob esse nome, e enviar uma versão nova com o mesmo nome reanalisa o mesmo projeto com as mesmas identidades estáveis de achado.

O que acontece com o arquivo. O navegador o envia direto para o armazenamento de objetos privado sob uma autorização assinada, de objeto único e com tamanho limitado; o portal nunca repassa os bytes. O worker de scan baixa o arquivo com um teto de bytes, descompacta na área de trabalho isolada da execução e roda os mesmos motores que roda em um clone. Nada dentro do arquivo é executado. O arquivo é apagado quando a execução termina, qualquer que seja o resultado, então um scan novo precisa de um envio novo. Um projeto enviado não tem cadência nem gatilho por push; cada envio é uma execução manual.

O que é recusado ou ignorado. Um arquivo protegido por senha, um método de compressão diferente dos padrão, uma entrada que tenta escrever fora da pasta do projeto, um arquivo que se expande além da contagem de arquivos ou do tamanho descompactado aceitos, e qualquer coisa que não seja um zip fazem a execução falhar com um motivo claro. Links, arquivos de dispositivo e pastas de controle de versão (.git e semelhantes) dentro do arquivo nunca são materializados. Os arquivos são gravados sem permissão de execução.

Projetos enviados contam nos repositórios monitorados do seu plano.

CI/CD pipeline checks

Os workflows do GitHub Actions do repositório são verificados, sem modelo, em busca das fraquezas de pipeline que transformam um pull request ou um comentário em código rodando com os secrets do repositório.

Essas verificações são exatas, então um achado se encerra depois de uma única revisão limpa do mesmo arquivo de workflow.

Limites e o que não é analisado

• A cobertura é declarada, não presumida. A linha do repositório e o relatório dizem quantos arquivos de código o último scan leu para controle de acesso, contra o total que o clone tem, e rotulam um repositório de automação de testes como tal. "Sem achados de SAST" com uma fração pequena de arquivos lidos significa que a revisão não encontrou nada no que leu, não que a árvore inteira foi lida; a cobertura cresce a cada scan.
• As verificações de CI/CD cobrem workflows do GitHub Actions. Configurações de Bitbucket Pipelines e de GitLab CI ainda não são verificadas.

• Projetos enviados não têm histórico git. A varredura de secrets no histórico e os scans disparados por push precisam de um repositório conectado.

• Só a branch padrão. Outras branches e pull ou merge requests não são analisados.

• Tamanho do repositório. Repositórios de até 2 GB são clonados; um maior não é analisado e a execução informa o motivo.
• Orçamento de revisão por scan. Cada scan revisa até 50 arquivos de código com SAST. Os arquivos com achado aberto vêm primeiro e o restante rotaciona pelo repositório, então a cobertura cresce a cada scan.
• Histórico do git. A varredura de secrets em todo o histórico da branch padrão está disponível nos planos que a incluem, ativada por repositório.
• Só edições em nuvem. Veja os provedores acima.

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, quebra de autenticação (o handler que autentica concede uma identidade sem verificar uma credencial, ou um callback de login ou de single sign-on que nunca confere se a conta está ativa), métodos que um dispatcher expõe por convenção sem verificação de autorização própria, chamada de método ou função escolhida pela requisição sem allowlist, path traversal ou inclusão de arquivo a partir de um caminho controlado pela requisição, 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; a família de Exposição no código cobre credenciais fixas, dados pessoais no código-fonte e ganchos de bypass de controle de segurança; a família de pipeline CI/CD cobre checkouts de pull request target, injeção em expressões, permissões write-all e actions de terceiros sem pin. Novas classes são adicionadas à medida que a análise cresce.

O que você vê

• AppSec → Code Security: a visão de conjunto dos repositórios. Um cabeçalho com a cobertura de monitoramento (repositórios monitorados em relação aos que as conexões concederam, com as conexões por trás deles) e as ações da página; oito cards de indicadores em Security overview: repositórios com acesso concedido, repositórios monitorados, achados abertos com a barra de severidade, WASViking SAST Findings (controle de acesso, acesso a dados de backend, exposição no código e CI/CD), AI / LLM Security com quantos repositórios usam IA, componentes rastreados, execuções neste mês e franquia do plano em uso, cada um explicado ao passar o mouse e em Sobre os indicadores. O inventário oferece as visões Todas, Monitorados, Com achados e Maior risco (a pontuação do SBOM mais recente, da maior para a menor) sobre os filtros por nome, provedor, origem, cobertura e achados, com Limpar filtros assim que um deles estiver ativo. Uma linha por repositório em duas faixas: os fatos (o repositório com branch, visibilidade, conta e origem, os controles Monitorar e Histórico Git, o último scan com o commit que foi analisado, componentes, achados abertos por severidade, a pontuação de risco e as ações) e, em seguida, os detalhes de WASViking SAST e de AI / LLM Security: os achados de SAST por classe com a data em que o código foi revisado pela última vez e quantos arquivos de código do repositório o último scan leu (um repositório de automação de testes recebe esse rótulo), 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. A Visão compacta recolhe os detalhes atrás de uma seta e é lembrada no navegador; em telas estreitas cada linha vira um cartão. Exportar CSV baixa o inventário com os filtros em uso, todas as páginas de uma vez. 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, de Exposição no código, de pipeline CI/CD e de AI / LLM, a cobertura do último scan e o perfil de uso de IA, para um responsável pelo código ou um auditor.
• Inventário de software: componentes em Exposure → Inventory → Software Bill of Materials, correspondências diárias com advisories em Exposure → Inventory → Supply Chain Intel, submissões de secrets em AppSec → 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, descartado quando o clone termina: no GitHub, um token de instalação limitado àquele repositório; no Bitbucket e no GitLab, o token de acesso da autorização, renovado automaticamente, que a WASViking usa apenas para os repositórios do workspace ou grupo conectado.
• Os clones usam apenas https até github.com, bitbucket.org ou gitlab.com, 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 ou em um grupo do GitLab, a conexão só é aceita a partir de um owner, de modo que um membro que consegue ver o código 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

• AppSec → Code Security: cobertura, resultados e execuções.
• Admin → 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.
• Admin → User → Profile & Plan Usage → Subscription → Repositories: franquia e uso.

Perguntas frequentes

O Code Security funciona com GitHub, Bitbucket e GitLab? Sim, com GitHub.com, Bitbucket Cloud e GitLab.com. Cada provedor é conectado uma vez em Admin → System Settings → Connected Repositories, e todos recebem as mesmas análises, os mesmos gatilhos e os mesmos achados.

Posso conectar GitHub Enterprise Server, Bitbucket Data Center ou um GitLab self-managed? Hoje não. O Code Security alcança apenas as edições em nuvem. Enquanto isso, os gates de pipeline cobrem dependências e secrets a partir do seu próprio CI.

Qual branch é analisada, e os pull requests são analisados? A branch padrão de cada repositório monitorado. Pull e merge requests não são analisados.

Posso conectar mais de um workspace ou grupo? Sim. Cada workspace do Bitbucket ou grupo do GitLab é uma conexão própria, e uma instalação do GitHub App cobre os repositórios que você concede a ela. O seu plano conta repositórios monitorados, não conexões.

Por que a aplicação do GitLab pede a permissão api? É a única permissão do GitLab que permite adicionar um webhook, que é como um push dispara um scan. A WASViking a usa para ler a lista de projetos e gerenciar esse único webhook, e nunca altera código nem configurações dos seus projetos.

O que acontece com o código depois de um scan? O clone e todos os arquivos intermediários são excluídos ao fim da execução. A WASViking guarda os achados com as suas evidências, a lista de componentes, a evidência de secrets mascarada e o registro da execução.

Configuração

Siga Configure o Code Security: conecte o GitHub, o Bitbucket ou o GitLab, 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.