Des preuves à tester, pas à croire sur parole.

Une déclaration signée sur un événement. Aujourd’hui, c’est un contrôle de code sur une pull request ou sur main. À partir de v1.4.0, c’est aussi un changement fusionné, une règle de revue modifiée ou un push direct. Un enregistrement de changement nomme la pull request, qui l’a rédigée, approuvée et fusionnée, les checks et règles en vigueur et les résultats sur le code, chaque fait étant étiqueté selon la façon dont il a été obtenu. Les personnes apparaissent sous forme d’empreintes de leurs comptes GitHub.

Techniquement, c’est une déclaration in-toto avec le prédicat SLSA verification summary, scellée dans une enveloppe DSSE et signée avec ECDSA P-256 ; les prédicats des autres types d’enregistrement arrivent avec v1.4.0. L’ancrage dans le journal de transparence public Rekor de Sigstore est intégré, sur adhésion de chaque organisation ; seuls les hachages d’enregistrements sont publiés. Les organisations Enterprise peuvent aussi s’ancrer dans leur propre Rekor.

Au moment de l’événement : à chaque contrôle de code aujourd’hui, et à partir de v1.4.0 à chaque fusion de pull request, à chaque modification d’une règle de revue ou à chaque push qui contourne la revue. Les enregistrements ne sont pas reconstitués après coup à partir de logs ou de tickets, donc un trou entre deux instantanés ne passe pas inaperçu.

Les faits recalculés ont été calculés par Toevan à partir du code ou de l’historique git, et vous pouvez les refaire. Les faits rapportés + scellés viennent de GitHub et ont été signés au moment de l’événement : vous vous y fiez dans la mesure où vous vous fiez à GitHub. Les faits déclarés + scellés, comme un changement de ce qui est vérifié, ont été déclarés par l’organisation avec leur historique. Les dérogations sont des enregistrements de Toevan non scellés dans le registre aujourd’hui, et le rapport le dit. Les faits consommés viendront de l’enregistrement signé d’un autre système, comme la provenance du build ; c’est prévu. Non capturé signifie qu’aucune source fiable n’existait, et Toevan ne le déduit pas.

Oui. Les règles sont évaluées sur le graphe de code du dépôt, sans modèle d’apprentissage automatique dans la décision. Le même commit, la même version du moteur et la même version du jeu de règles donnent toujours le même résultat : vous pouvez rejouer une évaluation échantillonnée et attendre un résultat identique.

Dans l’application, Vérifier maintenant revérifie la chaîne de hachage, chaque signature et les preuves stockées. Cela s’exécute dans Toevan.

Avec des outils courants et sans compte Toevan, openssl vérifie un enregistrement face à la liste publique de toutes les clés avec lesquelles Toevan a signé, actuelles et retirées : la signature, et que le fichier d’enregistrement est celui que nomme la déclaration. À partir de v1.4.0, les rapports et la branche de preuves affichent les commandes, et Toevan documente une ligne cosign v2 qui vérifie la signature et le type de déclaration, pas le lien avec l’enregistrement.

Avec le vérificateur Toevan, disponible sur demande, une commande rejoue toute la chaîne et vérifie chaque signature et chaque preuve Rekor hors ligne.

Avec git, vous lisez les preuves sur une branche toevan/evidence chaînée par hachage et en ajout seul, dans le propre dépôt du client, et chaque rapport porte une empreinte de contenu, le SHA-256 du manifeste joint au PDF. À partir de v1.4.0, vous pouvez aussi recompter la population des changements avec git et le CSV du rapport.

L’ancrage dans le journal de transparence public Rekor de Sigstore est intégré, sur adhésion de chaque organisation ; seuls les hachages d’enregistrements sont publiés. Les verdicts signés peuvent aussi être poussés dans les flux Kosli du client.

À partir de v1.4.0, le rapport de preuves de changement liste chaque commit arrivé sur la branche par défaut pendant la période, directement depuis l’historique git, et rapproche chacun de l’enregistrement de la pull request fusionnée ou du push qui l’y a amené. Un commit qu’aucun enregistrement n’explique est signalé avec sa raison, jamais déduit. Vous pouvez refaire vous-même la population avec git à partir du CSV de la population. Chaque déploiement que GitHub marque comme production est relié au commit qu’il a livré. Les branches de production que l’organisation désigne, comme une branche de release, recevront la même population avec v1.4.1, qui est prévue.

Prévu, et hors de v1.4.0. Un correctif copié reçoit un nouvel identifiant de commit, donc sa revue ne se reporte pas automatiquement. Toevan le rapprochera de l’original revu par son contenu avec git patch-id, et considérera qu’une copie dont le contenu a changé exige sa propre revue.

L’ancrage dans le journal de transparence public Rekor de Sigstore est intégré, sur adhésion de chaque organisation ; seuls les hachages d’enregistrements sont publiés. Une entrée montre seulement qu’un enregistrement de hachage donné existait à un moment donné : ni code, ni noms de fichiers, ni constats. Les organisations Enterprise peuvent aussi s’ancrer dans leur propre Rekor.

Il ne signifie pas que le client respecte le référentiel, et Toevan n’exprime aucun avis sur la conception ou l’efficacité de fonctionnement des contrôles. Les revues d’accès, la surveillance en production, la réponse aux incidents, le risque lié aux tiers, la sécurité physique et les changements faits hors gestion de versions relèvent de vos procédures habituelles. Chaque rapport les liste.

GitHub aujourd’hui. GitLab et Bitbucket sont sur la feuille de route. Les changements faits hors gestion de versions, comme des modifications directes de la base de données ou de la console, sont hors du périmètre des preuves.

Dans le stockage en ajout seul de Toevan, avec une conservation d’au moins trois ans, et en copie sur une branche du dépôt du client. Les rapports s’exportent en PDF et en CSV par référentiel, période et dépôt.

La copie dans le dépôt du client reste en place. La chaîne se rejoue avec la commande toevan et, à partir de v1.4.0, chaque enregistrement signé se vérifie aussi avec openssl seul et la clé publiée, avec les commandes de la branche de preuves. La vérification des enregistrements passés ne dépend pas de la poursuite du service par Toevan.