Perfil EGAF Core: garantía L1 para la entrega verificada

2026-08-30 · Garantía ·

El perfil Core es la línea base predeterminada de EGAF. Si un repositorio no tiene .egaf/profile.yaml, el evaluador usa core, de modo que los controles obligatorios de L1 siempre aplican. Todos los demás perfiles de industria de esta serie extienden Core y unen más marcos encima. Esa es toda la regla de composición: añadir, nunca relajar.

Sistema en prelanzamiento, operado por su fundador; las etiquetas de capacidad actuales describen el límite de la evidencia.

Cómo funciona el Evidence-Gated Assurance Framework

El Evidence-Gated Assurance Framework (EGAF) es un estándar de garantía orientado a la especificación. Está En curso. Un proyecto declara conformidad con EGAF L1, L2 o L3 en un commit dado, con evidencia adjunta. No es una certificación, una acreditación ni una autorización. La evaluación independiente de cualquier organización sigue siendo una cuestión aparte.

Tres partes componen una ejecución:

  1. Un catálogo de controles. Cada control es un check de máquina (un artefacto producido por una herramienta independiente) o un evidence: attestation (una declaración firmada por un principal identificado). Una comprobación declarada sin un artefacto que la respalde es DRIFT, nunca PROVEN. Un archivo vacío pero analizable no es un veredicto.
  2. Un evaluador determinista. Las mismas entradas producen un informe de conformidad idéntico byte a byte. El evaluador no ejecuta pruebas ni escáneres. Lee artefactos que otras herramientas ya produjeron y registra sus digests. Un agente no puede fabricar un PROVEN sin producir el artefacto que la comprobación nombra.
  3. Un perfil versionado. .egaf/profile.yaml en el repositorio consumidor es lo que evalúa CI. Si ese archivo no está presente, el evaluador usa el perfil core incluido, por lo que los controles obligatorios de L1 siempre aplican. Los perfiles solo pueden endurecer un umbral; una anulación que lo relaje se rechaza en el momento de la validación.

Tres niveles. L1 Core es obligatorio para declarar cualquier conformidad con EGAF: trazabilidad, límites de complejidad y duplicación, cobertura de sentencias y de ramas de toda la base de código, mutación en los archivos modificados, integridad del verificador, evidencia firmada, higiene de la cadena de suministro. Una EXCEPTION nunca satisface un control L1. L2 Regulated añade controles de perfil de industria (paquetes de evidencia, retención, registros de riesgo de modelo). L3 Safety-critical añade independencia, cobertura estructural, entradas para la calificación de herramientas y vinculación con peligros. Si falla un control L1 aplicable, la primera línea del informe es L0.

El estado de un control se deriva de los siete resultados de comprobación que ya se usan en los paquetes de evidencia de Koinessa:

Resultado de la comprobación Estado del control
PASS PROVEN
FAIL FAILED
SKIPPED-NOT-APPLICABLE con una razón registrada NOT-APPLICABLE
INFRASTRUCTURE-ERROR, TOOL-MISSING, EVIDENCE-INVALID o ABSTAIN DRIFT
Evidencia ausente DRIFT

Un nivel se alcanza únicamente cuando todos los controles aplicables en ese nivel y en los niveles inferiores están PROVEN o NOT-APPLICABLE (L2/L3 también pueden contar con una EXCEPTION vigente con un aprobador independiente). El informe siempre muestra dos listas de honestidad: No probado (FAILED y DRIFT) y Aceptado sin prueba (NOT-APPLICABLE y EXCEPTION). Una insignia limpia sobre un bloque de honestidad vacío es el fallo que el marco existe para evitar.

Los marcos son orientación. Los controles son comportamiento. La evidencia demuestra que el comportamiento ocurrió. Las cargas organizativas — formación, seguridad física, BAA, una evaluación C3PAO, la calificación de herramientas DO-330, un encargo SOC 2 Type II — siguen recayendo en la organización. El catálogo cita identificadores de cláusulas y paráfrasis; no reproduce texto normativo.

El catálogo que describe esta serie es una instantánea con estado Medido: 109 controles, incorporados a Koinessa en el pin 0.0.0-dev+98d08ef el 2026-08-30. El repositorio público de la especificación está Planeado; hasta que el operador cree su grupo de GitLab, trata EGAF como un borrador pre-1.0 etiquetado y pendiente de publicación. El primer informe de conformidad del propio Koinessa en la rama principal está Planeado.

Consulta el libro blanco de Koinessa para la tesis más amplia de Evidence-Gated Agentic Development, y el informe de entrega verificada para lo que este sistema ya publica sobre sí mismo.

El perfil Core (id core, L1)

En curso. Fuente: vendor/egaf/catalog/profiles/core.yaml, pin 0.0.0-dev+98d08ef.

Core es L1. Es el objetivo de trinquete: exigente tanto en los controles estructurales como en los umbrales numéricos, con cada umbral citado. El operador dictaminó que ese estándar no se mueve para Koinessa — complejidad de máximo 15 por función y 100 por archivo, duplicación de máximo 2 por ciento, cobertura de sentencias y de ramas del 100 por ciento en toda la base de código, puntuación de mutación de al menos 80 por ciento por archivo fuente modificado. Los pragmas de exclusión de cobertura cuentan como no cubiertos. Una EXCEPTION nunca satisface un control L1 obligatorio; solo suprime la alerta y se incluye en «Aceptado sin prueba».

Marcos que lleva Core (la unión que heredan todos los demás perfiles): SSDF v1.1, NIST SP 800-218A, SLSA v1.2, in-toto v1, NIST SP 800-207, NIST AI RMF 1.0, NIST AI 600-1, ISO/IEC 5055, ISO/IEC 25010, ISO/IEC/IEEE 29119, WCAG 2.2, OpenTelemetry y las prácticas DORA.

De forma predeterminada, la aplicabilidad corresponde a proyectos agénticos que tienen releases y deploys. Un proyecto que genuinamente no usa agentes de codificación establece agentic: false en su propio perfil; el valor predeterminado — que la ausencia del campo implica aplicabilidad — se deja intacto en ui, firmware, services y data_store, de modo que una línea base genérica nunca reduzca en silencio aquello a lo que se aplican los controles de un adoptante específico.

La retención es de 12 meses. Ese número es un piso para un proyecto que no está bajo ningún régimen regulatorio específico. Queda por debajo de todos los mínimos financieros y de salud con fuente citada en los perfiles regulados del catálogo. Un proyecto bajo un régimen específico extiende uno de esos perfiles, en vez de aumentar este número directamente.

own_test_runners es obligatorio y no puede estar vacío en L1. Core distribuye vitest como marcador de posición, que todo adoptante debe reemplazar por su propio runner antes de basarse en el perfil. Una herramienta ahí listada nunca puede respaldar un veredicto de herramienta independiente para la familia TST. La independencia del productor es un campo, no una afirmación en prosa.

since_commit empieza como un centinela de 40 ceros. Los controles de trazabilidad (de TRC-01 a TRC-03) no se evalúan sobre el historial hasta que el adoptante fija ese campo en el commit donde comenzó su propia evaluación EGAF. Los commits anteriores a ese punto de corte quedan exentos.

Core es lo que ejecutas si quieres el estándar y todavía no has elegido una capa regulada o de seguridad crítica. El perfil OSS Maintainer es Core más identidad de cadena de suministro de código abierto. Las páginas L2 y L3 de esta serie son Core más un régimen.

Lo que esta página no afirma

La conformidad con EGAF es una declaración por commit que un proyecto hace sobre sí mismo, con evidencia adjunta. No otorga una certificación, un nivel SLSA ni una autorización para operar. Citar un marco en un perfil es una correspondencia, no un estado que el adoptante haya alcanzado. Los elementos planeados no llevan fechas.

Este artículo es uno de diez en una serie. Cada página conserva la misma mecánica y cambia el perfil.

El resto del blog de ingeniería cubre el bucle de verificación sobre el que se apoya EGAF. La página principal de Koinessa expone la posición del producto.