La release est une porte, elle aussi.
Publier runward sur npm est un geste humain délibéré : créer la release. Tout ce qui suit est de la mécanique déterministe, sans jeton à voler, sans intervention, et vérifiable par n'importe qui. La chaîne de publication applique à sa propre supply chain le principe de la porte : le déterministe exécute, l'humain décide du franchissement.
Le même principe, appliqué à soi-même
La porte de runward tient en une phrase : le déterministe exécute, l'humain décide du franchissement. runward check --strict n'appelle aucun modèle et rend le même verdict sur la même entrée ; franchir la porte reste la décision de l'opérateur. La chaîne de publication suit exactement le même dessin. Pousser du code sur main déclenche les tests, jamais une publication. Ce qui publie sur npm, c'est un geste humain délibéré : créer la release GitHub. Une fois ce geste posé, plus personne ne touche à rien.
Ce qui s'exécute ensuite, sans intervention
Après le geste, la mécanique déroule seule, et chaque maillon est choisi pour être vérifiable :
- OIDC Trusted Publishing : npm fait confiance au workflow exact du dépôt, pas à un jeton. Il n'existe aucun
NPM_TOKEN, aucun secret long-vécu à voler ou à faire tourner. - Provenance SLSA : chaque version publiée porte une attestation signée qui la relie au commit et au workflow qui l'ont produite.
- SBOM CycloneDX attestée : l'inventaire des dépendances est généré dans un job séparé, doté du seul droit de lecture, puis attesté contre le tarball exact qui part sur npm. Une action tierce compromise ne peut pas atteindre le scope de publication.
- Actions épinglées par SHA : chaque brique de la chaîne est figée sur un commit précis, pas sur une étiquette mouvante.
La v0.21.0, publiée aujourd'hui, est passée par cette chaîne exacte : un clic, puis des machines.
Vérifiable, pas déclaré
Rien de tout cela n'est une promesse de sécurité : c'est une posture de conception, et elle se vérifie sans nous croire sur parole. npm audit signatures contrôle la provenance depuis votre terminal ; le workflow de release est public dans le dépôt ; l'attestation et la SBOM sont attachées à chaque release. Un système qui demande de la confiance aveugle contredirait tout ce que runward défend. Celui-ci se laisse auditer, c'est le principe.
Le détail complet, y compris ce qu'une revue fournisseur peut exiger et ce qui ne s'applique pas à un outil local sans flux de données, est dans l'adoption en environnement régulé.
Installer : npx runward init --example
Release v0.21.0 sur GitHub · La documentation · CHANGELOG
← Toutes les nouveautés