Scanner les vulnérabilités des dépendances (sans bloquer la livraison)

Pourquoi scanner ses dépendances

Ton app, c'est 5 % de ton code et 95 % de dépendances. Chacune peut porter une vulnérabilité connue (une advisory publiée : CVE, avis GHSA…). Un scanner de dépendances — OSV-Scanner, Trivy, Dependabot… — compare ton lockfile aux bases de vulnérabilités et te dit : « telle version de telle lib est vulnérable, corrige en montant à X ». Sans ça, tu embarques des failles connues sans le savoir.

Le piège : le scan bloquant dès le jour 1

Le réflexe « sécurité = strict » pousse à faire échouer la CI dès qu'une vuln est trouvée. Ça paraît sûr, et c'est un piège :

• une advisory publiée cette nuit sur une lib transitive rend ta pipeline rouge du jour au lendemain, alors que tu n'as rien changé ;
• elle bloque toutes les livraisons — y compris le hotfix urgent qui n'a rien à voir ;
• beaucoup de vulns sont non corrigeables tout de suite (pas de patch amont, dépendance transitive, faux positif) → tu es coincé ;
• résultat : l'équipe apprend à contourner le scan (skip, --no-verify), et la sécurité devient du théâtre.

Un outil de sécurité qui bloque la livraison sur des choses que tu ne peux pas corriger entraîne les gens à l'ignorer. C'est pire que pas de scan.

Le pattern : report-only d'abord

On découple la visibilité du blocage : le scan tourne, publie ses résultats (rapport, artefact, commentaire de MR), mais ne fait pas échouer la pipeline (continue-on-error / exit 0 forcé). Tu gardes 100 % de la visibilité, zéro couplage entre la santé du scanner et ta capacité à livrer.

scan osv → trouve des vulns → PUBLIE le rapport → exit 0  (pipeline verte)
                                                    ▲
                          la livraison ne dépend PAS de l'humeur du scanner

Puis une montée en puissance progressive, quand le signal est propre :

1. report-only : on récolte, on mesure le bruit, on traite les vraies vulns à froid.
2. enforce sélectif : on ne bloque que sur critique + correctif disponible, avec une allowlist des cas connus non-corrigeables (avec date de revue).
3. jamais un blocage aveugle sur tout.

La règle générale : tout nouveau gate se déploie en mode observe avant enforce. On regarde ce qu'il dirait, on règle le bruit, puis on lui donne le pouvoir de bloquer — et seulement sur ce qui est actionnable.