Docs · Conformité & régulé · Adopter en régulé
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é. 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é. 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.
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_TOKENni 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 --freezeles 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). 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). Les adaptateurs de CI 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.