Seu código é uma superfície de ataque. Avalie-o da mesma forma que você avalia o que está em execução.
Conecte seus repositórios do GitHub ou do Bitbucket uma única vez. A WASViking clona cada branch padrão por conta própria e executa teste estático de segurança de aplicações, análise de dependências, detecção de secrets e geração de SBOM, e então registra cada risco com o seu contexto de remediação na mesma fila de Findings dos seus testes de aplicações e de APIs. Sem mudança no pipeline. Nada para instalar.
Ferramentas de pipeline só veem o código que tem pipeline. Scanners nem chegam a ver o código.
A maior parte da segurança de código vive dentro do CI. Repositórios sem pipeline, o serviço legado que ninguém mais implanta e a ferramenta interna que nunca ganhou um job ficam sem cobertura, e são eles que guardam o código mais antigo. Onde existe pipeline, cada ferramenta reporta no seu próprio console, de modo que alertas de dependências, secrets vazados e as fraquezas na lógica da própria aplicação são triados em três lugares diferentes, por três pessoas diferentes, contra três relógios diferentes.
O Code Security transforma isso em um único movimento. A WASViking lê o código, correlaciona com o que os seus scans já sabem sobre a aplicação em execução e registra o resultado onde a equipe já trabalha: a fila de Findings, a pontuação de risco, os alertas e os tickets.
[clone] acme/payments-api @ 3f9c2e1, branch padrão, workspace isolado
[sast] 18 arquivos relevantes para segurança selecionados, 4 fraquezas com evidência
[deps] 212 componentes, 9 vulneráveis, 1 no CISA KEV
[secrets] 1 credencial hard-coded, evidência mascarada
[sbom] CycloneDX registrado, drift desde a última execução: +3 componentes
→ 14 achados registrados, 2 reabertos, 1 resolvido sozinho
→ workspace excluído, registro da execução mantido
Quatro análises em cada repositório monitorado, um único conjunto de achados.
Cada execução clona a branch padrão em um workspace isolado e de curta duração, em um worker dedicado. Nada do repositório é executado, em momento algum. O clone e todos os arquivos intermediários são excluídos ao final da execução; ficam apenas os achados, a lista de componentes, a evidência mascarada e o registro da execução.
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 prioriza 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 controla o acesso e protege os seus usuários. Cada fraqueza vem com o arquivo e a linha, a rota e o parâmetro, o motivo de ser explorável, um cenário de ataque e a correção para aquele código exato.
Evidência ancorada no código real
Cada linha reportada é verificada contra o arquivo real antes de chegar até você. Uma fraqueza que a análise não consegue fundamentar no código é descartada, de modo que um desenvolvedor nunca abre um achado que aponta para um código que não existe. O painel de evidências mostra o trecho com a linha vulnerável destacada.
Análise de dependências
Manifestos de dependências de npm, pip, go, composer, Maven e gem viram uma lista de componentes comparada com o OSV e o catálogo CISA KEV, com detecção de drift em relação ao scan anterior do mesmo repositório. Uma correspondência com o KEV é destacada na linha, porque é a primeira a ser corrigida.
Detecção de secrets
A working tree é analisada em busca de credenciais hard-coded a cada execução, e o histórico git completo da branch padrão quando você ativa essa opção para um repositório. A evidência é mascarada antes de ser armazenada. Os achados ficam ao lado dos achados de DAST e SAST da mesma aplicação.
SBOM a cada scan
Cada execução produz um SBOM CycloneDX do repositório. Ele alimenta a reverificação diária do Supply Chain Intel contra novos advisories e pode ser exportado como um SBOM Evidence Bundle assinado para um cliente ou um auditor.
Cobertura que se amplia sozinha
Todo arquivo com um achado aberto é revisado novamente a cada scan, e o orçamento de revisão restante circula em rodízio pelo restante do repositório. Os repositórios monitorados são analisados na cadência do plano e imediatamente após um push na branch padrão, de modo que a cobertura cresce a cada execução sem que ninguém precise agendar.
Código e runtime em uma única fila, para que uma correção seja medida uma só vez.
Scanners de código isolados reportam no próprio console e param no commit. A WASViking também executa o seu DAST externo e interno, os seus testes de API e a sua telemetria de borda, de modo que uma fraqueza encontrada no código fica ao lado dos achados da aplicação que a entrega, sob o mesmo nome de repositório, a mesma pontuação de risco e o mesmo relógio de SLA.
Achados com identidade estável
A mesma fraqueza no mesmo lugar é um único achado ao longo dos scans, mesmo quando os números de linha mudam. Ele é reaberto em caso de regressão e se resolve sozinho quando duas revisões consecutivas do mesmo arquivo não o encontram mais. Severidade, pontuação de risco, SLA, trilha de auditoria, atribuição, webhooks e ticketing funcionam exatamente como para um achado vindo do tráfego.
Cobertura para o código que ninguém implanta
Não é preciso pipeline nem agente, de modo que o serviço legado, a ferramenta interna e o repositório que nunca ganhou um job de CI recebem a mesma avaliação que a aplicação principal. A cobertura é decidida por uma chave por repositório, não por qual equipe é dona de um servidor de build.
Um único movimento para o pipeline e a plataforma
Equipes que já condicionam merges a um gate da WASViking no GitHub Actions ou no Bitbucket Pipelines continuam fazendo isso. Os resultados do gate e da plataforma se unem sob o mesmo nome de repositório, em uma única linhagem, um único histórico de drift e um único conjunto de achados.
Uma única resposta para a pergunta "o nosso código é seguro", com a evidência anexada.
A liderança não pergunta qual scanner encontrou o quê. Ela pergunta se o código que processa dados de clientes é avaliado, se os riscos são conhecidos e se estão sendo fechados. O Code Security responde com números que se sustentam: o que foi revisado, o que foi encontrado, o que foi corrigido e quando.
Uma única fila de remediação
Os desenvolvedores abrem um achado e veem o arquivo e a linha, a rota, o parâmetro, o motivo de ser explorável e a correção, e então o fecham na ferramenta que já usam. Achados novos e reabertos chegam ao Slack, ao Teams, ao Jira, ao ServiceNow ou a um webhook pelas mesmas regras de qualquer outro achado.
Registros prontos para auditoria
Cada execução guarda o seu gatilho, branch, commit, duração e resultado. O relatório do repositório lista todos os achados abertos por motor, incluindo a seção de SAST, em um PDF que um responsável pelo código ou um auditor consegue ler. O SBOM Evidence Bundle comprova o que o software contém.
Minutos da conexão ao primeiro resultado
Instale o WASViking GitHub App ou aprove o consumer do Bitbucket, ative Monitored nos repositórios que importam e clique em Scan now. Os primeiros resultados aparecem na página enquanto você ainda está nela, e a cadência assume a partir daí.
Evidências mapeadas aos controles que o seu auditor já cobra.
Desenvolvimento seguro, revisão de código, inventário de componentes e gestão de vulnerabilidades são controles nomeados em todos os principais frameworks. O Code Security produz o registro por repositório e por execução que esses controles esperam.
| Framework | Controle | Com o que o Code Security contribui |
|---|---|---|
| PCI DSS v4.0 | Req 6.2.3 software sob medida e personalizado revisado antes da liberação · Req 6.3.1 vulnerabilidades identificadas e classificadas · Req 6.3.2 inventário de software sob medida e personalizado e de componentes de terceiros | Achados de SAST com evidência no nível do código-fonte e severidade, vulnerabilidades de dependências classificadas com contexto de KEV e um SBOM CycloneDX por repositório atualizado a cada scan |
| ISO 27001:2022 | Anexo A.8.25 ciclo de vida de desenvolvimento seguro · A.8.28 codificação segura · A.8.8 gestão de vulnerabilidades técnicas | Um registro contínuo e datado da avaliação de código por repositório, com cada fraqueza acompanhada da detecção à resolução, passando pela regressão |
| NIST SSDF (SP 800-218) | PW.7 revisar e analisar código legível por humanos · PW.4 reutilizar software bem protegido · PS.3 arquivar e proteger cada release de software | Análise automatizada de código a cada execução, procedência de componentes com correspondências de vulnerabilidades e um SBOM mantido por scan |
| OWASP Top 10 · ASVS | A01 Quebra de Controle de Acesso · A02 Falhas Criptográficas (secrets hard-coded) · A06 Componentes Vulneráveis e Desatualizados | Cada achado traz o seu mapeamento de CWE e OWASP, de modo que o relatório é lido no vocabulário que o avaliador espera |
| LGPD · GDPR | Artigo 46 · Artigo 32, medidas técnicas e organizacionais | Evidência demonstrável e datada de que o código que processa dados pessoais é avaliado continuamente e de que as fraquezas identificadas são fechadas |