Examen des modifications de dépendances

Détection des fichiers manifeste

Signalez cette compétence quand l'un de ces fichiers apparaît dans la diff :

• package.json, package-lock.json
• *.csproj, Directory.Packages.props, packages.lock.json
• Cargo.toml, Cargo.lock
• go.mod, go.sum
• requirements.txt, pyproject.toml, poetry.lock
• Gemfile, Gemfile.lock

Zone 1 : Nouvelles dépendances

Quand une PR ajoute une dépendance qui n'existait pas précédemment dans le codebase, le processus d'examen et d'approbation des dépendances de Bitwarden exige un examen et une approbation AppSec avant intégration. Cela s'applique à toutes les nouvelles dépendances — production, dev et test.

Le soumetteur doit fournir le nom/version du package, l'écosystème, la justification, la portée, les produits affectés et ce qu'il remplace. Un ingénieur en sécurité crée une tâche VULN dans Jira et évalue la dépendance selon la sécurité (CVE connues, exploitabilité), la compatibilité de licence (les licences permissives comme MIT/Apache-2.0 sont acceptables ; les licences copyleft comme GPL/AGPL sont signalées), la santé de la maintenance (mainteneurs actifs, versions récentes, politique de sécurité), le risque de chaîne d'approvisionnement (typosquatting, changements de propriété, scripts d'installation obfusqués) et les dépendances transitives avant de rendre une décision d'approbation.

Points à vérifier

1. S'agit-il d'une dépendance entièrement nouvelle (pas déjà présente dans le codebase) ?
2. La description de la PR contient-elle un signal d'approbation indiquant que le processus a été suivi ?

Signaux d'approbation

Preuves que le processus d'approbation des dépendances a été suivi :

• La description de la PR référence une tâche VULN (par ex. VULN-1234)
• La description de la PR mentionne explicitement l'approbation AppSec ou le processus d'examen des dépendances

Gravité

• Aucun signal d'approbation trouvé → ⚠️ IMPORTANT : Nouvelle dépendance <package> ajoutée. Bitwarden exige une approbation AppSec avant d'introduire de nouvelles dépendances. Le soumetteur doit contacter l'équipe AppSec pour initier le processus d'examen et d'approbation des dépendances.
• Incertain quant à l'obtention de l'approbation → ❓ QUESTION : Une approbation AppSec a-t-elle été obtenue pour la nouvelle dépendance <package> ?

À ne pas signaler

• Les dépendances qui existent déjà dans le codebase (les mises à jour de version ne sont pas de nouvelles dépendances)
• Les dépendances ajoutées par Renovate/Dependabot en tant que mises à jour de dépendances transitives (celles-ci font partie de la surveillance de l'étape 5 pour les dépendances approuvées existantes)

Zone 2 : Changements de version majeure

Un changement de version majeure (par ex. v2 → v3) peut introduire des breaking changes qui affectent le codebase de Bitwarden.

Points à vérifier

1. S'agit-il d'un changement de version SemVer majeure ?
2. La description de la PR discute-t-elle des breaking changes ou des étapes de migration ?

Gravité

• Bump majeur sans discussion de migration → ❓ QUESTION : Ceci passe <package> de vX à vY (majeur). Les breaking changes ont-ils été évalués ?
• Rétrogradation de version → ⚠️ IMPORTANT : <package> est rétrogradé de vX à vY. C'est inhabituel et peut réintroduire des vulnérabilités résolues.

Zone 3 : Hygiène du fichier de verrouillage

Les fichiers de verrouillage assurent des builds reproductibles. Les incohérences entre les manifestes et les fichiers de verrouillage sont une préoccupation de fiabilité de build et de sécurité.

Points à vérifier

À ne pas signaler

• Les grandes diffs de fichier de verrouillage à partir d'une petite modification de manifeste — c'est un comportement normal. Les fichiers de verrouillage peuvent changer considérablement à partir d'une seule addition de dépendance ou d'un bump de version.
• Les modifications de fichier de verrouillage uniquement qui s'accompagnent d'une modification claire du manifeste dans la même PR.

Zone 4 : PRs de dépendances automatisées

Les PRs Renovate et Dependabot font partie du processus d'étape 5 (Monitoring) de Bitwarden. Ces mises à jour automatisées de dépendances existantes approuvées nécessitent un traitement d'examen différent.

Comment détecter

• Auteur de la PR : renovate[bot], dependabot[bot] ou comptes de bot similaires
• Modèle de titre de PR : "Update ...", "Bump ...", "chore(deps): ..."

Conseils d'examen

Zone 5 : Suppression de dépendances

Quand une dépendance est supprimée d'un manifeste, vérifiez que la suppression est complète.

Points à vérifier

1. Existe-t-il des références de code restantes au package supprimé ?
   • JavaScript/TypeScript : import ... from '<package>', require('<package>')
   • C#/.NET : using <namespace>, références dans d'autres fichiers .csproj
   • Rust : use <crate>::, extern crate <crate>
   • Python : import <package>, from <package> import
2. Y a-t-il des références dans les fichiers de build ou d'infrastructure ?
   • Dockerfile, docker-compose.yml
   • Fichiers de workflow CI (.github/workflows/*.yml)
   • Scripts de build, Makefile, task runners

Gravité

• Des imports morts ou des références persistent → ♻️ DEBT : <package> supprimé du manifeste mais toujours référencé dans le code.