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 a formatos JSON/YAML legibles por máquina con cuatro capas:

  1. Catálogos - Definiciones de controles (NIST 800-53, ISO 27001, BSI IT-Grundschutz)
  2. Perfiles - Líneas base específicas de la organización
  3. Capa de implementación - Planes de seguridad del sistema, definiciones de componentes
  4. Capa de evaluación - Resultados de evaluación, POA&M

El BSI documenta oficialmente: "OSCAL es compatible con estándares internacionales". El GCBoK define taxonomías de cumplimiento alemanas (GoBD, BSI, DSGVO) como catálogos OSCAL — esto no existe actualmente 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 estado de Git.

VPRM - Verifiable Process Reward Model

En el contexto del GCBoK, OPA/Rego funciona como VPRM: las barreras para agentes de IA surgen a través de un conjunto de reglas determinista, no mediante ingeniería de prompts. De este modo, los agentes de IA no se protegen mediante restricciones de prompt, 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, las huellas GPG se vinculan a V7GUIDs — las identidades permanecen a prueba de falsificación incluso si un agente de IA manipula la estructura semántica.

Arquitectura de keyring GPG para trazabilidad forense

Para que las firmas GPG permanezcan verificables a largo plazo — incluso años después de su creación, tras la expiración o revocación de claves, y durante la reconstrucción desde 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          # Claves públicas de líderes de equipo
│   ├── service-accounts/      # CI/CD, bots, automatización
│   └── identities/            # Claves personales (solo repos de PII)
│       ├── axel-d.asc
│       └── axel-d_governikus.pdf  # Prueba de identidad pgp.governikus.de
├── trusted-keys.gpg           # Keyring recopilado (opcional, para verificadores)
└── compliance/                # Documentos GoBD/DSGVO

Modelo de dos niveles: repositorio TOP vs. repositorio PII

Nivel Repositorio Contenido Relevancia DSGVO
Organizativo Repositorio TOP (Tenant Organizational Platform) Claves de líderes de equipo, cuentas de servicio, bots CI/CD, ancla de confianza trusted-keys.gpg Sin datos personales — conforme a la DSGVO
Personal Repositorio PII (Personal Identifiable Information) Claves de desarrolladores, pruebas de identidad (confirmaciones de Governikus), huellas GPG personales PII — acceso solo mediante claims de unidad organizativa (ver abajo)

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

  1. Legal — nivel de tenant (entidad jurídica, p. ej. GCC, GCD, CFP)
  2. Organizativo — PMO/divisiones/departamentos/ubicaciones (≈ unidad organizativa de AD)

Verificación aislada del keyring local

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

# Utilizar solo claves del repositorio, ignorar el keyring local
gpg --no-default-keyring --keyring .gitcover/keys/team-lead.asc 
    --verify-commit <commit-hash>

Validez temporal y ciclo de vida de claves

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

Relevancia para la documentación de procedimientos GoBD y NIS2

Ver 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 y autenticidad) profundiza en estos temas. El proyecto de investigación GitCover.IdP (BSFZ 288-335-338/2026-1) investiga la integración de IdP.

uuidV7 - UUID Version 7

UUID versión 7 compatible con RFC-4122: basada en tiempo, ordenable, resistente a colisiones. La extensión específica de GitCover con un identificador de clase de 14 bits convierte las UUIDs en V7GUIDs (ver Conceptos).

Git como IdP - Identity Provider

Repositorios Git basados en Gitea como fuente única de verdad (SSoT) para un sistema integrado de gestión de identidad y acceso (IAM). El proyecto de investigación reconocido por el BSFZ investiga si las organizaciones/equpos de Git pueden mapear clientes OAuth2 y permisos y gestionar >1.000 usuarios de forma eficiente.

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

Nivel Alcance Tipo de repositorio Claim OIDC Ejemplo
1. Legal Tenant (entidad jurídica) Repositorio TOP + repositorio PII tenant_id (basado en V7GUID) GCC, GCD, CFP, ADA
2. Organizativo PMO / división / departamento / ubicación Repositorio PII (granular) org_unit_id (≈ unidad organizativa de AD) GCC-Portfolio, GCD-IT, CFP-Sales

Jerarquía de claims en la pipeline de entrada

La pipeline de entrada (ver Procedimientos: Aislamiento de tenants lee el others.json según el claim del usuario e inyecta las rutas permitidas:

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

De este modo, un usuario con org_unit_id = GCC-Portfolio obtiene acceso al repositorio PII del portfolio, pero no a PII/GCD-IT — incluso con el mismo tenant_id.

Ver también: El proyecto de investigación de GitCover.IdP se describe en Proyectos de inv estigación. La arquitectura de keyring (TOP vs. PII) se describe arriba en "Arquitectura de keyring GPG".