VulnReach

SCA sensible au runtime — prouve quelles CVE sont réellement atteignables, pas seulement installées.

VulnReach est désormais un projet OWASP officiel. 🎉

Démo

Étape 1 — L'analyse SCA révèle 74 CVE dans les dépendances

Étape 2 — VulnReach prouve lesquelles sont réellement atteignables

Résultats — chaîne de preuve par CVE

Tableau de bord — 42 CVE confirmées atteignables sur 9 dépôts

Langages pris en charge : Python est entièrement prêt pour la production (taint, AST, route, runtime). Java et JavaScript disposent d'une analyse de graphe d'appels fonctionnelle et sont expérimentaux. Go, C# et PHP sont sur la feuille de route. Voir ROADMAP.md pour plus de détails.

VulnReach s'appuie sur la sortie SCA standard en ajoutant un contexte d'atteignabilité — prouvant via l'analyse statique, le suivi de taint et la couverture runtime réelle lesquelles des CVE détectées peuvent réellement être atteintes dans votre application.

Statut du projet

Derniers développements (publiés)

• Pipeline d'exécuteurs parallèles tenant compte des dépendances pour des analyses plus rapides
• Atteignabilité Python — prêt pour la production (couches taint, AST, route et runtime toutes fonctionnelles)
• Atteignabilité Java — graphe d'appels fonctionnel avec analyse des dépendances Maven/Gradle (expérimental)
• Atteignabilité JavaScript — graphe d'appels fonctionnel avec détection des points d'entrée de route (expérimental)
• Annulation d'analyse — POST /scan/{id}/cancel arrête les analyses en cours
• Contrat de réponse d'analyse stable : summary + compartiments classifiés sur GET /scan/{id}
• Normalisation partagée des réponses d'analyse entre l'API et le mode local de la bibliothèque (parité)
• Frontière d'exécution sécurisée par défaut :
  • la composition de base s'exécute sans montage du socket Docker
  • les analyses dynamiques nécessitent une adhésion explicite via VULNREACH_ALLOW_DOCKER_DAEMON=true
  • le profil d'exécution utilise un docker-socket-proxy restreint
• Passerelles de qualité déterministes basées sur des fixtures pour Java/JavaScript/Go dans le CI
• Accepté comme projet OWASP officiel — owasp.community/projects/vulnreach
• Endpoint IA pour prochaines étapes — POST /findings/{id}/next-steps produit des recommandations de remédiation orientées analyste (actions immédiates, sondes de validation, chemins de mise à niveau, surveillance) pour un résultat déterministe. Paresseux / à la demande : les analyses n'appellent jamais le LLM, et une défaillance du LLM est dégradée avec grâce. Le verdict déterministe est en lecture seule. Voir .

Expérimental

• Mode de traçage scan.runtime.ebpf (axé Linux, adhésion explicite)
• Génération OpenAPI assistée par IA et flux DAST intelligents

Voir :

• docs/incubator-readiness.md
• docs/threat-model.md

Comment ça fonctionne

Chaque CVE est classée via une chaîne de preuve à cinq niveaux :

1. SCA (Trivy)              → is the package installed and vulnerable?
2. Taint analysis (tainter) → does user input flow to the vulnerable sink?
3. AST analysis             → is the vulnerable function in your call graph?
4. Route exposure           → is the call path reachable from an HTTP endpoint?
5. Runtime coverage         → was the vulnerable code actually executed?

Le résultat est une liste de résultats priorisés avec quatre niveaux :

Démarrage rapide

Avec Docker Compose (recommandé)

Avis de sécurité — avant de commencer, copiez .env.example vers .env.local et remplacez chaque valeur CHANGE_ME par un secret aléatoire fort.
N'exposez pas VulnReach sur un réseau public sans définir de véritables identifiants et configurer CORS_ORIGINS.

git clone https://github.com/ihrishikesh0896/vulnreach.git
cd vulnreach

# 1. Create your local config
cp .env.example .env.local

# 2. Fill in every CHANGE_ME — generate secrets with: openssl rand -hex 32
$EDITOR .env.local

# 3. Start the stack
docker compose up --build

# Optional: enable dynamic runtime scans (Docker daemon access via restricted socket proxy)
# docker compose -f docker-compose.yml -f docker-compose.runtime.yml up --build

Lancer une analyse

Options d'authentification :

• JWT à courte durée de vie : POST /login
• Jeton API longue durée (clé API) : créez-le dans l'interface Settings -> API Keys, puis utilisez-le comme Authorization: Bearer <API_KEY>

# Get a token (replace with the credentials you set in .env.local)
TOKEN=$(curl -s -X POST http://localhost:8000/login \
  -H "Content-Type: application/json" \
  -d '{"username":"<your-admin-user>","password":"<your-admin-password>"}' | jq -r .access_token)

# Start scan from a GitHub repo
curl -X POST http://localhost:8000/scan \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"repo_url":"https://github.com/yourorg/yourapp"}'

# Poll for results
curl http://localhost:8000/scan/<scan_id> \
  -H "Authorization: Bearer $TOKEN" | jq .summary

Fonctionnalités

• SCA filtré par atteignabilité — classe chaque CVE selon la force des preuves, et pas seulement le score CVSS
• Confirmation runtime — collecte de couverture basée sur Docker via coverage.py
• Suivi de taint — trace l'entrée utilisateur → les sinks vulnérables (SQL, subprocess, YAML, pickle)
• DAST piloté par LLM — Claude/OpenAI/Ollama génère et valide des payloads d'exploitation (optionnel)
• Passerelles CI/CD — policy.block_if fait échouer les builds sur les résultats critiques confirmés
• Authentification JWT — multi-utilisateur, accès basé sur les rôles (admin / analyste)
• Jetons API (clés API) — authentification machine longue durée pour curl/CI (Authorization: Bearer <API_KEY>)
• Export PDF — GET /scan/{id}/export/pdf
• Aucun verrouillage fournisseur — les fonctionnalités LLM sont définies par défaut sur provider: none ; Ollama est pris en charge pour une utilisation hors ligne

En pratique

Cible d'analyse : multi-tier-dvpa — une application Python/Django volontairement vulnérable avec 72 CVE brutes réparties sur 11 paquets.

46 % des résultats ont été sortis de la file indifférenciée « tout corriger » pour rejoindre une liste d'actions priorisée. Dans un service de production typique (où de nombreuses dépendances transitives ne sont jamais appelées), ce chiffre atteint 70 à 90 %.

Méthodologie complète, détail de la chaîne de preuve et ventilation par paquet : docs/benchmark.md

Documentation

Usage

• USAGE_PACKAGE.md — installation du paquet/CLI, dépendances, démarrage, utilisation
• USAGE_UI.md — installation UI/serveur, dépendances, démarrage, utilisation

Opérateurs / Déployeurs

• docs/deployment.md — configuration Docker Compose, variables d'environnement, notes de production
• docs/configuration.md — référence complète de la configuration scan.yml
• docs/api.md — endpoints REST et schémas

Architecture / Sécurité

• docs/architecture.md — conception du pipeline et modèle d'exécution
• docs/threat-model.md — limites de confiance, STRIDE, cas d'abus
• docs/incubator-readiness.md — état de préparation OSS/OWASP
• docs/DAST.md — concepts et flux DAST

Contributeurs

• ROADMAP.md — fonctionnalités prévues, limitations connues, état du support des langages
• docs/development.md — internes, agents, stockage, points d'extension
• OWASP.md — notes sur le projet OWASP
• SECURITY.md — divulgation de vulnérabilités et rotation des clés
• CONTRIBUTING.md — processus de contribution
• CHANGELOG.md — historique des versions

Prérequis

• Python 3.11+
• PostgreSQL 13+
• Docker + Docker Compose v2 (pour l'analyse dynamique)
• trivy dans le PATH (install)
• jq (utilisé dans les exemples de démarrage rapide — install)

Optionnel (tout est ignoré proprement en cas d'absence) :

• semgrep — pip install semgrep
• tainter — pip install tainter (analyse de flux de taint ; voir guide de développement)

Licence

Apache 2.0 — voir LICENSE.