Livre blanc sur la sécurité et la confidentialité (présentation)Chapitre 11

Chapitre 11 : Divulgation des vulnérabilités et mises à jour de sécurité

FileBolt encourage la divulgation responsable et bâtit la confiance grâce à des mécanismes de correction et de communication prévisibles. En parallèle, les capacités de sécurité doivent pouvoir évoluer : politiques de sécurité Web, mécanismes d'authentification côté serveur et implémentations du chiffrement de bout en bout et des protocoles (par exemple, les mises à niveau de cryptoVersion). Ce chapitre présente les canaux de contact publics, les processus de traitement, les principes de publication des correctifs et d'annonce, et explique les stratégies d'évolution versionnée et de dépréciation.

11.0 Résumé

DOIT : fournir des canaux publics de signalement des vulnérabilités (par ex. security.txt et une adresse e-mail de support).
DEVRAIT : proposer des mécanismes de soumission chiffrés (par ex. une clé PGP) pour transmettre les détails en toute sécurité.
DEVRAIT : définir une cadence claire de réponse et de correction (SLA/délais cibles) et communiquer via la page d'état (Status Page) si nécessaire.
DOIT : traiter en priorité maximale les vulnérabilités susceptibles d'affecter les engagements Zero-Knowledge (XSS, injection dans la chaîne d'approvisionnement, fuite de fragments dans les journaux).
DOIT : mettre en œuvre une évolution versionnée (cryptoVersion) et définir des stratégies de compatibilité, de migration et de dépréciation.

11.1 Canaux de signalement des vulnérabilités et contact

11.1.1 Points d'entrée publics

DOIT : indiquer les canaux de signalement des vulnérabilités, la date d'expiration et les liens vers la politique dans /.well-known/security.txt.
DOIT : fournir une adresse e-mail de contact sécurité joignable (par ex. support@filebolt.net ou une adresse dédiée security@filebolt.net).
DEVRAIT : fournir de brèves instructions et des consignes de soumission sur la page Sécurité et confidentialité.

11.1.2 Soumission chiffrée et traitement des informations sensibles

DEVRAIT : fournir une clé publique PGP (ou équivalent) afin que les chercheurs puissent transmettre en toute sécurité les détails de reproduction.
DOIT : appliquer en interne une visibilité au moindre privilège sur les détails des vulnérabilités, en ne les communiquant qu'au personnel nécessaire à la correction.
DOIT : interdire aux chercheurs d'inclure dans leurs rapports du texte en clair d'utilisateur, des CEK, des fragments d'URL ou des éléments permettant de dériver une clé ; s'ils y figurent par inadvertance, l'équipe DOIT traiter le cas comme un incident sensible et en limiter la diffusion.

11.2 Délais de réponse et principes de communication

Les délais dépendent de la taille de l'équipe et de la complexité, mais le projet DEVRAIT fournir une cadence cible prévisible et communiquer rapidement lorsque les objectifs ne sont pas tenus. Cibles recommandées (ajustables selon la réalité et publiées dans /security ou security.txt) :

Première réponse : par exemple, accuser réception et attribuer un identifiant de suivi sous 48 heures.
Évaluation initiale : par exemple, terminer la classification de la gravité et l'évaluation de l'étendue de l'impact sous 7 jours.
Publication du correctif : progression selon la gravité ; les P0/P1 sont traités en priorité pour une correction et une publication rapides.

DEVRAIT : maintenir la communication nécessaire pendant le traitement (par exemple, reproduit/non reproduit, besoin d'informations complémentaires, fenêtre de correction estimée) et éviter de divulguer publiquement des détails exploitables.

11.3 Processus de divulgation

Réception : consigner les informations du rapport, les étapes de reproduction, l'impact et les coordonnées du chercheur ; attribuer un responsable et un suivi.
Vérification : reproduire dans un environnement isolé ; évaluer l'étendue de l'impact, l'exploitabilité et les composants concernés (frontend/backend/edge/stockage).
Correction : implémenter le correctif, ajouter des tests et des cas de non-régression, ajouter des règles de protection si nécessaire (WAF/limitation de débit/durcissement des politiques).
Publication : déploiement canari avec suivi des indicateurs clés ; déploiement complet après avoir confirmé l'absence de régression ou de nouveaux risques.
Annonce : expliquer publiquement l'impact, le contenu du correctif et les actions requises des utilisateurs (le cas échéant), sans élargir la surface d'attaque.

Pour les vulnérabilités critiques ou les événements à fort impact sur les utilisateurs, DEVRAIT publier des mises à jour d'événement ou des post-mortems via /status en cohérence avec le processus de réponse aux incidents du chapitre 10.

11.4 Vulnérabilités affectant les frontières du Zero-Knowledge

Le cœur de l'engagement Zero-Knowledge est le suivant : le serveur ne peut pas accéder à la CEK, et l'environnement de téléchargement/déchiffrement est isolé autant que possible, sans script tiers. Par conséquent, les catégories suivantes DOIVENT être traitées en priorité maximale :

XSS / injection : possibilité d'exécuter des scripts arbitraires sur les pages de téléchargement/déchiffrement, de lire les fragments ou les éléments de clé en mémoire.
Injection dans la chaîne d'approvisionnement : empoisonnement de dépendances, remplacement d'artefacts de build, injection CDN/edge entraînant une altération des scripts.
Fuite via les journaux/la supervision : fragment d'URL, CEK, jeton ou texte en clair consigné par accident et accessible.
Politique de chargement des ressources incorrecte : pages de téléchargement/déchiffrement important des scripts tiers, assouplissement de la CSP élargissant la surface d'exécution.

Le traitement doit comprendre : un confinement immédiat (mise hors ligne du code à risque/durcissement de la politique/blocage du vecteur), une publication rapide du correctif, une analyse rétrospective de l'impact, et une mention claire dans l'annonce indiquant « si des éléments de clé ou du texte en clair ont potentiellement été exposés ».

11.5 Mises à jour de sécurité et vérification de non-régression

DOIT : établir des cas de non-régression pour les changements liés à la sécurité (authentification, contrôle d'accès, CSP, filtrage des journaux, flux de chiffrement).
DEVRAIT : effectuer des contrôles automatisés sur les pages critiques (téléchargement/déchiffrement) pour s'assurer qu'il n'y a aucun script tiers et que les politiques d'en-têtes correspondent aux attentes.
DEVRAIT : refaire des tests sur les éléments vérifiables de l'extérieur (par ex. analyses TLS/en-têtes de sécurité) après la publication du correctif.
DEVRAIT : documenter clairement les changements de compatibilité introduits par les correctifs (par ex. anciens liens/ancien manifeste).

Conformément au chapitre 12 : les analyses de tiers vérifient certaines bases du Web mais ne peuvent pas prouver directement tous les détails d'implémentation du Zero-Knowledge/E2EE ; la vérification de non-régression devrait donc couvrir à la fois l'implémentation du protocole et les bases visibles.

11.6 Versionnement du protocole et de la cryptographie (cryptoVersion)

L'implémentation du chiffrement et du protocole de FileBolt DOIT prendre en charge le versionnement afin de faciliter les mises à niveau d'algorithmes, la correction de défauts d'implémentation et l'introduction d'une isolation plus forte. Il est recommandé d'utiliser des champs explicites (par exemple, cryptoVersion) liés dans le manifeste/les métadonnées.

Version explicite : chaque transfert/manifeste DOIT déclarer sa cryptoVersion afin de déterminer les algorithmes, les paramètres et les règles d'encodage.
Aucune déduction implicite : le client DOIT décider de la logique d'analyse et de déchiffrement d'après des champs explicites du manifeste, et non par déduction ou par heuristiques de repli.
Échec fermé : DOIT échouer de façon fermée (fail closed) face à des versions inconnues ou à des paramètres incohérents, sans jamais rétrograder vers des modes non sécurisés.

11.7 Compatibilité, migration et dépréciation

11.7.1 Compatibilité descendante

DEVRAIT : prendre en charge la lecture des anciennes versions de transfert pendant les périodes de transition afin de limiter l'impact sur les liens historiques des utilisateurs.
DOIT : indiquer publiquement les limites de sécurité, les restrictions et les plans de dépréciation des anciennes versions.

11.7.2 Migration (en conservant le Zero-Knowledge)

DEVRAIT : proposer côté utilisateur des parcours « Renvoyer/Rechiffrer » si une migration de l'ancienne vers la nouvelle version est nécessaire.
DOIT : préserver le Zero-Knowledge pendant la migration : le rechiffrement s'effectue sur le client, le serveur ne peut accéder ni à la CEK ni au texte en clair.

11.7.3 Dépréciation et fin de vie (EOL)

DOIT : fournir un calendrier de fin de vie clair pour les versions jugées désormais non sécurisées.
DEVRAIT : inviter les utilisateurs à renvoyer leurs fichiers dans l'interface/la documentation et prévoir des fenêtres de migration suffisantes.
DOIT : après la fin de vie, les clients rencontrant des versions dépréciées doivent l'indiquer clairement et ne doivent pas tenter le déchiffrement.

11.8 Identifiants d'affirmation associés (réservé)

Ce chapitre couvre les « canaux de divulgation des vulnérabilités, processus, versionnement et dépréciation ». Les identifiants d'affirmation correspondants seront ajoutés à l' Annexe : liste maîtresse des identifiants d'affirmation qui constitue l'unique source faisant foi.