security-policies

El repositorio security-policies guarda las reglas que GitLab aplica en todo el grupo projectairframe: los trabajos que inyecta en los pipelines, los pida un repositorio o no, y las reglas sobre quién debe aprobar un merge. Es pequeño, unos pocos archivos, y es el único repositorio que la compuerta de aprobación no juzga. Es a propósito: es la vía de emergencia de la plataforma.

Para qué sirve

El archivo de pipeline de un producto pertenece a su equipo, así que nada que la plataforma deba ejecutar siempre puede vivir ahí. Las políticas de seguridad de GitLab se ejecutan junto al pipeline propio de un repositorio y este no puede quitarlas. Este repositorio es donde viven esas políticas, así que cambiarlas es un merge request revisado como todo lo demás.

Qué contiene

Un archivo de políticas, .gitlab/security-policies/policy.yml, guarda cuatro tipos de política:

Dos políticas de ejecución de pipelines. La de todo el grupo inyecta dos trabajos en cada pipeline: gate:integrity, que le pregunta a la compuerta si el pipeline puede ejecutarse, y validate:injected. La dirección de la compuerta está escrita en el propio trabajo, una dirección vacía falla de forma cerrada, y la política excluye los pipelines de este repositorio. La de productos inyecta el componente validate sobre las raíces del producto y el componente build-test, con su evidencia de pruebas, en el pipeline de cada repositorio de producto.
Dos políticas de aprobación de merge requests. La primera exige, en cada rama por defecto, la aprobación de una persona con nombre del catálogo que no sea ni el autor ni quien hizo commits; las aprobaciones se reinician cuando se suben commits nuevos. La segunda, la required ownership gate, exige la propia aprobación de la compuerta en el último commit del merge request, en cada repositorio que nombra su alcance: hoy, todos los repositorios menos este. Un repositorio creado después se suma con un merge request aquí, una vez que la lista propia de la compuerta lo agregó.
Una política de ejecución de análisis: la detección de secretos, el análisis de dependencias y el análisis estático de GitLab en cada merge request y todos los días.

Las dos políticas de ejecución de pipelines no permiten anular variables: ninguna variable de proyecto, de grupo, de instancia ni de pipeline llega a los trabajos que inyectan. Un ajuste en un proyecto no puede apuntar gate:integrity a otra dirección, vaciarla ni cambiar cómo se comportan las herramientas de validación.

Dos plantillas guardan los trabajos inyectados, y un script, approvers.py, verifica que quienes aprueban según la política sean exactamente las personas activas del catálogo con cuenta en GitLab, nombradas una por una, nunca un rol.

Cómo se conecta

Cada repositorio ejecuta sus trabajos. Los trabajos de todo el grupo llegan a cada pipeline del grupo salvo los de este repositorio; los de productos llegan a cada repositorio en los grupos de recorridos, donde viven los productos.
La compuerta de aprobación depende de él. La required ownership gate es lo que convierte la aprobación de la compuerta en una condición para integrar.
control-plane lo inició. La raíz gitlab de control-plane escribió estos archivos una vez, en el arranque, y desde entonces ignora su contenido.
Es parte de cada versión. Una versión de la plataforma nombra el commit de este repositorio, junto con las otras partes.

Quién lo cambia, y por qué es la vía de emergencia

Un cambio aquí es un merge request aprobado por una persona con nombre que no lo escribió. El pipeline verifica el archivo de políticas contra el esquema publicado por GitLab y ejecuta la verificación de quienes aprueban. Pero aquí no se exige la aprobación de la compuerta, y los pipelines de este repositorio no llevan gate:integrity, así que un merge request aquí no espera a la compuerta.

La razón es la recuperación. Si la compuerta no puede aprobar o no se puede alcanzar, todos los demás repositorios quedan bloqueados, incluida cualquier corrección de la propia compuerta. Un merge request aquí, solo con la aprobación de alguien que no es el autor, puede sacar un repositorio del alcance de la required ownership gate y de la política de ejecución de pipelines de todo el grupo por dos horas como máximo, y ese repositorio puede volver a integrar; el merge request inverso devuelve las dos. Esto se ensayó el 2026-10-02: con la compuerta en funcionamiento, la regla dejó un repositorio 10 segundos después del merge y volvió 16 segundos después del inverso, y con la compuerta inalcanzable durante dos minutos, el pipeline de este repositorio pasó igual. Concesiones y vía de emergencia tiene el procedimiento completo.

Así que lo que protege este repositorio es la aprobación de una persona con nombre, nunca su autor. Hoy quienes aprueban son las cuentas del mantenedor, porque una sola persona opera la plataforma: el mecanismo se aplica, pero la separación entre dos personas todavía no es real.

Dónde está

En el repositorio security-policies: