Modèle d'engagement de Bitwarden
Bitwarden suit un modèle d'engagement en 4 phases pour les travaux de sécurité. Cette skill supporte principalement la Phase 1 (dirigée par l'ingénierie) et assiste les artefacts des Phases 2-4.
Phase 1 : Évaluation initiale de sécurité (Équipe d'ingénierie)
- Créer des diagrammes de flux de données (Mermaid, Excalidraw ou Structurizr)
- Définir les exigences de sécurité séparément des exigences produit
- Proposer des définitions de sécurité (modèle de menace + objectifs de sécurité)
- Identifier les menaces initiales en utilisant STRIDE (voir
references/stride-framework.md)
Phase 2 : Examen de l'équipe AppSec (AppSec + Ingénierie)
- Partager les diagrammes de flux de données et les définitions de sécurité à l'avance
- Parcourir l'architecture système en collaboration
- Valider ou affiner les définitions de sécurité proposées
- Identifier les menaces supplémentaires, évaluer le risque
- Éviter de supposer que les atténuations externes existent
Phase 3 : Implémentation (Équipe d'ingénierie)
- Implémenter les mesures d'atténuation de sécurité nécessaires
- Créer des tâches de suivi Jira pour les menaces sans protections existantes
- Inclure les considérations de sécurité dans la planification des sprints
Phase 4 : Test et validation (Ingénierie + AppSec)
- Vérifier que les mesures d'atténuation fonctionnent comme prévu
- Adopter une mentalité adversariale lors de la revue de code
- Tester les hypothèses (par ex. « Puis-je contourner le SSO ? ») en travaillant à rebours
- Mettre à jour les définitions de sécurité à mesure que le système évolue
Définitions de sécurité
Les définitions de sécurité sont la construction formelle de Bitwarden pour communiquer la posture de sécurité d'un système. Chaque définition a trois composants : un modèle de menace (capacités de l'attaquant), des objectifs de sécurité (ce que le système garantit) et un statut d'objectif accepté (évaluation honnête du respect ou non de l'objectif).
Utilisez le vocabulaire standard de Bitwarden lors de la rédaction des définitions — voir references/bitwarden-vocabulary.md pour le glossaire complet. Alignez les objectifs de sécurité avec les principes de sécurité de Bitwarden (P01-P06) — voir references/security-principles.md.
Composant Modèle de menace
Décrivez les capacités ET les limitations de l'attaquant — ce qu'il peut et ne peut pas faire. Énoncez toujours les deux aspects pour délimiter précisément la définition :
- « L'attaquant peut exécuter un processus en espace utilisateur après la déconnexion du client de l'utilisateur » + « L'attaquant n'a pas accès aux mécanismes de stockage sécurisé »
- « L'attaquant a un accès à la base de données et peut lire et écrire dans la table Send » + « L'attaquant n'a pas accès aux clés de chiffrement de protection des données ASP.NET Core »
Incluez des exemples concrets si utile (par ex. « Un exemple pour ceci est un appareil volé »). Ne supposez pas que des atténuations externes sont en place — même si l'obtention d'un token d'authentification est difficile, explorez toujours ce qui se passe si un attaquant en possède un.
Composant Objectifs de sécurité
Énoncez des garanties concises et testables sur ce qui ne peut pas se produire compte tenu du modèle de menace. Référencez des assets spécifiques (tokens, clés, données du coffre) :
- « Les tokens valides ne peuvent pas être accédés par l'attaquant après la déconnexion du client de l'utilisateur »
- « L'attaquant ne peut pas récupérer les MasterKeys décryptées qui ne lui appartiennent pas »
- « L'attaquant peut effectuer des lectures uniquement sur les listes d'adresses e-mail chiffrées »
Composant Statut d'objectif accepté
Fournissez une évaluation honnête de l'état actuel :
- L'objectif est atteint — Expliquez comment (par ex. « Le nettoyage de l'état utilisateur comprend la suppression du token stocké du disque »)
- L'objectif est partiellement atteint — Détaillez ce qui fonctionne et ce qui ne fonctionne pas, en utilisant des indicateurs séparés pour chaque aspect
- L'objectif n'est pas atteint — Expliquez l'écart et pourquoi il est accepté
- Meilleur effort — Pour les objectifs dépendant des capacités de la plateforme (par ex. « Cet objectif n'est pas respecté pour les clients qui n'ont pas accès à un stockage sécurisé tel que web et navigateur »)
Quand un objectif est connu comme défaillant, liez le problème de suivi pertinent. Notez les réserves d'étendue (par ex. « Ces définitions ne s'appliquent pas dans le cas d'un Vault Timeout défini sur Never »).
Rédaction des définitions de sécurité
- C'est normal de se tromper — l'objectif est d'amorcer la conversation et de voir si ces garanties peuvent être contournées
- Commencez par ce que le système DEVRAIT garantir, puis validez par analyse de menace
- Séparez les définitions au niveau macro (par ex. chiffrement bout à bout) des définitions au niveau micro spécifiques à la fonctionnalité
- Numérotez les définitions séquentiellement (SD1, SD2, SD3) — chacune est une unité autonome
- Incluez un glossaire des termes spécifiques à la fonctionnalité quand la fonctionnalité introduit un vocabulaire spécialisé
Génération d'artefacts
Utilisez les modèles dans examples/ lors de la génération d'artefacts :
examples/security-definition-document.md— Modèle de document SD complet avec glossaire, définitions numérotées et statut d'objectif acceptéexamples/data-flow-diagram.md— Modèle DFD Mermaid avec limites de confianceexamples/threat-catalog.md— Modèles de tableau de catalogue de menaces et de suivi d'atténuation
Quand engager AppSec
Les équipes doivent initier un engagement complet avec l'équipe AppSec (#team-eng-appsec) quand :
- Projets greenfield ou nouveaux services
- Modifications de partage de données (appartenances à des organisations, Send, fonctionnalités de partage)
- Nouveaux canaux IPC entre composants
- Fonctionnalité interdomaine ou cross-origin
- Incertitude sur les implications de sécurité — effectuez d'abord une Évaluation initiale de sécurité et publiez les résultats sur #team-eng-appsec avec une note indiquant l'incertitude quant à la nécessité d'un engagement complet
Les questions rapides (par ex. préoccupations concernant une bibliothèque tierce ou une pratique de codage) n'ont pas besoin d'un engagement complet — publiez-les directement sur #team-eng-appsec.
Règles critiques
- Séparez les exigences produit des exigences de sécurité dans les décompositions techniques. Elles servent des objectifs différents et ont des parties prenantes différentes.
- Les définitions de sécurité sont des documents vivants. Revisitez-les quand les fonctionnalités changent, que de nouvelles menaces émergent ou que des problèmes de sécurité sont découverts.
- La complexité augmente le risque de vulnérabilité. Signalez le code critique pour la sécurité excessivement complexe comme dette technique. Un code complexe avec de nombreuses dépendances et une logique intriquée est exceptionnellement difficile à sécuriser.
- La modélisation des menaces n'identifiera jamais toutes les vulnérabilités. C'est un outil parmi tant d'autres. Équilibrez-le avec l'analyse de code, les tests de sécurité et l'examen adversarial.
- Ne supposez pas de mesures d'atténuation externes. Lors de la définition du modèle de menace, explorez ce qui se passe si un attaquant contourne les contrôles externes.