Docs · Comprendre · Après la spec · L’étage release
L'étage release : Kosli, JFrog, Chainloop.
« On a déjà Kosli, non ? » — non, et c'est plus intéressant qu'un non : la custody d'artefacts publiés est l'étage sous lequel runward se place. Constats datés d'août 2026, pris de leur documentation.
Si votre chaîne porte déjà Kosli, JFrog AppTrust ou Chainloop, la question se pose : est-ce que runward fait la même chose ? Non — et la raison est mécanique, pas commerciale : ces outils vérifient un artefact après le build, runward vérifie un arbre de travail avant le merge. Cette page décrit les deux mécanismes et comment ils se branchent l'un sur l'autre.
La carte d'ensemble. Cette page traite l'aval. Pour situer d'un coup d'œil tout le voisinage — spec-driven, harnais, custody, admission — et la case que runward occupe, voir le périmètre.
Deux étages, deux objets
| Ce qui est gouverné | Quand | Ce qui est vérifié | |
|---|---|---|---|
| runward | l'arbre de travail | avant le merge | les décisions porteuses ont été prises, tracées, et adossées à une preuve qui résout |
| Kosli, JFrog Evidence, Chainloop | un artefact publié | après le build, à la promotion | la provenance, la custody, la conformité du pipeline qui a produit l'artefact |
L'étage release répond à « cet artefact vient-il d'où il prétend, et a-t-il passé ce qu'il devait passer ? ». runward répond à « les choix qui feront tenir ce système ont-ils été faits et prouvés, avant que le code n'entre ? ». Aucune des deux questions ne remplace l'autre, et un système qui répond à la première sans la seconde livre une chaîne de custody impeccable autour d'un système dont personne n'a arbitré l'architecture.
Ce que ces outils font, dans leurs propres mots
Constats datés d'août 2026, pris de leur documentation, jamais de résumés tiers.
- Chainloop se présente comme un evidence store et policy engine open-source pour la chaîne d'approvisionnement logicielle : sa CLI tourne dans le pipeline CI, récupère ce que le build a produit, dépose ces fichiers dans un stockage adressé par contenu et les référence dans une attestation in-toto signée. Il vérifie qu'un pipeline respecte son contrat : celui qui cesse d'émettre une nomenclature cesse de le satisfaire. Support de 17 types de preuve (SBOM, OpenVEX, CSAF, SARIF…).
- Kosli enregistre les changements « pour prouver la conformité sans ralentir », avec un Evidence Vault immuable et append-only qui conserve les fichiers de preuve (résultats JUnit, pièces jointes) et leurs empreintes. Il opère sur des flows et des artefacts une fois produits.
- JFrog Evidence attache des attestations signées aux artefacts, builds, packages et Release Bundles v2 (Artifactory 7.111+), avec un écosystème de partenaires couvrant les étapes de build et de promotion.
Le fil commun, et c'est lui qui compte : les trois prennent ce que le build a émis. Aucun ne regarde un arbre de travail avant le merge, parce que ce n'est pas leur métier.
Comment les deux se branchent
Les trois acceptent des preuves externes. Le verdict runward devient donc un type de preuve de plus dans leur chaîne :
# Kosli — le verdict comme preuve générique sur le trail de l'artefact
kosli attest generic --name runward-gate --flow <flow> --trail <trail> \
--attachments verdict.dsse.json --compliant=true
# JFrog Evidence — preuve externe attachée à la version du package
jf evd create --package-name <pkg> --package-version <v> \
--predicate verdict.intoto.json --predicate-type https://runward.dev/verdict/v1
La valeur --compliant vient du code de sortie de runward, jamais d'un humain qui retape un verdict qu'il n'a pas re-dérivé. Les recettes complètes (signature cosign, dépôt Archivista/Chainloop/OCI, admission Kyverno sur une VSA) sont dans docs/interop.md du dépôt.
Ce que runward apporte que cet étage ne peut pas produire
Un evidence store conserve ce qu'on lui donne. Il ne peut pas fabriquer une preuve que personne n'a produite — et la décision d'architecture prise avant le premier commit n'est émise par aucun pipeline. C'est la matière que runward produit :
- une décision porteuse tracée et ratifiée (l'ADR, avec son déclencheur de réévaluation), pas seulement un artefact horodaté ;
- une preuve qui résout : un pointeur typé qui ouvre un fichier, trouve un symbole à la frontière d'identifiant, lit un cas de test enregistré vert, un scan sans finding ouvert ;
- un verdict re-dérivable hors ligne :
runward verifyrecalcule tout depuis l'arbre seul, sans réseau, sans racine de confiance, sans clé. Un evidence store prouve qu'un fichier n'a pas bougé ; runward re-calcule le jugement lui-même.
Ce que runward ne fait pas, et ne fera pas
Il ne publie pas, ne dépose pas, n'agrège pas, ne surveille pas. Il n'y a pas de runward push, pas de vue de flotte, pas de store hébergé : ce sont des runtimes, du côté de l'opérateur (ADR-0054). Un outil qui gouverne une flotte a besoin d'un service qui tourne ; runward a besoin d'un dossier et d'un système de fichiers. C'est ce qui lui permet de rendre le même verdict sur votre poste, dans votre CI et chez votre auditeur, des mois plus tard.