Xpsd

OWASP Xpsd

Une seule commande qui détermine si une vulnérabilité signalée est réellement atteignable dans une arborescence de sources donnée.

Fournissez-lui une description de CVE, ou un rapport complet de scan de vulnérabilités, et il exécute une analyse d'atteignabilité pilotée par LLM sur votre code, puis écrit des verdicts structurés, des rapports markdown et du SARIF que GitHub code scanning lit.

Pour limiter les coûts, l'agent ne lit pas votre dépôt dans le contexte du modèle. Il travaille plutôt via une boîte à outils : ast-grep pour la navigation structurelle dans le code, les recherches OSV.dev et le rendu de pages pour récupérer l'avis et le commit de correction ; et la récupération de dépendances pour amener une version amont épinglée dans le bac à sable lorsque le composant affecté est compilé plutôt que vendu.

Intégration à GitHub CI

L'action s'exécute sur GitHub Copilot via le GITHUB_TOKEN intégré au workflow. Accordez copilot-requests: write et il n'y a rien d'autre à configurer. L'utilisation d'OWASP Xpsd est facturée à l'organisation avec le reste de vos dépenses Copilot.

permissions:
  contents: read
  security-events: write
  copilot-requests: write   # the built-in token authenticates Copilot

Si vous préférez utiliser votre propre modèle, provider-type et api-key basculent l'exécution vers Anthropic, OpenAI ou Azure sans rien changer d'autre.

Un workflow

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

Remplacez le scanner par celui que vous utilisez déjà. OWASP Xpsd détecte automatiquement le format du rapport :

Producteur	Format
Grype	`grype -o json`, ou SARIF
Trivy	`trivy -f json`, ou SARIF
OSV-Scanner	`--format json`
Snyk	`snyk test --json`, seul ou `--all-projects`
tout producteur SARIF	SARIF 2.1.0

Ce qui apparaît dans l'onglet Security

Verdict	Alerte	Sévérité
atteignable (confiance moyenne/élevée)	error	selon le CVSS
atteignable (faible confiance), incertain, analyse échouée	warning, revue manuelle requise	selon le CVSS
non atteignable	note, informatif	abaissée à low

Un résultat écarté est classé en low plutôt que de conserver sa note CVSS, car la note décrit la vulnérabilité et non le risque qu'elle représente pour votre code. Un critique que rien ne peut atteindre est ce qui enterre celui qui le peut. La note réelle reste dans l'alerte, avec le raisonnement et les preuves.

Chaque alerte porte la justification du modèle, le chemin d'appel depuis le point d'entrée jusqu'à l'utilisation vulnérable, et des liens de preuve vers les lignes de code concernées. Les ré-exécutions rafraîchissent les mêmes alertes sur place, et les résultats qui disparaissent d'un envoi ultérieur se ferment automatiquement.

Le coût est par résultat, une session agentique chacun, donc le filtrage est la façon de garder une exécution réduite : min-severity, min-cvss, max-findings et only sélectionnent ce qu'il faut examiner, tandis que is-remote ne conserve que les résultats démontrés comme joignables par le réseau (CVSS AV:N) et is-exploited ne conserve que ceux que le jeu de données CVSS-BT liste comme exploités. Les deux exigent une preuve positive, donc un résultat qu'ils ne peuvent confirmer est écarté. fail-on transforme un verdict atteignable en étape échouée lorsque vous voulez que le build soit bloqué.

L'atteignabilité dépend aussi de faits qui ne figurent pas dans le code, comme ce qui est réellement compilé ou ce qui est exposé à un réseau. L'entrée guidance les transmet comme vérité terrain pour l'analyse.

Documentation

docs/arch.md : comment fonctionne OWSP Xpsd.
docs/github-actions.md : intégration au workflow, chaque entrée et sortie, sémantique des alertes, dépannage.
docs/usage.md : la CLI, les deux modes, le filtrage, les fournisseurs, le schéma de verdict et les options.
docs/build.md : construction de l'image et builds natifs.

Contribution et sécurité

Les rapports de bugs et les pull requests sont les bienvenus ; voir CONTRIBUTING.md. Signalez les vulnérabilités en privé comme décrit dans SECURITY.md, qui documente également le modèle de menace et les limitations connues.