owasp/xpsdTriage di raggiungibilità per le scansioni delle vulnerabilità. Invia i risultati dello scanner a un agente LLM che legge il tuo codice sorgente e stabilisce quali CVE sono effettivamente raggiungibili.
Un solo comando che stabilisce se una vulnerabilità segnalata è effettivamente raggiungibile in un determinato albero dei sorgenti.
Fornisci una descrizione CVE, o un intero report di scansione delle vulnerabilità, e questo esegue un'analisi di raggiungibilità guidata da LLM sul tuo codice, quindi scrive verdetti strutturati, report markdown e SARIF che GitHub code scanning legge.
Per mantenere bassi i costi, l'agente non legge il tuo repository nel contesto del modello. Lavora invece attraverso un insieme di strumenti: ast-grep per la navigazione strutturale del codice, ricerche su OSV.dev e rendering delle pagine per recuperare l'advisory e il commit di correzione; e il recupero delle dipendenze per portare una versione upstream fissata nella sandbox quando il componente interessato viene compilato anziché vendorizzato.
L'action viene eseguita su GitHub Copilot tramite il GITHUB_TOKEN integrato nel workflow.
Concedi copilot-requests: write e non c'è nient'altro da
configurare. L'utilizzo di OWASP Xpsd viene addebitato all'organizzazione insieme al resto della spesa
Copilot.
permissions:
contents: read
security-events: write
copilot-requests: write # the built-in token authenticates Copilot
Se preferisci usare un tuo modello, provider-type e api-key passano l'esecuzione ad Anthropic, OpenAI o Azure senza modificare nient'altro.
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
Sostituisci lo scanner con quello che già utilizzi. OWASP Xpsd rileva automaticamente il formato del report:
| Produttore | Formato |
|---|---|
| Grype | grype -o json, oppure SARIF |
| Trivy | trivy -f json, oppure SARIF |
| OSV-Scanner | --format json |
| Snyk | snyk test --json, singolo o --all-projects |
| qualsiasi produttore SARIF | SARIF 2.1.0 |
| Verdetto | Avviso | Gravità |
|---|---|---|
| raggiungibile (confidenza media/alta) | error | da CVSS |
| raggiungibile (bassa confidenza), incerto, analisi fallita | warning, richiede revisione manuale | da CVSS |
| non raggiungibile | note, informativo | abbassata a low |
Un finding escluso viene archiviato come low anziché mantenere la sua valutazione CVSS, perché il punteggio descrive la vulnerabilità e non il rischio che essa rappresenta per il tuo codice. Un critical che nulla può raggiungere è ciò che seppellisce quello che invece può essere raggiunto. Il punteggio reale resta nell'avviso, insieme alla motivazione e alle prove.
Ogni avviso riporta la motivazione del modello, il percorso di chiamata dal punto di ingresso all'uso vulnerabile e i link alle prove nelle righe di codice implicate. Le riesecuzioni aggiornano gli stessi avvisi sul posto, e i finding che scompaiono da un caricamento successivo vengono chiusi automaticamente.
Il costo è per finding, una sessione agentica ciascuno, quindi il filtraggio è il modo per mantenere contenuta un'esecuzione: min-severity, min-cvss, max-findings e only selezionano cosa esaminare, mentre is-remote mantiene solo i finding dimostrati come raggiungibili via rete (CVSS AV:N) e is-exploited mantiene solo quelli che il dataset CVSS-BT elenca come sfruttati. Entrambi richiedono prove positive, quindi un finding che non riescono a confermare viene scartato. fail-on trasforma un verdetto di raggiungibilità in uno step fallito quando vuoi bloccare la build.
La raggiungibilità dipende anche da fatti che non sono nel codice, come ciò che viene effettivamente compilato o ciò che è esposto a una rete. L'input guidance li fornisce come verità di base per l'analisi.
Segnalazioni di bug e pull request sono benvenute; vedi CONTRIBUTING.md. Segnala le vulnerabilità in privato come descritto in SECURITY.md, che documenta anche il modello di minaccia e i limiti noti.
Apache License 2.0, vedi LICENSE. Copyright 2026 ByteRay Ltd.