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 - baselines 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 conectable con estándares internacionales». El GCBoK define taxonomías de cumplimiento alemanas (GoBD, BSI, DSGVO) como catálogos OSCAL — esto no existe hasta ahora en el mercado.

Los catálogos OSCAL y las reglas OPA forman parte de la capa semántica legible por máquina de la ontología GitCover: describen, en el mismo lenguaje que los diccionarios L1–L6, qué requisitos se aplican y cómo se verifican (véase Conceptos: jerarquía de negocio como ontología y Glosario: ontología).

Los GCPN-Events/Flags (ciclo de vida de firma y expediente) se derivan de estos catálogos OSCAL (ao-buchfuehrung, gobd, ustg-rechnung, bmf-erechnung). La colección inmutable GCPN-EVENTS-FLAGS porta el anclaje de gobernanza (AO §146, GoBD Rz. 146/147) y se referencia en el GCPN mediante events.enum_ref.

OPA / Rego - Política como código

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 actúa como VPRM: los guardarraíles para agentes de IA surgen mediante un conjunto de reglas determinista, no mediante ingeniería de prompts. Así, los agentes de IA no se aseguran 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:

• Identidad (huella GPG = actor)
• Contenido (hash del commit = datos)
• Momento (marca temporal del commit = cuándo)

A partir de los metadatos .gc.md, las huellas GPG se vinculan a V7GUIDs — las identidades siguen siendo a prueba de falsificación incluso si un agente de IA manipula la estructura semántica.

GCSIG — Firma como artefacto versionado

El historial de Git por sí solo no basta como prueba de firma: un force-push puede reescribirlo. Por ello, cada firma relevante de código/commit de Git (GPG, signed commit, PR) se deposita adicionalmente como artefacto inmutable {name}.gcsig.md (esquema gcsig-1.4). Este vincula:

• Objeto (SHA de commit/árbol/etiqueta/PR)
• Firma GPG + huella del firmante + estado de verificación
• Fases como flags de 32 bits (draft, presented, accepted, signed, denied, withdrawn, revoked, expired, superseded, verified)

Así, la firma del commit queda versionada en Git y resistente a reescrituras del historial; un GCPN posterior referencia el GCSIG mediante parents[]/children[] (GCSIG:{docUid}). Creación: gc-docsign gcsig <repo> --commit <sha>.

Arquitectura de keyring GPG para la demostrabilidad forense

Para que las firmas GPG sigan siendo verificables a largo plazo —incluso años después de su creación, tras la expiración o revocación de la clave, y al reconstruir a partir de git bundle/archivos 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

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

1. Legal — nivel de tenant (entidad jurídica, p. ej., GCC, GCD, GCP)
2. Organizativo — PMO/Divisiones/Departamentos/Ubicaciones (≈ AD Organizational Unit)

Verificación aislada del keyring local

Un verificador (o auditor 10 años después) verifica sin depender 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>

• --no-default-keyring: ignora ~/.gnupg/
• --keyring: usa exclusivamente la clave del repositorio
• La clave pública estaba en el momento del commit en el repositorio → carácter probatorio reconstruible forense

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:

• La clave pública está presente en el historial de Git del commit
• Incluso con la expiración/revocación actual de la clave: el commit demuestra que la clave era fiable en aquel momento
• git bundle transporta repositorios incluidas claves y pruebas → unidad forense portátil, independiente de la infraestructura viva

Relevancia para la documentación de procedimientos GoBD y NIS2

• GoBD (§ 146 AO, documentación de procedimientos): la arquitectura de keyring forma parte de la documentación de procedimientos — describe cómo se generan, archivan y verifican de forma auditable las pruebas de identidad. El patrón «clave en el repositorio» cumple los requisitos de la GoBD sobre verificabilidad e inmutabilidad del vínculo de identidad.
• NIS2 (derechos de acceso, Art. 21): la separación TOP/PII-Repo y el control de acceso basado en Org-Unit (mediante claims OIDC tenant_id + claim de Org-Unit) implementan el principio de mínimo privilegio. Solo los roles autorizados (mediante claim de Org-Unit) obtienen acceso a los PII-Repos y, con ello, a claves personales.

Véase también: La serie de artículos «GoBD-Verfahrensanweisungen für 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 del IdP.

uuidV7 - UUID versión 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 UUID en V7GUIDs (véase Conceptos).

Modelo de épocas temporales (real · tenant · person)

División de normas: Las normas RFC para GUID ordenables temporalmente (RFC 9562/4122) describen exclusivamente la estructura — disposición de bits, longitud y posición del campo de timestamp, versión y variante. La semántica —qué significa el timestamp, en particular la época temporal como magnitud de referencia y la clasificación en el sufijo— la norma GCBoK (especificación V7GUID, esquema OSS v7guid-epoch-mode-1.0). Por tanto, un modo como person no infringe la estructura RFC; es una semántica GCBoK sobre una estructura conforme a RFC.

El timestamp de 48 bits (unix_ts_ms, RFC 9562) es sin signo y ordenable; su época de referencia es en GitCover un modo definido (union/enum, esquema OSS v7guid-epoch-mode-1.0):

El prefijo RFC (timestamp + versión + variante) sigue siendo la interfaz del Normative-Root al Customizing («herencia de interfaces»); el sufijo (resto de los 128 bits) porta la clasificación GitCover (L1–L6, categorías/patrones de bits, búsqueda por registro/palabra clave). Los valores temporales anteriores a la época elegida son un error definido (sin wrap de signo): la aritmética de .NET es con signo (DateTimeOffset devuelve long negativos para pre-1970), y solo se documenta no negativo — así se conservan el orden y el formato RFC, mientras que los datos históricos (p. ej., fechas de nacimiento, PII) siguen siendo clasificables.

Regla de nombres de JSON de instancia (`

El registro de datos base (JSON de instancia) de un objeto se deposita en la ruta del repositorio Git —y por tanto en el WorkingDirectory— como {docType}.{classId}.json (docType = abreviatura de clase, classId = V7GUID-Class-Identifier; p. ej., PII_PERSON.01a12f72-4c75-74f1-8626-dd1ae65b6062.json). Esto es un índice natural: las herramientas cercanas al SO encuentran los datos de instancia mediante {docType} y/o {classId}, sin conocer un nombre de archivo fijo. Se aplica a todos los artefactos de datos (entre otros, PII persons/<uuidv7>/, entradas de registro, esquemas de comprobante).

Base temporal y de flags (GitCover.Core)

• validFrom/validTo (nullable, SSoT temporal-1.0): validFrom = ancla «desde» (inicio del conjunto de solución), validTo según contexto — consulta diaria day: validTo < date.AddDays(1). null = «desconocido desde cuándo» / «sigue vigente». Lógica central: GitCover.Core.Types.Temporal.
• Regla de dos estados booleanos: absent == false; un valor presente sigue siendo determinante (false/f/n/no/0/null son falsy, nunca interpretar como true); false puede omitirse (minimización de bloat).
• Flag-BitVectors (acumulativos, [Flags]): el esquema base de flags ENUM pertenece al esquema (phase-flags-1.0), no a la instancia; las instancias llevan status_flags (solo los establecidos; presencia == establecido) + phases_result + current_phase como string.Join(" + ", …). Código: GitCover.Core.Types.Flags.
• Esquemas que referencian 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 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 investiga si las organizaciones/equipos de Git pueden representar clientes OAuth2 y permisos y gestionar de forma eficiente más de 1.000 usuarios.

Responsabilidad de dos niveles para PII (legal + organizativa)

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

• Legal (nivel de tenant): la entidad jurídica es responsable del tratamiento conforme a la protección de datos (Art. 4 Nr. 7 DSGVO). La tenant_id se deriva de forma determinista de la V7GUID del directorio TOP (véase [Conceptos: Registro central de tenants](v7guid-beleg-ketten-und-cryptographic-evidence.html #zentrales-tenant-register)).
• Organizativo (PMO/Org-Unit): dentro de un tenant, varias unidades organizativas (PMO, departamentos, ubicaciones) pueden ser responsables de forma autónoma de subconjuntos de PII. Esto corresponde a la estructura de unidades organizativas de Active Directory. La asignación se realiza mediante el claim personalizado org_unit_id, que en el others.json del tenant se mapea a rutas de repositorio.

Asignación persona a rol (puente PII) — trabajo pendiente

Asignación persona a rol (puente PII) — trabajo pendiente

Los contenedores de firma GCPN referencian participantes (attendees) como Actors (rol en el tenant, función en la empresa) y solo contienen personas pseudonimizadas (persons.mappings con referencia a PII). La asignación canónica persona → roles → Org-Units reside en el círculo PII (gitignored) — para un modelo integral, las siguientes relaciones aún deben elaborarse en detalle en el GCBoK:

Vinculación: gcpn-container-2.7 → attendees (roles en el expediente) → persons.mappings (referencia PII pseudonimizada) → PII-Repo (asignación canónica). Hasta la elaboración, las referencias pseudonimizadas aquí documentadas se consideran una solución transitoria.

Jerarquía de claims en la Inlet-Pipeline

La Inlet-Pipeline (véase Procedimientos: aislamiento de mandantes 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": "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 portafolio, 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 en «Arquitectura de keyring GPG».