security-policies

O repositório security-policies guarda as regras que o GitLab aplica em todo o grupo projectairframe: os jobs que ele injeta nos pipelines, quer um repositório peça ou não, e as regras sobre quem precisa aprovar um merge. Ele é pequeno, poucos arquivos, e é o único repositório que o controle de aprovação não julga. Isso é de propósito: ele é a via de emergência da plataforma.

Para que serve

O arquivo de pipeline de um produto pertence à sua equipe, então nada que a plataforma precise rodar sempre pode viver ali. As políticas de segurança do GitLab rodam ao lado do pipeline do próprio repositório e ele não pode removê-las. Este repositório é onde essas políticas vivem, então mudá-las é um merge request revisado como todo o resto.

O que ele contém

Um arquivo de políticas, .gitlab/security-policies/policy.yml, guarda quatro tipos de política:

Duas políticas de execução de pipeline. A do grupo todo injeta dois jobs em cada pipeline: gate:integrity, que pergunta ao controle de aprovação se o pipeline pode rodar, e validate:injected. O endereço do controle está escrito no próprio job, um endereço vazio falha de forma fechada, e a política exclui os pipelines deste repositório. A de produtos injeta o componente validate sobre as raízes do produto e o componente build-test, com sua evidência de testes, no pipeline de cada repositório de produto.
Duas políticas de aprovação de merge request. A primeira exige, em cada branch padrão, a aprovação de uma pessoa nomeada do catálogo que não seja nem o autor nem quem fez commits; as aprovações são zeradas quando commits novos são enviados. A segunda, a required ownership gate, exige a própria aprovação do controle no último commit do merge request, em cada repositório que seu alcance nomeia: hoje, todos os repositórios menos este. Um repositório criado depois entra com um merge request aqui, depois que a lista do próprio controle o adicionou.
Uma política de execução de análises: a detecção de segredos, a análise de dependências e a análise estática do GitLab em cada merge request e todo dia.

As duas políticas de execução de pipelines não permitem sobrescrever variáveis: nenhuma variável de projeto, de grupo, de instância nem de pipeline chega aos jobs que elas injetam. Uma configuração em um projeto não pode apontar o gate:integrity para outro endereço, esvaziá-lo nem mudar o comportamento das ferramentas de validação.

Dois templates guardam os jobs injetados, e um script, approvers.py, verifica se quem aprova segundo a política são exatamente as pessoas ativas do catálogo com conta no GitLab, nomeadas uma a uma, nunca um papel.

Como ele se conecta

Cada repositório roda seus jobs. Os jobs do grupo todo chegam a cada pipeline do grupo, menos os deste repositório; os de produtos chegam a cada repositório nos grupos de jornadas, onde os produtos vivem.
O controle de aprovação depende dele. A required ownership gate é o que torna a aprovação do controle uma condição para integrar.
O control-plane o iniciou. A raiz gitlab do control-plane escreveu esses arquivos uma vez, na inicialização, e desde então ignora o seu conteúdo.
Ele faz parte de cada versão. Uma versão da plataforma nomeia o commit deste repositório, junto com as outras partes.

Quem o muda, e por que ele é a via de emergência

Uma mudança aqui é um merge request aprovado por uma pessoa nomeada que não a escreveu. O pipeline verifica o arquivo de políticas contra o esquema publicado pelo GitLab e roda a verificação de quem aprova. Mas aqui a aprovação do controle não é exigida, e os pipelines deste repositório não levam o gate:integrity, então um merge request aqui não espera o controle.

O motivo é a recuperação. Se o controle de aprovação não puder aprovar ou não puder ser alcançado, todos os outros repositórios ficam bloqueados, inclusive qualquer correção do próprio controle. Um merge request aqui, só com a aprovação de alguém que não é o autor, pode tirar um repositório do alcance da required ownership gate e da política de execução de pipelines do grupo todo por no máximo duas horas, e esse repositório pode voltar a integrar; o merge request inverso traz as duas de volta. Isso foi ensaiado em 2026-10-02: com o controle no ar, a regra saiu de um repositório 10 segundos depois do merge e voltou 16 segundos depois do inverso, e com o controle inalcançável por dois minutos, o pipeline deste repositório passou mesmo assim. Concessões e via de emergência tem o procedimento completo.

Então o que protege este repositório é a aprovação de uma pessoa nomeada, nunca a do seu autor. Hoje quem aprova são as contas do mantenedor, porque uma só pessoa opera a plataforma: o mecanismo é aplicado, mas a separação entre duas pessoas ainda não é real.

Onde fica

No repositório security-policies: