Axis 4: Techniques

OSCAL - Open Security Controls Assessment Language

OSCAL transforms compliance documentation from Word/Excel into machine-readable JSON/YAML formats with four layers:

1. Catalogs - Control definitions (NIST 800-53, ISO 27001, BSI IT-Grundschutz)
2. Profiles - organization-specific baselines
3. Implementation Layer - System Security Plans, Component Definitions
4. Assessment Layer - Assessment Results, POA&M

The BSI officially documents: "OSCAL is compatible with international standards". The GCBoK defines German compliance taxonomies (GoBD, BSI, GDPR) as OSCAL catalogs - this does not yet exist on the market.

OPA / Rego - Policy as Code

Open Policy Agent with the Rego language. Compliance rules are implemented as code that is automatically checked against the Git state.

VPRM - Verifiable Process Reward Model

In the GCBoK context, OPA/Rego functions as a VPRM: Guardrails for AI agents are created through a deterministic rule set, not through prompt engineering. AI agents are thus secured not through prompt constraints, but through code validation.

GPG Signing

Every compliance-relevant Git commit is GPG-signed. The signature binds:

• Identity (GPG fingerprint = actor)
• Content (commit hash = data)
• Time (commit timestamp = when)

From .v7g.md metadata onward, GPG fingerprints are bound to V7GUIDs - identities remain forgery-proof even if an AI agent manipulates the semantic structure.

GPG Keyring Architecture for Forensic Verifiability

For GPG signatures to remain verifiable in the long term — even years after creation, after key expiry or revocation, and when reconstructing from git bundle/ZIP archives — the public keys must be part of the repository. For this purpose, the GCBoK defines a keyring-in-repo pattern:

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

Two-Level Model: TOP-Repo vs. PII-Repo

This separation reflects the two levels of responsibility for PII:

1. Legal — Tenant level (legal entity, e.g. GCC, GCD, CFP)
2. Organizational — PMO/Divisions/Departments/Locations (≈ AD Organizational Unit)

Verification Isolated from the Local Keyring

A verifier (or an auditor 10 years later) verifies without dependency on the local GPG keyring:

# 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: Ignores ~/.gnupg/
• --keyring: Uses only the key from the repository
• The public key was in the repository at the time of the commit → forensically reconstructable evidentiary value

Temporal Validity and Key Lifecycle

The question “Was the signature valid at the time of the commit?” is answered by the repository integration:

• The public key is present in the Git history of the commit
• Even if the key has since expired or been revoked: the commit proves that the key was trustworthy at that time
• git bundle transports repos including keys and evidence → a portable forensic unit, independent of live infrastructure

Relevance for GoBD Process Documentation and NIS2

• GoBD (§ 146 AO, process documentation): The keyring architecture is part of the process documentation — it describes how identity proofs are generated, archived and verified in an audit-proof manner. The “keys-in-repo” pattern meets the GoBD requirements for the verifiability and immutability of the identity binding.
• NIS2 (access permissions, Art. 21): The TOP/PII-Repo separation and the Org-Unit-based access control (via OIDC claims tenant_id + Org-Unit claim) implement the principle of least privilege. Only authorized roles (via Org-Unit claim) are granted access to PII-Repos and thus to personal keys.

See also: The article series “GoBD Process Instructions for Git” in the GCBoK (Module 3: Cryptographic Integrity, Module 4: Signatures & Authenticity) explores these topics in depth. The research project GitCover.IdP (BSFZ 288-335-338/2026-1) investigates IdP integration.

uuidV7 - UUID Version 7

RFC-4122-compliant UUID Version 7: time-based, sortable, collision-resistant. The GitCover-specific extension with 14-bit class identifiers turns UUIDs into V7GUIDs (see Concepts).

Git as IdP - Identity Provider

Gitea-based Git repositories as the Single Source of Truth (SSoT) for an integrated identity and access management system (IAM). The BSFZ-recognized research project investigates whether Git organizations/teams can map OAuth2 clients and permissions and manage more than 1,000 users performantly.

Two-Level Responsibility for PII (Legal + Organizational)

Personal data (PII) in the GitCover stack is subject to dual responsibility, which is reflected in the repository architecture and the OIDC claims:

• Legal (tenant level): The legal entity is the controller under data protection law (Art. 4 Nr. 7 DSGVO). The tenant_id is derived deterministically from the V7GUID of the TOP directory (see [Concepts: Central Tenant Register](v7guid-beleg-ketten-und-cryptographic-evidence.html #zentrales-tenant-register)).
• Organizational (PMO/Org-Unit): Within a tenant, multiple organizational units (PMOs, departments, locations) can be independently responsible for subsets of PII. This corresponds to the structure of Active Directory Organizational Units. The assignment is made via the custom claim org_unit_id, which is mapped to repository paths in the tenant's others.json.

Claim Hierarchy in the Inlet Pipeline

The Inlet pipeline (see Procedures: Tenant Isolation reads the others.json depending on the user claim and injects the allowed paths:

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

As a result, a user with org_unit_id = ORG-1-Portfolio receives access to the portfolio's PII-Repo, but not to PII/ORG-2-IT — even with the same tenant_id.

See also: The research project on GitCover.IdP is described in Research Projects. The keyring architecture (TOP vs. PII) is described above under “GPG Keyring Architecture”.