GitCover Symbol GCBoKGitCover Body of Knowledge

Eje 14: Certificación (provisional)

Nota: Este capítulo describe los planes para la Fase 3 (Q2–Q4 2027). Las capacidades de certificación esbozadas aquí están previstas o planificadas. Su consecución depende del éxito de la comunidad y de la aceptación del GCBoK. En el momento actual (2026) nadie puede predecirlo seriamente.

Objetivo

Establecer un esquema de certificación para el compliance nativo de Git sobre la base del GCBoK, que cumpla los requisitos estructurales de ISO/IEC 24773 (BoK como base para esquemas de certificación) — siempre que la comunidad acepte el GCBoK como estándar de referencia normativo.

ISO/IEC 24773 — Requisitos estructurales (breve resumen)

ISO/IEC 24773 define cómo debe estar estructurado un Body of Knowledge (BoK) para que pueda servir de base a esquemas de certificación. Exigencias principales:

Nivel Término ISO/IEC 24773 Equivalente en el GCBoK (Estado)
1 Knowledge Areas (KAs) 14 ejes (01–14) — existentes
2 Competencies por KA previsto — definir por eje
3 Learning Outcomes planificado — objetivos de aprendizaje medibles por Competency
4 Assessment Criteria previsto — criterios de evaluación para los exámenes
5 Professional Roles planificado — asignación de roles (p. ej. Compliance Engineer, Auditor)
6 Competency Levels previsto — niveles (Entry / Practitioner / Expert)

Enfoque planificado (Fase 3, Q2–Q4 2027)

1. Definición de Competencies por eje (previsto)

Para cada uno de los 14 ejes se deben formular 2–4 Competencies. Ejemplo (eje 02 — Conceptos):

Competency ID Título (título de trabajo) Descripción (planificado)
GCBOK-02-C1 Aplicar la clasificación V7GUID Asignar de forma determinista la jerarquía L1–L6 + los campos ampliados (RepositoryId, ProcessTypeId, GatewayId, VariantId)
GCBOK-02-C2 Construir cadenas de evidencia (Evidence Chains) Encadenamiento prev_sha256, firmas GPG, construir cadenas de evidencia V7GUID para las pruebas GoBD
GCBOK-02-C3 Validar la Cryptographic Evidence Chain Verificar hash de commit de Git + firma GPG + V7GUID como verificabilidad O(1)

2. Learning Outcomes por Competency (planificado)

Por Competency 2–3 Learning Outcomes medibles (taxonomía de Bloom: Remember → Create). Ejemplo GCBOK-02-C1:

LO ID Formulación (planificado) Nivel de Bloom
GCBOK-02-C1-LO1 Poder explicar los seis niveles de jerarquía (L1–L6) y su anchura de 4 bits Understand
GCBOK-02-C1-LO2 Determinar la notación class correcta (L1_L2_L3_L4_L5_L6) para una evidencia dada Apply
GCBOK-02-C1-LO3 Reconocer y corregir una clasificación V7GUID errónea según las reglas del Dictionary Analyze

3. Assessment Criteria (previsto)

Criterio Descripción (previsto)
Examen teórico Opción múltiple / respuesta corta sobre conceptos, definiciones, normas
Ejercicio práctico En un entorno Git de prueba: generar el V7GUID, crear el Sidecar, validar la cadena de evidencia
Estudio de caso Resolver un escenario de compliance dado (p. ej. cierre anual GoBD) con los medios del GCBoK

4. Mapeo de Professional Roles (planificado)

Rol Ejes relevantes (ejemplo) Nivel de certificación (previsto)
Compliance Engineer 01, 02, 04, 05, 06 Practitioner
Git-native Auditor 01, 02, 05, 07, 14 Expert
Developer (GitCover Stack) 02, 03, 04, 06 Entry → Practitioner
PMO / Governance Lead 01, 05, 07, 10, 14 Practitioner → Expert

5. Competency Levels (previsto)

Nivel Denominación Requisitos previos (previsto)
Entry Comprensión de los fundamentos Examen teórico aprobado; capítulos 01–06 del GCBoK leídos
Practitioner Competencia de aplicación Entry + ejercicio práctico + 1 estudio de caso; al menos 1 año de experiencia en proyectos
Expert Competencia de diseño Practitioner + varios estudios de caso; contribución a la comunidad (PRs, Reviews, traducciones); al menos 3 años de experiencia

Dependencias y riesgos

Factor Influencia en la certificación
Aceptación de la comunidad Sin un uso amplio del GCBoK como obra de referencia, no habrá demanda de certificación
Madurez de las herramientas Webstatic, OPA, OSCAL-Tooling deben ser estables y estar documentados
Ecosistema de socios Asociaciones BSI/ENISA (Roadmap Fase 3) como ancla de credibilidad
Marco jurídico Los esquemas de certificación en DE/UE requieren acreditación (DAkkS o similar)

Próximos pasos (provisional)

  1. Recopilar feedback de la comunidad (Gitea Issues, Discussions) — ¿existe demanda?
  2. Elaborar y revisar Competencies piloto para 2–3 ejes (p. ej. 02, 04, 05)
  3. Taller de Learning Outcomes con posibles formadores/examinadores
  4. Assessment-Tooling como prototipo (¿basado en webstatic? ¿exportación OSCAL?)
  5. Decisión: continuar solo si hay una respuesta positiva de la comunidad

Referencias