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.

OSCAL catalogs and OPA rules are part of the machine-readable semantic layer of the GitCover ontology: They describe, in the same language as the L1–L6 dictionaries, which requirements apply and how they are verified (see Concepts: Business hierarchy as ontology and Glossary: Ontology).

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 acts as 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 tamper-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. The GCBoK defines a keyring-in-repo pattern for this:

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 with today's key expiry/revocation: The commit proves that the key was trustworthy at that time
• git bundle transports repos including keys and proofs → 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 "key-in-repo" pattern meets the GoBD requirements for verifiability and immutability of the identity binding.
• NIS2 (access authorizations, 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) receive 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 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 >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.

Person-to-Role Mapping (PII Bridge) — Work Required

Person-to-Role Mapping (PII Bridge) — Work Required

The GCPN signature containers reference participants (attendees) as Actors (role in the tenant, function in the company) and record persons only in pseudonymized form (persons.mappings with PII reference). The canonical mapping Person → Roles → Org-Units resides in the PII scope (gitignored) — for an end-to-end model, the following relationships still need to be worked out in detail in the GCBoK:

Linkage: gcpn-container-1.0 → attendees (roles in the process) → persons.mappings (pseudonymized PII reference) → PII repo (canonical mapping). Until this has been elaborated in detail, the pseudonymized references documented here serve as an interim solution.

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"
  ]
}

This way, 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".