Exemple de rapport de preuves de changement

1. Synthèse

Ce qui a été capturé

Toevan a capturé les fusions dans les branches protégées, 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

2. Pé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 de l’enregistrement signé d’un autre système, comme une provenance de build, et relié par commit ou empreinte. Prévu.

Vérifier l’enregistrement d’origine de façon indépendante.

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

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 faits hors de GitHubOrganisationnel
• Changements faits hors de GitHub, comme des modifications directes de la base de données ou de la consoleOrganisationnel

3. Preuve 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.

Écarts : fusionnées sans approbation indépendante

Modifications des contrôles eux-mêmes

Push directs sans pull request

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é

4. Preuve 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).

Jusqu’où l’analyse est allée

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é

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

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

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

6. Enregistrements 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.

Autres enregistrements (exemple)

7. Comment vérifier ce rapport

Vous n’avez pas à faire confiance à Toevan ni à l’organisation. Choisissez la voie qui correspond à votre rôle. Seule la troisième demande des outils.

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, openssl et la commande toevan, que Toevan fournit sur demande. 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.

8. Ajouts prévusPrévu

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

• Branches de production désignées (v1.4.1)

  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.

$ openssl dgst -sha256 -verify toevan.pub \
    -signature sig.der \
    pae.bin
Verified OK

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