Los 3 checks de seguridad que todo pipeline AWS necesita

Los tres checks de seguridad esenciales para cualquier pipeline AWS son el escaneo de secretos con gitleaks, el escaneo de Infrastructure as Code con Checkov y el ECR Enhanced Scanning de imágenes. Los tres se ejecutan automáticamente antes de producción y atajan los errores más comunes sin reemplazar a un equipo de seguridad.

Te pinto la escena, que sale del artículo de Mario Góngora publicado el 20 de junio de 2026: un developer mergea un pull request un viernes a la tarde, el repo es público y el commit lleva una AWS access key hardcodeada en un archivo de config. Veinte minutos después llega el mail de AWS Abuse. Para entonces alguien ya encontró la key, levantó instancias EC2 en tres regiones y arrancó a minar. La factura llega a USD 3.000 antes de que alcancen a rotarla.

Un pipeline CI/CD es la cadena automatizada que toma tu código, lo testea, lo empaqueta y lo despliega a producción. Los checks de seguridad AWS pipeline son controles automáticos que se insertan en esa cadena para detectar credenciales filtradas, configuraciones de infraestructura inseguras y vulnerabilidades conocidas antes de que el código llegue a correr. No son un equipo de seguridad: son la primera barrera que ataja lo obvio.

¿Qué pasa cuando se expone una AWS key en el repositorio?

Pasa rápido. Hay bots que escanean GitHub público las 24 horas buscando el patrón AKIA (el prefijo de las access keys de AWS). Cuando lo encuentran, no piden permiso: lanzan instancias EC2 para minar cripto y la factura se dispara antes de que vos te enteres.

El detalle incómodo es que el code review no atajó nada. ¿Por qué? Porque revisar a ojo es manual, y un humano cansado un viernes a la tarde no se fija si en la línea 42 de un archivo de config hay una clave de 40 caracteres. La verdad es que pedir “developers más cuidadosos” no es una estrategia de seguridad. La estrategia es que algo automático mire por vos en cada commit, sin excepciones.

¿Cómo funciona el escaneo de secretos con gitleaks?

gitleaks es una herramienta open source de SAST (análisis estático) que escanea cada commit buscando patrones que parezcan credenciales. Detecta access keys de AWS, tokens de GitHub, private keys y API keys de un montón de servicios, todo con expresiones regulares.

Ponele que escribís AKIAIOSFODNN7EXAMPLE en un archivo. gitleaks lo detecta contra su conjunto de reglas y te frena el pipeline antes del merge. Lo podés correr de dos formas: como pre-commit hook (te avisa en tu propia máquina antes de pushear) o como paso del pipeline (lo ataja en el server, que es donde realmente importa porque no depende de la buena voluntad de cada dev).

Eso sí: es personalizable con un archivo .gitleaks.toml. Ahí definís reglas propias, ignorás falsos positivos (esos tokens de ejemplo en la documentación que no son secretos reales) y ajustás la sensibilidad. Sin esa config, te vas a comer alertas de cosas que no son y el equipo va a empezar a ignorarlas, que es el peor escenario posible.

¿Qué es el Infrastructure as Code scanning y por qué previene misconfigs?

Infrastructure as Code (IaC) es tratar tu infraestructura como código versionado, con Terraform o CloudFormation, en vez de hacer clic en la consola de AWS. Tiene una ventaja enorme y un riesgo nuevo: si escribís mal una regla, la replicás en todos lados.

Los errores clásicos que un escáner de IaC te ataja:

• S3 buckets públicos: un archivo de Terraform que deja un bucket abierto a internet, y ahí se filtran datos que nadie debería ver.
• IAM policies con * en todo: una política que permite cualquier acción sobre cualquier recurso. Si esa key se filtra, el atacante tiene las llaves del reino.
• Security groups sin restricción: el puerto 22 (SSH) abierto a 0.0.0.0/0, o sea, a todo el planeta.

Herramientas como Checkov o TFLint escanean esos archivos y detectan el patrón de misconfiguration antes de que apliques nada en producción. Es uno de esos controles que atajan los errores obvios de forma automática, sin reemplazar a un equipo de seguridad. O sea: es lo mínimo, no lo opcional.

¿Cómo detecta ECR Enhanced Scanning vulnerabilidades en las imágenes?

El tercer check ataca una capa distinta: la imagen del contenedor. ECR Enhanced Scanning es la función de Amazon Elastic Container Registry que se integra con Amazon Inspector para escanear las imágenes contra CVEs conocidos, según la documentación oficial de AWS.

Lo interesante es que mira dos cosas: las capas base del sistema operativo y las dependencias del lenguaje (los paquetes de Python, Node, lo que uses). Y acá viene lo bueno: hace continuous monitoring. No escanea una sola vez y listo. Cada vez que se publica un CVE nuevo, re-evalúa las imágenes que ya tenés guardadas. Una imagen que hoy está limpia puede aparecer vulnerable mañana sin que vos toques nada, y ECR te avisa.

Cada vulnerabilidad viene con su nivel de severidad, así priorizás: un CRITICAL en una imagen de producción se arregla hoy, un LOW en algo interno puede esperar.

Los tres checks comparados

Check	Herramienta	Qué escanea	Capa que cubre	Dónde corre
Secretos	gitleaks	Credenciales en el código (AKIA, tokens, private keys)	Código fuente	Pre-commit hook + pipeline
IaC	Checkov / TFLint	Misconfigs en Terraform/CloudFormation	Infraestructura	Pipeline, antes de aplicar
Imágenes	ECR Enhanced Scanning (Inspector)	CVEs en SO y dependencias	Contenedor	Al pushear a ECR + continuo

¿Cómo se implementan los tres checks en GitHub Actions?

La idea es agregar tres pasos al workflow YAML. A grandes rasgos:

1. Paso gitleaks: sumás la action oficial de gitleaks para que escanee en cada push. Si encuentra un secreto, el job falla y el merge se bloquea.
2. Paso Checkov: agregás el escaneo de tus archivos de Terraform. Configurás el umbral de falla (por ejemplo, fallar solo en HIGH y CRITICAL para no frenar todo por un warning menor).
3. Paso ECR con scanning habilitado: activás scanOnPush en el repositorio de ECR y conectás el push de la imagen al final del pipeline.

Tres puntos críticos para que esto sirva de verdad. Que corra en cada push y en cada rama, no solo en main (las cosas se filtran en las feature branches). Que las fallas estén bien configuradas para no generar ruido. Y que las notificaciones lleguen a alguien que las mire. Esto no es exclusivo de GitHub Actions: lo mismo lo armás en GitLab CI o en Jenkins con el mismo concepto.

¿Qué hacer si descubrís una credencial expuesta?

Acá el tiempo es todo. El orden importa:

1. Rotá la key en AWS ya: entrá a IAM y desactivá o eliminá la access key comprometida. Esto primero, antes que nada.
2. Revisá CloudTrail: mirá qué se hizo con esa key. Instancias EC2 levantadas, accesos a S3, cualquier acción rara. CloudTrail te da el log de quién hizo qué.
3. Borrá la key vieja del todo: desactivar no alcanza, eliminala.
4. Limpiá el historial de git: sacar el secreto del último commit no sirve si sigue en el historial. Usás git filter o herramientas similares, con cuidado, porque reescribir historia compartida tiene sus bemoles.

Una aclaración que mucha gente pasa por alto: una vez que la key tocó un repo público, asumí que está comprometida para siempre. No alcanza con borrarla del archivo. La clave ya la copiaron. Por eso rotar es lo primero, no lo último.

¿Qué prácticas de DevSecOps complementan estos checks?

Los tres checks atajan lo obvio, pero no son toda la historia. Lo que suma de verdad:

• Secrets manager, no variables de entorno: guardá las credenciales en AWS Secrets Manager, no hardcodeadas ni en .env versionados.
• IAM roles granulares: cada servicio con el permiso mínimo que necesita, no una key todopoderosa para todo.
• Audit logging siempre prendido: CloudTrail activo para poder reconstruir qué pasó cuando algo sale mal.
• Escaneo en todas las ramas: el control tiene que cubrir todo el pipeline, no solo el merge final.

Si todo esto corre sobre infraestructura propia, vale tener el hosting y los dominios con un proveedor serio como donweb.com para la parte de cloud y servidores en la región. La seguridad del pipeline no sirve de mucho si la base está floja.

Errores comunes al armar estos controles

• Escanear solo la rama main: los secretos se filtran en feature branches y PRs. Si gitleaks corre solo en el merge a main, ya es tarde. Corré en cada push.
• No configurar el .gitleaks.toml: sin manejo de falsos positivos, el equipo se cansa de las alertas y empieza a ignorarlas. Una alerta ignorada es peor que no tener alerta.
• Creer que ECR escanea una sola vez: mucha gente piensa que el scan al pushear ya cubre todo. No. Activá el continuous monitoring para que re-evalúe cuando salen CVEs nuevos.
• Dejar el pipeline en warning y no en fail: si el check encuentra algo pero no frena el merge, no estás protegiendo nada, estás generando un log que nadie lee.

Preguntas Frecuentes

¿Cuáles son los tres checks de seguridad esenciales en un pipeline AWS?

Escaneo de secretos con gitleaks, escaneo de Infrastructure as Code con Checkov y ECR Enhanced Scanning de imágenes. Cada uno cubre una capa distinta: código, infraestructura y contenedores. Los tres se integran en GitHub Actions como pasos del pipeline.

¿Cómo se escanean secretos automáticamente en el código?

Con gitleaks, una herramienta open source que detecta cada commit contra patrones de credenciales como las access keys de AWS (prefijo AKIA), tokens de GitHub y private keys. Se corre como pre-commit hook en tu máquina o como paso del pipeline en el server.

¿Qué hago si expongo una AWS key en un commit?

Rotá la key en IAM de inmediato, antes de cualquier otra cosa. Después revisá CloudTrail para ver si la usaron, eliminá la key vieja y limpiá el historial de git. Asumí que la clave ya está comprometida para siempre: rotar no es opcional.

¿Qué es ECR scanning y cómo funciona?

ECR Enhanced Scanning es la función de Amazon Elastic Container Registry que usa Amazon Inspector para escanear imágenes de contenedor contra CVEs conocidos. Cubre el sistema operativo base y las dependencias del lenguaje, y hace monitoreo continuo: re-evalúa imágenes guardadas cuando salen vulnerabilidades nuevas.

¿Estos tres checks reemplazan a un equipo de seguridad?

No. Atajan los errores más comunes de forma automática, pero no cubren todo el stack de DevSecOps. Funcionan como defense in depth junto a IAM granular, secrets management y audit logging. Son la primera barrera, no la única.

Conclusión

El caso de los USD 3.000 en 20 minutos no es raro ni espectacular: es lo que pasa cuando nada en el pipeline está mirando. Los tres checks (gitleaks para secretos, Checkov para IaC y ECR Enhanced Scanning para imágenes) no requieren un equipo de seguridad dedicado ni un proyecto de seis meses. Se enchufan en GitHub Actions esta semana, corren en cada push y atajan justo los errores que el code review manual se saltea un viernes a la tarde. Lo que cambió es que ya no hace falta confiar en que el dev se acuerde: la automatización mira por vos. Empezá por gitleaks, que es el de mayor impacto por menor esfuerzo, y sumá los otros dos en las semanas siguientes.

Fuentes

• Three Security Checks for Any AWS Pipeline – artículo original de Mario Góngora en dev.to
• Amazon ECR Image Scanning – documentación oficial de AWS
• gitleaks – repositorio oficial en GitHub