GitCover Symbol GCBoKGitCover Body of Knowledge

Eje 4: Técnicas

OSCAL - Open Security Controls Assessment Language

OSCAL transforma la documentación de cumplimiento de Word/Excel en formatos JSON/YAML legibles por máquina con cuatro capas:

  1. Catalogs - Definiciones de controles (NIST 800-53, ISO 27001, BSI IT-Grundschutz)
  2. Profiles - Líneas base específicas de la organización
  3. Implementation Layer - System Security Plans, Component Definitions
  4. Assessment Layer - Assessment Results, POA&M

El BSI documenta oficialmente: «OSCAL es compatible con los estándares internacionales». El GCBoK define las taxonomías de cumplimiento alemanas (GoBD, BSI, DSGVO) como catálogos OSCAL - algo que hasta ahora no existe en el mercado.

OPA / Rego - Policy as Code

Open Policy Agent con el lenguaje Rego. Las reglas de cumplimiento se implementan como código que se verifica automáticamente contra el Git-State.

VPRM - Verifiable Process Reward Model

En el contexto del GCBoK, OPA/Rego actúa como VPRM: los guardrails para agentes de IA surgen de un conjunto de reglas determinista, no del Prompt-Engineering. De este modo, los agentes de IA no se protegen mediante Prompt-Constraints, sino mediante validación de código.

Firma GPG

Cada commit de Git relevante para el cumplimiento se firma con GPG. La firma vincula:

A partir de los metadatos .v7g.md, los GPG-Fingerprints se vinculan a los V7GUIDs - las identidades permanecen a prueba de falsificación incluso cuando un agente de IA manipula la estructura semántica.

Arquitectura de keyring GPG para la trazabilidad forense

Para que las firmas GPG sigan siendo verificables a largo plazo — también años después de su creación, tras la expiración o revocación de la clave, y al reconstruir a partir de archivos git bundle/ZIP — las claves públicas deben formar parte del repositorio. El GCBoK define para ello un patrón de keyring en el repositorio:

Estructura: .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

Modelo de dos niveles: TOP-Repo vs. PII-Repo

Nivel Repositorio Contenido Relevancia DSGVO
Organizativo TOP-Repo (Tenant Organizational Platform) Claves de Team-Leads, Service-Accounts, bots de CI/CD, ancla de confianza trusted-keys.gpg Sin datos personales — conforme al DSGVO
Personal PII-Repo (Personal Identifiable Information) Claves de desarrolladores, pruebas de identidad (confirmaciones de Governikus), GPG-Fingerprints personales PII — acceso solo mediante Org-Unit-Claims (véase abajo)

Esta separación refleja los dos niveles de responsabilidad para PII:

  1. Legal — nivel de tenant (entidad jurídica, p. ej. GCC, GCD, CFP)
  2. Organizativo — PMO/Divisions/Departments/Locations (≈ AD Organizational Unit)

Verificación aislada del keyring local

Un verificador (o un auditor 10 años después) verifica sin dependencia del keyring GPG local:

# Nur Repository-Schlüssel nutzen, lokalen Keyring ignorieren
gpg --no-default-keyring --keyring .gitcover/keys/team-lead.asc \
    --verify-commit <commit-hash>

Validez temporal y ciclo de vida de las claves

La pregunta «¿Era válida la firma en el momento del commit?» se responde mediante la integración en el repositorio:

Relevancia para la documentación de procedimientos GoBD y NIS2

Véase también: La serie de artículos «Instrucciones de procedimiento GoBD para Git» en el GCBoK (Módulo 3: Integridad criptográfica, Módulo 4: Firmas & Autenticidad) profundiza en estos temas. El proyecto de investigación GitCover.IdP (BSFZ 288-335-338/2026-1) examina la integración del IdP.

uuidV7 - UUID Version 7

UUID Version 7 compatible con RFC-4122: basada en el tiempo, ordenable, resistente a colisiones. La extensión específica de GitCover con identificadores de clase de 14 bits convierte las UUIDs en V7GUIDs (véase Conceptos).

Git como IdP - Identity Provider

Repositorios Git basados en Gitea como Single Source of Truth (SSoT) para un sistema integrado de gestión de identidades y accesos (IAM). El proyecto de investigación reconocido por el BSFZ examina si las organizaciones/equipos Git pueden representar OAuth2-Clients y permisos y gestionar >1.000 usuarios de forma eficiente.

Los datos personales (PII) están sujetos en el GitCover-Stack a una doble responsabilidad que se refleja en la arquitectura de repositorios y en los OIDC-Claims:

Nivel Scope Tipo de repositorio OIDC-Claim Ejemplo
1. Legal Tenant (entidad jurídica) TOP-Repo + PII-Repo tenant_id (basado en V7GUID) GCC, GCD, CFP, ADA
2. Organizativo PMO / Division / Department / Location PII-Repo (de grano fino) org_unit_id (≈ AD Organizational Unit) GCC-Portfolio, GCD-IT, CFP-Sales

Jerarquía de claims en la Inlet-Pipeline

La Inlet-Pipeline (véase Procedimientos: Aislamiento de tenants lee la others.json según el User-Claim e inyecta las rutas permitidas:

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

Así, un usuario con org_unit_id = ORG-1-Portfolio obtiene acceso al PII-Repo del portfolio, pero no a PII/ORG-2-IT — incluso con el mismo tenant_id.

Véase también: El proyecto de investigación sobre GitCover.IdP se describe en Proyectos de investigación. La arquitectura de keyring (TOP vs. PII) se describe arriba bajo «Arquitectura de keyring GPG».