ADR 020 — Vuln management : VEX pour l'inexploitable, risk acceptance pour l'exploitable accepté (2026-06-19)

Statut

Accepté (2026-06-19) et validé hors infra (scan Trivy local : la CVE migrée en VEX est bien neutralisée par --vex, le gate reste vert). Premier ADR du projet transverse de gestion continue des vulnérabilités.

Le comment (pédagogique) est dans le guide Comprendre le vuln management.

Contexte

Le scan de sécurité est aujourd'hui build-time : Trivy (fs + image) bloque au build les CVE HIGH/CRITICAL fixables. Quand une CVE est fixée upstream mais qu'on ne peut pas la patcher (le correctif casserait une dépendance), on l'a jusqu'ici mise dans .trivyignore (cas vécu #95/#96 : deux CVE starlette).

Limite de cette approche : .trivyignore mélange deux situations très différentes sous une même « liste à taire ».

• Une CVE peut être présente mais inexploitable (le code vulnérable n'est jamais atteint par l'application). La taire est légitime, mais en commentaire libre, sans format standard ni traçabilité.
• Une CVE peut être réellement atteignable, et on choisit d'accepter le risque (impact limité, pas de correctif applicable). La taire « comme les autres » masque le fait qu'on porte un vrai risque.

Mettre les deux dans le même fichier, avec la même mécanique, empêche de distinguer « je prouve que je ne suis pas concerné » de « je suis concerné mais j'assume ».

Décision 1 — VEX (OpenVEX) pour les CVE non exploitables

On déclare les CVE non exploitables dans un document VEX (Vulnerability Exploitability eXchange) au format OpenVEX, .vex/openvex.json, consommé par Trivy via --vex.

• Statut not_affected + justification dans un vocabulaire fermé, machine-lisible (ex. vulnerable_code_not_in_execute_path).
• Premier cas : CVE-2026-48818 (starlette, SSRF/NTLM via StaticFiles). L'application n'enregistre aucun StaticFiles et n'appelle aucun mount() (vérifié par revue de code) : le code vulnérable n'est jamais dans le chemin d'exécution → not_affected / vulnerable_code_not_in_execute_path.
• Format standard et interopérable (réutilisable par d'autres scanners), avec timestamp (date de la déclaration) → auditabilité.

Alternative écartée : garder ces CVE dans .trivyignore. Rejeté car non standard, justification en commentaire libre, et surtout : confond inexploitabilité prouvée et risque accepté.

Décision 2 — Risk acceptance documentée pour l'exploitable accepté

Une CVE atteignable mais dont on accepte le risque reste dans .trivyignore, mais explicitement étiquetée « risque accepté » avec :

• la preuve d'atteignabilité (où le code vulnérable est appelé),
• l'analyse d'impact (pourquoi le risque est tolérable),
• une date de revue et le lien vers l'issue de dette.

Cas : CVE-2026-54283 (starlette, DoS via request.form()). Le /login utilise OAuth2PasswordRequestForm (confirmé app/routers/auth.py), donc le code est atteignable. Impact limité (DoS CPU sur un endpoint, ni fuite ni RCE). Risque accepté, revue au 2026-09-19 ou au déblocage de #96.

On n'utilise pas un VEX not_affected pour ce cas : ce serait déclarer faussement une inexploitabilité. VEX = exploitabilité, pas acceptation de risque.

Conséquences

• .trivyignore ne contient plus que : (1) CVE OS Debian unfixed (documentation, déjà masquées par --ignore-unfixed) et (2) risques acceptés exploitables, datés.
• Les CVE non exploitables vivent dans .vex/openvex.json, déclaration standard.
• Les 3 gates Trivy (fs-scan + les 2 invocations image-scan) consomment --vex. Le SBOM CycloneDX (#68) reste exhaustif (inventaire, pas un gate).
• Process réutilisable par les autres clusters (homelab, platform) : le découpage VEX / risk acceptance est indépendant d'AWS. Suivi workspace projects/vuln-mgmt/.

Critères de validation

• [x] Scan local sans --vex : CVE-2026-48818 réapparaît (preuve qu'elle n'est plus dans .trivyignore).
• [x] Scan local avec --vex : CVE-2026-48818 supprimée, CVE-2026-54283 masquée par .trivyignore, gate fs-scan vert (exit 0).
• [x] glab ci lint valide le pipeline modifié.
• [ ] Pipeline MR + develop verts (gate image-scan avec --vex sur l'image réelle).

Mise à jour (2026-06-30) — dette #96 levée

Les deux CVE starlette qui motivaient ces exceptions sont corrigées par le bump starlette 1.3.1 (avec fastapi 0.138 + prometheus-fastapi-instrumentator 8.0.2), proposé par Renovate (Phase 2 du vuln management) et validé par la CI : le test d'intégration tests/test_metrics.py prouve que /metrics fonctionne toujours, ce qui invalide l'hypothèse bloquante d'origine. Un scan Trivy fs sans filtre ne détecte plus CVE-2026-48818 ni CVE-2026-54283.

En conséquence : le statement VEX CVE-2026-48818 et l'entrée .trivyignore CVE-2026-54283 sont retirés (exceptions devenues mortes) et l'issue #96 est fermée. Le pattern VEX reste câblé (.vex/openvex.json à statements vides, flags --vex en place) pour resservir. Leçon : une remédiation se termine par le nettoyage des exceptions, sinon on laisse des angles morts qui masqueraient de futures CVE.