VulnReach

SCA sensible au runtime — prouve quels CVE sont réellement atteignables, et pas seulement installés.

VulnReach est désormais un Projet OWASP officiel. 🎉

Démo

Étape 1 — Le SCA fait remonter 74 CVE parmi les dépendances

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

---

Constats — chaîne de preuves par CVE

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

Prise en charge des langages : Python est entièrement prêt pour la production (taint, AST, route, runtime). Java et JavaScript disposent d'une analyse fonctionnelle du graphe d'appels 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 par analyse statique, suivi de teinte (taint tracking) et couverture runtime en direct lesquels des CVE détectés peuvent réellement être atteints dans votre application.

---

État du projet

Derniers développements (livrés)

• Pipeline de runner parallèle conscient des dépendances pour des scans plus rapides
• Atteignabilité Python — prêt pour la production (couches taint, AST, route, 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 routes (expérimental)
• Annulation de scan — POST /scan/{id}/cancel arrête les scans en cours
• Contrat de réponse de scan stable : summary + buckets classifiés sur GET /scan/{id}
• Normalisation partagée des réponses de scan entre l'API et le mode local du package (parité)
• Frontière runtime sécurisée par défaut :
  • la composition de base s'exécute sans montage du socket Docker
  • les scans dynamiques nécessitent une activation explicite via VULNREACH_ALLOW_DOCKER_DAEMON=true
  • le profil runtime utilise un docker-socket-proxy restreint
• Portes de qualité déterministes sur les fixtures pour Java/JavaScript/Go en CI
• Accepté comme Projet OWASP officiel — owasp.community/projects/vulnreach
• Endpoint AI next-steps — POST /findings/{id}/next-steps produit des recommandations de remédiation destinées à l'analyste (actions immédiates, sondes de validation, chemins de mise à niveau, surveillance) pour un constat déterministe. Paresseux / à la demande : les scans n'appellent jamais le LLM, et les échecs du LLM se dégradent gracieusement. Le verdict déterministe est en lecture seule. Voir docs/api.md.

Expérimental

• Mode de traçage scan.runtime.ebpf (axé Linux, activation 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é via une chaîne de preuves à cinq couches :

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 constats priorisés avec quatre niveaux :

Niveau	Signification
DYNAMICALLY_REACHABLE	La couverture runtime a confirmé l'exécution — corriger immédiatement
STATICALLY_REACHABLE	Chemin de code prouvé via AST/taint — priorité élevée
UNCERTAIN	Signal faible uniquement — à investiguer
NOT_REACHABLE	Aucune preuve — supprimer de la file d'alertes

---

Démarrage rapide

Avec Docker Compose (recommandé)

Avis de sécurité — avant de démarrer, 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 vrais 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 un scan

Options d'authentification :

• JWT de courte durée : POST /login
• Jeton d'API de longue durée (clé API) : à créer dans l'UI Settings -> API Keys, puis à utiliser 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