owasp/xpsdTriagem de alcançabilidade para varreduras de vulnerabilidades. Envia os resultados do scanner para um agente LLM que lê seu código-fonte e decide quais CVEs são realmente alcançáveis.
Um único comando que decide se uma vulnerabilidade reportada é realmente alcançável em uma determinada árvore de código-fonte.
Forneça a ele uma descrição de CVE, ou um relatório completo de varredura de vulnerabilidades, e ele executa uma análise de alcançabilidade orientada por LLM sobre o seu código, e então grava veredictos estruturados, relatórios em markdown e SARIF que o GitHub code scanning lê.
Para manter o custo baixo, o agente não lê o seu repositório para o contexto do modelo. Ele trabalha por meio de um conjunto de ferramentas: ast-grep para navegação estrutural de código, consultas ao OSV.dev e renderização de páginas para obter o aviso e o commit de correção; e busca de dependências para trazer uma versão upstream fixada para o sandbox quando o componente afetado é compilado em vez de vendorizado.
A action é executada no GitHub Copilot por meio do GITHUB_TOKEN integrado ao workflow.
Conceda copilot-requests: write e não há mais nada a
configurar. O uso do OWASP Xpsd é cobrado da organização junto com o restante dos seus gastos
com o Copilot.
permissions:
contents: read
security-events: write
copilot-requests: write # the built-in token authenticates Copilot
Se preferir usar seu próprio modelo, provider-type e api-key alternam a execução para Anthropic, OpenAI ou Azure sem alterar mais nada.
name: reachability
on:
workflow_dispatch:
schedule:
- cron: "0 6 * * 1"
permissions:
contents: read
security-events: write
copilot-requests: write
jobs:
reachability:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: anchore/sbom-action@v0
with: {format: cyclonedx-json, output-file: sbom.cdx.json, upload-artifact: false}
- uses: anchore/scan-action@v6
with: {sbom: sbom.cdx.json, output-format: json, output-file: scan.json, fail-build: false}
- uses: byteray-ai/xpsd@v1
id: xpsd
with:
scan-file: scan.json
model: gpt-5.3-codex
min-severity: high
max-findings: "10" # cap the analyzed findings, highest severity first
# min-cvss: "7.0" # numeric floor instead of the severity band
# is-remote: "true" # only findings shown to be network-reachable (AV:N)
# is-exploited: "true" # only findings CVSS-BT lists as exploited
# max-cycles: "30" # tool-call budget per finding
# max-tokens: "150000" # token budget per finding; first ceiling hit wins
# fail-on: reachable # fail the step when something is reachable
- uses: github/codeql-action/upload-sarif@v3
if: always()
with:
sarif_file: ${{ steps.xpsd.outputs.sarif-file }}
category: xpsd-reachability
Troque o scanner por aquele que você já executa. O OWASP Xpsd detecta automaticamente o formato do relatório:
| Produtor | Formato |
|---|---|
| Grype | grype -o json, ou SARIF |
| Trivy | trivy -f json, ou SARIF |
| OSV-Scanner | --format json |
| Snyk | snyk test --json, único ou --all-projects |
| qualquer produtor SARIF | SARIF 2.1.0 |
| Veredito | Alerta | Severidade |
|---|---|---|
| alcançável (confiança média/alta) | error | a partir do CVSS |
| alcançável (baixa confiança), incerto, análise falhou | warning, requer revisão manual | a partir do CVSS |
| não alcançável | note, informativo | rebaixado para low |
Um achado descartado é registrado como low em vez de manter sua classificação CVSS, porque a pontuação descreve a vulnerabilidade e não o risco que ela representa para o seu código. Um crítico que nada consegue alcançar é o que soterra aquele que consegue. A pontuação real permanece no alerta, junto com a justificativa e as evidências.
Cada alerta carrega a justificativa do modelo, o caminho de chamada do ponto de entrada até o uso vulnerável, e links de evidência para as linhas de código-fonte implicadas. Reexecuções atualizam os mesmos alertas no local, e achados que desaparecem de um upload posterior são fechados automaticamente.
O custo é por achado, uma sessão agêntica cada, então a filtragem é como você mantém uma
execução pequena: min-severity, min-cvss, max-findings e only selecionam o que
analisar, enquanto is-remote mantém apenas achados comprovadamente alcançáveis pela rede (CVSS
AV:N) e is-exploited mantém apenas aqueles que o conjunto de dados CVSS-BT lista como
explorados. Ambos exigem evidência positiva, então um achado que eles não conseguem confirmar é
descartado. fail-on transforma um veredito alcançável em uma etapa com falha quando você quer
bloquear o build.
A alcançabilidade também depende de fatos que não estão no código, como o que de fato
é compilado ou o que está exposto a uma rede. A entrada guidance fornece
esses fatos como verdade fundamental para a análise.
Relatos de bugs e pull requests são bem-vindos; veja CONTRIBUTING.md. Relate vulnerabilidades de forma privada conforme descrito em SECURITY.md, que também documenta o modelo de ameaças e limitações conhecidas.
Apache License 2.0, veja LICENSE. Copyright 2026 ByteRay Ltd.