Configure o Code Security (SAST, SCA, secrets e SBOM)

Conecte o GitHub ou o Bitbucket uma única vez e deixe a WASViking clonar e avaliar por conta própria os repositórios que você escolher, com SAST, análise de dependências, detecção de secrets e geração de SBOM, na cadência do seu plano e a cada push. Sem mudança no CI e sem agente para instalar.

O Code Security é a forma de avaliar o seu código-fonte continuamente sem depender de pipeline. Você conecta a sua conta do GitHub (por meio do WASViking GitHub App) ou o seu workspace do Bitbucket Cloud (por meio de OAuth), escolhe quais repositórios a WASViking pode ler, e a WASViking^® assume a partir daí: ela clona a branch padrão em um workspace privado e de curta duração, executa testes estáticos de segurança de aplicações (SAST), análise de dependências, detecção de secrets e geração de SBOM, e registra os resultados em Findings, na página do Code Security e no seu inventário de software, sob o nome do repositório.

Nada muda no seu CI. Nada é instalado do seu lado. O repositório passa a ser um ativo no seu inventário, como um alvo. A capacidade em si é descrita em Code Security.

Quando usar cada opção

O que a WASViking faz com um repositório conectado

• Clona a branch padrão (clone raso por padrão; histórico completo apenas quando a varredura de secrets no histórico do git está ativada) em uma área temporária isolada, em um worker dedicado. Nada do repositório é executado, em momento algum.
• Executa SAST no código-fonte da aplicação: a descoberta automatizada de código classifica os arquivos que importam para a segurança, a análise os revisa e reporta cada fraqueza com o arquivo e a linha, a rota e o parâmetro, por que ela é explorável, um cenário de ataque e a correção. Todo arquivo com um achado aberto é revisado novamente a cada scan, e o restante do orçamento de revisão é distribuído em rodízio pelo resto do repositório.
• Executa o motor de SBOM: os manifestos de dependências (npm, pip, go, composer, Maven, gem, pub) viram um SBOM CycloneDX, enriquecido com OSV e CISA KEV, com detecção de drift em relação ao scan anterior do mesmo repositório.
• Executa o motor de secrets na árvore de trabalho, e no histórico do git quando o seu plano inclui esse recurso e você o ativa para aquele repositório.
• Registra os resultados em Application Security → Code Security (cobertura, última execução, componentes, achados abertos por severidade, achados de SAST, risco), Inventory → Software Bill of Materials, Application Security → Hard-coded Secrets e Findings (filtre por repositório), com a branch, o commit e o provedor vinculados a cada envio.
• Exclui o clone e todos os arquivos intermediários ao final da execução, inclusive quando a execução falha ou excede o tempo limite. Só ficam os dados derivados: os achados com suas evidências, a lista de componentes, as correspondências de vulnerabilidades, as evidências de secrets com os valores ocultados e o registro da execução.

Antes de começar

• Um plano que inclua o Code Security (Pro e superiores; um parceiro ou a nossa equipe pode habilitá-lo em outros planos). A aba Repositories, em Account → Subscription, mostra a franquia e o que está em uso.
• Um papel na conta com a capacidade Connected Repositories (Admins e Managers editam, Analysts visualizam).
• No GitHub: você precisa ser proprietário (owner) da conta ou da organização que detém os repositórios. A WASViking confirma isso durante o fluxo de conexão, então um membro que tem permissão para instalar o App, mas não é proprietário da organização, não consegue concluir a conexão; peça a um proprietário que a finalize. No Bitbucket: acesso ao workspace e permissão para adicionar webhooks de repositório.

Passo 1: conecte o provedor

1. Abra Settings → System Settings → Connected Repositories.
2. Clique em Connect GitHub. Você é levado ao GitHub, escolhe a conta, escolhe Only select repositories (recomendado) e seleciona os repositórios que a WASViking pode ler. O GitHub devolve você à WASViking e a conexão aparece com os repositórios concedidos. O App pede apenas Contents: read, Metadata: read e Members: read. Esta última é a forma como a WASViking confirma que quem conecta uma organização é proprietário dela; ela nunca é usada para ler um repositório.
3. Ou clique em Connect Bitbucket. Você é levado ao Bitbucket, aprova o consumer da WASViking e (se pertencer a vários workspaces) escolhe o workspace ao retornar. O consumer pede Account: read, Repositories: read e Webhooks: read and write.

Para adicionar repositórios depois: edite a instalação no GitHub (a lista sincroniza sozinha) ou clique em Sync na conexão. O Bitbucket lista todos os repositórios do workspace que você pode ler.

Settings → System Settings → Connected Repositories: a conexão, o que ela concedeu e onde sincronizar ou desconectar.

O card da conexão é o registro do que você entregou: a qual conta ela pertence, quantos repositórios a concessão cobre, quantos deles você está monitorando e quando a lista foi sincronizada pela última vez. Manage on GitHub leva você de volta à instalação para adicionar ou remover repositórios, e Disconnect encerra o acesso do nosso lado e revoga a chave do runner.

Passo 2: escolha o que monitorar

Abra Application Security → Code Security. Todos os repositórios concedidos são listados; ative Monitored nos que a WASViking deve avaliar. Cada repositório monitorado conta uma unidade na franquia do seu plano, qualquer que seja o tamanho dele e a frequência com que é analisado.

Git history: nos planos que incluem esse recurso, ative-o por repositório para executar o motor de secrets também no histórico completo da branch padrão. É mais pesado (um clone completo), então reserve-o para os repositórios em que credenciais vazadas em commits antigos importam.

Application Security → Code Security: uma linha por repositório, com os controles, o último scan e o que ele encontrou.

A linha é onde você lê o resultado sem sair da página: o commit que foi analisado, quantos componentes foram catalogados, os achados abertos divididos por severidade, os WASViking SAST Findings por classe de fraqueza, com a data da última revisão do código, e a pontuação de risco. Um marcador Drift significa que o conjunto de dependências mudou desde o scan anterior, e KEV significa que pelo menos um achado está no catálogo da CISA de vulnerabilidades exploradas, que é o que você deve olhar primeiro. Open findings leva à lista de Findings já filtrada por aquele repositório.

Os blocos no topo resumem o parque de repositórios: quantos repositórios as conexões concederam, quantos você monitora, achados abertos em todos eles, componentes rastreados, achados de SAST, execuções neste mês e quanto da franquia do seu plano está em uso.

Passo 3: faça um scan agora e depois deixe rodar

• Scan now em um repositório monitorado enfileira uma execução imediatamente (uma execução manual por repositório a cada 10 minutos). A linha mostra a execução passando por Queued, Cloning, Scanning e Recording results, e o painel Runs mantém o histórico: gatilho, branch, commit, duração, componentes, ocorrências de secrets, achados de SAST, achados promovidos e um motivo em linguagem clara quando uma execução não é concluída.
• Na cadência do plano: todo repositório monitorado é analisado pelo menos uma vez por intervalo (Pro a cada 24 horas, Business a cada 4 horas, personalizado no Enterprise), com o número de execuções simultâneas do seu plano.
• No push: um push para a branch padrão dispara um scan imediatamente quando o intervalo desde o último scan já passou; caso contrário, o push fica registrado e a próxima janela agendada o processa, de modo que um repositório movimentado nunca é analisado com mais frequência do que a cadência do plano.

As execuções no lado do servidor consomem as mesmas franquias mensais de envios de SBOM e de secrets que os gates de pipeline. Quando uma franquia se esgota, a execução registra esse motivo e a próxima execução tenta novamente após a renovação.

O que acontece quando o acesso muda

• A desinstalação do GitHub App, ou a sua suspensão, é detectada automaticamente: a conexão mostra o estado, os repositórios monitorados são liberados e nenhum novo clone é tentado.
• Repositórios removidos da instalação (ou excluídos, arquivados, transferidos) são marcados como No longer granted (não mais concedido) e deixam de contar.
• Disconnect em Settings desinstala o App (GitHub) ou descarta os tokens e remove os webhooks de push (Bitbucket), libera os repositórios e desativa a credencial do runner. O seu inventário, os SBOMs, o histórico de secrets e os achados permanecem.
• Encerrar a sua conta WASViking revoga todas as concessões de provedores, como um dos efeitos imediatos do encerramento.

Notas de segurança

• As credenciais do provedor nunca chegam ao seu navegador e são armazenadas criptografadas. A WASViking gera um token de curta duração, com escopo de repositório, para cada execução; ele é passado ao git pelo ambiente do processo, nunca em uma linha de comando, e descartado quando o clone termina.
• Os clones usam apenas https para github.com / bitbucket.org, com prompts, LFS e submódulos desativados e um teto de tamanho por repositório.
• Cada execução tem a sua própria credencial para enviar resultados (uma chave de sistema com escopo da conexão, oculta da página API Keys e revogada na desconexão), de modo que uma execução nunca pode gravar fora da sua organização.
• A verificação ativa de credenciais (chamar provedores terceiros para confirmar que um secret vazado ainda funciona) fica desligada nas execuções no lado do servidor.
• Em uma organização, a conexão só é aceita quando vem de um proprietário, e essa verificação é o único uso da permissão Members: read do App. Ver uma instalação não é o mesmo que ser proprietário dela: o GitHub mostra a instalação de uma organização a todo membro que alcance um repositório coberto, então, sem a prova de propriedade, qualquer funcionário poderia vincular a sua organização a um tenant WASViking próprio e ler tudo o que a instalação concede.

Onde isto se encaixa na plataforma

• Cobertura, achados de SAST e execuções: Application Security → Code Security; componentes em Inventory → Software Bill of Materials; ocorrências de secrets em Application Security → Hard-coded Secrets; triagem em Findings com o filtro de repositório.
• Uso e capacidade do plano: Account → Subscription → Repositories.
• Como ler e fechar o primeiro resultado de SAST, passo a passo: Faça a triagem do seu primeiro achado de SAST.
• Os gates de pipeline continuam sendo a forma de bloquear um build: GitHub Actions e Bitbucket Pipelines.
• O roteamento de alertas está documentado em Slack e Teams e Webhooks.