Processus de Security Advisory

Cette page documente comment Tale traite les correctifs liés à la sécurité, depuis le premier rapport jusqu'à l'advisory publiée. La forme du processus — brouillon privé sur GitHub, patch publié, advisory publiée avec lien CVE et renvoi vers les release notes — est conventionnelle ; la page existe pour que les exploitants sachent quoi surveiller et pour que les rapporteurs sachent à quoi s'attendre.

Côté exploitant, la suite pratique est courte : abonne-toi aux GitHub Security Advisories sur tale-project/tale et lis la section ## 🔒 Security de chaque release. Tout ce qui décroche un CVE apparaît dans les deux endroits, avec le chemin d'upgrade et les contournements nommés explicitement.

Canaux

• Principal : GitHub Security Advisories sur tale-project/tale. Les advisories sont préparées en privé, liées à un CVE quand applicable, puis publiées une fois une version patchée disponible.
• Secondaire : chaque advisory est référencée dans les release notes GitHub correspondantes sous la section ## 🔒 Security (voir format des release notes).
• Notification directe (manuelle pour l’instant) : les advisories critiques sont envoyées par email aux opérateurs connus. Il n’existe pas encore de liste email automatisée — c’est prévu.

Quand déposer une advisory

On dépose un GitHub Security Advisory quand l’un des points suivants s’applique :

• Score CVSS v3.1 ≥ 4.0 (Medium ou plus).
• Tout bug susceptible de fuiter des secrets entre tenants, des session tokens ou d’escalader des privilèges.
• Tout correctif touchant authentification, session, cadrage d’organisation, crypto ou stockage de secrets — même sans rapport externe.
• Toute CVE de dépendance atteignable (le chemin de code vulnérable est exercé par Tale).

On ne dépose pas d’advisory pour des CVE de dépendance dont les chemins ne sont clairement pas atteints — documente-les dans la section ## 🔒 Security normale des release notes avec une note expliquant pourquoi elles ne sont pas exploitables ici.

Matrice gravité → escalade

Calendrier

1. Brouillon privé dans GitHub Security Advisory. Inclure versions affectées, description, estimation de gravité.
2. Demander un CVE via l’UI Advisory de GitHub si gravité ≥ Medium.
3. Préparer la release patchée sur un fork/branche privée. Ne pas pousser les patchs sur main avant publication.
4. Divulgation coordonnée avec le rapporteur en cas de signalement externe — typiquement 90 jours max d’embargo, plus court pour les problèmes activement exploités.
5. Publier l’advisory en même temps que la disponibilité du tale upgrade patché. Référencer CVE et tag de release.
6. Lien croisé dans les release notes de la version patchée.

Contenu d’une advisory

• Versions affectées (plage ou liste).
• Version patchée (tag exact, ex. v1.6.1).
• Résumé de l’impact — ce qu’un attaquant pourrait faire.
• Prérequis — position réseau, état d’auth, feature flags nécessaires pour exploiter.
• Contournements pour les opérateurs qui ne peuvent pas upgrader tout de suite.
• Credits au rapporteur (avec accord).

Action opérateur

Les opérateurs devraient :

• suivre les releases de tale-project/tale (GitHub → Watch → Custom → Security advisories, gratuit) ;
• traiter les entrées ## 🔒 Security comme des invitations à mettre à jour ;
• s’abonner à la liste de notification directe (quand elle existera) pour les alertes critiques.

Où cela s'inscrit

Les avis de sécurité sont la façon dont Ruler GmbH divulgue les CVE et dont les exploitants apprennent ce qu'il faut patcher sur une instance auto-hébergée. Chaque advisory pointe vers une release Tale qui contient le correctif ; les exploitants déroulent tale deploy pour avancer, tandis que les clients Cloud reçoivent le même correctif au prochain déploiement de la plateforme. Le pendant release-notes du même événement vit dans Format des notes de version sous la section ## 🔒 Security ; la slash-command /release du dépôt principal rédige automatiquement cette section quand une release sort.