Axe 4 : Techniques

OSCAL - Open Security Controls Assessment Language

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

1. Catalogs - Définitions de contrôles (NIST 800-53, ISO 27001, BSI IT-Grundschutz)
2. Profiles - baselines spécifiques à l'organisation
3. Implementation Layer - System Security Plans, Component Definitions
4. 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, DSGVO) comme catalogues OSCAL — cela n'existe pas encore sur le marché.

Les catalogues OSCAL et les règles OPA font partie de la couche sémantique lisible par machine de l'ontologie GitCover : ils décrivent, dans la même langue que les dictionnaires L1–L6, quelles exigences s'appliquent et comment elles sont vérifiées (voir Concepts : Hiérarchie métier comme ontologie et Glossaire : Ontologie).

Les GCPN-Events/Flags (cycle de vie des signatures et des opérations) sont dérivés de ces catalogues OSCAL (ao-buchfuehrung, gobd, ustg-rechnung, bmf-erechnung). La collection immuable GCPN-EVENTS-FLAGS porte l'ancrage de gouvernance (AO §146, GoBD Rz. 146/147) et est référencée dans le GCPN via events.enum_ref.

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 automatiquement vérifié par rapport à l'état Git.

VPRM - Verifiable Process Reward Model

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

Signature GPG

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

• Identité (empreinte GPG = acteur)
• Contenu (hash du commit = données)
• Moment (timestamp du commit = quand)

À partir des métadonnées .gc.md, les empreintes GPG sont liées aux V7GUID — les identités restent infalsifiables même lorsqu'un agent IA manipule la structure sémantique.

GCSIG — la signature comme artefact versionné

L'historique Git seul ne suffit pas comme preuve de signature : un force-push peut le réécrire. C'est pourquoi chaque signature pertinente de code/commit Git (GPG, signed commit, PR) est en outre déposée comme artefact immuable {name}.gcsig.md (schéma gcsig-1.4). Celui-ci lie :

• Objet (SHA du commit/arbre/tag/PR)
• Signature GPG + empreinte du signataire + statut de vérification
• Phases sous forme de drapeaux 32 bits (draft, presented, accepted, signed, denied, withdrawn, revoked, expired, superseded, verified)

Ainsi, la signature de commit devient versionnée par Git et résistante à la réécriture d'historique ; un GCPN ultérieur référence le GCSIG via parents[]/children[] (GCSIG:{docUid}). Génération : gc-docsign gcsig <repo> --commit <sha>.

Architecture de trousseau 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 de git bundle/archives ZIP — les clés publiques doivent faire partie du dépôt. Le GCBoK définit pour cela un modèle de trousseau 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 : dépôt TOP vs dépôt PII

Cette séparation reflète les deux niveaux de responsabilité pour les PII :

1. Juridique — niveau tenant (personne morale, p. ex. GCC, GCD, GCP)
2. Organisationnel — PMO/divisions/départements/sites (≈ AD Organizational Unit)

Vérification isolée du trousseau local

Un vérificateur (ou un auditeur 10 ans plus tard) vérifie sans dépendance au trousseau 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é issue du dépôt
• La clé publique se trouvait au moment du commit dans le dépôt → caractère probant reconstituable forensiquement

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 en cas d'expiration/révocation actuelle de la clé : le commit prouve que la clé était à l'époque digne de confiance
• git bundle transporte les dépôts y compris clés et justificatifs → unité forensique portable, indépendante de l'infrastructure vivante

Pertinence pour la documentation de procédure GoBD et NIS2

• GoBD (§ 146 AO, documentation de procédure) : L'architecture de trousseau fait partie de la documentation de procédure — elle décrit comment les justificatifs d'identité sont générés, archivés et vérifiés de manière auditables. Le modèle « clé dans le dépôt » satisfait les 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 dépôt TOP/PII et le contrôle d'accès basé sur les org-units (via les claims OIDC tenant_id + claim org-unit) mettent en œuvre le principe du moindre privilège. Seuls les rôles autorisés (via claim org-unit) obtiennent l'accès aux dépôts PII et donc aux clés personnelles.

Voir aussi : La série d'articles « Instructions de procédure GoBD pour Git » du 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 de l'IdP.

uuidV7 - UUID Version 7

UUID version 7 compatible RFC 4122 : basé sur le temps, triable, résistant aux collisions. L'extension spécifique à GitCover avec un identifiant de classe de 14 bits transforme les UUID en V7GUID (voir Concepts).

Modèle d'époques temporelles (real · tenant · person)

Partage normatif : Les normes RFC relatives aux GUID triables temporellement (RFC 9562/4122) décrivent exclusivement la structure — disposition des bits, longueur et position du champ d'horodatage, version et variante. La sémantique — ce que le timestamp signifie, en particulier l'époque temporelle comme grandeur de référence et la classification dans le suffixe — est normée par le GCBoK (spécification V7GUID, schéma OSS v7guid-epoch-mode-1.0). Un mode comme person n'enfreint donc pas la structure RFC ; il relève d'une sémantique GCBoK sur une structure conforme à la RFC.

Le timestamp de 48 bits (unix_ts_ms, RFC 9562) est unsigned et triable ; son époque de référence est, chez GitCover, un mode défini (union/enum, schéma OSS v7guid-epoch-mode-1.0) :

Le préfixe RFC (horodatage + version + variante) reste l'interface entre le Normative-Root et le Customizing (« Interface-Inheritance ») ; le suffixe (reste des 128 bits) porte la classification GitCover (L1–L6, catégories/motifs de bits, recherche registry/keyword). Les valeurs temporelles antérieures à l'époque choisie constituent une erreur définie (pas de wrap de signe) : l'arithmétique .NET est signée (DateTimeOffset fournit des long négatifs pour pre-1970), et seules des valeurs non négatives sont documentées — ainsi le tri et le format RFC restent préservés, tandis que les données historiques (p. ex. dates de naissance, PII) restent ordonnançables.

Règle de nommage de l'instance JSON (`

L'enregistrement de base (JSON d'instance) d'un objet est déposé dans le chemin du dépôt Git — et donc dans le WorkingDirectory — sous la forme {docType}.{classId}.json (docType = abréviation de classe, classId = V7GUID-Class-Identifier ; p. ex. PII_PERSON.01a12f72-4c75-74f1-8626-dd1ae65b6062.json). Il s'agit d'un index naturel : les outils proches du système d'exploitation trouvent les données d'instance via {docType} et/ou {classId}, sans connaître un nom de fichier fixe. S'applique à tous les artefacts de données (notamment PII persons/<uuidv7>/, entrées de registre, schémas de justificatifs).

Base temporelle & de drapeaux (GitCover.Core)

• validFrom/validTo (nullable, SSoT temporal-1.0) : validFrom = ancre « à partir de » (début de l'ensemble solution), validTo selon le contexte — requête journalière day : validTo < date.AddDays(1). null = « inconnu depuis quand » / « toujours valide ». Logique centrale : GitCover.Core.Types.Temporal.
• Règle booléenne à 2 états : absent == false ; une valeur présente reste déterminante (false/f/n/no/0/null sont falsy, ne jamais les interpréter comme true) ; false peut être omis (minimisation du bloat).
• Flag-BitVectors (cumulatifs, [Flags]) : le schéma de base des drapeaux ENUM appartient au schéma (phase-flags-1.0), pas à l'instance ; les instances portent status_flags (uniquement ceux définis ; présence == défini) + phases_result + current_phase sous forme de string.Join(" + ", …). Code : GitCover.Core.Types.Flags.
• Schémas référençant temporal-1.0 : pii-person, ou, iam-feature, repository-catalog, repository-identity, legal-entity, gcep-peer-registry, ocr-artifact, dictionary, category-catalog, business-meal-receipt, source-fact, beleg-journal.

Git comme IdP - Identity Provider

Dépôts Git basés sur Gitea comme 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 examine si les organisations/équipes Git peuvent représenter des clients OAuth2 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 la stack GitCover, à une double responsabilité, qui se reflète dans l'architecture des dépôts et les claims OIDC :

• Juridique (niveau tenant) : la personne morale est responsable du traitement au sens du droit de la protection des données (art. 4, point 7, RGPD). 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 organisationnelles (PMO, services, sites) peuvent être responsables de manière autonome de sous-ensembles de PII. Cela correspond à la structure des Active-Directory-Organizational-Units. L'affectation se fait via le claim personnalisé org_unit_id, qui est mappé dans le others.json du tenant sur des chemins de dépôt.

Affectation personne-rôle (pont PII) — besoin de travail

Affectation personne-rôle (pont PII) — besoin de travail

Les conteneurs de signature GCPN référencent les participants (attendees) comme Actors (rôle dans le tenant, fonction dans l'entreprise) et ne consignent les personnes que de manière pseudonymisée (persons.mappings avec renvoi PII). L'affectation canonique Personne → Rôles → Org-Units réside dans le cercle PII (gitignored) — pour un modèle cohérent, les relations suivantes doivent encore être détaillées dans le GCBoK :

Liaison : gcpn-container-2.7 → attendees (rôles dans l'opération) → persons.mappings (renvoi PII pseudonymisé) → dépôt PII (affectation canonique). Jusqu'à l'élaboration, les renvois pseudonymisés documentés ici font office de solution transitoire.

Hiérarchie des claims dans le pipeline d'inlet

Le pipeline d'inlet (voir Procédures : Isolation des mandants lit le others.json selon le claim de l'utilisateur 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 dépôt PII du portefeuille, 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 trousseau (TOP vs PII) est décrite ci-dessus sous « Architecture de trousseau GPG ».