hawser — Spécification de conformité, certification et sécurité

Marché cible : programmes critiques pour la sûreté et la sécurité (avionique, spatial, défense, ferroviaire, automobile, industriel, médical). Ces clients ne peuvent adopter un outil de SCM que s’il produit des preuves de certification, s’il est lui-même qualifiable, s’il présente une posture de sécurité auditable et s’il est irréprochable en matière de protection des données. Ce document précise ce que hawser doit fournir, par domaine, et met en correspondance chaque exigence avec une fonctionnalité technique et une phase de livraison.

Terminologie : « l’outil » = le binaire haw + haw-core. « Le demandeur » = l’équipe sûreté/sécurité du client qui détient l’argumentaire de certification. hawser fournit des preuves et un kit de qualification ; le demandeur détient la décision finale dans son plan (PSAC, plan de sûreté, hypothèses SEooC).

1. La place de hawser dans le cycle de vie

hawser est un outil de gestion de configuration logicielle (SCM) + composition. Il décide quelle révision de quel dépôt entre dans un build et consigne cette décision de manière immuable. Il ne compile, ne génère ni ne vérifie pas de code embarqué/aéroporté. Cette délimitation de périmètre est la phrase la plus importante pour la qualification : elle borne les modes de défaillance de l’outil à « sélectionne/consigne le mauvais jeu de sources » — et non « émet du code objet erroné ».

Conséquences de ce périmètre :

• La sortie de l’outil (haw.lock + arbre matérialisé) est vérifiable de manière indépendante par le build et la revue en aval, ce qui réduit la rigueur de qualification requise.
• Les preuves qu’il produit (baseline, SBOM, provenance) sont consommées par les processus de SCM, de sûreté et de sécurité du client — hawser est un producteur de preuves, pas une autorité.

2. Qualification de l’outil

hawser est pertinent pour la qualification dans toutes les normes de sûreté, car un outil de configuration/composition peut sélectionner la mauvaise source dans un build de sûreté. La classification et la rigueur diffèrent selon la norme ; les artefacts que hawser doit fournir sont en grande partie communs (§2.6).

2.1 DO-178C / DO-330 (aéroporté) & DO-278A (sol/ATM)

• Qualification de l’outil régie par la DO-330. Le critère est déterminé par la capacité de l’outil à insérer une erreur dans le produit et/ou à ne pas en détecter une :
  • Si le processus du client re-vérifie l’arbre matérialisé/le build de manière indépendante → Critère 3 → généralement TQL-5 (rigueur la plus faible).
  • Si le lockfile/l’arbre est réputé fiable sans re-vérification indépendante → Critère 1 → TQL-4 (ou supérieur en DAL A/B).
• Recommandation de hawser aux demandeurs : conservez le build et la revue en aval comme activité de vérification afin que l’outil reste en Critère 3 / TQL-5. Documentez ce choix dans le PSAC.
• Livrables fournis par hawser : Tool Operational Requirements (TOR), Tool Qualification Plan (TQP), exigences de l’outil + cas de test + résultats avec traçabilité, gabarit de Tool Accomplishment Summary (TAS) et une liste des limitations connues / errata.

2.2 ISO 26262-8:2018 §11 (automobile) + ASPICE

• Déterminez le Tool Confidence Level TCL1–3 à partir de Tool Impact (TI) × Tool error Detection (TD). hawser est TI2 (un dysfonctionnement peut violer une exigence de sûreté) avec un TD1/TD2 atteignable si le client vérifie le build → généralement TCL1–TCL2.
• Méthodes de qualification prises en charge par hawser : 1a confiance accrue par l’usage (métriques d’utilisation, gabarit d’historique de terrain), 1b évaluation du processus de développement de l’outil (nos preuves de SDLC, §7), 1c validation de l’outil (notre suite de tests + résultats).
• Correspondance ASPICE : SUP.8 Configuration Management et SUP.10 Change Request Management (voir §3). Fournissez la table de correspondance comme artefact commercial/d’audit.

2.3 IEC 61508-3 (sûreté fonctionnelle industrielle)

• Classification comme outil de support hors ligne T2/T3. hawser contribue à ce qui est construit → à traiter comme T3 sauf si le build du client re-dérive indépendamment le jeu de sources.
• Fournir : preuves de validation de l’outil, enregistrement de la version + configuration, liste des défauts connus.

2.4 EN 50128 / EN 50716 (ferroviaire)

• Classe d’outil T2/T3 (§6.7). Fournissez un Tool Qualification Report et la preuve que l’outil est utilisé dans son enveloppe opérationnelle validée.

2.5 Spatial (ECSS-E-ST-40 / ECSS-Q-ST-80) & médical (IEC 62304)

• Spatial : outil utilisé dans le cadre d’un plan de SCM ; fournir les enregistrements de configuration + validation.
• Médical IEC 62304 §8 gestion de la configuration/SOUP : fournir SBOM + preuves de baseline.

2.6 Le jeu d’artefacts de qualification commun (produit une seule fois, mis en correspondance par norme)

1. Tool Operational Requirements — ce que haw doit faire, sous forme d’énoncés vérifiables.
2. Matrice de traçabilité exigences → tests (chaque exigence a un test).
3. Suite de tests + résultats lisibles par machine par LTS publiée, par OS pris en charge.
4. Manuel de sûreté/d’exploitation — usage prévu, enveloppe opérationnelle, contraintes et les mesures d’évitement d’erreur que l’utilisateur doit appliquer (p. ex. « committer le lockfile », « vérifier que le build re-dérive l’arbre »).
5. Limitations connues & errata, versionnés.
6. Enregistrement de configuration — version exacte de l’outil, versions des dépendances, provenance du build.
7. Tables de correspondance par norme (DO-330 / ISO 26262-8 / IEC 61508 / EN 50128 / ASPICE).

Le déterminisme est une exigence stricte pour tout ce qui précède : mêmes entrées ⇒ haw.lock et sélection d’arbre identiques au bit près, sur chaque OS. Pas d’horloge murale, pas d’ordre d’itération de map, pas de non-déterminisme réseau dans la résolution. Voir §8.

3. Reproductibilité & preuves de SCM

L’atout commercial et de certification. hawser transforme « faites confiance à notre processus » en « voici la baseline signée et reproductible ».

• haw.lock = la baseline de configuration. Chaque dépôt épinglé à un id d’objet exact. Committé, relisible par diff, vérifiable par machine.
• Résolution déterministe. Algorithme de résolution documenté et versionné (voir resolver/mod.rs) ; la priorité des overlays est totale et stable.
• Détection de dérive. haw status / haw verify prouve que l’arbre sur disque correspond à la baseline — c’est bel et bien une activité de vérification de configuration pour le plan de SCM du client.
• Bundle de preuves. haw evidence émet : baseline (lock) + SBOM + attestation de provenance + enregistrement de configuration de l’outil, sous forme d’une archive signée unique pour le paquet de données de certification.

Correspondance avec les normes :

4. Sécurité de la chaîne d’approvisionnement & SBOM

Vent réglementaire favorable — de plus en plus obligatoire, pas optionnel.

• Export SBOM dans les deux formats dominants : CycloneDX et SPDX 2.3 (ISO/IEC 5962), SPDX 3.0 quand il sera stable. Inclut les éléments minimaux NTIA (fournisseur, composant, version, id unique, relation de dépendance, auteur, horodatage).
• hawser émet un SBOM du produit composé (dépôts + leurs ids épinglés) et livre un SBOM de haw lui-même (son arbre de dépendances Rust) à chaque version.
• EU Cyber Resilience Act (Règlement (UE) 2024/2847). En vigueur depuis déc. 2024 ; les obligations principales s’appliquent ~déc. 2027, le signalement des vulnérabilités/incidents ~sept. 2026. Exige des fabricants de produits comportant des éléments numériques qu’ils maintiennent un SBOM et gèrent les vulnérabilités. Le chemin lock→SBOM de hawser est un facilitateur de conformité direct pour les clients, et hawser lui-même doit être conforme au CRA en tant que produit que nous vendons.
• US EO 14028 / NIST SSDF (SP 800-218) et provenance SLSA v1.0. hawser émet des attestations de provenance de build/composition (style in-toto) pour que l’arbre composé porte un « ce qui est entré, d’où, à quel id » vérifiable.

5. Cryptographie & intégrité

Les clients sensibles exigent une intégrité cryptographique de bout en bout et un inventaire cryptographique documenté. Principes de conception : vérifier par défaut là où le client l’active, ne jamais inventer de cryptographie, être remplaçable par du FIPS, être rigoureux quant aux secrets.

5.1 Vérification de signature (intégrité des sources)

• Vérifier les signatures de commit/tag avant checkout lorsque le client l’active : OpenPGP (GPG), signature SSH et Sigstore / gitsign (sans clé). Modes de politique : off | warn | require. require fait échouer sync sur tout dépôt non signé/non vérifié.
• Ancres de confiance configurées par espace de travail (ensembles de signataires autorisés, trousseaux, racines Fulcio).

5.2 Intégrité de la baseline

• Lockfile signé / attestation de résolution signée. haw lock --sign produit une signature détachée ou une attestation in-toto sur les octets canoniques du lock, afin qu’un relecteur puisse prouver que la baseline n’a pas été altérée après approbation.
• Une sérialisation du lock canonique et stable au bit près est un prérequis (§8).

5.3 Identité de l’outil (un outil qualifié doit être vérifiable en identité)

• Versions de haw signées et reproductibles. Signatures Cosign/Sigstore + sommes de contrôle SHA-256 + provenance de build SLSA pour chaque artefact et chaque LTS. Les clients vérifient que le binaire qu’ils exécutent correspond à celui qui est qualifié.

5.4 Agilité de hachage

• Prendre en charge le format d’objet SHA-256 de git aux côtés de SHA-1 et consigner lequel est utilisé dans le lock. Les programmes de sûreté à longue durée de vie survivent à la marge de sécurité anti-collision de SHA-1 ; stockez l’id le plus robuste disponible. Ne jamais s’appuyer sur SHA-1 comme seule garantie d’intégrité d’une baseline.

5.5 Module cryptographique & transport

• TLS vers les API de forge via rustls ; aucune rétrogradation de protocole, TLS minimum épinglé à 1.2 (préférer 1.3). Pour les environnements FIPS 140-3, livrer un build reposant sur un module validé FIPS (p. ex. rustls + aws-lc-rs FIPS, ou OpenSSL FIPS système) et documenter la frontière.
• Publier un inventaire cryptographique (algorithmes, bibliothèques, versions) — requis pour les audits d’agilité cryptographique et les échanges FIPS/Common Criteria.

5.6 Gestion des secrets

• Les jetons de forge et identifiants ne sont jamais écrits dans haw.toml, haw.lock, les journaux ou l’état de l’espace de travail. Récupérez-les depuis le trousseau de l’OS, les assistants git credential ou un gestionnaire de secrets (Vault) via env/assistant. Masquez toute chaîne ayant l’apparence d’un identifiant dans les journaux et les erreurs.

5.7 Contrôle des exportations (hawser en tant que produit intégrant de la cryptographie)

• hawser utilise/lie de la cryptographie → probablement ECCN 5D002 au titre de l’EAR américain. Démarche : auto-classification comme grand public (740.17 / note grand public) et, pour le cœur open source, dépôt de la notification de code source de chiffrement publié auprès du BIS/NSA (§742.15(b)). Publiez l’ECCN et la classification afin que les clients puissent valider l’importation/l’usage dans leur juridiction.
• Wassenaar/double usage : logiciel commercial à double usage ; le maintenir hors du champ ITAR en ne regroupant pas de données techniques contrôlées. Les clients de la défense détiennent les contrôles de leur programme ITAR/EAR.

6. Protection des données (RGPD & équivalents)

hawser traite des données personnelles de manière incidente : nom + e-mail de l’auteur/committer git, noms d’utilisateur de forge, identités des relecteurs de PR/MR, acteur CI, horodatages de revue. Toutes sont des données personnelles au titre du RGPD (et du CCPA, LGPD, UK-GDPR).

Position de conception — c’est un argument de vente, pas seulement une contrainte :

• Local d’abord, zéro sortie par défaut. Pour un fonctionnement local, les données ne quittent jamais la machine/le réseau de l’opérateur → le client est le responsable de traitement et l’éditeur de hawser n’est pas un sous-traitant (rien ne nous est transmis). C’est la posture la plus irréprochable possible pour les réseaux classifiés/réglementés.
• Aucune télémétrie par défaut. Toute télémétrie future est strictement sur adhésion, anonymisée, hébergeable dans l’UE et entièrement documentée ; les builds isolés (air-gapped) n’ont aucun chemin réseau vers nous.
• Activation de licence hors ligne. La validation de licence ne doit pas appeler nos serveurs avec des données personnelles ; fournissez une activation par fichier/hors ligne pour les environnements isolés et souverains.
• Résidence / souveraineté des données. Les déploiements auto-hébergés et isolés conservent toutes les données à l’intérieur du périmètre du client. Pour tout composant hébergé optionnel (serveur de licences, miroir), proposez une région UE et un Data Processing Agreement (DPA) signé.
• Registres de traitement (Art. 30) & support AIPD. Fournissez une description des flux de données et un gabarit d’entrée d’AIPD documentant exactement quels champs de données personnelles hawser lit et où ils vont (réponse : nulle part, pour un usage local).
• Droit à l’effacement vs historique immuable. hawser ne crée aucun nouveau magasin de données personnelles ; il lit des métadonnées git/forge qui existent déjà. Les demandes d’effacement sont traitées au niveau de l’historique git / de la couche forge par le client — hawser documente cette frontière plutôt que de prétendre satisfaire l’effacement sur des objets de commit immuables.
• Livrez un avis de confidentialité et un contact security.txt / .well-known/security.txt.

7. Sécurité de l’outil lui-même (SDLC sécurisé)

Un outil vendu à des programmes critiques pour la sécurité fait lui-même partie de la surface d’attaque. La preuve d’un SDLC sécurisé est une condition préalable à l’achat et alimente la méthode 1b d’ISO 26262 / l’assurance de développement d’outil de la DO-330.

• Sûreté mémoire. unsafe_code = "forbid" sur tout l’espace de travail (déjà en place). Un outil de SCM en Rust, à sûreté mémoire, est un différenciateur concret face aux acteurs en place en C/Python — affichez-le.
• Assurance des dépendances. cargo-audit (avis RUSTSEC), cargo-deny (politique de licence
  • avis + verrous de crates bannies), et revue de la chaîne d’approvisionnement (cargo-vet/cargo-crev) en CI, faisant échouer le build en cas de violation.
• Builds vendorisés + reproductibles. Vendorisez les dépendances pour une reconstruction en environnement isolé ; épinglez la toolchain (rust-toolchain.toml) ; builds de version reproductibles au bit près.
• SBOM propre publié à chaque version (§4) avec signatures (§5.3).
• Divulgation des vulnérabilités & gestion des CVE. Politique publiée, contact sécurité, fenêtre de divulgation coordonnée, émission de CVE et engagement de rétroportage par LTS (§ commercial).
• Surface réseau bornée et documentée. L’outil effectue des E/S réseau uniquement pour les opérations git/forge explicites invoquées par l’utilisateur ; documentez chaque sortie. Aucun appel caché.
• Moindre privilège. Aucune élévation ; aucune écriture en dehors de l’espace de travail + du répertoire de cache configuré.

8. Auditabilité & déterminisme (transversal)

• Contrat de déterminisme. Mêmes manifeste + lock + overlays ⇒ résolution et sélection d’arbre identiques au bit près sur Linux/macOS/Windows. Pas de Date.now, pas d’itération non ordonnée dans la sérialisation (utiliser des maps ordonnées — déjà IndexMap), émission TOML canonique pour le lock.
• Journal d’audit structuré. Chaque opération mutante consigne l’acteur, l’opération, le dépôt affecté, l’id d’objet avant/après, l’horodatage — lisible par machine (JSON) pour la capture de preuves en CI.
• Sortie lisible par machine. --format json sur status/verify/graph/evidence pour que les pipelines puissent capturer et comparer automatiquement les preuves de certification. Schémas stables et versionnés.
• Codes de sortie stables pour que les portes CI soient fiables (0 ok, valeurs non nulles distinctes pour dérive / échec de vérification / échec de signature).

9. Backlog de fonctionnalités mis en correspondance avec les exigences de conformité

Ce qui doit être construit pour rendre ce qui précède réel. Les phases se réfèrent à ARCHITECTURE.md §6.

Contactez les mainteneurs pour savoir comment ces éléments sont packagés, licenciés et pris en charge.