Governação da segurança de pipelines CI/CD para auditorias em 2026
São 08:17 de uma segunda-feira e o Diretor de Segurança da Informação de uma fintech em crescimento recebe a mensagem que qualquer líder de segurança receia:
“A build de produção parece limpa, mas o hash do artefacto não corresponde ao commit de origem.”
Em poucos minutos, a engenharia confirma que a release passou nos testes unitários, que o ticket de implementação existe e que o serviço exposto ao cliente está estável. Mas o pipeline conta outra história. Um runner de CI autoalojado foi reutilizado em vários projetos. Uma credencial temporária de nuvem permaneceu ativa mais tempo do que o previsto. O registo de artefactos mostra uma imagem de contentor assinada, mas a chave de assinatura estava acessível a partir do mesmo runner que executou scripts de build não fidedignos.
O gestor de releases consegue provar que algo foi implementado. O que a organização não consegue provar, pelo menos não com a rapidez necessária, é o que foi compilado, quem o aprovou, se o ambiente de build estava limpo e se a evidência resistiria a uma auditoria ou a uma investigação de incidente.
Isto já não é apenas um problema de DevOps.
Em 2026, a governação da segurança de pipelines CI/CD situa-se na interseção entre a segurança da cadeia de fornecimento de software, a resiliência operacional, a responsabilização em matéria de privacidade, a segurança de produto e a supervisão do risco cibernético ao nível do conselho de administração. A NIS2 obriga os órgãos de gestão a aprovar e supervisionar medidas de gestão de riscos de cibersegurança. O DORA exige que as entidades financeiras governem o risco das TIC, os incidentes, os testes e as dependências de terceiros. O RGPD da UE exige que responsáveis pelo tratamento e subcontratantes demonstrem segurança adequada e responsabilização relativamente aos dados pessoais. O Cyber Resilience Act eleva as expectativas de mercado para produtos seguros com elementos digitais, atualizações seguras e tratamento de vulnerabilidades. A ISO/IEC 27001:2022 exige um SGSI que transforme o tratamento de riscos em operações controladas e evidenciadas.
O pipeline tornou-se o rasto de auditoria da confiança no software moderno.
A nova pergunta de conformidade: consegue provar o que chegou à produção?
Durante anos, os programas DevSecOps concentraram-se em adicionar scanners aos pipelines. A análise estática, as verificações de dependências, a análise de segredos, a análise de contentores e a validação de infraestrutura como código tornaram-se comuns. Esses controlos continuam a ser relevantes, mas não respondem à pergunta de governação que auditores, reguladores, clientes e conselhos de administração colocam agora:
A organização consegue provar que cada implementação em produção teve origem em código-fonte aprovado, foi compilada num ambiente controlado, produziu um artefacto verificável, passou pelos pontos de controlo de segurança exigidos, utilizou credenciais aprovadas, seguiu a gestão de alterações e gerou evidência passível de preservação?
Os atacantes sabem que sistemas de build, dependências de pacotes, tokens de programadores, runners de CI, automatização de releases, registos de artefactos e funções de implementação na nuvem são alvos de elevado valor. Um pipeline comprometido pode contornar as defesas tradicionais porque utiliza automatização confiável para introduzir código malicioso em ambientes confiáveis.
Por isso, um modelo maduro de governação da segurança de pipelines CI/CD necessita de seis pilares de evidência.
| Pilar de evidência | O que demonstra | Evidência típica |
|---|---|---|
| Integridade da origem | O artefacto implementado teve origem em código-fonte aprovado | ID do commit, proteção de branches, aprovações de pull request, commits assinados, registos de auditoria do repositório |
| Proveniência de build | O artefacto foi produzido por um pipeline conhecido, em condições controladas | ID da build, identidade do runner, receita de build, manifesto de dependências, hash do artefacto, registo de assinatura |
| Endurecimento dos runners | O ambiente de execução não podia ser facilmente reutilizado ou adulterado | Registos de runners efémeros, imagem de referência, estado dos patches, controlos de isolamento, restrições de rede |
| Integridade do artefacto | O pacote de release não foi alterado após a build | Assinatura, checksum, registo do repositório, registo de promoção, política de tags imutáveis |
| Governação da implementação | A alteração foi autorizada, testada e rastreável | ID do pedido de alteração, evidência de aprovação, registos de promoção entre ambientes, plano de reversão |
| Preparação forense | A evidência pode ser preservada durante uma auditoria ou resposta a incidentes | Registos exportados, capturas de ecrã, hashes de ficheiros, registo da cadeia de custódia |
É aqui que a abordagem da Clarysec difere da conformidade baseada em checklists. Tratamos a plataforma CI/CD como um processo de negócio governado, e não apenas como uma ferramenta técnica. Esse processo deve estar incluído no âmbito do SGSI, ser sujeito a avaliação de riscos, controlado, monitorizado, auditado e melhorado.
Inclua CI/CD no SGSI da ISO/IEC 27001:2022
A ISO/IEC 27001:2022 começa pelo contexto, pelas partes interessadas e pelo âmbito. As cláusulas 4.1 a 4.4 exigem que as organizações compreendam questões internas e externas, determinem os requisitos das partes interessadas, identifiquem requisitos legais, regulamentares e contratuais, e definam o âmbito do SGSI considerando as dependências com outras organizações.
Para um prestador SaaS, fintech, prestador de serviços geridos, fornecedor de software ou empresa nativa da nuvem, o CI/CD está quase sempre dentro desse âmbito, porque afeta diretamente a prestação do serviço, os dados de clientes, a infraestrutura de produção e os compromissos contratuais.
As cláusulas 5.1 a 5.3 tornam a liderança responsável pelo SGSI. Isto é relevante porque a automatização moderna de releases situa-se entre engenharia, segurança, operações de nuvem, compras, conformidade e gestão de produto. Se nenhum executivo assumir o apetite ao risco da automatização de implementações em produção, a organização acaba, normalmente, com ferramentas fragmentadas e evidência inconsistente.
As cláusulas 6.1.1 a 6.1.3 fornecem a base de planeamento. A organização deve avaliar riscos para a confidencialidade, integridade e disponibilidade, identificar proprietários do risco, comparar riscos com critérios, selecionar tratamentos, comparar os controlos selecionados com o Anexo A, produzir uma Declaração de Aplicabilidade e obter aprovação para o plano de tratamento de riscos e para o risco residual.
Uma avaliação de riscos de CI/CD não deve limitar-se a declarar “risco da cadeia de fornecimento de software”. Deve identificar cenários realistas:
- Um script de build malicioso exfiltra chaves de assinatura a partir de um runner partilhado.
- Um programador contorna a proteção de branches e implementa código sem revisão.
- Uma ação de terceiro comprometida modifica um artefacto durante a build.
- Uma credencial de staging concede acesso à produção.
- Uma implementação ocorre sem pedido de alteração associado.
- Os registos do pipeline necessários para a reconstrução de um incidente são sobrescritos após sete dias.
- Um incidente de envenenamento de dependências chega à pré-produção ou à produção.
A cláusula 8.1 exige então a operação planeada e controlada dos processos do SGSI, evidência documentada, controlo das alterações planeadas, revisão de alterações não intencionais e controlo de processos, produtos ou serviços fornecidos externamente que sejam relevantes para o SGSI. Se o pipeline altera a produção, deve produzir evidência de operação controlada.
O modelo de controlo da Clarysec para entrega segura de software
A Clarysec liga políticas, controlos e evidência de auditoria. O Zenith Blueprint: roteiro de 30 passos para auditores Zenith Blueprint coloca DevOps seguro e desenvolvimento seguro na fase de Gestão de riscos, passo 14. Indica que as organizações devem proteger as ferramentas CI/CD, assegurar que apenas pessoal autorizado pode acionar implementações, utilizar MFA para acesso ao pipeline, proteger a integridade dos artefactos de build, e registar e monitorizar ações CI/CD.
“Controlos de pipeline DevOps: as ferramentas CI/CD devem ser protegidas — apenas pessoal autorizado pode acionar implementações; utilizar MFA para acesso ao pipeline; proteger a integridade dos artefactos de build. Registar e monitorizar ações CI/CD.”
Essa orientação torna-se acionável quando é traduzida em cláusulas de política e requisitos de evidência.
A P24 Política de Desenvolvimento Seguro Política de Desenvolvimento Seguro estabelece:
“Os artefactos de build devem ser assinados e rastreáveis aos commits de origem.”
Este é um dos controlos mais fortes num programa de governação CI/CD. Indica à engenharia que um artefacto de produção deve transportar uma linhagem verificável até ao controlo de origem. Também indica aos auditores o que testar: selecionar uma release de produção, inspecionar a assinatura do artefacto, validar a referência do commit, rever a aprovação do pull request e confirmar o registo da build do pipeline.
A mesma política estabelece:
“Todas as atividades de desenvolvimento devem ser acompanhadas através de sistemas de controlo de versões aprovados, com controlos de acesso aplicados, trilhos de auditoria e proteções de branches.”
Isto desloca a governação para montante. Se os repositórios de origem não estiverem protegidos, a proveniência de build é fraca. Se as proteções de branches puderem ser contornadas, o pipeline poderá compilar fielmente código não aprovado. Se os trilhos de auditoria estiverem desativados, a reconstrução de incidentes dependerá da memória e de capturas de ecrã, em vez de evidência.
Para organizações de menor dimensão, a Política de Desenvolvimento Seguro para PME Política de Desenvolvimento Seguro para PME inclui um requisito mínimo pragmático:
“Registo da versão do código, data de implementação e aprovador”
Esse registo simples de implementações é um ponto de partida sólido. Muitas PME não precisam de governação pesada de releases no primeiro dia, mas precisam de saber que versão entrou em produção, quando e quem a aprovou.
A política para PME também estabelece:
“O acesso a ferramentas ou sistemas de implementação em produção deve ser controlado, registado e revisto periodicamente pelo Diretor-Geral ou pelo prestador de TI.”
Este é o passo de governação que muitas equipas mais pequenas omitem. Uma plataforma CI/CD com credenciais de produção na nuvem é uma via de acesso privilegiado à produção.
Três áreas de controlo da ISO/IEC 27002:2022 por trás de CI/CD seguro
O Zenith Controls: guia de conformidade cruzada Zenith Controls é a bússola de conformidade cruzada da Clarysec para mapear normas e referenciais oficiais para relações práticas de controlo. Para a governação da segurança de pipelines CI/CD, três áreas de controlo da ISO/IEC 27002:2022 são centrais.
| Controlo ISO/IEC 27002:2022 | Papel na governação CI/CD | Controlos e evidência relacionados |
|---|---|---|
| 5.21 Gestão da segurança da informação na cadeia de fornecimento das TIC | Governa plataformas CI/CD, ações de terceiros, repositórios de pacotes, serviços de build na nuvem, registos e desenvolvimento externalizado | Diligência prévia de fornecedores, requisitos contratuais de segurança, registos de prestadores, inventários de dependências |
| 8.25 Ciclo de vida de desenvolvimento seguro | Integra a segurança nos requisitos, conceção, codificação, build, testes e release | Arquitetura segura, programação segura, testes de segurança, assinatura de artefactos, evidência de release |
| 8.32 Gestão de alterações | Assegura que as implementações são intencionais, justificadas, aprovadas e auditáveis | ID do pedido de alteração, aprovação, registo de implementação, plano de reversão, registo de alteração de emergência |
O Zenith Controls descreve 5.21 como um controlo preventivo que suporta confidencialidade, integridade e disponibilidade, tendo a segurança nas relações com fornecedores como capacidade operacional-chave. Isto enquadra-se no CI/CD porque os pipelines modernos dependem de serviços externos: plataformas de controlo de origem, runners alojados, registos de contentores, repositórios de pacotes open source, ações GitHub de terceiros, ferramentas de análise, Interfaces de Programação de Aplicações de implementação na nuvem e programadores externalizados.
No mapeamento de 5.21, o Zenith Controls liga a segurança da cadeia de fornecimento das TIC a 5.19 Segurança da informação nas relações com fornecedores, 5.20 Tratamento da segurança da informação nos acordos com fornecedores, 8.27 Arquitetura segura de sistemas e princípios de engenharia, 8.28 Programação segura, 8.29 Testes de segurança no desenvolvimento e na aceitação, 5.15 Controlo de acesso, 5.28 Recolha de evidência, 8.25 Ciclo de vida de desenvolvimento seguro e 8.30 Desenvolvimento externalizado.
Para 8.25, o Zenith Controls identifica o ciclo de vida de desenvolvimento seguro como um controlo preventivo que protege confidencialidade, integridade e disponibilidade. Liga requisitos de segurança, arquitetura, codificação, testes, desenvolvimento externalizado e 8.31 Separação de ambientes de desenvolvimento, teste e produção.
Para 8.32, o Zenith Controls enquadra a gestão de alterações como a ponte entre desenvolvimento e operações. Relaciona-a com 8.9 Gestão da configuração, 8.8 Gestão de vulnerabilidades técnicas, SDLC seguro e resposta a incidentes. É por isso que a automatização de implementações não pode ficar fora da governação de alterações. É o mecanismo através do qual as alterações em produção acontecem.
Proveniência de build: a história da release que os auditores conseguem seguir
A proveniência de build é a capacidade de responder, com evidência, de onde veio um artefacto de software e como foi produzido. Um registo forte de proveniência conta a história de uma release:
- Que repositório de origem e commit foram utilizados.
- Que branch ou tag desencadeou a build.
- Que pull request, revisor e aprovação foram associados.
- Que definição de pipeline foi executada.
- Que runner executou a tarefa.
- Que dependências e imagens de base foram utilizadas.
- Que testes e pontos de controlo de segurança foram executados.
- Que artefacto foi produzido.
- Que assinatura ou hash foi gerado.
- Que implementação consumiu o artefacto.
A P05 Política de Gestão de Alterações Política de Gestão de Alterações fornece a ligação de governação. Estabelece:
“As alterações baseadas em ferramentas devem continuar a cumprir esta política e ser rastreáveis a um ID de pedido de alteração correspondente.”
Isto responde ao argumento comum de que implementações automatizadas não necessitam de tickets de alteração. A automatização não elimina a governação de alterações. Altera a forma como a evidência é gerada.
A mesma política estabelece:
“Todos os pedidos de alteração, revisões, aprovações e evidência de suporte devem ser registados no sistema centralizado de gestão de alterações.”
Na prática, o sistema de gestão de alterações deve ser o índice, não o depósito indiscriminado. O ticket deve apontar para o repositório de origem, a execução da build, a assinatura do artefacto, o registo de implementação e o plano de reversão. A evidência detalhada pode permanecer nas ferramentas de engenharia se a retenção, o controlo de acesso e a exportabilidade estiverem definidos.
| Pergunta de controlo | Evidência a reter | Proprietário |
|---|---|---|
| A origem foi aprovada? | Aprovação do pull request, definições de proteção de branches, identidade do revisor | Responsável de engenharia |
| A build foi controlada? | ID da execução da build, ID do runner, versão da definição do pipeline, registos da tarefa | DevOps |
| O artefacto era rastreável? | Hash do artefacto, assinatura, referência ao commit de origem, metadados do registo | Equipa de plataforma |
| Os pontos de controlo de segurança foram executados? | Resultados de SAST, SCA, contentores, DAST e análises IaC, aprovações de exceções | Segurança |
| A implementação foi autorizada? | ID do pedido de alteração, aprovador, janela de implementação, plano de reversão | Gestor de Alterações |
| A evidência pode ser preservada? | Registos exportados, capturas de ecrã, hashes, registo da cadeia de custódia | Segurança ou conformidade |
Endurecimento dos runners: o controlo de produção subestimado
Os runners CI/CD são frequentemente tratados como infraestrutura descartável, mas são ambientes de execução de alto risco. Um runner pode aceder a código-fonte, segredos, caches de build, repositórios de pacotes, chaves de assinatura, registos de artefactos e funções de implementação na nuvem. Se for persistente, partilhado, excessivamente privilegiado ou mal monitorizado, torna-se um ponto de pivô privilegiado.
A posição de governação segura é simples: os runners que compilam ou implementam código de produção devem ser endurecidos como infraestrutura de produção.
| Área de endurecimento do runner | Controlo esperado | Evidência de auditoria |
|---|---|---|
| Isolamento | Utilizar runners efémeros para builds sensíveis e evitar a partilha entre limites de confiança | Registos do ciclo de vida dos runners, definições de grupos de runners |
| Segurança de credenciais | Utilizar credenciais de curta duração e identidade de workload em vez de segredos de longa duração | Configuração de identidade, definições de expiração de tokens, registos de rotação de segredos |
| Princípio do menor privilégio | Separar funções de build, teste, assinatura e implementação | Definições de funções, revisão de acessos, exportações de permissões |
| Controlo de rede | Restringir o acesso de saída e bloquear conectividade desnecessária à produção | Regras de firewall, exportações de políticas de rede, registos de tráfego de saída |
| Integridade da configuração de referência | Aplicar patches às imagens dos runners e registar versões aprovadas | Inventário de imagens, relatórios de patches, digests das imagens de build |
| Proteção da cache | Prevenir contaminação entre projetos através de caches de build | Política de cache, definições de isolamento de projetos |
| Monitorização | Registar ações administrativas, alterações de configuração e anomalias em tarefas | Registos de auditoria CI/CD, eventos SIEM, registos de alertas |
A Política de Dados de Teste e Ambientes de Teste Política de Dados de Teste e Ambientes de Teste estabelece:
“A integração com pipelines CI/CD deve impor a separação de ambientes e de credenciais de autenticação.”
Um runner que consegue implementar em staging e em produção com o mesmo modelo de credenciais viola, na prática, a separação de ambientes, mesmo que a infraestrutura esteja logicamente separada. A Clarysec recomenda normalmente identidades de implementação separadas por ambiente, pontos de controlo de aprovação específicos para produção e controlos explícitos que impeçam tarefas de ambientes inferiores de aceder a segredos de produção.
O Zenith Blueprint, na fase Controlos em ação, passo 21, reforça este ponto através da separação de ambientes de desenvolvimento, teste e produção:
“Se for utilizado CI/CD, confirme que a promoção de implementações entre ambientes é controlada e exige revisão ou aprovação. Documente isto no seu Procedimento de Gestão de Ambientes e recolha capturas de ecrã ou exportações da consola para o suportar.”
Numa auditoria real, isto significa que o auditor não deve ver apenas um diagrama. Deve ver exportações da consola que demonstrem credenciais específicas por ambiente, ambientes de implementação protegidos, pontos de controlo de aprovação e registos que provem que a promoção foi controlada.
Evidência de implementação: o artefacto de conformidade escondido à vista de todos
As equipas DevSecOps mais maduras não tratam a recolha de evidência como uma corrida trimestral. Desenham pipelines para gerar evidência automaticamente.
A Política de Registo e Monitorização para PME Política de Registo e Monitorização para PME identifica eventos de registo relevantes como:
“Registos de sistema: alterações de configuração, ações administrativas, instalações de software, atividade de aplicação de patches”
Os sistemas CI/CD produzem as quatro categorias. As alterações de configuração do pipeline afetam a forma como o software é compilado. As ações administrativas alteram quem pode aprovar ou implementar. As instalações de software ocorrem em imagens de build e alvos de implementação. A atividade de aplicação de patches pode fluir através de processos automatizados de release. Estes eventos devem ser registados, retidos e revistos de acordo com o risco.
Para preparação de investigação, a P31S Política de Recolha de Evidência e Análise Forense para PME Política de Recolha de Evidência e Análise Forense para PME estabelece:
“Capturas de ecrã, registos exportados e hashes de ficheiros devem ser armazenados juntamente com o ficheiro da cadeia de custódia.”
Isto é especialmente importante após uma suspeita de comprometimento do pipeline. Capturas de ecrã isoladas constituem evidência fraca. Registos sem hashes podem ser contestados. Um ficheiro de cadeia de custódia sem referências de origem está incompleto.
Um registo defensável de implementação em produção deve incluir o seguinte.
| Item de evidência | Conteúdo mínimo | Fonte primária | Valor de conformidade |
|---|---|---|---|
| Pedido de alteração | Necessidade de negócio, nível de risco, aprovação, ID da alteração, plano de reversão | JIRA, ServiceNow, issue Git | ISO 27002 8.32, DORA Article 9 |
| Registo de origem | Repositório, commit, branch, aprovações de pull request | Git, GitHub, GitLab, Azure DevOps | ISO 27002 8.25, NIS2 Article 21 |
| Registo de build | ID do pipeline, ID do runner, registos de build, dados de dependências | Plataforma CI/CD | ISO 27002 8.25, evidência da cadeia de fornecimento das TIC |
| Atestado de proveniência de build | Registo assinado dos inputs, ambiente e processo de build | Ferramenta CI/CD, workflow compatível com SLSA | ISO 27002 5.21, suporte ao CRA Annex I |
| Registo de ponto de controlo de segurança | Resultados de SAST, SCA, DAST, contentores e análises IaC | Ferramentas de segurança, registos do pipeline | ISO 27002 8.29, DORA Article 9 |
| Registo do artefacto | Hash, assinatura, caminho no registo, digest imutável | Registo de artefactos | ISO 27002 8.25, evidência de atualização segura do CRA |
| Registo de implementação | Ambiente, ator, marcação temporal, aprovação de produção | GitOps, plataforma de implementação | ISO 27002 8.32, DORA Article 10 |
| Registo de monitorização | Verificações de saúde e anomalias pós-implementação | SIEM, plataforma de observabilidade | Expectativas de deteção e resposta do DORA |
| Preservação da evidência | Registos exportados, capturas de ecrã, hashes, registo de custódia | Repositório de evidência | ISO 27002 5.28, investigação de incidente |
Este pacote transforma o CI/CD de uma sequência de passos técnicos numa história de governação, controlo e diligência prévia.
Mapeamento da governação CI/CD para NIS2, DORA, RGPD da UE e CRA
A NIS2 aplica-se a muitas entidades essenciais e importantes, incluindo infraestrutura digital, gestão de serviços TIC e organizações fornecedoras digitais quando os critérios são cumpridos. O Article 20 é particularmente relevante porque cria deveres de cibersegurança ao nível da gestão. Os órgãos de gestão devem aprovar medidas de gestão de riscos de cibersegurança, supervisionar a sua implementação e receber formação.
O Article 21 fornece a linha de base de gestão de riscos. Exige medidas técnicas, operacionais e organizacionais adequadas e proporcionadas que cubram análise de riscos, políticas, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição, desenvolvimento e manutenção seguros, tratamento de vulnerabilidades, avaliação de eficácia, higiene de cibersegurança, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos e MFA quando adequado.
| Tema do NIS2 Article 21 | Interpretação de governação CI/CD |
|---|---|
| Análise de riscos e políticas | Modelo de ameaças do pipeline, política de desenvolvimento seguro, avaliação de riscos dos runners |
| Tratamento de incidentes | Playbook de comprometimento do pipeline, revogação de artefactos, controlo de release de emergência |
| Continuidade de negócio | Recuperação do controlo de origem, registo de artefactos e automatização de implementações |
| Segurança da cadeia de fornecimento | Ações de terceiros, pacotes, desenvolvimento externalizado, dependências de registos |
| Desenvolvimento e manutenção seguros | SDLC seguro, revisão de código, testes, tratamento de vulnerabilidades |
| Avaliação de eficácia | Testes dos controlos do pipeline, amostragem de auditoria, métricas e exceções |
| Controlo de acesso e MFA | Repositório, administração CI/CD, registo de runners, funções de implementação em produção |
| Criptografia | Assinatura de artefactos, proteção de segredos, gestão de chaves |
O Article 23 acrescenta comunicação faseada de incidentes significativos, incluindo alerta precoce no prazo de 24 horas após a tomada de conhecimento, notificação de incidente no prazo de 72 horas e relatório final no prazo máximo de um mês após a notificação do incidente. Se um comprometimento CI/CD puder causar interrupção operacional severa, perda financeira ou dano material a terceiros, o processo de classificação de incidentes deve estar preparado antes do incidente.
Para entidades financeiras, o DORA é aplicável desde 17 de janeiro de 2025 e cobre gestão do risco das TIC, comunicação de incidentes, testes de resiliência, partilha de informações, gestão de riscos de terceiros TIC e requisitos contratuais. O Article 5 exige um quadro interno de governação e controlo para o risco das TIC, com responsabilidade do órgão de gestão. O Article 6 exige um quadro documentado de gestão do risco das TIC integrado na gestão global de riscos.
Os Articles 8 a 14 mapeiam diretamente para a governação de pipelines CI/CD. As entidades financeiras devem identificar e classificar funções de negócio suportadas por TIC, ativos, dependências, ameaças e vulnerabilidades. Devem proteger os sistemas TIC através de políticas, controlos de acesso, autenticação forte, proteção de chaves criptográficas, gestão de alterações TIC controlada, aplicação de patches e segmentação. Devem detetar anomalias, responder, recuperar e aprender com incidentes.
Os Articles 28 a 30 são igualmente importantes porque plataformas CI/CD, prestadores de controlo de origem, registos de artefactos, sistemas de build na nuvem e programadores externalizados podem ser dependências TIC de terceiros. O DORA espera diligência prévia, salvaguardas contratuais, avaliação de risco de concentração, direitos de auditoria e inspeção, gatilhos de cessação, estratégias de saída e cláusulas de nível de serviço.
O RGPD da UE acrescenta a perspetiva da responsabilização. O Article 5 exige que os dados pessoais sejam tratados de forma lícita, leal e transparente, para finalidades especificadas, minimizados, exatos, retidos apenas pelo tempo necessário e protegidos contra tratamento não autorizado ou ilícito e contra perda, destruição ou dano acidental. O Article 5(2) exige que o responsável pelo tratamento demonstre conformidade.
Os pipelines CI/CD são relevantes para o RGPD da UE porque os programadores podem utilizar dados de produção em ambientes de teste, os registos do pipeline podem expor dados pessoais ou tokens, as releases podem alterar a lógica de tratamento e artefactos comprometidos podem causar violações de dados pessoais. Quando alterações de software afetam controlos de privacidade, o registo de alteração deve capturar o impacto na privacidade. Quando um incidente de pipeline causa acesso não autorizado a dados pessoais, a avaliação da violação deve estar ligada ao tratamento de incidentes.
As expectativas do CRA acrescentam segurança de produto e evidência de atualizações seguras. Para fabricantes e fornecedores de software que colocam produtos com elementos digitais no mercado da UE, os clientes esperam cada vez mais ficheiros de segurança de produto, evidência de tratamento de vulnerabilidades, controlos de atualização segura e integridade de releases. A governação CI/CD fornece grande parte dessa evidência através da rastreabilidade da origem, artefactos assinados, resultados de análises de vulnerabilidades, notas de versão, correções de segurança e registos de distribuição de atualizações.
NIST CSF 2.0 e COBIT 2019: a perspetiva de auditoria para além da ISO
O NIST CSF 2.0 fornece uma camada de integração para a governação da cibersegurança. O seu Núcleo, os Perfis Organizacionais e os Níveis ajudam as organizações a compreender a postura atual e alvo, priorizar ações alinhadas com requisitos legais e regulamentares, e comunicar o risco cibernético.
Para CI/CD, a Clarysec cria frequentemente um Perfil de Pipeline de Entrega de Software. O Perfil Atual capta como funcionam hoje o controlo de origem, os runners, a assinatura de artefactos e as aprovações de implementação. O Perfil Alvo define o estado exigido para operações reguladas. O plano de lacunas torna-se o roteiro de implementação.
A função GOVERN do NIST é especialmente relevante. A GV.OC-03 exige que os requisitos de cibersegurança legais, regulamentares e contratuais sejam compreendidos e geridos. A GV.RM cobre apetite ao risco e priorização padronizada de riscos. A GV.RR atribui responsabilização da liderança, papéis e recursos. A GV.PO exige que políticas de risco de cibersegurança sejam estabelecidas, aplicadas, revistas e atualizadas. A GV.OV cobre supervisão e avaliação de desempenho.
Um auditor COBIT 2019 ou de estilo ISACA prestará frequentemente menos atenção ao detalhe criptográfico da assinatura de artefactos e mais ao desenho da governação. Perguntará se a propriedade está definida, se a habilitação de alterações é controlada, se os serviços de terceiros são geridos com base no risco, se a monitorização produz garantia, se as exceções são aprovadas e se a gestão recebe reporte significativo.
| Perspetiva de auditoria | Pergunta provável de auditoria | Evidência que responde |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | O CI/CD está incluído no âmbito do SGSI, na avaliação de riscos, na Declaração de Aplicabilidade e nos controlos operacionais? | Âmbito do SGSI, registo de riscos, mapeamento da SoA, cláusulas de política, amostras de implementação |
| Revisor de controlos ISO/IEC 27002:2022 | O SDLC seguro, a separação de ambientes, o controlo de acesso, a gestão de alterações e a recolha de evidência estão implementados? | Proteções de branches, credenciais de ambientes, aprovações, assinaturas de artefactos, registos |
| Avaliador NIS2 | A gestão aprovou medidas proporcionadas para desenvolvimento seguro, cadeia de fornecimento, controlo de acesso, tratamento de incidentes e resiliência? | Atas do Conselho de Administração, plano de tratamento de riscos, mapeamento do Article 21, playbook de incidentes, registos de fornecedores |
| Auditor DORA | O pipeline suporta a gestão do risco das TIC, alterações controladas, monitorização, testes, comunicação de incidentes e governação de terceiros TIC? | Inventário de ativos TIC, registos de alteração, registos de deteção, classificação de incidentes, registo de prestadores |
| Revisor RGPD da UE | A organização consegue demonstrar segurança e responsabilização para releases que afetam dados pessoais? | Notas de revisão de privacidade, controlos de dados de teste, registos de acesso, workflow de avaliação de violação |
| Avaliador NIST CSF 2.0 | Qual é a postura atual versus alvo do pipeline e o plano de melhoria priorizado? | Perfil CSF, análise de lacunas, POA&M, métricas, registos de aceitação do risco |
| Auditor COBIT 2019 ou ISACA | Estão definidos papéis, responsabilidades, controlos de processo, medidas de desempenho e atividades de garantia? | RACI, lista de proprietários dos controlos, relatórios de KPI e KRI, resultados de auditoria interna, registo de exceções |
Falhas comuns em auditorias CI/CD e métricas ao nível do conselho de administração
A maioria das constatações de auditoria em CI/CD é previsível. A primeira é evidência não ligada. A equipa tem registos Git, registos do pipeline e registos de implementação, mas nenhum registo de alteração único os liga. A segunda é automatização excessivamente privilegiada, em que uma tarefa consegue ler segredos de produção, enviar artefactos, aprovar implementações e modificar definições do pipeline. A terceira são runners partilhados persistentes, que criam risco de contaminação entre projetos e tornam mais difícil delimitar o âmbito forense após um comprometimento.
Outras falhas comuns incluem artefactos não assinados ou sobrescritos, contornos informais de análises, falta de visibilidade sobre fornecedores e fuga de dados pessoais em registos. Um bom pipeline permite exceções, mas exige aprovação, data de expiração, propriedade do risco e revisão.
Os líderes de segurança devem evitar reportar ao conselho de administração apenas contagens de scanners. Em vez disso, devem reportar métricas de confiança nas releases:
- Percentagem de implementações em produção associadas a registos de alteração aprovados.
- Percentagem de artefactos de produção assinados e rastreáveis a commits de origem.
- Número de implementações que utilizam exceções ou aprovações de emergência.
- Percentagem de utilizadores CI/CD privilegiados com MFA e revisão de acessos recente.
- Número de credenciais de implementação de longa duração ativas.
- Percentagem de serviços críticos que utilizam runners endurecidos ou efémeros.
- Tempo médio para revogar ou rodar segredos do pipeline após um incidente.
- Número de dependências críticas de fornecedores que suportam a entrega de software.
- Taxa de completude da evidência para releases amostradas em auditoria.
Estas métricas suportam a liderança, o planeamento e o controlo operacional da ISO/IEC 27001:2022. Também suportam a supervisão da gestão prevista no NIS2 Article 20 e as expectativas de governação do DORA.
Torne o seu pipeline auditável antes do incidente
A governação da segurança de pipelines CI/CD em 2026 não consiste em abrandar a engenharia. Consiste em tornar a entrega de software confiável, resiliente e demonstrável. Os melhores programas usam automatização para acelerar a evidência, não para contornar a governação.
Uma implementação prática da Clarysec começa com três ações.
- Utilize o Zenith Blueprint Zenith Blueprint para inserir DevOps seguro, acesso ao código-fonte, separação de ambientes e gestão de alterações no seu roteiro de implementação da ISO/IEC 27001:2022.
- Utilize os Zenith Controls Zenith Controls para mapear riscos CI/CD entre SDLC seguro, cadeia de fornecimento das TIC, controlo de acesso, gestão de alterações, recolha de evidência, NIS2, DORA, RGPD da UE, NIST CSF 2.0 e perspetivas de auditoria COBIT 2019.
- Implemente os modelos de políticas da Clarysec, incluindo Política de Desenvolvimento Seguro, Política de Gestão de Alterações, Política de Dados de Teste e Ambientes de Teste, Política de Desenvolvimento Seguro para PME, Política de Registo e Monitorização para PME e Política de Recolha de Evidência e Análise Forense para PME, para definir quem aprova releases, como os artefactos são rastreados, como os runners são controlados e que evidência deve ser retida.
Se a sua próxima amostra de auditoria começar com “mostrem-nos o trilho da release de produção”, a sua equipa deve conseguir responder em minutos, não em semanas. Essa é a diferença entre automatização DevOps e entrega de software governada.
Descarregue o toolkit de políticas da Clarysec, reveja o seu pipeline CI/CD face ao Zenith Blueprint e aos Zenith Controls, ou agende uma avaliação Clarysec para transformar o seu pipeline de uma fonte de ansiedade em auditoria num pilar de resiliência digital.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
