owasp/xpsdTriaje de alcanzabilidad para escaneos de vulnerabilidades. Envía los hallazgos del escáner a un agente LLM que lee tu código fuente y decide qué CVE son realmente alcanzables.
Un solo comando que decide si una vulnerabilidad reportada es realmente alcanzable en un árbol de código fuente determinado.
Pásale una descripción de CVE, o un informe completo de escaneo de vulnerabilidades, y ejecuta un análisis de alcanzabilidad impulsado por LLM sobre tu código, y luego escribe veredictos estructurados, informes en markdown y SARIF que GitHub code scanning lee.
Para mantener el costo bajo, el agente no lee tu repositorio en el contexto del modelo. En su lugar, trabaja mediante un conjunto de herramientas: ast-grep para la navegación estructural del código, consultas a OSV.dev y renderizado de páginas para extraer el aviso y el commit de corrección; y obtención de dependencias para traer una versión upstream fijada al sandbox cuando el componente afectado se compila en lugar de estar vendorizado.
La acción se ejecuta en GitHub Copilot a través del GITHUB_TOKEN integrado en el workflow.
Concede copilot-requests: write y no hay nada más que
configurar. El uso de OWASP Xpsd se factura a la organización junto con el resto de tu gasto en Copilot.
permissions:
contents: read
security-events: write
copilot-requests: write # the built-in token authenticates Copilot
Si prefieres usar tu propio modelo, provider-type y api-key cambian la ejecución a Anthropic, OpenAI o Azure sin modificar nada más.
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
Cambia el escáner por el que ya estés usando. OWASP Xpsd detecta automáticamente el formato del informe:
| Productor | Formato |
|---|---|
| Grype | grype -o json, o SARIF |
| Trivy | trivy -f json, o SARIF |
| OSV-Scanner | --format json |
| Snyk | snyk test --json, único o --all-projects |
| cualquier productor de SARIF | SARIF 2.1.0 |
| Veredicto | Alerta | Severidad |
|---|---|---|
| alcanzable (confianza media/alta) | error | según CVSS |
| alcanzable (confianza baja), incierto, análisis fallido | warning, requiere revisión manual | según CVSS |
| no alcanzable | note, informativo | rebajada a low |
Un hallazgo descartado se registra como low en lugar de conservar su calificación CVSS, porque la puntuación describe la vulnerabilidad y no el riesgo que esta supone para tu código. Un crítico que nada puede alcanzar es lo que entierra al que sí puede. La puntuación real permanece en la alerta, junto con el razonamiento y la evidencia.
Cada alerta incluye la justificación del modelo, la ruta de llamadas desde el punto de entrada hasta el uso vulnerable, y enlaces de evidencia a las líneas de código implicadas. Las reejecuciones actualizan las mismas alertas en su sitio, y los hallazgos que desaparecen de una carga posterior se cierran automáticamente.
El coste es por hallazgo, una sesión agéntica cada uno, así que el filtrado es la forma de mantener una
ejecución pequeña: min-severity, min-cvss, max-findings y only seleccionan qué
examinar, mientras que is-remote conserva solo los hallazgos que se demuestra que son alcanzables por red (CVSS
AV:N) e is-exploited conserva solo aquellos que el conjunto de datos CVSS-BT lista como
explotados. Ambos necesitan evidencia positiva, así que un hallazgo que no puedan confirmar se
descarta. fail-on convierte un veredicto de alcanzable en un paso fallido cuando quieres que la
compilación quede bloqueada.
La alcanzabilidad también depende de hechos que no están en el código, como qué se
compila realmente o qué está expuesto a una red. La entrada guidance los pasa
como verdad fundamental para el análisis.
Los informes de errores y las pull requests son bienvenidos; consulta CONTRIBUTING.md. Reporta vulnerabilidades de forma privada como se describe en SECURITY.md, que también documenta el modelo de amenazas y las limitaciones conocidas.
Apache License 2.0, consulta LICENSE. Copyright 2026 ByteRay Ltd.