Documentação

O caminho mais curto do cadastro até o primeiro achado lido:

1. Cadastre um alvo. Em Alvos → Novo alvo, escolha o tipo (site/URL, repositório Git, ou host/rede) e informe o valor. Alguns tipos exigem verificação de posse antes do primeiro scan.
2. Dispare uma varredura. Em Scans → Novo scan, escolha o alvo e um scanner compatível com o tipo dele (a tabela em Tabela resumo mostra qual scanner serve para qual tipo de alvo).
3. Acompanhe o status. O job passa por queued → running → succeeded (ou failed, com o motivo). A maioria dos scanners termina em minutos — os de rede (OpenVAS) e os assíncronos (Dependency-Track) podem levar bem mais, ver tempo estimado de cada um.
4. Leia os achados. Em Findings, cada achado vem com severidade, e — depois de processado pelo motor de priorização — um nível de prioridade e o motivo dele estar onde está. Ver Como interpretar um achado para o que cada campo significa.
5. Confira o uso do seu plano. No menu da conta (canto inferior esquerdo) → Solicitar upgrade de plano, o modal mostra quantos alvos, scans do mês, usuários e sensores você já usa frente ao limite contratado — antes de esbarrar num bloqueio.
6. (Opcional) Instale um sensor. Se o alvo está numa rede que a plataforma não alcança de fora (rede interna, atrás de NAT), ou se você não quer que código-fonte/hosts saiam do seu perímetro, veja Instalar sensores remotos.

Um achado (finding) chega da varredura com uma severidade atribuída pelo próprio scanner que o encontrou. A plataforma então calcula, em cima disso, um nível de prioridade — a pergunta que geralmente importa mais não é "quão grave é isto isoladamente", é "o que eu corrijo primeiro".

Severidade — o que o scanner disse

Uma de Critical, High, Medium, Low ou Info, atribuída pelo scanner conforme o critério dele (CVSS quando aplicável, heurística própria quando não). É o dado bruto — ainda não leva em conta se aquele CVE é explorado ativamente, se o ativo é crítico para o negócio, ou há quanto tempo o achado está aberto.

Nível de prioridade (tier) — o que a plataforma concluiu

Uma escala própria de cinco níveis, na mesma linguagem em toda a interface — nunca "baixo/médio/alto":

O nível vem de um número de 0 a 100 (o "composto"), calculado a partir de cinco fatores: severidade, EPSS, criticidade do ativo afetado, tempo em aberto frente ao prazo esperado para a severidade, e confiabilidade do achado (se o scanner confirmou o achado, e se ele já reapareceu depois de corrigido). Quando um fator não se aplica — por exemplo, um achado de SAST não tem CVE, logo não tem EPSS — o peso dele é redistribuído entre os demais, em vez de contar como zero. Isso evita penalizar sistematicamente achados que nunca teriam aquele dado.

EPSS e CISA KEV — as duas fontes externas

EPSS (Exploit Prediction Scoring System, mantido pela FIRST.org) é uma estimativa — não uma certeza — da probabilidade de um CVE ser explorado nos próximos 30 dias. CISA KEV (Known Exploited Vulnerabilities, mantido pela agência de cibersegurança dos EUA) é uma lista fechada: só entra um CVE com exploração já confirmada em ataques reais. É por isso que KEV vira extreme por override, e EPSS é só mais uma das cinco dimensões do composto — uma é fato observado, a outra é estimativa.

SLA de remediação — quanto tempo é "tempo demais"

Achado aberto além do prazo da própria severidade pesa mais no composto — é a dimensão "idade vs. SLA".

Depois de ler: decidir e agir

Um achado pode receber uma decisão formal — corrigido, risco aceito (com responsável e prazo de reavaliação) ou falso positivo — que fica registrada com autor e data. Achados com decisão formal saem da lista de prioridades: já foram triados, não competem mais por atenção. Para o que ainda está em aberto, é possível abrir um plano de ação (responsável, prazo, evidência de correção) direto no achado. E o resumo executivo (Conta → Resumo) traduz tudo isso — quantos achados em cada nível, e por que o do topo é o do topo — em texto corrido, sem precisar entrar achado por achado.

Um sensor é um pequeno programa que roda numa máquina dentro da sua rede e faz as varreduras ali, do lado de dentro do firewall — em vez de a plataforma tentar alcançar seus sistemas de fora. Ele abre a conexão sempre de dentro para fora (só de saída), então nenhuma porta precisa ser aberta. Assim, código-fonte, hosts internos e pacotes de SO nunca saem do seu perímetro.

Tipos de sensor

Passo a passo

1. Pré-requisitos: uma máquina Linux na rede a escanear, com Docker e Docker Compose instalados, e saída HTTPS para a plataforma.
2. No painel, vá em Conta → Sensores Remotos → Novo sensor. Escolha o tipo, dê um identificador (ex.: matriz-sp) e clique em Gerar pacote. Para o Strix, preencha ali o modelo de IA, a chave e os alvos permitidos.
3. Baixe o .zip — a credencial já vem dentro dele, e só é mostrada uma vez.
4. Copie para a máquina e descompacte: unzip bscope-*.zip -d sensor, depois cd na pasta criada.
5. Configuração por tipo (só a do seu pacote):
   • Host/rede — OpenVAS: troque a senha padrão em openvas/.env e no docker-compose.yml (têm que ser iguais). Primeiro boot demora ~30 min (baixa o feed).
   • Host/rede — Vuls: gere uma chave SSH em vuls-ssh/ e autorize nos servidores alvo.
   • Repositórios: cadastre o token Git no alvo (Targets → 🔑) ou preencha GIT_TOKEN em repo/.env — no segundo caso o token não sai da sua máquina. Havendo os dois, o do painel vence.
   • Strix: se não preencheu no painel, edite strix/.env com LLM_API_KEY e ALLOWED_TARGETS, e crie /var/tmp/breachscope-strix.
6. Suba: docker compose up -d e acompanhe com docker compose logs -f.
7. Confirme: em até 1 min o sensor aparece como Online em Conta → Sensores Remotos.

Usar o sensor num scan

Cadastre ou edite um alvo do tipo compatível e escolha o sensor no campo "Executar em". Vuls e Strix só rodam por sensor — se disparar sem escolher um, o painel avisa.