GCBoK · Kapitel 3 & 4

Konzepte & Techniken

Die Kernkonzepte der Git-native Compliance — von der V7GUID-Identifikation über Beleg-Ketten bis zur Policy-as-Code-Architektur.

Grundlagen · Kapitel 3.1

Git-native
Compliance

Git-native Compliance bezeichnet das Architekturparadigma, bei dem alle Compliance-Artefakte, Entscheidungen, Identitäten und Nachweise primär in Git-Repositories leben — versioniert, GPG-signiert, OSCAL-maschinenlesbar, OPA-validierbar — ohne einen sekundären Compliance-Store zu benötigen.

Das Paradigma ist analog zu Cloud-native (Architektur für Cloud-Infrastruktur, CNCF) und GitOps (Git als Source of Truth für Deployments). Git-native Compliance nutzt Git als unveränderliche, kryptographisch verankerte Evidenz-Basis.

  • P1

    Git als alleinige Evidenz-Basis

    Kein sekundärer Compliance-Store. Alle Nachweise sind Git-Commits mit GPG-Signatur.

  • P2

    Maschinenlesbare Policy

    Compliance-Anforderungen werden als OSCAL-Kataloge und OPA/Rego-Regeln im Repository verwaltet.

  • P3

    Deterministische Identifikation

    Jedes Artefakt wird durch V7GUID eindeutig und sortierbar identifiziert — ohne zentrale Datenbank.

  • P4

    Kryptographische Verkettung

    SHA256-Hashverkettung und GPG-Signierung erzeugen unveränderliche Beleg-Ketten (GoBD-konform).

Positionierungsformel (GCBoK §3.1)
„Git-native Compliance bedeutet, dass alle Compliance-Artefakte, Entscheidungen, Identitäten und Nachweise primär in Git-Repositories leben — versioniert, GPG-signiert, OSCAL-maschinenlesbar, OPA-validierbar — ohne einen sekundären Compliance-Store zu benötigen."

— GCBoK §3.1, GitCover Commons gUG 2026

Git

Versionierung · GPG-Signierung · Unveränderlichkeit · Branching

OSCAL

Maschinenlesbare Compliance-Kataloge · GoBD · NIS2 · BSI GS++

OPA / Rego

Policy as Code · Validierung · Audit-Trails · VPRM

V7GUID

Deterministisch · Sortierbar · Klassen-kodiert · Beleg-Ketten

Konzepte · Kapitel 4.1

V7GUID
Categorized UUIDv7

V7GUID (auch: GitCover Version-7-GUID, Categorized UUIDv7 Identifier) bezeichnet ein Kategorisierungsschema für Identifikatoren in GitCover-Artefakten. Es basiert auf RFC-4122-kompatiblem UUID Version 7 (zeitbasiert, sortierbar) und erweitert diesen um ein GitCover-spezifisches 14-Bit Klassen-Segment.

V7GUID löst die Anforderung aus der GoBD-Zeitgerechtheit: Belege müssen zeitlich rekonstruierbar sein, ohne eine zentrale Sequenzdatenbank zu benötigen. Der 48-Bit-Millisekunden-Zeitstempel garantiert globale Sortierbarkeit.

Das 14-Bit Klassen-Segment (bits 66–79) ist deterministisch belegt und identifiziert den Artefakt-Typ: INVOICE, PERSON, PAYMENT, POLICY, etc.

Bekannte Klassen-Identifier
KlasseHexVerwendung
PERSON0x01Natürliche Person, Mitglied, Consent
INVOICE0x02Ausgangsrechnung, XRechnung
PAYMENT0x03Zahlungsbeleg, Buchungsvorgang
POLICY0x10OPA/OSCAL-Policydokument
AUDIT0x20Audit-Log-Eintrag, Prüfnachweis
Bit-Layout der V7GUID (128 Bit total)
timestamp_ms48 Bit
ver4
rand_a12
var2
class14 Bit
rand_b48
Beispiel V7GUID (INVOICE-Klasse)
0197a3c1-f3c0-7b00-8002-d4e8f12a3b09
         ↑ ms-Timestamp    ↑ class=INVOICE
Metadaten-Schema (.v7g.md)
v7guid: "0197a3c1-f3c0-7b00-8002-d4e8f12a3b09"
class: INVOICE
sha256: "7d4e2f9c..."
prev_sha256: "3f2a1c8b..."
gpg_fingerprint: "ABCD1234..."
timestamp_iso: "2026-06-14T11:18:00+02:00"
gobd_periode: "FY2026"

Schutzrecht: Patent 10 2025 003 091.6 (DPMA, Anmeldetag 09.09.2025). IPC: G06F 16/23, G06F 21/64, H04L 9/32.

Konzepte · Kapitel 4.2

Kryptographische
Beleg-Ketten

Eine Beleg-Kette (Evidence Chain) ist eine verkettete Folge von Compliance-Artefakten, bei der jeder Beleg den SHA256-Hash seines Vorgängers enthält und per GPG signiert ist. Das Prinzip ist analog zu einer Blockchain, jedoch Git-nativ und ohne Konsensprotokoll.

Die Verkettung erfüllt die GoBD-Anforderung der Zeitgerechtheit und Unveränderlichkeit: Nachträgliche Manipulationen brechen die Hashkette und werden durch v7g-verify erkannt. Öffentliche Hash-Deposits (Git-Commits) ermöglichen externen Prüfern die unabhängige Verifikation.

Der GitCover.DMS-Toolstack besteht aus: v7g-pack, v7g-verify, v7g-sign, v7g-export — alle operieren auf .v7g.zip-Containern mit eingebetteten .v7g.md-Metadatendateien.

Beleg-Kette (Evidence Chain)
Beleg B1 · PERSON
V7GUID: 0197a3b2-...-PERSON SHA256: 3f2a1c… prev: — GPG: ✓
Beleg B2 · INVOICE
V7GUID: 0197a3c1-...-INVOICE SHA256: 7d4e2f… prev: 3f2a1c… GPG: ✓
Beleg B3 · PAYMENT
V7GUID: 0197a3d0-...-PAYMENT SHA256: 1b8f90… prev: 7d4e2f… GPG: ✓

GoBD-Relevanz: Die Hash-Kette erfüllt §§ 146–147 AO (Aufbewahrungspflicht) und GoBD §14 (Unveränderlichkeit). Öffentliche Hash-Deposits in Git-Commits ermöglichen externe Prüferverifikation ohne Zugriff auf Inhalte.

Techniken · Kapitel 4.3

OSCAL & OPA
Policy as Code

OSCAL (Open Security Controls Assessment Language, NIST) ist das maschinenlesbare Format für Compliance-Kataloge und Kontrollrahmen in GitCover. Alle normativen Anforderungen aus GoBD, NIS2, BSI GS++ werden als OSCAL-Kataloge in Git verwaltet — versioniert, überprüfbar, forkbar.

OPA/Rego (Open Policy Agent) validiert zur Laufzeit, ob Git-Artefakte die OSCAL-definierten Anforderungen erfüllen. In GitCover fungiert OPA/Rego als VPRM (Verifiable Process Reward Model) für KI-Agenten: Guardrails entstehen durch deterministisches Regelwerk, nicht durch Prompt-Engineering.

OSCAL Catalog

Maschinenlesbare Kontrollen: GoBD §§, NIS2 Artikel, BSI-Grundschutz-Bausteine

OSCAL Profile

Tailoring: Auswahl relevanter Kontrollen für KMU-Profil · EÜR · Bilanz

OPA Policies

Rego-Regeln für Artefakt-Validierung · Audit-Trail-Prüfung · GCUCB-Guards

GCRef

Maschinenlesbare Schicht: OSCAL-Kataloge + OPA-Sets im Git-Repository (GCRef)

OSCAL-Katalog-Fragment (GoBD)
{
  "catalog": {
    "uuid": "0197a3e0-...-POLICY-...",
    "metadata": {
      "title": "GoBD Compliance Catalog",
      "version": "2026-01"
    },
    "controls": [{
      "id": "gobd-146",
      "title": "Aufbewahrungspflicht",
      "class": "GoBD-§146-AO",
      "parts": [{
        "name": "statement",
        "prose": "Buchungsbelege sind
          10 Jahre aufzubewahren..."
      }]
    }]
  }
}
OPA/Rego Policy-Beispiel
package gitcover.gobd

# Alle Belege müssen SHA256 + V7GUID haben
deny[msg] {
  input.beleg.sha256 == ""
  msg := sprintf("Beleg %v fehlt SHA256",
    [input.beleg.v7guid])
}

# Aufbewahrungsfrist mindestens 10 Jahre
deny[msg] {
  years := input.beleg.retention_years
  years < 10
  msg := "GoBD §147: min. 10 Jahre"
}

Techniken · Kapitel 4.4

Git als
Identity Provider

GitCover.IdP bezeichnet den Einsatz von Gitea als vollwertigen Identity Provider (IdP) — ein Kernelement der GitCover-Architektur, das in der BSFZ-Bescheinigung 288-335-338/2026-1 als das originalste Merkmal (N2) gewürdigt wurde.

Gitea übernimmt OpenID Connect (OIDC) / OAuth2-Funktionen: Nutzeridentitäten, Organisationsstrukturen, Team-Zugehörigkeiten und Zugriffsrechte werden Git-nativ verwaltet — kein externer LDAP, kein Keycloak, keine Azure AD.

Hypothese H1

Git-Metadaten (Commit-Autor, GPG-Schlüssel) reichen zur OIDC-Identifikation — ohne separaten IdP.

Hypothese H2

OPA-Regeln aus Git-versionierten OSCAL-Katalogen können als KI-Agent-Guardrails (VPRM) wirken.

Hypothese H3

GCEP ermöglicht nachweislich compliant Cross-Tenant-Datenaustausch zwischen Gitea-Instanzen.

BSFZ 2026-1

Forschungsbescheinigung: Positive Stellungnahme vom 22.04.2026. FZulG WJ 2025 beantragt.

GitCover.IdP Architektur
Gitea (IdP)
├── OIDC/OAuth2 Endpunkt
├── Organisationen → Tenants
├── Teams → Rollen/Scopes
├── GPG-Schlüssel → Identität
└── Repos → Compliance-Artefakte
Abhängige Services
├── GCPN (Buchhaltung)
├── GCUCB (KI-Bus)
├── GCEP (Exchange)
└── GitCover.DMS (Dok.)

Abgrenzung: GitCover.IdP ist explizit kein Ersatz für Keycloak, Azure AD oder LangChain. Die Neuartigkeit liegt in der Git-nativen Kombination von Identität + Compliance + Audit-Trail in einem einzigen Repository-Stack.

Konzepte · Kapitel 4.5

GCUCB & VPRM
KI-Agenten ohne Systemprompt-Last

Der GitCover Unified Communication Bus (GCUCB) ist ein Shared-Memory-basierter Kontext-Bus mit deterministischer V7GUID-Adressierung. Er ist die zentrale Datendrehscheibe zwischen KI-Agenten, OPA-Validatoren und Audit-Systemen innerhalb einer GitCover-Installation.

GCUCB eliminiert das wiederholte Serialisieren/Deserialisieren durch typisierten Direktzugriff auf Memory-Mapped-File-Regionen. KI-Agenten erhalten typisierte, V7GUID-referenzierte ref struct-Accessor-Klassen anstelle riesiger Systemprompts.

VPRM (Verifiable Process Reward Model): OPA/Rego fungiert als Belohnungssignal-Generator — Guardrails entstehen durch deterministisches Regelwerk, nicht durch Prompt-Engineering. Forschungsfeld BSFZ-Modul 2026–2028.

GCUCB Shared-Memory Layout
/dev/shm/gcucb.mmap
┌─────────────────────────────────┐
│ Header (V7GUID · Version · Size) │  32 Byte
├─────────────────────────────────┤
│ Schema-Registry                  │  variabel
│  (OSCAL/OPA → Roslyn-Generated) │
├─────────────────────────────────┤
│ Object-Pool                      │
│  (V7GUID → ref struct Accessor) │  O(1)
├─────────────────────────────────┤
│ Audit Ring-Buffer                │  16 MB
│  (OPA Reward-Signal-Log)        │
└─────────────────────────────────┘
Podman Pod · Shared IPC Namespace

Performance-Baseline: FlatBuffers 10× schneller als JSON. AgentDiet-Studie: 39.9–59.7% Overhead-Reduktion durch selektiven Kontext. Forschungsfragen F1–F5 (Frascati-qualifiziert) im BSFZ-Antrag.