16 contrôles. 4 référentiels. Preuves signées.

01La conformité comme porte de release, pas comme scanner

nixfleet-compliance livre 16 modules de contrôle typés sur 4 référentiels. Chaque contrôle suit le motif enforce + prove : enforce applique le contrôle (sysctl, règle pare-feu, politique SSH). prove émet une preuve JSON structurée vers /var/lib/nixfleet-compliance/evidence.json. Un timer systemd exécute le collecteur toutes les heures pour les entités essentielles, quotidiennement pour les entités importantes.

La couche conformité n'a pas de dépendance d'exécution sur nixfleet. Elle détecte les fonctionnalités nixfleet au moment de l'évaluation via options ?, donc elle fonctionne avec ou sans l'agent ou le control plane. Dépôt : arcanesys/nixfleet-compliance (MIT).

02Les 16 contrôles

Chaque contrôle typé déclare l'article qu'il satisfait par référentiel. La matrice ci-dessous donne la vue transversale ; le détail par référentiel se trouve dans §03.

03Couverture par référentiel

Les mêmes 16 contrôles satisfont quatre presets de référentiels via des cartographies article-level différentes. Couverture : 10 / 10 sous-articles de l'Article 21 NIS2, ISO 27001:2022 Annexe A sur A.5 et A.8, DORA Articles 8 / 9 / 12 / 17, ANSSI BP-028 R7–R14 + R33. La cartographie article par article de chaque référentiel est sur sa propre page :

• NIS2 — Cartographie Article 21 (10 sous-articles)
• DORA — Cartographie Chapitre III (Articles 8, 9, 12, 17)
• ISO 27001:2022 — Cartographie Annexe A (contrôles A.5 + A.8)
• ANSSI BP-028 v2.0 — Cartographie (R7–R14 + R33, quatre niveaux de hardening)
• Classification d'entité NIS2 (seuils essentielle vs importante à travers la flotte)

Couverture article-level additionnelle (sans preset complet à ce stade) : CRA (Règlement UE sur la cyber-résilience) Art. 10 sur _supply-chain, _encryption-in-transit, _secure-boot, et Art. 11 sur _vulnerability-mgmt. SecNumCloud sur _key-management, _network-segmentation, _secure-boot.

04Format de preuve - JSON signé canonicalisé

Le collecteur écrit trois fichiers dans /var/lib/nixfleet-compliance/ : evidence.json (l'enregistrement), evidence.json.sig (signature ed25519 base64 sur les octets JCS-canoniques de l'enregistrement, RFC 8785), et evidence.host.pub (clé publique SSH ed25519 de l'hôte, publiée à côté). Un auditeur disposant des trois fichiers exécute nixfleet-compliance-verify pour reproduire la canonicalisation et vérifier la signature : sans control plane, sans confiance envers l'opérateur, sans confiance envers un éditeur de scanner. Exemple d'enregistrement du contrôle _supply-chain :

{
  "schemaVersion": 1,
  "hostname": "water-plant-01",
  "collectedAt": "2026-04-05T10:00:00Z",
  "controls": [
    {
      "controlId": "supply-chain",
      "passed": true,
      "frameworkArticles": {
        "nis2":     ["21(d)"],
        "iso27001": ["A.5.19", "A.5.21"],
        "cra":      ["Art. 10"]
      },
      "details": {
        "has_configuration_revision": true,
        "sbom_generated": true,
        "closure_package_count": 847,
        "inputs_fresh": true
      }
    }
  ]
}

Décision de conception : frameworkArticles relie chaque contrôle aux articles qu'il satisfait. details contient la sortie brute des sondes, pas un résumé - les auditeurs vérifient chaque assertion individuellement. Le booléen passed au niveau du contrôle est dérivé des details. Il n'est pas asserté par la configuration.

05Deux modes d'application

• Portes statiques : le build échoue avant qu'une closure non-conforme ne puisse être livrée. Pas de détection à l'exécution - la closure livrée est conforme par construction.
• Sondes d'exécution : gating de la promotion par vagues et rollback de l'agent sur échec de sonde. Le CP refuse de faire avancer une vague si une sonde de conformité a échoué dans la vague précédente.

06Moteur de gouvernance

Deux modes d'application globaux via compliance.governance.enforceMode : enforce (les contrôles appliquent la config NixOS ET exécutent les sondes) ou report (les contrôles exécutent uniquement les sondes, aucune config NixOS appliquée) - utile pour intégrer des parcs régulés où l'on veut le signal de conformité avant d'activer quoi que ce soit. La désactivation par contrôle est indépendante du mode : définir compliance.controls.<nom>.enable = false et documenter l'exception en ligne. Les presets de framework utilisent enforce par défaut, avec un curseur strictness qui pilote les défauts pertinents par contrôle.

07CLI compliance-check

compliance-check lit /var/lib/nixfleet-compliance/evidence.json et affiche pass/fail coloré par contrôle. --live réexécute chaque sonde en ligne (utile en CI ou avant un audit). Sortie disponible aussi en JSON pour le scripting.

Parcourir le flux de conformité - 15 min →