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
Preuve issue du code · ce que font les changements
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
- 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
- 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
- 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
| Preuve | Contrôles concernés | Obtenu |
|---|---|---|
| Approbation, revue indépendante, approbation sur le dernier commit | SOC 2 CC8.1 · ISO 27001 A.8.32 · DORA RTS 2024/1774 Art. 17 (prévu) | |
| Checks requis à la fusion ; règles de revue en vigueur ; changements de règles et contournements | SOC 2 CC8.1 · ISO 27001 A.8.32 · DORA RTS 2024/1774 Art. 17 (prévu) | |
| Push directs vers les branches protégées | SOC 2 CC8.1 · ISO 27001 A.8.4, A.8.32 | |
| Règles de code : frontières d’architecture, codage sécurisé, dépendances | ISO 27001 A.8.25 · SOC 2 CC8.1 | |
| Population des changements et exhaustivité | SOC 2 CC8.1 · ISO 27001 A.8.32 | |
| Déploiement d’un commit en production | SOC 2 CC8.1 · ISO 27001 A.8.32 | |
| Dérogations et changements de périmètre | Exceptions aux règles ci-dessus |
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ôle | Résultat | Obtenu |
|---|---|---|
| Approuvé par une autre personne que l’auteur | 143 / 146 · 3 écarts | |
| Approbation donnée sur le dernier commit | 137 / 143 approuvées · 6 approuvées sur un commit antérieur | |
| Checks requis réussis à la fusion | 146 / 146 | |
| Signatures de commit vérifiées par GitHub | 144 / 146 | |
| Règles de revue en vigueur enregistrées à la fusion | 146 / 146 |
Écarts : fusionnées sans approbation indépendante
| PR | Fusionnée | Auteur | Règle en vigueur à la fusion | Enregistrement |
|---|---|---|---|---|
| ledger-service #388 | 24 juil. | 4be1…09c2 | Aucune (règle ajoutée le 02 août) | rec_51b9e20 |
| ledger-service #391 | 29 juil. | c58f…71d0 | Aucune (règle ajoutée le 02 août) | rec_6e07a3d |
| payments-api #1903 | 19 sept. 14:12 | 2a6e…f915 | Désactivée de 14:02 à 14:31 (admin) | rec_0c88f14 |
Modifications des contrôles eux-mêmes
| Quand (UTC) | Changement | Par | Enregistrement |
|---|---|---|---|
| 02 août 09:14 | Règle de revue appliquée à ledger-service : 2 approbations, checks requis | 9d07…e3a4 | rec_8a2f61c |
| 19 sept. 14:02 | Exigence de revue désactivée sur payments-api/release/* | 2a6e…f915 | rec_3f10b9a |
| 19 sept. 14:31 | Exigence de revue réactivée | 2a6e…f915 | rec_3f10c02 |
Push directs sans pull request
| Quand (UTC) | Branche | Commit | Par | Enregistrement |
|---|---|---|---|---|
| 19 sept. 14:09 | payments-api/release/v1 | 7c1e0a2 | 2a6e…f915 | rec_7c1e0a2 |
| 19 sept. 14:22 | payments-api/release/v1 | 91d4b3f | 2a6e…f915 | rec_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.
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.
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ègle | Ce qu’elle vérifie | Dernière release | Constats |
|---|---|---|---|
| layer-dependency-handlers-to-db | Les handlers de requêtes n’appellent jamais directement la base de données | Respectée | 0 |
| service-boundaries | Les services ne se joignent que par leurs interfaces publiques | Respectée | 0 |
| role-placement-policy | Les abstractions et leurs implémentations se trouvent dans les couches que l’architecture leur attribue | Respectée | 0 |
| layer-dependency-policy | Une dépendance entre couches n’est permise que si la politique la liste | Respectée | 0 |
Security Essentials 2.14.0 · codage sécurisé
| Règle | Ce qu’elle vérifie | Dernière release | Constats |
|---|---|---|---|
| secret-detection-high | Aucun identifiant à forte confiance codé en dur dans le source ou la configuration | En échec | 1 · dérogation |
| no-committed-secret-files | Aucun .env, clé privée ou keystore versionné | Respectée | 0 |
| vulnerable-dependency | Aucune dépendance avec une vulnérabilité élevée ou critique connue (OSV.dev) | Respectée | 0 |
| encryption-at-rest | Stockage et connexions aux bases de données chiffrés | Respectée | 0 |
| iac-network-segmentation | Aucune exposition publique de services internes | Respectée | 0 |
| iac-encryption-policy | Options de chiffrement du stockage activées dans le code d’infrastructure | Respectée | 0 |
| iac-access-control | Aucune politique d’accès avec caractère générique | Respectée | 0 |
| sensitive-unsafe-log-flow | Les données sensibles n’atteignent aucune destination de journalisation | Respectée | 0 |
Jusqu’où l’analyse est allée
| Dépôt | Couverture sur la dernière release | Gate | Exécutions sous le gate sur la période |
|---|---|---|---|
| payments-api | 97,9 % | 95 % | 0 |
| ledger-service | 96,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.
| Date | Changement | Demandé par · approuvé par | Motif | Enregistrement |
|---|---|---|---|---|
| 20 sept. | Dérogation : secret-detection-high, payments-api/config/sandbox.yaml (fichier exact), expire le 20 déc. | c58f…71d0 · 4be1…09c2 | Clé de sandbox sans accès à la production ; rotation planifiée | rec_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ègles | Version | À partir du | Changement |
|---|---|---|---|
| Clean Architecture | 1.4.0 | 15 juil. (toute la période) | Aucun changement |
| Security Essentials | 2.13.0 | 15 juil. | Aucun changement |
| Security Essentials | 2.14.0 | 12 août | Rè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_5b81d4eLe 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)
| Enregistrement | Changement | Approbation indépendante | Règles de code | Scellé (UTC) |
|---|---|---|---|---|
| rec_b7e21f0 | payments-api #1918 | Oui | 11 / 12 · dérogation | 13 oct. 09:58 |
| rec_9d41e02 | ledger-service #412 | Oui | 12 / 12 | 09 oct. 16:21 |
| rec_0c88f14 | payments-api #1903 | Non · contournement admin | 12 / 12 | 19 sept. 14:12 |
| rec_7c1e0a2 | push direct 7c1e0a2 | Non · sans PR | 12 / 12 | 19 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érification | Ce qu’elle prouve | Ce 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épendante | L’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 reproductible | Le 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. |
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.
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.
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é.
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é.
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 keyCette commande demande le vérificateur Toevan, que Toevan fournit sur demande. Elle ne fait pas partie de la voie openssl ci-dessus.