clawsec/wiki/fr/migration-signed-feed.md

Enregistrement de migration: Nourriture non signée → Nourriture signée (Complété)

Oui. 1) Objectif et statut

Documentez comment la distribution de conseils ClawSec est passée de la livraison non signée feed.json à la vérification de la signature individuelle, la compatibilité étant préservée pour les anciens clients.

Situation actuelle sur main:

• La publication de flux signés est active dans les flux de travail de conseil et de déploiement.
• Les consommateurs de Suite et NanoClaw sont par défaut sur les paramètres d'alimentation signés.
• Le comportement non signé n'existe que sous forme de contournement de compatibilité explicite (CLAWSEC_ALLOW_UNSIGNED_FEED=1).

Oui. 2) Données de référence (aujourd ' hui, après la migration)

Voies d'alimentation actuelles en utilisation active:

• Source de vérité: advisories/feed.json
• Signature de la source: advisories/feed.json.sig
• Copie des compétences : skills/clawsec-feed/advisories/feed.json
• Signature de la copie de compétence: skills/clawsec-feed/advisories/feed.json.sig
• Copie des pages : public/advisories/feed.json
• Signature des pages : public/advisories/feed.json.sig
• Dernière copie miroir: public/releases/latest/download/advisories/feed.json (+ .sig)

Par défaut du consommateur actuel :

• skills/clawsec-suite/hooks/clawsec-advisory-guardian/handler.ts
• skills/clawsec-suite/scripts/guarded_skill_install.mjs
• skills/clawsec-nanoclaw/lib/advisories.ts
• URL par défaut : https://clawsec.prompt.security/advisories/feed.json

Oui. 3) Principes migratoires

• **Deuxième publication : publier les signatures avant de procéder à la vérification.
• Non ouvert seulement pendant la transition : la période de compatibilité temporaire est explicite et limitée dans le temps.
• Mentions de déploiement: faire appliquer la vérification après télémétrie confirme la stabilité de l'édition signée.
• Fast runback: préserver un chemin de retour au comportement non signé pendant que la cause racine est étudiée.

Oui. 4) Chronologie progressive (historique)

• Oui. Phase 0 — Préparation (achevée)

Produits livrables:

• clés de signature générées et empreintes digitales enregistrées
• Les secrets de GitHub créés
• clé(s) publique(s) ajoutée(s) en repo
• runbooks approuvés (security-signing-runbook.md, ce fichier)

Critères de sortie:

• empreintes clés vérifiées par l'examinateur

• contrôle des branches/flux de travail protégé activé

• Oui. Phase 1 — La signature de l'IC est activée, aucune exécution par le client (achevée)

Mettre en œuvre :

• ajouter l'étape de signature/le flux de travail pour produire advisories/feed.json.sig
• produire en option advisories/checksums.json + .sig
• s'assurer que l'IC vérifie les signatures avant la publication des artefacts

Actualiser également le déploiement :

• copier les artefacts .sig vers public/advisories/
• miroir .sig en public/releases/latest/download/advisories/

Critères de sortie:

• signatures générées avec succès pour tous les chemins de mise à jour de flux

• les artefacts de déploiement contiennent à la fois la charge utile et les compagnons de signature

• Oui. Phase 2 — Soutien à double lecture/vérification du consommateur (achevé)

Mettre en œuvre chez les consommateurs:

• lire feed.json et feed.json.sig
• vérifier avec la clé publique
• garder le contrôle temporaire non signé retour pendant la fenêtre de migration

Validation:

• parcours d'essai à distance signé
• tester le chemin de repli signé local
• essai de refus de signature non valide

Critères de sortie:

• logique de vérification libérée et testée

• aucune défaillance de vérification faussement positive pendant la période de stabilisation

• Oui. Phase 3 — Exécution (achevée)

Actions:

• désactiver le comportement de repli temporaire non signé dans les chemins par défaut
• ajouter des portes CI/publish qui échouent lorsque .sig est manquant
• annoncer la date d'exécution dans les notes de diffusion et les documents

Critères de sortie:

• tous les clients de production vérifient les signatures par défaut

• aucune dépendance d'alimentation non signée dans le débit d'installation standard

• Oui. Phase 4 — Stabilisation (en cours)

Actions:

• exécuter la première clé de rotation de la perceuse de table
• perceuse de table en marche arrière
• migration étroite avec examen post-mise en œuvre

Oui. 5) Plan de redressement

Déclencheurs arrière

Lancer un renversement si l'une des situations suivantes se produit:

• défaillances persistantes de la vérification de la signature entre les clients
• la signature de workflow ne peut pas produire de signatures valides
• compromis clé suspecté mais la clé de remplacement n'est pas encore déployée
• chemin de déploiement publie des paires de charge utile/signature erronées

Niveau de recul

Niveau 1 (préféré): Fenêtre de contournement de vérification, publication signée

Utilisation lorsque : la signature est saine, le vérificateur côté client a un défaut.

Actions:

1. Réactiver le comportement temporaire non signé-acceptation dans la branche de libération du client.
2. Sortie du patch du navire avec date d'expiration explicite pour le contournement.
3. Continuez à signer le pipeline actif pour éviter les lacunes en matière d'authenticité.

Objectif de récupération: restaurer une vérification stricte dans les 24–48h.

Niveau 2 : pipeline signé interrompu, alimentation non signée faisant temporairement autorité

Utiliser lorsque : la signalisation est instable ou produit des artefacts incohérents.

Actions:

1. Désactiver le workflow de signature ou l'étape de signature.
2. Continuer à publier advisories/feed.json non signé via les workflows existants.
3. Révertissez les portes de déploiement qui nécessitent des artefacts .sig.
4. Ouvrir l'enregistrement des incidents et le temps de suivi en mode non signé.

Objectif de récupération: restaurer l'édition signée ASAP, idéalement <72h.

Niveau 3 : Gel complet

Utiliser quand: compromis ou intégrité du dépôt / flux de travail est en doute.

Actions:

1. Pas de mutation de flux d'alimentation et de déploiement.
2. Restaurer le commit connu-bon pour les fichiers de conseil / flux de travail.
3. Rotation des clés et des références.
4. Reprendre le pipeline seulement après l'approbation de l'examen de la sécurité.

Rouler après le retour

• identifier la cause racine Ajouter les essais/portes de régression
• redéployer les artefacts signés
• publier un résumé de l'incident + des mesures correctives

Oui. 6) Plan de communication

Pour les événements d'exécution et de recul, communiquer :

• ce qui a changé
• action attendue de l'opérateur/client
• durée du mode de compatibilité temporaire (le cas échéant)
• commandes de vérification pour les utilisateurs

Chaînes recommandées:

• Notes de sortie de GitHub
• mises à jour du dépôt README/docs
• rapport d'incident dans le dépôt

Oui. 7) Liste de contrôle aller/pas aller

Allez seulement si tout est vrai:

• le taux de réussite des processus de signature est stable
• les signatures sont en miroir avec tous les paramètres d'alimentation documentés
• Voie de vérification du consommateur testée pour la distance + recul local
• le propriétaire de retour est assigné et accessible
• la procédure de rotation clé a été à sec au moins une fois

Références sources

• .github/workflows/poll-nvd-cves.yml
• .github/workflows/community-advisory.yml
• .github/workflows/deploy-pages.yml
• compétences/clawsec-suite/hooks/clawsec-advisory-guardian/handler.ts
• compétences/clawsec-suite/scripts/guarded_skill_install.mjs
• avis/feed.json
• wiki/security-signing-runbook.md