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

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 semantics layer of the GitCover ontology: they describe, in the same language as the L1–L6 dictionaries, which requirements apply and how they are checked (see Concepts: Business hierarchy as ontology and Glossary: Ontology).

The GCPN events/flags (signature and process lifecycle) are derived from these OSCAL catalogs (ao-buchfuehrung, gobd, ustg-rechnung, bmf-erechnung). The immutable collection GCPN-EVENTS-FLAGS carries the governance anchoring (AO §146, GoBD Rz. 146/147) and is referenced in the GCPN via events.enum_ref.

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 by deterministic rule sets, not by prompt engineering. This means AI agents are not secured by prompt constraints, but by 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)

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

GCSIG — Signature as a versioned artifact

Git history alone is not sufficient as signature evidence: a force-push can rewrite it. Therefore, every relevant Git code/commit signature (GPG, signed commit, PR) is additionally stored as an immutable artifact {name}.gcsig.md (schema gcsig-1.4). It binds:

• Object (commit/tree/tag/PR SHA)
• GPG signature + signer fingerprint + verification status
• Phases as 32-bit flags (draft, presented, accepted, signed, denied, withdrawn, revoked, expired, superseded, verified)

This makes the commit signature Git-versioned and history-rewrite-proof; a subsequent GCPN references the GCSIG via parents[]/children[] (GCSIG:{docUid}). Creation: gc-docsign gcsig <repo> --commit <sha>.

GPG keyring architecture for forensic traceability

So that GPG signatures remain verifiable in the long term — even years after creation, after key expiry or revocation, and when reconstructed 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, GCP)
2. Organizational — PMO/divisions/departments/locations (≈ AD Organizational Unit)

Verification isolated from the local keyring

A verifier (or 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 exclusively the key from the repository
• The public key was in the repository at the time of the commit → forensic, reconstructable evidence character

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 in the case of 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 created, archived and verified in an audit-proof manner. The "key-in-repo" pattern fulfills the GoBD requirements for verifiability and immutability of the identity binding.
• NIS2 (access permissions, Art. 21): The separation of TOP/PII repo 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) gain 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 greater depth. The research project GitCover.IdP (BSFZ 288-335-338/2026-1) investigates the IdP integration.

uuidV7 - UUID Version 7

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

Time epoch model (real · tenant · person)

Standard division: The RFC standards for temporally sortable GUIDs (RFC 9562/4122) describe exclusively the structural design — bit layout, length and position of the timestamp field, version and variant. The semantics — what the timestamp means, in particular the time epoch as reference quantity and the classification in the suffix — are standardized by GCBoK (V7GUID specification, OSS schema v7guid-epoch-mode-1.0). A mode such as person therefore does not violate the RFC structure; it is a GCBoK semantics on an RFC-conformant structure.

The 48-bit timestamp (unix_ts_ms, RFC 9562) is unsigned and sortable; in GitCover its reference epoch is a defined mode (union/enum, OSS schema v7guid-epoch-mode-1.0):

The RFC prefix (timestamp + version + variant) remains the interface from the normative root to customizing ("interface inheritance"); the suffix (rest of the 128 bits) carries the GitCover classification (L1–L6, categories/bit patterns, registry/keyword search). Time values before the chosen epoch are a defined error (no sign wrap): .NET arithmetic is signed (DateTimeOffset returns negative long for pre-1970), and only non-negative values are recorded — this keeps sorting and RFC format intact while historical data (e.g. birth dates, PII) remain orderable.

Instance JSON naming rule (`

The base data record (instance JSON) of an object is stored in the Git repo path — and thus in the working directory — as {docType}.{classId}.json (docType = class abbreviation, classId = V7GUID class identifier; e.g. PII_PERSON.01a12f72-4c75-74f1-8626-dd1ae65b6062.json). This is a natural index: OS-adjacent tooling finds instance data by {docType} and/or {classId} without knowing a fixed file name. Applies to all data artifacts (including PII persons/<uuidv7>/, registry entries, evidence schemas).

Temporal & flag basis (GitCover.Core)

• validFrom/validTo (nullable, SSoT temporal-1.0): validFrom = "from" anchor (start of the solution set), validTo context-dependent — day query day: validTo < date.AddDays(1). null = "unknown since when" / "still valid". Central logic: GitCover.Core.Types.Temporal.
• Boolean two-state rule: absent == false; an existing value remains authoritative (false/f/n/no/0/null are falsy, never interpret as true); false may be omitted (bloat minimization).
• Flag bit vectors (cumulative, [Flags]): the ENUM flag base schema belongs in the schema (phase-flags-1.0), not in the instance; instances carry status_flags (only set ones; presence == set) + phases_result + current_phase as string.Join(" + ", …). Code: GitCover.Core.Types.Flags.
• Schemas that reference 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 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 represent OAuth2 clients and permissions and can manage >1,000 users with good performance.

Two-level responsibility for PII (legal + organizational)

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

• Legal (tenant level): The legal entity is the data protection controller (Art. 4 No. 7 GDPR). The tenant_id is derived deterministically from the V7GUID of the TOP directory (see Concepts: Central tenant register).
• Organizational (PMO/org unit): Within a tenant, several organizational units (PMOs, departments, locations) can independently be 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 assignment (PII bridge) — work needed

Person-to-role assignment (PII bridge) — work needed

The GCPN signature containers reference participants (attendees) as actors (role in the tenant, function in the company) and carry persons only pseudonymized (persons.mappings with PII reference). The canonical assignment person → roles → org units lies in the PII circle (gitignored) — for a consistent model, the following relationships still need to be worked out in detail in the GCBoK:

Linkage: gcpn-container-2.7 → attendees (roles in the process) → persons.mappings (pseudonymized PII reference) → PII repo (canonical assignment). Until this is worked out, the pseudonymized references documented here apply 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 permitted paths:

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

Thus a user with org_unit_id = ORG-1-Portfolio gains 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".