Pour les auditeurs
Des preuves à tester, pas à croire sur parole.
- Vérifiez hors ligneChaque enregistrement signé se vérifie hors ligne avec openssl standard, sans logiciel Toevan ni compte.
- Voyez comment chaque fait a été obtenuRecalculé, rapporté, déclaré, consommé ou non capturé, sur chaque fait.
- Sachez ce qui n’est pas couvertChaque rapport liste les contrôles qui restent à la charge de l’organisation.
Trois façons de vérifier
Trois façons de vérifier, dont une hors ligne avec openssl standard.
Choisissez la voie qui correspond à votre rôle. Seule la troisième demande des outils : elle vérifie hors ligne avec openssl standard, sans logiciel Toevan ni compte.
1
Dans l’application de l’organisation
Tout auditeur invité par l’organisation
Un rôle Auditeur, aucun accès au dépôt
Accès en lecture seule à la liste des preuves, aux exports et aux rapports, avec Vérifier maintenant pour contrôler à nouveau le registre, les signatures et les éventuelles preuves de journal.
- Signature valide pour chaque enregistrement
- Inchangé depuis sa signature
- Heure consignée, si l’ancrage dans Rekor est activé
2
Regardez l’organisation l’exécuter
Tests usuels d’un rapport généré par le client
Un partage d’écran ou une visite
Vous choisissez les échantillons pendant la séance ; un ingénieur exécute les vérifications sous vos yeux.
- Vérification des enregistrements que vous avez échantillonnés
- Comptes de l’auteur et de l’approbateur pour chaque échantillon
- Le résultat du code pour un commit de votre choix
3
Exécutez-le vous-même
Spécialistes de l’audit informatique
git, openssl et un accès en lecture temporaire ; pour toute la chaîne, le vérificateur Toevan (sur demande, pas encore public)
Vérifiez n’importe quel enregistrement hors ligne avec la clé publiée et des outils standard. Pour rejouer toute la chaîne, Toevan fournit la commande toevan sur demande ; elle n’est pas encore publique.
- Signature et enregistrement, hors ligne, avec openssl
- Têtes de branche de preuves comparées au rapport
- Indépendance établie à partir des identifiants de compte de chaque enregistrement
La vérification telle que l’imprime le README de la branche de preuves de votre client, après le clonage et le téléchargement de la clé. Elles demandent openssl (OpenSSL 3 ou plus récent, ou le LibreSSL fourni par macOS) et les utilitaires shell sed, wc, tr, cut, cat et printf, dans n’importe quel shell POSIX. Rien de Toevan n’est nécessaire.
- l’empreinte de la clé : comparez-la à l’identifiant de clé sur api.toevan.com/v1/public/evidence/keys
- la signature, sur les octets exacts qui ont été signés (DSSE v1)
- le fichier d’enregistrement est celui que nomme la déclaration signée
- ce dont parle la déclaration ; comparez-la à l’enregistrement choisi
$ git clone --branch toevan/evidence <your-client's-repo> evidence && cd evidence
$ curl -o toevan.pub https://api.toevan.com/v1/public/evidence/keys/<key_id>.pem
$ ENV=attestations/<head_sha>/<record_id>.dsse.json
$ REC=records/<head_sha>/<record_id>.json
$ PUB=toevan.pub
$ openssl pkey -pubin -in "$PUB" -outform DER | openssl dgst -sha256
SHA2-256(stdin)= <key id>
$ T=$(sed -E 's/.*"payloadType":"([^"]*)".*/\1/' "$ENV")
$ sed -E 's/.*"payload":"([^"]*)".*/\1/' "$ENV" | openssl base64 -d -A > statement.json
$ sed -E 's/.*"sig":"([^"]*)".*/\1/' "$ENV" | openssl base64 -d -A > sig.der
$ { printf 'DSSEv1 %s %s %s ' "${#T}" "$T" "$(wc -c < statement.json | tr -d ' ')"; cat statement.json; } > pae.bin
$ openssl dgst -sha256 -verify "$PUB" -signature sig.der pae.bin
Verified OK
$ H=$(sed -E 's/.*"record_hash":"sha256:([0-9a-f]{64})".*/\1/' statement.json)
$ if [ "$(openssl dgst -sha256 -r "$REC" | cut -d' ' -f1)" = "$H" ]; then echo "record matches the statement"; else echo "RECORD DOES NOT MATCH THE STATEMENT"; fi
record matches the statement
$ printf 'record %s\n' "$(sed -nE 's/.*"record_id":"([^"]*)".*/\1/p' statement.json)"
record <the record id you picked>
$ printf 'subject %s\n' "$(sed -nE 's/.*"subject":\[\{"digest":\{"([^"]*)":"([^"]*)"\},"name":"([^"]*)"\}\].*/\3 \1:\2/p' statement.json)"
subject git+https://github.com/<owner>/<repository> gitCommit:<the commit you picked>
Le fichier d’enveloppe tient sur une seule ligne de JSON, tel que Toevan l’écrit ; s’il a été reformaté, remettez-le d’abord sur une ligne. Comparez la clé à l’identifiant de clé que Toevan publie sur api.toevan.com/v1/public/evidence/keys et imprime dans chaque rapport.
Origine
Comment chaque fait a été obtenu.
Chaque fait d’un enregistrement et d’un rapport porte l’une de six étiquettes, pour que votre auditeur sache dans quelle mesure s’y fier.
- Recalculé
- Toevan l’a calculé lui-même à partir du code ou de l’historique git. Le refaire à partir des mêmes entrées et obtenir le même résultat.
- Rapporté + scellé
- GitHub l’a rapporté ; Toevan l’a capturé au moment de l’événement et signé. S’y fier dans la mesure où vous vous fiez à GitHub. Toute modification ultérieure est détectable.
- Déclaré + scellé
- L’organisation l’a déclaré, par exemple un changement de ce qui est vérifié ; Toevan a signé la déclaration et son historique. Voir qui a déclaré quoi, quand, et chaque modification ultérieure.
- Enregistrement Toevan, non scellé
- Conservé dans la base de données de Toevan mais non scellé dans le registre, comme une dérogation aujourd’hui. Aucune signature ne le protège. Le considérer comme une déclaration de Toevan et demander à l’organisation l’approbation qui la fonde.
- Consommé
- Repris des enregistrements de déploiement et de release de GitHub et relié par commit ou empreinte. Vérifier l’enregistrement d’origine dans GitHub.
- Non capturé
- Aucune source fiable n’était disponible. Toevan ne le déduit pas. L’obtenir auprès de l’organisation par d’autres moyens.
Ce que vous recevez
Quatre fichiers, chacun avec son hash.
Le SHA-256 de chaque fichier est indiqué, pour que vous puissiez confirmer ce qui vous a été remis.
- Rapport de preuves de changement
sha256:3f9a…c21ePDF - Enregistrements
sha256:[csv hash]CSV · changements fusionnés, changements de contrôles, échantillons - Clé publique de Toevan
sha256:[key hash]toevan.pub · keyid 8c1f…e0a2 - Commande Toevan
sha256:[binary hash]toevan audit verify · fournie par Toevan sur demande, pas encore publique
L’identifiant de clé est celui que Toevan publie sur api.toevan.com/v1/public/evidence/keys et imprime dans chaque rapport.
Les questions des auditeurs
Si un client vous remet des preuves Toevan, ces questions viennent généralement en premier.
Écrivez-nouspilots@toevan.com
Les enregistrements
4 questionsQu’est-ce qu’un enregistrement de preuve Toevan ?
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. Depuis 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 autres types d’enregistrement portent leurs propres prédicats. 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.
Quand un enregistrement est-il écrit, et par qui ?
Au moment de l’événement : à chaque contrôle de code aujourd’hui, et depuis v1.4.0 à chaque fusion de pull request dans la branche par défaut, à 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.
Que signifient les étiquettes de chaque fait ?
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 sont repris des enregistrements de déploiement et de version de GitHub et reliés par commit ou digest ; vérifiez l’enregistrement d’origine dans GitHub. Non capturé signifie qu’aucune source fiable n’existait, et Toevan ne le déduit pas.
Le résultat sur le code est-il déterministe ?
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.
Vérification
4 questionsQuels outils vérifient les preuves ?
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. 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 et pas encore public, 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. 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 de gate signés peuvent aussi être poussés dans les trails Kosli du client.
Comment tester l’exhaustivité, pas seulement l’exactitude ?
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, ce qui est prévu.
Comment sont traités les correctifs copiés vers les branches de release ?
Prévu. 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.
Que révèle le journal de transparence public ?
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.
Périmètre et conservation
4 questionsQue ne signifie pas un rapport propre ?
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.
Quels systèmes de gestion de versions sont pris en charge ?
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.
Où vivent les preuves, et pendant combien de temps ?
Dans le stockage en ajout seul de Toevan, conservé au moins trois ans (5, 7 ou 10 avec Enterprise), 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.
Et si le client cesse d’utiliser Toevan ?
La copie dans le dépôt du client reste en place. Chaque enregistrement signé se vérifie avec openssl standard et la clé publiée, avec les commandes de la branche de preuves, sans logiciel Toevan. La vérification des enregistrements passés ne dépend pas de la poursuite du service par Toevan. Rejouer toute la chaîne demande le vérificateur Toevan, disponible sur demande et pas encore public.
Parcourez avec nous les preuves d’un client.
Si vous auditez un client de Toevan, nous vous guiderons dans la vérification lors d’un appel, avec vos propres outils.
- En visio, avec vos propres outils
- Accès en lecture seule, rien ne change
- Vérifiable sans compte Toevan