Aller au contenu
Ouvrir le menuFermer le menu

Exemple de rapport

Exemple de rapport de preuves de changement

Ce que reçoit votre auditeur pour deux dépôts et un trimestre : comment chaque changement fusionné est entré et ce qu’il fait, chaque fait étant étiqueté selon la façon dont il a été obtenu.

Organisation et données fictives, à titre d’illustration uniquement.

Le contenu de cet exemple est affiché en français. Le rapport que génère Toevan est en anglais là où il cite la sortie du produit.

ActifLa preuve issue du code est active dès aujourd’hui. Les enregistrements de changement et la preuve de processus sont actifs depuis v1.4.0. La dernière section présente des couches ultérieures, marquées Prévu.

Organisation et données fictives, à titre d’illustration uniquement.

toevan

Rapport de preuves de changement

Changements fusionnés

Northwind (données d’exemple) · 2 dépôts · branche par défaut · 15 juil. au 13 oct. 2026

Préparé pour
[Cabinet d’audit]
Dépôts
northwind/payments-api · northwind/ledger-service
Changements dans le périmètre
146 pull requests fusionnées dans la branche par défaut, chacune avec un enregistrement de changement scellé, et 2 push directs, capturés depuis GitHub au fil de l’eau.
Enregistrements
4 152 enregistrements scellés : enregistrements de changement, événements de changement de contrôles et contrôles de code. Signatures vérifiées à la génération.
Moteur et jeux de règles
toevan-engine 0.9.4 · Clean Architecture 1.4.0 · Security Essentials 2.14.0
Personnes
Représentées par des empreintes de leurs comptes GitHub dans les enregistrements scellés. Les dérogations nomment leur demandeur et leur approbateur.
Généré
13 oct. 2026, 11:42 UTC par [nom]
Empreinte du rapport
sha256:3f9a…c21e

Ce rapport est une preuve que l’auditeur doit apprécier. Toevan n’exprime aucun avis sur la conception ou l’efficacité de fonctionnement des contrôles. Chaque fait indique comment il a été obtenu. Les contrôles hors du périmètre de Toevan sont listés dans la section de périmètre et restent de la responsabilité de l’organisation.

1Synthèse

Preuve de processus · comment les changements sont entrés

Pull requests fusionnées146dans la branche par défaut
Approbation indépendante143 / 1463 écarts
Push directs2sans pull request, signalés
Changements de contrôles31 a ouvert un trou de 29 minutes

Preuve issue du code · ce que font les changements

Pull requests contrôlées146 / 146verdict du gate avant fusion
Règles de code respectées11 / 12code de production, dernière release
Couverture de l’analyse97,4 %gate 95 % · 0 exécution en dessous
Dérogations approuvées10 expirée sur la période

Ce qui a été capturé

Toevan a capturé les fusions dans la branche par défaut, les modifications des règles de revue, les contournements et les push directs des deux dépôts tels que GitHub les a rapportés, et a scellé chacun au moment des faits. Sur la période, 146 pull requests ont été fusionnées et 2 commits ont été poussés directement. Rapporté + scellé

Points d’attention

  1. Deux push directs vers payments-api/release/v1 le 19 sept., dans une fenêtre de 29 minutes pendant laquelle l’exigence de revue était désactivée.Processus
  2. Trois pull requests fusionnées sans approbation par une autre personne que l’auteur : deux dans ledger-service avant l’existence de sa règle de revue, une par contournement d’administrateur pendant la fenêtre du 19 sept.Processus
  3. La règle secret-detection-high échoue sur le code de production (1 constat), couverte par une dérogation approuvée jusqu’au 20 déc.Code, Dérogations

2Périmètre, provenance et correspondance avec les contrôles

Comment chaque fait a été obtenu

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.

Les preuves et les contrôles auxquels elles se rapportent

PreuveContrôles concernésObtenu
Approbation, revue indépendante, approbation sur le dernier commitSOC 2 CC8.1 · ISO 27001 A.8.32 · DORA RTS 2024/1774 Art. 17 (prévu)Rapporté + scelléRecalculé
Checks requis à la fusion ; règles de revue en vigueur ; changements de règles et contournementsSOC 2 CC8.1 · ISO 27001 A.8.32 · DORA RTS 2024/1774 Art. 17 (prévu)Rapporté + scellé
Push directs vers les branches protégéesSOC 2 CC8.1 · ISO 27001 A.8.4, A.8.32Rapporté + scellé
Règles de code : frontières d’architecture, codage sécurisé, dépendancesISO 27001 A.8.25 · SOC 2 CC8.1Recalculé
Population des changements et exhaustivitéSOC 2 CC8.1 · ISO 27001 A.8.32Recalculé
Déploiement d’un commit en productionSOC 2 CC8.1 · ISO 27001 A.8.32ConsomméNon capturé
Dérogations et changements de périmètreExceptions aux règles ci-dessusEnregistrement Toevan, non scellé

Non couvert par ce rapport

  • Revues d’accès, processus d’arrivée et de départOrganisationnel
  • Surveillance en production, réponse aux incidentsOrganisationnel
  • Risque lié aux tiers TIC, sécurité physiqueOrganisationnel
  • Déploiements et artefacts hors de GitHub, et si un artefact déployé tourne encoreOrganisationnel
  • Fusions dans des branches autres que la branche par défautPas dans cette version
  • Changements faits hors de GitHub, comme des modifications directes de la base de données ou de la consoleOrganisationnel

3Preuve de processus

Comment les 146 pull requests fusionnées sur la période ont été revues et fusionnées, capturé depuis GitHub au moment de chaque fusion.

ContrôleRésultatObtenu
Approuvé par une autre personne que l’auteur143 / 146 · 3 écartsRecalculé
Approbation donnée sur le dernier commit137 / 143 approuvées · 6 approuvées sur un commit antérieurRapporté + scellé
Checks requis réussis à la fusion146 / 146Rapporté + scellé
Signatures de commit vérifiées par GitHub144 / 146Rapporté + scellé
Règles de revue en vigueur enregistrées à la fusion146 / 146Rapporté + scellé

Écarts : fusionnées sans approbation indépendante

PRFusionnéeAuteurRègle en vigueur à la fusionEnregistrement
ledger-service #38824 juil.4be1…09c2Aucune (règle ajoutée le 02 août)rec_51b9e20
ledger-service #39129 juil.c58f…71d0Aucune (règle ajoutée le 02 août)rec_6e07a3d
payments-api #190319 sept. 14:122a6e…f915Désactivée de 14:02 à 14:31 (admin)rec_0c88f14

Modifications des contrôles eux-mêmes

Quand (UTC)ChangementParEnregistrement
02 août 09:14Règle de revue appliquée à ledger-service : 2 approbations, checks requis9d07…e3a4rec_8a2f61c
19 sept. 14:02Exigence de revue désactivée sur payments-api/release/*2a6e…f915rec_3f10b9a
19 sept. 14:31Exigence de revue réactivée2a6e…f915rec_3f10c02

Push directs sans pull request

Quand (UTC)BrancheCommitParEnregistrement
19 sept. 14:09payments-api/release/v17c1e0a22a6e…f915rec_7c1e0a2
19 sept. 14:22payments-api/release/v191d4b3f2a6e…f915rec_91d4b3f

Les changements de contrôles et les push directs sont capturés comme événements au moment où ils se produisent, pour qu’un trou entre deux instantanés ne passe pas inaperçu. Les personnes sont représentées par des empreintes de leurs comptes GitHub ; l’indépendance est calculée à partir des identifiants de compte. Rapporté + scellé

Population des changements

Chaque commit arrivé sur la branche par défaut pendant la période, listé depuis l’historique git et rapproché d’un enregistrement. Recalculé

Déploiements liés par commit

Quel commit est arrivé en production, et quand. Toevan le lit dans GitHub ; il ne le produit pas. Là où GitHub ne détient aucun enregistrement de déploiement, le lien est signalé comme non capturé, jamais déduit de la chronologie. ConsomméNon capturé

4Preuve issue du code

Ce que fait le code, vérifié en lisant le code lui-même sur la version exacte fusionnée. Les règles marquées en échec s’appliquent au code de production ; la documentation et les fixtures de test sont hors périmètre (voir Dérogations).

Clean Architecture 1.4.0 · règles de conception

RègleCe qu’elle vérifieDernière releaseConstats
layer-dependency-handlers-to-dbLes handlers de requêtes n’appellent jamais directement la base de donnéesRespectée0
service-boundariesLes services ne se joignent que par leurs interfaces publiquesRespectée0
role-placement-policyLes abstractions et leurs implémentations se trouvent dans les couches que l’architecture leur attribueRespectée0
layer-dependency-policyUne dépendance entre couches n’est permise que si la politique la listeRespectée0

Security Essentials 2.14.0 · codage sécurisé

RègleCe qu’elle vérifieDernière releaseConstats
secret-detection-highAucun identifiant à forte confiance codé en dur dans le source ou la configurationEn échec1 · dérogation
no-committed-secret-filesAucun .env, clé privée ou keystore versionnéRespectée0
vulnerable-dependencyAucune dépendance avec une vulnérabilité élevée ou critique connue (OSV.dev)Respectée0
encryption-at-restStockage et connexions aux bases de données chiffrésRespectée0
iac-network-segmentationAucune exposition publique de services internesRespectée0
iac-encryption-policyOptions de chiffrement du stockage activées dans le code d’infrastructureRespectée0
iac-access-controlAucune politique d’accès avec caractère génériqueRespectée0
sensitive-unsafe-log-flowLes données sensibles n’atteignent aucune destination de journalisationRespectée0

Jusqu’où l’analyse est allée

DépôtCouverture sur la dernière releaseGateExécutions sous le gate sur la période
payments-api97,9 %95 %0
ledger-service96,6 %95 %0

La couverture est la part des fichiers source de production du dépôt que l’index de code a analysés au commit indexé. Sous le gate, une exécution est signalée au lieu d’être enregistrée comme réussie. Les versions du moteur et du jeu de règles sont consignées dans chaque enregistrement, donc tout résultat peut être rejoué. Recalculé

5Dérogations et changements de périmètre

Chaque décision qui a modifié ce qui était vérifié, ou accepté un écart connu.

DateChangementDemandé par · approuvé parMotifEnregistrement
20 sept.Dérogation : secret-detection-high, payments-api/config/sandbox.yaml (fichier exact), expire le 20 déc.c58f…71d0 · 4be1…09c2Clé de sandbox sans accès à la production ; rotation planifiéerec_b30e7c5

Aucune dérogation n’a expiré ni été révoquée sur la période. Le demandeur et l’approbateur sont des comptes différents pour chaque entrée. Les dérogations sont des enregistrements de Toevan non scellés dans le registre. Enregistrement Toevan, non scellé

Versions des jeux de règles utilisées sur la période

Jeu de règlesVersionÀ partir duChangement
Clean Architecture1.4.015 juil. (toute la période)Aucun changement
Security Essentials2.13.015 juil.Aucun changement
Security Essentials2.14.012 aoûtRègles mises à jour par Toevan

6Enregistrements de changement

Un changement en entier, tel que l’auditeur le voit en échantillonnant. Tous les enregistrements figurent dans l’export CSV, et chaque enveloppe signée se trouve sur la branche de preuves du dépôt de l’organisation.

rec_5b81d4e

Le changement

Pull request
payments-api #1921 · Add tenant check to refund handler
Rapporté + scellé
Auteur · fusionné par
4be1…09c2 · 9d07…e3a4 · 13 oct. 2026, 10:41 UTC dans main
Rapporté + scellé
Commit de fusion
5b81d4e
Rapporté + scellé

Preuve de processus

Approbations
9d07…e3a4, c58f…71d0 · toutes deux sur le dernier commit e81b2d0
Rapporté + scellé
Indépendant de l’auteur
Oui, par identifiant de compte GitHub
Recalculé
Checks requis
ci/test ✓ · ci/lint ✓ · toevan/gate ✓
Rapporté + scellé
Règles en vigueur
main-protection : 2 approbations, checks requis, commits signés
Rapporté + scellé
Signature du commit
Vérifiée par GitHub
Rapporté + scellé

Preuve issue du code

Règles de conception
4 / 4 respectées
Recalculé
Codage sécurisé
7 / 8 respectées · secret-detection-high sous dérogation rec_b30e7c5
Recalculé
Couverture · moteur
98,1 % (gate 95 %) · toevan-engine 0.9.4
Recalculé

Chemin vers la production

Publié
Release v2.31.0 · 13 oct. 2026, 11:05 UTC
Rapporté + scellé
Déployé
production · 13 oct. 2026, 11:20 UTC · empreinte du build sha256:7d3e…a1c4 · rec_9e41b07
Consommé
Copié vers la release
Non capturé : le lien de backport (L5) n’est pas intégré dans cette version
Non capturé

Sceau

Signature
ECDSA P-256 · enveloppe DSSE · keyid 8c1f…e0a2
Enregistrement précédent
rec_b7e21f0
Ancrage public
Ancrage Rekor facultatif · désactivé pour cette organisation

Autres enregistrements (exemple)

EnregistrementChangementApprobation indépendanteRègles de codeScellé (UTC)
rec_b7e21f0payments-api #1918Oui11 / 12 · dérogation13 oct. 09:58
rec_9d41e02ledger-service #412Oui12 / 1209 oct. 16:21
rec_0c88f14payments-api #1903Non · contournement admin12 / 1219 sept. 14:12
rec_7c1e0a2push direct 7c1e0a2Non · sans PR12 / 1219 sept. 14:09

7Comment vérifier ce rapport

Chaque voie vous permet de tester vous-même les preuves. Choisissez la voie qui correspond à votre rôle. Seule la troisième demande des outils.

VérificationCe qu’elle prouveCe qu’elle ne prouve pas
L’enregistrement est authentique et inchangéL’enregistrement a été signé avec la clé publiée de Toevan et n’a pas été modifié depuis. La chaîne de hachage montre qu’aucun n’a été retiré.Que les faits qu’il contient sont exacts : les deux vérifications suivantes s’en chargent.
L’approbation était indépendanteL’approbateur et l’auteur sont des comptes GitHub différents, recalculé à partir des identifiants de compte de l’enregistrement.Que la revue elle-même était suffisante.
Le résultat sur le code est reproductibleLe même commit, la même version du moteur et la même version du jeu de règles donnent le même résultat.Que les règles couvrent tous les risques du code.
  1. Dans l’application de l’organisation

    Accès auditeur en lecture seule, aucun accès au dépôt

    • L’organisation vous invite avec le rôle Auditeur : accès en lecture seule à la liste des preuves, aux exports et aux rapports.
    • Vérifier maintenant contrôle à nouveau tout le registre, les signatures et les éventuelles preuves du journal de transparence dans l’application.
    • Vous n’ouvrez rien d’autre : dépôts, code et constats sont refusés.
  2. Regardez l’organisation l’exécuter

    Partage d’écran ou sur site

    • Vous choisissez les échantillons pendant la séance ; un ingénieur exécute les vérifications sous vos yeux.
    • Vérification de chaque enregistrement échantillonné : chaîne, signature, inchangé.
    • Comptes de l’auteur et de l’approbateur pour chaque échantillon, comparés à l’écran.
  3. Exécutez-le vous-même

    Spécialistes de l’audit informatique avec accès en lecture temporaire

    • Utilisez git et openssl. Pour toute la chaîne, utilisez la commande toevan, que Toevan fournit sur demande et qui n’est pas encore publique. Aucun compte Toevan n’est nécessaire.
    • Vérifiez que les têtes de branche d’une copie correspondent à celles consignées dans le rapport.
    • Exécutez les commandes de l’annexe et comparez avec le rapport.

8Ajouts prévusPrévu

Couches ultérieures de la chaîne de preuves. Elles sont prévues et rien dans ce rapport n’en dépend. Chacune indique comment ses faits seront obtenus.

  • Branches de production désignées

    Les branches que l’organisation désigne comme production, comme une branche de release, chaque désignation déclarée et scellée avec chaque changement ultérieur. Chacune reçoit la même population que la branche par défaut : chaque commit listé directement depuis git et rapproché d’un enregistrement ou signalé.

    Déclaré + scelléRecalculé
  • Correctifs copiés rapprochés par contenu

    Un correctif revu sur main puis copié vers une branche de release reçoit un nouvel identifiant de commit. Toevan le rapprochera de l’original revu par son contenu (git patch-id) et signalera les copies dont le contenu a changé.

    Recalculé

Annexe · Commandes pour les relecteurs techniques

Les commandes qu’un ingénieur exécute pour vous, ou que vous exécutez vous-même.

Vérifier un enregistrement avec openssl et le shell, sans logiciel Toevan

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
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
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
printf 'record %s\n' "$(sed -nE 's/.*"record_id":"([^"]*)".*/\1/p' statement.json)"
printf 'subject %s\n' "$(sed -nE 's/.*"subject":\[\{"digest":\{"([^"]*)":"([^"]*)"\},"name":"([^"]*)"\}\].*/\3 \1:\2/p' statement.json)"

SHA2-256(stdin)= <key id>
Verified OK
record matches the statement
record <the record id you picked>
subject git+https://github.com/<owner>/<repository> gitCommit:<the commit you picked>

L’enveloppe tient sur une ligne de JSON, telle que Toevan l’écrit ; les trois chemins sont ceux de la branche de preuves. La première ligne après les chemins affiche l’identifiant de la clé, à comparer à la liste publiée. Attendez-vous à « Verified OK » et « record matches the statement » pour chaque enregistrement que vous vérifiez. Les deux dernières lignes doivent nommer l’enregistrement et le commit que vous avez choisis. Tout échec signifie que l’enregistrement a été altéré ou n’a pas été signé avec la clé publiée.

Rejouer toute la chaîne avec le vérificateur Toevan (sur demande, pas encore public)

$ toevan audit verify --path evidence-clone --pub-key toevan.pub
✓ chain intact · 4,152 records
✓ signatures verify under the published key

Cette commande demande le vérificateur Toevan, que Toevan fournit sur demande. Elle ne fait pas partie de la voie openssl ci-dessus.