# Adopter runward en environnement régulé

Pour une équipe TPRM, sécurité ou achats évaluant runward (la CLI) comme dépendance : ce que la due-diligence fournisseur classique ne couvre pas, et l'intégrité de la chaîne d'approvisionnement qui compte réellement.

## À qui s'adresse cette page

> **Cette page répond à une question différente, pour un public différent, que la page [Preuves de conformité](https://runward.dev/docs/compliance/evidence/).** Elle s'adresse à une **équipe TPRM, sécurité ou achats** qui évalue l'adoption de **runward (la CLI)** comme fournisseur ou comme dépendance de votre chaîne d'approvisionnement. Elle n'explique pas comment runward produit des preuves de conformité pour un système que *vous* construisez.
>
> **Si vous produisez des preuves pour votre propre système agentique livré** (ISO/IEC 42001, NIST AI RMF, règlement IA européen) : les brouillons de readiness, l'export OSCAL, `runward compliance <regime>`, allez plutôt sur la page **[Preuves de conformité](https://runward.dev/docs/compliance/evidence/)**. Celle-ci porte uniquement sur l'évaluation de runward en tant que fournisseur.

La posture en une ligne : runward est une **CLI locale, open source**. Elle s'exécute dans votre dépôt, n'émet aucune donnée, n'héberge rien et ne fait aucun appel réseau. L'objet d'une revue fournisseur classique, un tiers qui *détient vos données*, n'existe donc pas ici. Remettez cette page à votre évaluateur. Le raisonnement est consigné dans [ADR-0031](../adr/ADR-0031-sovereign-engineering-evidence-for-regulated-environments.md).

## 1. Pourquoi la due-diligence fournisseur classique ne s'applique pas

La due-diligence fournisseur classique est conçue pour évaluer un tiers placé **dans votre flux de données**, qui traite ou héberge vos données. runward n'est pas dans le flux : il s'exécute sur votre infrastructure, dans votre dépôt, sans runtime, sans point d'accès, sans transmission. Cela rend les contrôles suivants **sans objet**. Mieux vaut écrire "non applicable, et voici pourquoi" sur le questionnaire que de laisser une case vide, car un formulaire conçu pour du SaaS suppose un service hébergé qui n'existe pas ici.

| Contrôle habituellement exigé d'un fournisseur | Pourquoi il est sans objet ici |
|---|---|
| SOC 2 / ISO 27001 d'un hébergeur | Pas d'hébergeur. runward s'exécute dans votre dépôt, sur votre infrastructure. Aucun service à auditer. |
| DPA / RGPD art. 28 (contrat de sous-traitance) | Aucun tiers dans le flux de données, donc aucune relation de sous-traitance à encadrer. Votre dépôt peut contenir des données personnelles, mais elles restent chez vous, sous vos contrôles existants. |
| Résidence des données / hébergement souverain | Rien n'est hébergé ni transmis. Votre dépôt, votre région. |
| Test d'intrusion du service | Aucun service exposé : pas de runtime, pas de point d'accès à tester. |
| Liste des sous-traitants ultérieurs | Aucune. |
| Chiffrement en transit / au repos (côté fournisseur) | Pas de côté fournisseur. Vos contrôles de dépôt existants s'appliquent. |
| Continuité d'activité / plan de sortie du fournisseur | Sous licence MIT et forkable ; aucune dépendance hébergée à perdre. |

Poursuivre une certification SOC 2 de l'éditeur a été explicitement écarté comme sans objet : il n'y a aucun service à auditer. Pour un outil hors flux de données, **l'intégrité des artefacts et la capacité de fork** sont les substituts open source reconnus de ces contrôles SaaS.

## 2. Ce qui s'applique réellement : intégrité de la chaîne d'approvisionnement et santé du projet

Le véritable objet de revue d'une dépendance open source locale, c'est **l'intégrité de la chaîne d'approvisionnement** (peut-on faire confiance à l'artefact installé) et **la santé du projet** (le projet est-il maintenu et gouverné). runward est solide sur les deux.

### Intégrité de la chaîne d'approvisionnement

- **Provenance** : **npm OIDC Trusted Publishing** et une attestation **SLSA provenance**. Vérification : `npm audit signatures`.
- **SBOM** : un **SBOM CycloneDX**, attesté (SLSA build-provenance) et attaché à chaque Release GitHub.
- **Épinglage des dépendances** : lockfile commité ; chaque action de CI épinglée par **SHA** de commit.
- **Reproductibilité** : build déterministe ; quiconque peut re-vérifier l'artefact publié.
- **Durcissement de la CI** : les tests cœur s'exécutent **isolés du réseau** (`unshare -n`), une garantie zéro-réseau structurelle, pas une simple affirmation.
- **Posture continue** : un workflow **OpenSSF Scorecard**.
- **Aucun secret Actions durable** : la publication passe par OIDC trusted publishing, il n'y a donc ni `NPM_TOKEN` ni PAT à fuiter.

### Santé et gouvernance du projet

- **Divulgation coordonnée** : `SECURITY.md` (canal privé, fenêtre de réponse).
- **Propriété et cadence** : `CODEOWNERS`, SemVer, `CHANGELOG.md`, `GOVERNANCE.md`.
- **Bus factor** : mainteneur unique, atténué par la licence **MIT (droit de fork)** et un build reproductible. En open source, la capacité de fork est la réponse de continuité reconnue, plus forte qu'un SaaS mono-fournisseur que vous ne pouvez pas reconstruire.

Cela recoupe les contrôles porteurs du **socle OpenSSF OSPS Baseline** qu'un acheteur régulé recherche : provenance signée, SBOM, actions épinglées par SHA, divulgation coordonnée, revue par défaut, aucun secret commité et une suite de tests déterministe.

## 3. Cadre de licence

- **Outillage : MIT.** Librement réutilisable, sans copyleft, sans obligation virale. Le cas favorable dans une revue régulée.
- **Doctrine / méthode : CC BY-ND 4.0.** Vous pouvez l'**utiliser et l'appliquer** en interne : depuis CC 4.0, une adaptation *privée* non partagée est permise. Ce que la clause ND interdit, c'est de **redistribuer une version modifiée** du corpus. L'usage interne ne crée donc aucun dérivé distribué et ne soulève aucune obligation ; seule la republication d'une doctrine altérée en soulèverait une.

## 4. Les limites honnêtes, nommées et non masquées

- **Pas un validateur de conformité.** runward produit des *preuves d'appui prêtes pour l'audit* ; il ne confère ni conformité, ni certification, ni évaluation de conformité. L'acceptation reste toujours la décision de l'auditeur.
- **Pas un runtime.** Aucun journal d'exécution. La tenue de registres de l'art. 12 du règlement IA et les éléments post-marché / déclaration de conformité restent à la charge de **l'opérateur**. runward n'alimente que la documentation technique de *conception* (art. 11 / Annexe IV).
- **Instantané dans le temps.** Les preuves sont dérivées du contenu du dépôt, donc à rejouer en CI. `runward check --freeze` les scelle par SHA-256 ; toute dérive ultérieure fait rougir le gate jusqu'à re-vérification.
- **Pas de SLA, pas de garantie.** MIT "AS IS", au mieux, mainteneur unique, avec la capacité de fork comme réponse de continuité.

## 5. Cette posture est elle-même gardée contre la dérive, et runward ne se câble jamais lui-même

**Appliqué en CI, pas seulement affirmé.** Chaque affirmation vérifiable de cette page est appliquée par un **garde-fou de dérive** en CI ([ADR-0031](../adr/ADR-0031-sovereign-engineering-evidence-for-regulated-environments.md)). Si un contrôle cesse d'être vrai (une action de workflow dé-épinglée, un secret durable introduit, l'étape SBOM ou provenance retirée, la licence changée), le gate rougit **avant** que ce document ne devienne silencieusement obsolète. Le mainteneur tient la fiche ; le gate tient le mainteneur honnête.

**La frontière d'autorisation.** runward n'installe jamais de hooks git et n'écrit jamais dans `.git/` ([ADR-0012](../adr/ADR-0012-runward-never-installs-git-hooks.md)). Les [adaptateurs de CI](https://runward.dev/docs/operating/wire-the-gate/) sont des exemples inertes que l'opérateur câble délibérément. "Agent-operable" signifie qu'un agent peut piloter la CLI de bout en bout, y compris réaliser le câblage sur ordre de l'opérateur, pas que runward modifie votre dépôt en silence. C'est un choix d'autorisation délibéré, pas une capacité manquante, et c'est exactement ce qu'un acheteur régulé attend d'un outil qu'il installe.

## Voir aussi

- [La preuve de conformité du système que vous livrez](https://runward.dev/docs/compliance/evidence/)
- [ADR / décisions](https://runward.dev/docs/reference/adr/)
- [La frontière : runward ne se câble jamais tout seul](https://runward.dev/docs/operating/from-an-agent/the-wiring-boundary/)
- [Preuve et intégrité](https://runward.dev/docs/concepts/evidence/)