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

11.0 Résumé

• MUST: Fournissez des canaux publics de soumission des vulnérabilités (par exemple, security.txt et e-mail d'assistance).
• SHOULD: Fournissez des mécanismes de soumission cryptés (par exemple, une clé PGP) pour une soumission sécurisée des détails.
• SHOULD: Définissez une cadence claire de réponse et de remédiation (échéanciers SLA/cibles) et communiquez via la page d'état si nécessaire.
• MUST: Traitez les vulnérabilités potentiellement affectant les engagements Zero-Knowledge (XSS, injection dans la chaîne d'approvisionnement, fuite de fragments de journaux) comme la plus haute priorité.
• MUST: Implémenter l'évolution versionnée (cryptoVersion) et définir des stratégies de compatibilité, de migration et de dépréciation.

11.1 Canaux et contacts de soumission de vulnérabilités

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

Les délais dépendent de l'échelle et de la complexité de l'équipe, mais le projet DEVRAIT fournir une cadence cible prévisible et communiquer rapidement si les objectifs sont manqués. Cibles recommandées (ajustables en fonction de la réalité et publiées dans /security ou security.txt) :

• Première réponse: Par exemple, accusez réception et attribuez un identifiant de suivi dans les 48 heures.
• Évaluation initiale: Par exemple, terminer l’évaluation de la gravité et de l’étendue de l’impact dans un délai de 7 jours.
• Correction de la version: Progrès en fonction de la gravité ; P0/P1 prioritaires pour une correction et une publication rapides.

SHOULD: Maintenir la communication nécessaire pendant le traitement (par exemple, reproduit/non reproduit, besoin de plus d'informations, fenêtre de correction estimée) et éviter de divulguer publiquement les détails exploitables.

11.3 Processus de divulgation

1. Receipt: Enregistrer les informations du rapport, les étapes de reproduction, l'impact et le contact du chercheur ; attribuer le propriétaire et le suivi.
2. Verification: Se reproduire en milieu isolé ; évaluer la portée de l'impact, l'exploitabilité et les composants concernés (Frontend/Backend/Edge/Storage).
3. Remediation: Implémenter le patch, ajouter des cas de tests/régression, ajouter des règles de protection si nécessaire (WAF/Rate Limit/Policy Tightening).
4. Release: Canary publie et surveille les indicateurs clés ; libération complète après avoir confirmé l’absence de régression ou de nouveaux risques.
5. Announcement: expliquez publiquement l'impact, corrigez le contenu et les actions utilisateur requises (le cas échéant) sans étendre la surface d'attaque.

Pour les vulnérabilités critiques ou les événements à fort impact sur les utilisateurs, SHOULD publier des mises à jour d'événements ou des post-mortems via /status aligné sur le processus IR du chapitre 10.

11.4 Vulnérabilités affectant les limites de la connaissance nulle

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

• XSS / Injection: Possibilité d'exécuter des scripts arbitraires sur des pages de téléchargement/décryptage, de lecture de fragments ou de matériel de clé mémoire.
• Injection dans la chaîne d’approvisionnement: Empoisonnement de dépendances, remplacement d'artefacts de build, injection CDN/Edge conduisant à une falsification de script.
• Fuite de journal/surveillance: Fragment d'URL, CEK, jeton ou texte brut accidentellement enregistré et accessible.
• Politique de chargement de ressources incorrecte: Pages de téléchargement/déchiffrement important des scripts tiers, assouplissement CSP élargissant la surface d'exécution.

L'élimination doit inclure : un confinement immédiat (code à risque hors ligne/politique de renforcement/vecteur d'interdiction), une publication rapide de correctifs, une analyse d'impact rétrospective, et une déclaration claire dans l'annonce indiquant "si des éléments clés ou du texte brut ont été potentiellement exposés".

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

• MUST: Etablir des cas de régression pour les changements liés à la sécurité (Auth, Contrôle d'accès, CSP, Log Filtering, Encryption Flows).
• SHOULD: effectuez des vérifications automatisées sur les pages critiques (téléchargement/déchiffrement) pour vous assurer qu'aucun script tiers ni politique d'en-tête ne correspond aux attentes.
• SHOULD: effectuez un nouveau test des éléments vérifiables externes (par exemple, analyses TLS/en-tête de sécurité) après la publication du correctif.
• SHOULD: documentez clairement les modifications de compatibilité introduites par les correctifs (par exemple, anciens liens/ancien manifeste) dans la documentation.

Conformément au chapitre 12 : Les analyses tierces vérifient certaines références Web mais ne peuvent pas prouver directement les détails complets de la mise en œuvre de Zero-Knowledge/E2EE ; ainsi, la vérification de la régression devrait couvrir à la fois la mise en œuvre du protocole et les lignes de base visibles.

11.6 Versionnement du protocole et de la cryptographie (cryptoVersion)

Le chiffrement et la mise en œuvre du protocole de FileBolt DOIVENT prendre en charge le contrôle de version pour faciliter les mises à niveau des algorithmes, corriger les défauts de mise en œuvre et introduire une isolation plus forte. Il est recommandé d'utiliser des champs explicites (par exemple, cryptoVersion) lié dans le manifeste/métadonnées.

• Version explicite: Chaque transfert/manifeste DOIT déclarer son cryptoVersion pour déterminer les algorithmes, les paramètres et les règles de codage.
• Aucune inférence implicite: Le client DOIT décider de la logique d'analyse et de déchiffrement en fonction de champs manifestes explicites, et non de devinettes ou d'heuristiques de secours.
• Échec fermé: DOIT échouer lors de la fermeture lors de la rencontre de versions inconnues ou de paramètres incohérents, sans jamais passer à des modes non sécurisés.

11.7 Compatibilité, migration et dépréciation

11.8 ID de réclamation associés (réservé)

Ce chapitre couvre les « Canaux de divulgation des vulnérabilités, les flux de travail, la gestion des versions et la dépréciation ». Les identifiants de réclamation correspondants seront ajoutés au Annexe : Liste principale des identifiants de réclamation comme seule source faisant autorité.