Réponse aux incidents

# 1. Détection et triage

Nous surveillons les signaux de sécurité provenant de :

• Avis de sécurité GitHub (GHSA) et rapports de vulnérabilité privés.
• Issues/discussions GitHub publiques lorsque les rapports ne sont pas sensibles.
• Signaux automatisés (par exemple Dependabot, CodeQL, avis npm et analyse des secrets).

Triage initial :

1. Confirmer le composant affecté, la version et l’impact sur la limite de confiance.
2. Classer comme problème de sécurité ou durcissement/aucune action à entreprendre selon le périmètre et les règles hors périmètre du fichier SECURITY.md du dépôt.
3. Un responsable d’incident répond en conséquence.

# 2. Évaluation

Guide de sévérité :

• Critique : Compromission de package/release/dépôt, exploitation active, ou contournement non authentifié de limite de confiance avec contrôle à fort impact ou exposition de données.
• Élevée : Contournement vérifié de limite de confiance nécessitant des préconditions limitées (par exemple une action à fort impact authentifiée mais non autorisée), ou exposition d’identifiants sensibles appartenant à OpenClaw.
• Moyenne : Faiblesse de sécurité significative avec impact pratique, mais exploitabilité contrainte ou prérequis importants.
• Faible : Constats de défense en profondeur, déni de service à portée étroite, ou écarts de durcissement/parité sans contournement démontré de limite de confiance.

# 3. Réponse

1. Accuser réception auprès du rapporteur (en privé lorsque c’est sensible).
2. Reproduire sur les releases prises en charge et sur le dernier main, puis implémenter et valider un correctif avec une couverture de régression.
3. Pour les incidents critiques/élevés, préparer des release(s) corrigées aussi rapidement que possible en pratique.
4. Pour les incidents moyens/faibles, corriger dans le flux de release normal et documenter les conseils d’atténuation.

# 4. Communication

Nous communiquons via :

• Les avis de sécurité GitHub dans le dépôt affecté.
• Les notes de release/entrées de changelog pour les versions corrigées.
• Un suivi direct avec le rapporteur sur l’état et la résolution.

Politique de divulgation :

• Les incidents critiques/élevés doivent faire l’objet d’une divulgation coordonnée, avec émission d’un CVE lorsque cela est approprié.
• Les constats de durcissement à faible risque peuvent être documentés dans les notes de release ou les avis sans CVE, selon l’impact et l’exposition des utilisateurs.

# 5. Récupération et suivi

Après l’expédition du correctif :

1. Vérifier les remédiations dans la CI et les artefacts de release.
2. Exécuter une courte revue post-incident (chronologie, cause racine, lacune de détection, plan de prévention).
3. Ajouter des tâches de suivi de durcissement/tests/docs et les suivre jusqu’à leur achèvement.