Els teus pipelines CI/CD: la major superfície d'atac no vigilada

En el vertiginós món del desenvolupament de programari, l'automatització a través de pipelines d'Integració Contínua i Desplegament Continu (CI/CD) és fonamental. Tanmateix, cada vegada que un equip desplega codi al núvol, com ara a AWS, s'utilitzen credencials que atorguen accés a la infraestructura de producció. El problema rau en el fet que, en la majoria de les organitzacions, aquestes credencials tenen permisos excessius, es comparteixen entre entorns i rarament es revisen. Una bretxa en un sol pipeline pot significar el control total del compte.

Aquest no és un escenari hipotètic. Incidents recents, com l'atac a l'eina d'escaneig de seguretat Trivy el març de 2026, on atacs van forçar l'entrada de codi maliciós a les seves accions de GitHub, van demostrar com els secrets robats poden propagar-se a través d'ecosistemes open source com PyPI. Un altre exemple alarmant va ser una campanya impulsada per IA l'abril de 2026, que va obrir centenars de sol·licituds d'extracció (pull requests) malicioses en qüestió d'hores, exfiltrant credencials de múltiples organitzacions.

Problemes estructurals en la seguretat de pipelines

Existeixen tres debilitats fonamentals que incrementen aquesta superfície d'atac:

1. Credencials de llarga durada: La majoria dels pipelines utilitzen claus d'accés estàtiques emmagatzemades com a variables de CI/CD. Aquestes claus no expiren, no tenen un abast específic per a accions concretes i persisteixen fins i tot quan els empleats deixen l'empresa. Una única clau filtrada proporciona accés continu a un atacant.
2. Permisos compartits: És habitual que el mateix rol d'AWS Identity and Access Management (IAM) s'utilitzi per desplegar en entorns de desenvolupament, staging i producció. Això significa que una branca de funcionalitat compromesa podria accedir a dades de producció, ja que el model de permisos no distingeix entre aquests entorns.
3. Falta de visibilitat i abast: Els equips solen sol·licitar permisos amplis, ja que definir permisos granulars és un procés lent. Amb el temps, els rols acumulen accessos que ningú recorda haver atorgat, i rarament s'audita l'ús real de les credencials en comparació amb el que podrien fer.

Cap a pipelines CI/CD segurs amb mínim privilegi

AWS proposa una arquitectura de referència per implementar el principi de mínim privilegi en els pipelines CI/CD. Les idees clau inclouen:

• Eliminar credencials de llarga durada: Utilitzar l'autenticació federada (OpenID Connect o OIDC) amb AWS, suportada per plataformes com GitHub i GitLab. Els pipelines obtenen tokens de curta durada (aproximadament 1 hora) sense necessitat d'emmagatzemar secrets. Si un pipeline és compromès, el token expira abans que un atacant pugui establir persistència.
• Un rol per entorn i pipeline: El rol de desplegament de producció només ha d'acceptar sol·licituds de la branca principal d'un repositori específic. Això assegura que un desenvolupador en una branca de funcionalitat no pugui accedir a credencials de producció, fins i tot si modifica la configuració del pipeline. La seguretat es defineix a IAM, no només a l'arxiu del pipeline.

Quatre capes de defensa i separació de responsabilitats

Cap control únic és suficient. El patró recomanat apila diverses capes de seguretat:

• Guardrails a nivell d'organització: Polítiques de control de serveis (Service Control Policies) que impedeixen desactivar el registre d'auditoria o sortir de regions aprovades.
• Límits de permisos (Permission Boundaries): Restriccions en cada rol de pipeline per prevenir l'escalada de privilegis.
• Concessions específiques: Atorgar només les accions necessàries per a cada pipeline.
• Polítiques a nivell de recurs: Per a l'accés entre comptes.

Una decisió arquitectònica crucial és separar qui crea els permisos de qui els utilitza. Això s'aconsegueix mitjançant dos tipus de pipelines:

1. Pipeline de plataforma: Crea i gestiona rols d'IAM. S'executa des d'un repositori dedicat, requereix aprovacions humanes i és administrat per l'equip de plataforma/seguretat. Pot modificar permisos, però no desplegar aplicacions.
2. Pipelines de servei: Despleguen codi d'aplicació. Assumeixen rols precreats amb permisos fixos i fitats. No poden modificar els seus propis permisos ni els d'altres. Un pipeline de servei compromès no pot autoescalar els seus privilegis.

Refinament automatitzat i reducció de riscos

En lloc d'endevinar els permisos necessaris, es pot executar un pipeline amb accés ampli però limitat en un entorn de desenvolupament durant 90 dies. AWS CloudTrail registra cada crida a l'API, i IAM Access Analyzer genera una política de mínim privilegi basada en l'ús real. Aquesta política s'integra en el procés de revisió de codi, similar al codi d'aplicació. Aquest enfocament, que toca aspectes de la programació moderna, ajuda a alinear les pràctiques de seguretat amb estàndards com SOC 2 i ISO 27001.

La inversió inicial per implementar aquest patró pot variar, però els beneficis són immediats. El primer pas d'implementar OIDC i límits de permisos es pot realitzar en una tarda per pipeline, eliminant el risc més perillós: les credencials de llarga durada amb abast il·limitat. L'adopció d'aquestes pràctiques és crucial, especialment amb l'auge d'assistents de codificació amb IA, que també operen amb credencials de pipeline i podrien convertir-se en vectors d'escalada de privilegis si no es gestionen adequadament.

És vital preguntar-se:

• Quants pipelines utilitzen claus d'accés de llarga durada?
• Els rols de producció accepten sol·licituds només de la branca principal?
• Quan va ser l'última auditoria d'ús de permisos?
• Quin seria l'impacte d'una filtració de credencials?

La pregunta clau és si la teva organització tracta les credencials de pipeline amb el mateix rigor que l'accés a bases de dades de producció. Malauradament, els incidents recents suggereixen que la majoria encara no ho fa.

Fonts:

• Dev.to (https://dev.to/aws-builders/your-cicd-pipelines-are-your-largest-unmonitored-attack-surface-59ck)