Le système de référence des contrôles de changement logiciel
Chaque changement de code et de processus, scellé comme preuve d’audit.
Toevan vérifie le code de chaque pull request, enregistre comment chaque changement a été relu, approuvé et fusionné, et repère chaque modification des règles qui l’entourent. Chaque fait est signé et chaîné comme preuve que votre auditeur vérifie hors ligne avec openssl standard, sans logiciel Toevan ni compte.
- Données traitées dans l’UE
- DPA disponible
- Vérifiable avec Sigstore, in-toto et cosign
Fonctionne avec
- GitHub
- Kosli
- Sigstore
- Slack
- Jira
- Linear
Correspond à
- SOC 2
- ISO/IEC 27001
- PCI DSS v4.0
- NIST 800-53 Moderate
- HIPAA
- GDPR
- DORA
- Vérifie chaque changementBloque la fusion sur une règle enfreinte, avec le fichier et la ligne.
- Enregistre comment il est entréChaque relecture, approbation et fusion, telle qu’elle se produit sur GitHub.
- Repère les changements de contrôlesRègles désactivées, contournements administrateur et pushes directs.
- Le scelle comme preuveSigné et chaîné, pour que votre auditeur le vérifie hors ligne.
Pourquoi maintenant
Les fichiers de règles demandent au modèle de bien se tenir. Toevan vérifie qu’il l’a fait.
Les assistants IA écrivent désormais une grande part du code que fusionnent les équipes réglementées, plus vite que tout processus de relecture n’a été conçu pour l’absorber. Un fichier CLAUDE.md ou .cursorrules est une demande. Un gate de fusion est un contrôle, et l’enregistrement qu’il écrit est la preuve.
Comment ça marche
Un gate, un enregistrement. Toutes les vues qu’un audit demande.
Toevan s’exécute sur chaque pull request, sur main après chaque fusion et sur chaque modification de vos règles de relecture. Ce qu’il décide, il l’enregistre, et ce qu’il enregistre, votre équipe et vos auditeurs peuvent le voir.
§1
Gate
Bloque le changement et dit exactement pourquoi.
Chaque pull request est vérifiée comme un check GitHub par rapport aux blueprints que vous adoptez. Même changement, même règle, même résultat. Aucun modèle ne décide d’un verdict.
- 28 types de contraintes déterministes en conformité, sécurité et architecture
- Commente sur la ligne et publie son verdict comme relecture
- Exceptions demandées depuis la pull request, avec un motif et une échéance
- Correctifs suggérés, validés par la compilation et par le rayon d’impact
§2
Enregistrement
Enregistre comment chaque changement est entré.
Chaque fusion, approbation et modification de vos règles de relecture, capturée depuis GitHub au moment où elle se produit.
- Approbation indépendante sur le commit final et règles en vigueur à la fusion
- Règles de relecture désactivées, contournements administrateur et pushes directs, comme événements
§3
Sceau
Scelle chaque décision comme preuve.
Chaque exécution du gate, fusion et changement de règles écrit un enregistrement signé, en ajout seul, rattaché au commit et à la version du jeu de règles en vigueur.
- Chaîné par hachage et signé, avec ancrage facultatif dans Sigstore Rekor
- Exports CSV et PDF par référentiel, dépôt et période
- Conservé au moins trois ans (5, 7 ou 10 en Enterprise), avec une copie dans votre propre dépôt
Contrôles
Montre l’état des contrôles comme un audit le demande.
Suivez chaque dépôt par rapport aux référentiels sur lesquels vous êtes audité, voyez les exceptions avant qu’elles n’expirent et donnez aux auditeurs externes un rôle en lecture seule. Des vues pour les ingénieurs, l’audit interne et les auditeurs externes.
Taux de contraintes respectées
96.4%27 / 28 règles sans constat ouvert sur mainViolations ouvertes
30 critique · 1 élevée · 2 moyennesExécutions du gate aujourd’hui
1412 réussies · 2 bloquéesEnregistrements de preuve
4,81290 derniers jours · en ajout seul · signés| Dépôt | SOC 2 | DORA | Exceptions ouvertes | Dernière vérification |
|---|---|---|---|---|
| payments-api | 6 prouvés | 1 partiel | 1 | 17aa93d |
| ledger-service | 6 prouvés | 1 partiel | 0 | 91ac03e |
| web-checkout | 1 en échec | 1 partiel | 0 | 4d2e8b1 |
| partner-gateway | 6 prouvés | 1 partiel | 2 | e07f5a2 |
§4
Vérifier
Votre auditeur le vérifie hors ligne, avec openssl standard.
Aucun logiciel Toevan et aucun compte : standards ouverts et outils courants. Trois étapes, et la réponse revient en mots clairs. Si quoi que ce soit dans un enregistrement a été modifié après le scellement, la vérification le dit.
- Obtenir une copie des preuves
Les preuves vivent sur une branche du propre dépôt de votre client, à côté du code qu’elles décrivent. Un simple dossier d’enregistrements.
- Confirmer la clé
Vérifiez que l’empreinte de la clé correspond à l’identifiant de clé que Toevan publie sur api.toevan.com/v1/public/evidence/keys et imprime dans chaque rapport. Une commande l’affiche.
- Vérifier un enregistrement de votre échantillon
Lancez la vérification sur n’importe quel enregistrement. Elle répond à deux questions : l’énoncé signé a-t-il été modifié, et cet enregistrement est-il celui qui a été signé ?
rec_5b81d4eun enregistrement d’un échantillon de 25 · données d’exempleVerified OKL’énoncé est exactement ce qui a été signé avec la clé publiée.
record matches the statementCe fichier d’enregistrement est celui que couvre la signature. Vous pouvez vous fier à ce qu’il dit.
Les lignes qu’imprime le README de la branche de preuves. Elles n’ont besoin que d’openssl et du shell.
- étape 2 : afficher l’empreinte de la clé et la comparer à celle publiée
- étape 3a : reconstruire les octets exacts qui ont été signés (DSSE v1), puis vérifier la signature
- étape 3b : le fichier d’enregistrement est-il celui que nomme l’énoncé signé ?
$ 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>
Pour les auditeurs
Conçu pour l’audit, et honnête sur son périmètre.
Chaque contrôle de chaque référentiel du catalogue, cartographié : où Toevan apporte des preuves de code, où il apporte des preuves de processus, et la part bien plus large qui reste à votre organisation.
Ce que reçoit votre auditeur
- Un rapport par référentiel. Pour toute période et tout dépôt : un PDF pour le dossier, plus un CSV des enregistrements pour les tests.
- La piste de preuves complète. Chaque résultat de code, dérogation, fusion, approbation et changement de règles, chacun rattaché à son commit et à la version du jeu de règles en vigueur.
- Les changements de contrôles au moment où ils se produisent. Règles de relecture désactivées, contournements administrateur et pushes directs, scellés quand ils se produisent.
- Accès en lecture seule. Un rôle Auditeur qui lit les preuves, les exports et les rapports, et ne voit ni dépôts ni code.
- Des instructions qui n’exigent aucun compte. La vérification s’exécute hors ligne avec des outils ouverts, face à une clé publiée.
Comment chaque fait est étiqueté
Chaque fait porte l’une de six étiquettes, pour que votre auditeur sache jusqu’où s’y fier.
Les deux ont été scellées quand elles se sont produites, rien ne tombe donc entre deux instantanés. Recomptez vous-même la population avec git et le CSV de population du rapport.
Intégrations
Complet à lui seul. Connecté quand vous en avez besoin.
Toevan n’a besoin que de vos dépôts GitHub pour contrôler chaque changement, enregistrer comment il est entré, sceller les preuves et donner aux auditeurs ce qu’ils demandent. Gardez Semgrep, Snyk ou CodeQL pour la profondeur.
- Gate de pull requests et exceptions avec échéance
- Preuves scellées par changement et preuves de processus par fusion
- Tableaux de bord d’audit et un badge d’état pour le README
- S’exécute sur vos dépôts GitHub
Tarifs
Commencez gratuitement. Parlez-nous quand l’audit devient réel.
Chaque offre scelle les mêmes preuves et se vérifie de la même façon. Les offres diffèrent par le périmètre, les rapports, les workflows et l’endroit où Toevan s’exécute.
Free
Pour un premier dépôt et un premier aperçu du gate.
- Dépôts : jusqu’à 2 dans une organisation, 1 dans un compte personnel
- Sièges : jusqu’à 3 dans une organisation
- Piste de preuves scellée avec export
- Gate de pull request et canvas d’architecture
- Marketplace officielle de blueprints
- Correctifs IA : 10 chaque mois
Team
RecommandéTarifé par dépôt gouverné et facturé à l’année, pour les organisations de cinq à cent dépôts.
- Dépôts : 5 à 100, tarifé par dépôt gouverné, facturé à l’année
- Sièges : illimités
- Référentiels : tous les référentiels
- Deep Check : sous réserve d’usage raisonnable
- Rôles par dépôt
- Correctifs IA : inclus, sous réserve d’usage raisonnable
- Rapports de conformité en CSV et PDF
- SSO (SAML et OIDC), bientôt disponible
Commencez par un pilote : un dépôt et un référentiel, sur un cycle d’audit.
Enterprise
Plus de cent dépôts, ou des conditions sur mesure.
- Dépôts : plus de 100
- Déploiement self-hosted ou VPC privé, sur demande
- Conservation des preuves : 3, 5, 7 ou 10 ans, au choix
- Support prioritaire
- Conditions de volume
| Fonctionnalité | Free | Team | Enterprise |
|---|---|---|---|
| Preuves | |||
| Piste de preuves scellée avec export | Inclus | Inclus | Inclus |
| Vérification hors ligne avec des outils ouverts | Inclus | Inclus | Inclus |
| Rapports de conformité en CSV et PDF | Non inclus | Inclus | Inclus |
| Journal d’audit | Non inclus | Inclus | Inclus |
| Conservation des preuves | Au moins 3 ans | Au moins 3 ans | 3, 5, 7 ou 10 ans, au choix |
| Gate et contrôles | |||
| Gate de pull request et canvas d’architecture | Inclus | Inclus | Inclus |
| Marketplace officielle de blueprints | Inclus | Inclus | Inclus |
| Référentiels de conformité | Non inclus | tous les référentiels | tous les référentiels |
| Workflows d’exception | Non inclus | Inclus | Inclus |
| Analyse Deep Check avant fusion | Non inclus | sous réserve d’usage raisonnable | sous réserve d’usage raisonnable |
| Échelle et support | |||
| Dépôts | jusqu’à 2 dans une organisation, 1 dans un compte personnel | 5 à 100, tarifé par dépôt gouverné, facturé à l’année | plus de 100 |
| Sièges | jusqu’à 3 dans une organisation | illimités | conditions sur mesure |
| Correctifs IA | 10 chaque mois | inclus, sous réserve d’usage raisonnable | inclus, sous réserve d’usage raisonnable |
| Vos propres clés LLM | Non inclus | Inclus | Inclus |
| Support prioritaire | Non inclus | Non inclus | Inclus |
| Conditions de volume | Non inclus | Non inclus | Inclus |
| Intégrations et sécurité | |||
| Notifications Slack et webhook | Non inclus | Inclus | Inclus |
| Rôles par dépôt | Non inclus | Inclus | Inclus |
| SSO (SAML et OIDC) | Non inclus | Bientôt | Bientôt |
| Déploiement self-hosted ou VPC privé | Non inclus | Non inclus | sur demande |
Il n’y a pas encore de tarif public. Team est tarifé par dépôt gouverné et facturé à l’année, et nous le convenons avec vous.
Les questions qu’on nous pose en premier
Des réponses directes sur le périmètre, le déterminisme et la destination de votre code.
Une question sans réponse ?- Écrivez-nouspilots@toevan.com
- Poser vos questions lors d’un appel pilote de 45 minutesRéserver un appel
- Vous auditez un client de Toevan ?Plus de réponses pour les auditeurs
Périmètre et adéquation
3 questionsFaut-il remplacer Vanta, Kosli ou nos scanners ?
Non. Toevan fonctionne seul pour la couche de code, et aux côtés des outils que vous avez. Gardez vos scanners pour la profondeur ; les contrôles propres à Toevan donnent à chaque changement une base de référence et décident de la fusion selon vos règles. Les verdicts signés arrivent dans Kosli sous forme d’attestations, et les rapports de Toevan se joignent aux contrôles dans Vanta, Drata ou votre propre registre.
Ce que Toevan ajoute, c’est un enregistrement scellé, calculé à partir du changement lui-même : ce que fait chaque changement et, depuis v1.4.0, son chemin du commit à la production, signé au moment des faits et vérifiable hors ligne avec openssl standard.
Un rapport au vert signifie-t-il que nous sommes en conformité ?
Non, et chaque rapport le dit. Toevan apporte des preuves pour les contrôles qui relèvent du code et, depuis v1.4.0, de votre processus de changement. Il ne certifie jamais un contrôle et n’exprime aucun avis sur la conception ou l’efficacité de fonctionnement des contrôles. Les revues d’accès, la réponse aux incidents, les tests de résilience, le risque lié aux tiers et la gouvernance restent à votre processus, et chaque rapport liste exactement ce qu’il ne couvre pas.
Ne prenez-vous en charge que GitHub ?
GitHub aujourd’hui, via une GitHub App avec des check runs et des annotations de pull request. Depuis v1.4.0, il lit aussi les fusions, revues, changements de règles et déploiements en production au fil de l’eau. GitLab et Bitbucket sont sur la feuille de route. Si l’un des deux est votre point bloquant, dites-le-nous et il remonte dans la liste.
Comment ça tourne
3 questionsL’application des règles est-elle vraiment déterministe ?
Oui. Les contraintes des blueprints sont évaluées sur le graphe de dépendances sans modèle dans la boucle : même entrée, même verdict, à chaque exécution. L’IA sert à suggérer des correctifs et à expliquer les violations, jamais à décider si le code respecte les règles.
Notre code sort-il de notre périmètre ?
L’analyse, l’évaluation des blueprints, le gate de pull request et la signature des preuves s’exécutent sur l’infrastructure UE de Toevan, et votre code source n’en sort pas. Les contrôles de dépendances envoient des noms et des versions de paquets, sauf ceux que Toevan identifie comme privés, à des services publics comme OSV.dev. Les fonctions IA facultatives peuvent envoyer un contexte dérivé du code à un fournisseur de l’UE ou à votre propre clé de fournisseur. L’ancrage Rekor, intégré et sur adhésion de chaque organisation, ne publie que des hachages d’enregistrements. L’auto-hébergement est disponible sur demande. La déclaration complète figure sur la page Sécurité.
Que se passe-t-il quand le gate se trompe ?
Vous demandez une exception avec une justification, un périmètre et une durée. Le bon responsable la revoit, elle expire à l’échéance, et l’exception elle-même devient une preuve.
Apportez un dépôt et votre prochain audit.
Les pilotes démarrent au T1 2027 avec un petit groupe de design partners : des équipes réglementées qui livrent du code assisté par IA, de la Series B aux grands groupes. Le premier cycle d’audit fait la preuve.
- Un dépôt, un référentiel
- Des preuves dès la première pull request
- Vérifiable sans compte Toevan