Hardening de CI/CD
El pipeline guarda credenciales, ejecuta código de terceros y publica lo que va a producción. Comprometerlo es la ruta más corta para comprometer todo.
Qué es
El hardening de CI/CD consiste en reducir lo que un atacante puede lograr si compromete el pipeline: un runner, una acción de terceros, un token filtrado o un pull request malicioso. Los incidentes reales de cadena de suministro muestran el patrón: el objetivo deja de ser la aplicación y pasa a ser el camino que lleva el código a producción.
Fuera los secretos estáticos: OIDC
Las claves de nube guardadas como secretos del pipeline se filtran y viven para siempre. La alternativa es la federación por OIDC: el pipeline demuestra su identidad al proveedor de nube con un token de corta duración, y el proveedor entrega credenciales temporales, restringidas a ese repositorio y a esa rama.
permissions:
contents: read # mínimo por defecto
id-token: write # permite solicitar el token OIDC
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@<sha-completo-do-commit> # fijado por SHA
- uses: aws-actions/configure-aws-credentials@<sha-completo>
with:
role-to-assume: arn:aws:iam::123456789012:role/ci-deploy
aws-region: us-east-1
- run: ./scripts/deploy.shLas dependencias del pipeline también son dependencias
- Fijar acciones e imágenes por digest o SHA, no por una etiqueta mutable: una etiqueta puede reapuntarse a código malicioso.
- Permisos mínimos para el token del pipeline, definidos por job.
- Cuidado con los disparadores que ejecutan código de forks con acceso a secretos (por ejemplo, pull_request_target en GitHub Actions): tratar la entrada de un PR como no confiable.
- Inyección en scripts: nunca interpolar títulos de PR, nombres de rama o mensajes de commit directamente en comandos de shell.
Runners y entornos
Los runners efímeros (uno por job, descartado al final) evitan que un job contamine al siguiente y que las credenciales queden en disco. Los runners compartidos y de larga vida acumulan estado y se vuelven objetivos. Separa los runners que hacen deploy a producción de los que ejecutan pruebas de código externo, y restringe la red de salida a lo necesario.
Integridad de lo que sale del pipeline
Firmar los artefactos y registrar la procedencia (quién los construyó, a partir de qué commit, en qué entorno) permite que el destino verifique que lo que va a correr es exactamente lo que produjo el pipeline. Frameworks como describen niveles crecientes de estas garantías, y herramientas como cosign se encargan de la firma de imágenes.
conexiones en el mapa
- Infraestructura segura como códigopasa porHardening de CI/CD
- Policy as codese vuelve un gateHardening de CI/CD
- La seguridad como producto internoestandarizaHardening de CI/CD
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
en otros dominios
- Pipelines de CI que siguen siendo rápidosdevopsun pipeline que funciona también debe ser un pipeline confiable
- Orquestación y agents en paralelovibecodinglos agentes autónomos exigen la misma disciplina que los runners y las credenciales
- A08 Software or Data Integrity Failuresowaspel pipeline es parte de lo que debe mantenerse íntegro
- CI/CDappsecel pipeline visto como objetivo: el mismo pipeline, ahora endurecido
- Secrets - bóvedas y rotacióncloudsecOIDC en lugar de secretos estáticos en el pipeline
Estudia antes
Desbloquea
pon a prueba lo que entendiste
Cargando preguntas…