Axe 4 : Techniques

OSCAL - Open Security Controls Assessment Language

OSCAL transforme la documentation de conformité de Word/Excel en formats JSON/YAML lisibles par la machine, avec quatre couches :

Catalogs - Définitions de contrôles (NIST 800-53, ISO 27001, BSI IT-Grundschutz)
Profiles - Baselines spécifiques à l'organisation
Implementation Layer - System Security Plans, Component Definitions
Assessment Layer - Assessment Results, POA&M

Le BSI documente officiellement : « OSCAL est compatible avec les normes internationales ». Le GCBoK définit les taxonomies de conformité allemandes (GoBD, BSI, RGPD) comme catalogues OSCAL - cela n'existe pas encore sur le marché.

OPA / Rego - Policy as Code

Open Policy Agent avec le langage Rego. Les règles de conformité sont implémentées sous forme de code, qui est vérifié automatiquement par rapport au Git-State.

VPRM - Verifiable Process Reward Model

Dans le contexte du GCBoK, OPA/Rego fonctionne comme VPRM : les garde-fous pour les agents IA sont créés par un jeu de règles déterministe, et non par du prompt engineering. Ainsi, les agents IA ne sont pas sécurisés par des contraintes de prompt, mais par la validation de code.

Signature GPG

Chaque commit Git pertinent pour la conformité est signé avec GPG. La signature lie :

Identité (GPG-Fingerprint = acteur)
Contenu (Commit-Hash = données)
Moment (Commit-Timestamp = quand)

À partir des métadonnées .v7g.md, les GPG-Fingerprints sont liés aux V7GUIDs - les identités restent à l'épreuve de la falsification même si un agent IA manipule la structure sémantique.

Architecture de keyring GPG pour la traçabilité forensique

Pour que les signatures GPG restent vérifiables à long terme — même des années après leur création, après expiration ou révocation de la clé, et lors d'une reconstruction à partir d'archives git bundle/ZIP — les clés publiques doivent faire partie du dépôt. Le GCBoK définit à cet effet un modèle de keyring dans le dépôt :

Structure : `.gitcover/keys/`

.gitcover/
├── keys/
│   ├── team-lead.asc          # Öffentliche Schlüssel von Team-Leads
│   ├── service-accounts/      # CI/CD, Bots, Automation
│   └── identities/            # Personenbezogene Schlüssel (nur PII-Repos)
│       ├── person-a.asc
│       └── person-a_governikus.pdf  # Identitätsnachweis pgp.governikus.de
├── trusted-keys.gpg           # Gesammelter Keyring (optional, für Verifier)
└── compliance/                # GoBD/DSGVO-Dokumente

Modèle à deux niveaux : TOP-Repo vs. PII-Repo

Niveau	Dépôt	Contenu	Pertinence RGPD
Organisationnel	TOP-Repo (Tenant Organizational Platform)	Clés des Team-Leads, Service-Accounts, bots CI/CD, ancre de confiance `trusted-keys.gpg`	Aucune donnée à caractère personnel — conforme au RGPD
Personnel	PII-Repo (Personal Identifiable Information)	Clés des développeurs, justificatifs d'identité (confirmations Governikus), GPG-Fingerprints personnels	PII — accès uniquement via les Org-Unit-Claims (voir ci-dessous)

Cette séparation reflète les deux niveaux de responsabilité en matière de PII :

Juridique — niveau Tenant (entité juridique, p. ex. GCC, GCD, CFP)
Organisationnel — PMO/Divisions/Departments/Locations (≈ AD Organizational Unit)

Vérification isolée du keyring local

Un vérificateur (ou un auditeur 10 ans plus tard) vérifie sans dépendre du keyring GPG local :

# Nur Repository-Schlüssel nutzen, lokalen Keyring ignorieren
gpg --no-default-keyring --keyring .gitcover/keys/team-lead.asc \
    --verify-commit <commit-hash>

--no-default-keyring : ignore ~/.gnupg/
--keyring : utilise exclusivement la clé du dépôt
La clé publique se trouvait au moment du commit dans le dépôt → caractère probant reconstituable de manière forensique

Validité temporelle et cycle de vie des clés

La question « La signature était-elle valide au moment du commit ? » trouve sa réponse dans l'intégration au dépôt :

La clé publique est présente dans l'historique Git du commit
Même si la clé est aujourd'hui expirée ou révoquée : le commit prouve que la clé était alors digne de confiance
git bundle transporte les dépôts clés et justificatifs inclus → unité forensique portable, indépendante de toute infrastructure vivante

Pertinence pour la documentation des procédures GoBD et NIS2

GoBD (§ 146 AO, documentation des procédures) : l'architecture de keyring fait partie intégrante de la documentation des procédures — elle décrit comment les justificatifs d'identité sont générés, archivés et vérifiés de manière à satisfaire aux exigences d'audit. Le modèle « clé dans le dépôt » répond aux exigences GoBD en matière de vérifiabilité et d'inaltérabilité de la liaison d'identité.
NIS2 (droits d'accès, Art. 21) : la séparation TOP/PII-Repo et le contrôle d'accès basé sur les Org-Units (via les claims OIDC tenant_id + Org-Unit-Claim) mettent en œuvre le principe du moindre privilège. Seuls les rôles autorisés (via l'Org-Unit-Claim) obtiennent l'accès aux PII-Repos et donc aux clés personnelles.

Voir aussi : La série d'articles « Instructions de procédure GoBD pour Git » dans le GCBoK (Module 3 : Intégrité cryptographique, Module 4 : Signatures & authenticité) approfondit ces thèmes. Le projet de recherche GitCover.IdP (BSFZ 288-335-338/2026-1) étudie l'intégration IdP.

uuidV7 - UUID Version 7

UUID Version 7 compatible RFC-4122 : basée sur le temps, triable, résistante aux collisions. L'extension spécifique à GitCover par des identifiants de classe de 14 bits transforme les UUIDs en V7GUIDs (voir Concepts).

Git comme IdP - Identity Provider

Des dépôts Git basés sur Gitea en tant que Single Source of Truth (SSoT) pour un système intégré de gestion des identités et des accès (IAM). Le projet de recherche reconnu par le BSFZ étudie si les organisations/équipes Git peuvent représenter des OAuth2-Clients et des permissions et gérer plus de 1 000 utilisateurs de manière performante.

Responsabilité à deux niveaux pour les PII (Juridique + Organisationnel)

Les données à caractère personnel (PII) sont soumises, dans le stack GitCover, à une double responsabilité qui se reflète dans l'architecture des dépôts et dans les claims OIDC :

Niveau	Périmètre	Type de dépôt	Claim OIDC	Exemple
1. Juridique	Tenant (entité juridique)	TOP-Repo + PII-Repo	`tenant_id` (basé sur V7GUID)	`GCC`, `GCD`, `CFP`, `ADA`
2. Organisationnel	PMO / Division / Department / Location	PII-Repo (à granularité fine)	`org_unit_id` (≈ AD Organizational Unit)	`GCC-Portfolio`, `GCD-IT`, `CFP-Sales`

Juridique (niveau Tenant) : l'entité juridique est le responsable du traitement au sens de la protection des données (Art. 4 Nr. 7 DSGVO). La tenant_id est dérivée de manière déterministe de la V7GUID du répertoire TOP (voir [Concepts : Registre central des Tenants](v7guid-beleg-ketten-und-cryptographic-evidence.html #zentrales-tenant-register)).
Organisationnel (PMO/Org-Unit) : au sein d'un Tenant, plusieurs unités d'organisation (PMOs, départements, sites) peuvent être responsables de manière autonome de sous-ensembles de PII. Cela correspond à la structure des Active-Directory-Organizational-Units. L'association s'effectue via le Custom Claim org_unit_id, qui est mappé dans le fichier others.json du Tenant sur des chemins de dépôts.

Hiérarchie des claims dans le pipeline Inlet

Le pipeline Inlet (voir Démarches : Isolation des Tenants lit le fichier others.json selon le User-Claim et injecte les chemins autorisés :

{
  "tenant_id": "0197a3b2-f3c0-7b00-8001-000000000042",
  "org_unit_id": "ORG-1-Portfolio",
  "allowed_repos": [
    "TOP",
    "PII/ORG-1-Portfolio"
  ]
}

Ainsi, un utilisateur avec org_unit_id = ORG-1-Portfolio obtient l'accès au PII-Repo du portfolio, mais pas à PII/ORG-2-IT — même avec le même tenant_id.

Voir aussi : Le projet de recherche sur GitCover.IdP est décrit dans Projets de recherche. L'architecture de keyring (TOP vs. PII) est décrite ci-dessus sous « Architecture de keyring GPG ».