DEV Community: Bianca Torres

Nunca más hardcodees un token: Seguridad en GitHub para DevOps

Bianca Torres — Wed, 10 Jun 2026 21:41:47 +0000

El pasado sábado 6 de junio tuve la oportunidad de participar como speaker en el GitHub Community Day Perú 2026, donde compartí una charla sobre un tema que sigue siendo una de las causas más frecuentes de incidentes de seguridad: la exposición accidental de credenciales.

Durante la sesión hablamos de herramientas gratuitas que muchos equipos ya tienen disponibles dentro de GitHub, pero que no siempre aprovechan al máximo. Usamos GitHub todos los días para gestionar código, colaborar con nuestros equipos y automatizar despliegues, pero en muchas ocasiones solo utilizamos una pequeña parte de todo lo que la plataforma nos ofrece.

La buena noticia es que GitHub incorpora múltiples funcionalidades de seguridad que pueden ayudarnos a prevenir filtraciones de credenciales, proteger nuestros pipelines y mejorar nuestra postura de seguridad sin necesidad de adquirir herramientas adicionales.

En este artículo recopilo los principales conceptos que vimos durante la charla, junto con una demostración práctica de cómo desplegar una aplicación en AWS sin almacenar una sola credencial permanente.

El problema

Todos lo hemos hecho.

Hardcodear un API key “solo por ahora”, pushear un .env por accidente o compartir un token por Slack para salir de un apuro.

Son errores comunes, pero las consecuencias pueden ser graves: desde una factura inesperada en AWS hasta una filtración de información sensible.

En 2025, De acuerdo al reporte de GitGuardian, GitHub detectó más de 28 millones de secretos expuestos en repositorios públicos. Access Keys de AWS, tokens de GitHub, webhooks de Slack y muchas otras credenciales quedaron visibles para cualquiera que quisiera utilizarlas.

El flujo típico suele verse así:

Un developer necesita desplegar una aplicación.
Crea una Access Key y Secret Key.
Las almacena en un archivo .env o directamente en el código.
El archivo termina llegando al repositorio.
Un bot detecta las credenciales y comienza a utilizarlas en cuestión de segundos.

La solución no es simplemente “tener más cuidado”.
La solución es construir mecanismos que hagan mucho más difícil que estos errores lleguen a producción.

GitHub nos ofrece varias capas de protección que pueden ayudarnos precisamente con eso.

Las 5 capas de Seguridad en Github

1. GitHub Secrets

La primera línea de defensa es evitar almacenar información sensible dentro del código.

GitHub Secrets permite guardar valores cifrados que pueden ser consumidos por GitHub Actions durante la ejecución de un workflow.

Características:

Encriptados mediante libsodium.
Ocultos automáticamente en los logs.
No pueden visualizarse nuevamente después de guardarse.
Disponibles a nivel de repositorio, environment u organización.

Además, los Environments agregan controles adicionales como:

Aprobaciones manuales para producción.
Restricciones por branch.
Wait timers.
Protección de despliegues críticos.

Si todavía tienes credenciales hardcodeadas en tu código, este debería ser el primer cambio que realices.

2. OIDC con AWS (Zero Credentials)

OIDC es un protocolo de autenticación que permite que dos servicios se reconozcan sin compartir credenciales.

Tradicionalmente, muchos pipelines almacenan Access Keys de AWS dentro de GitHub Secrets.
Aunque esto es mejor que hardcodearlas, seguimos dependiendo de credenciales permanentes que pueden ser filtradas o comprometidas.

Con OpenID Connect (OIDC) podemos eliminar completamente ese problema.

¿Cómo funciona?

GitHub Actions inicia la ejecución del workflow.
GitHub genera un token JWT temporal.
AWS valida el token mediante un OIDC Provider.
AWS verifica que el repositorio tenga permiso para asumir un rol específico.
AWS entrega credenciales temporales.
Las credenciales expiran automáticamente

No hay keys. No hay tokens permanentes. Nada que pueda leakearse.

Paso 1 — Crear el OIDC Provider en IAM:
Provider URL: token.actions.githubusercontent.com

Paso 2 — Crear un IAM Role con trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:MI-ORG/MI-REPO:*"
        }
      }
    }
  ]
}

La condición StringLike es clave: solo TU repo puede asumir este rol. Si alguien forkea tu repo, no puede deployar.

Paso 3 — Usar en el workflow de Github Actions:

permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: ${{ vars.AWS_ROLE_ARN }}
      aws-region: us-east-1

Eso es todo. Cero secrets de AWS en GitHub.

3. Secret Scanning

Incluso con buenas prácticas, los errores siguen ocurriendo.

Por eso GitHub incorpora Secret Scanning.
Esta funcionalidad analiza automáticamente los commits buscando patrones asociados a credenciales conocidas.

Actualmente puede detectar más de 200 tipos de secretos pertenecientes a más de 100 proveedores.
Ejemplo: AWS, GitHub, Slack, Stripe, Twilio, npm, etc.

Para habilitarlo:
Settings → Code security and analysis → Secret scanning → Enable

Cuando GitHub detecta una credencial:

Genera una alerta.
Muestra exactamente dónde se encuentra.
En algunos casos coordina la revocación automática con el proveedor.

Es una capa reactiva, pero extremadamente útil.

4. Push Protection

Mientras Secret Scanning detecta problemas después del commit, Push Protection intenta detenerlos antes.

Cuando GitHub detecta una credencial durante un push, simplemente bloquea la operación.

El secret nunca llegó al repo. Nunca se expuso. Protección proactiva.

Para habilitarlo:
Settings → Code security and analysis → Push protection → Enable

5. Dependabot

La seguridad no se limita únicamente a las credenciales.
Muchas vulnerabilidades provienen de dependencias desactualizadas.

Cuando se publica un CVE crítico que afecta una librería utilizada por nuestro proyecto, Dependabot puede:

Detectar la vulnerabilidad.
Generar una alerta.
Crear automáticamente un Pull Request con la actualización.

Configuración (.github/dependabot.yml):

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Además de dependencias de aplicación, Dependabot también ayuda a mantener actualizadas las GitHub Actions utilizadas por nuestros pipelines.

Demo: Deploy completo sin credenciales

Para demostrar cómo funcionan varias de estas capas trabajando juntas, preparé una aplicación sencilla que lee un secreto desde una variable de entorno y lo muestra en una página web.

El código relevante:

const SECRET_MESSAGE = process.env.SECRET_MESSAGE || 'No secret configured'

La aplicación no conoce el valor del secreto.
Simplemente espera encontrar una variable de entorno durante la ejecución.

La demostración consistió en desplegar esta aplicación en Amazon ECS Fargate, utilizando GitHub Actions para automatizar todo el proceso y OIDC para autenticarnos en AWS sin necesidad de almacenar Access Keys permanentes.

El flujo:

GitHub Secret (SECRET_MESSAGE)
       ↓
GitHub Actions (OIDC → sin AWS keys)
       ↓
Build Docker image → Push a ECR
       ↓
Update ECS Task Definition (inyecta el secret)
       ↓
Deploy a ECS Fargate
       ↓
App muestra el secret

Resultado: El secret se muestra en la app, pero si buscas en todo el repositorio, no lo vas a encontrar. Se inyecta en runtime a través de la Task Definition de ECS. Nunca existió en el código fuente.

Qué puedes hacer hoy

Si te llevas algo de este artículo, que sea esto:

Habilita Push Protection: Protección inmediata contra leaks accidentales.
Migra de AWS access keys a OIDC: Eliminas el riesgo más grande de tu pipeline.
Agrega dependabot.yml: Un archivo y tus dependencias se mantienen actualizadas automáticamente.
Mueve secrets hardcodeados a GitHub Secrets: Revisa tu código, busca tokens hardcodeados, y muévelos.

Conclusión

La seguridad de credenciales no tiene que ser complicada.

GitHub nos proporciona múltiples capas de protección que abarcan desde la prevención de errores humanos mediante Push Protection, hasta la detección de credenciales expuestas con Secret Scanning y la eliminación completa de credenciales permanentes mediante OIDC.

La principal reflexión que quise transmitir durante mi charla en el GitHub Community Day Perú 2026 es que muchas veces utilizamos GitHub todos los días, pero no aprovechamos todo el potencial que nos ofrece en materia de seguridad.

Con unas pocas configuraciones podemos reducir significativamente el riesgo de exposición de credenciales y fortalecer nuestros pipelines sin añadir complejidad innecesaria.

Las diapositivas utilizadas para la presentación están disponibles en: https://speakerdeck.com/bnktch13/seguridad-en-github-para-devops
Y el código completo del ejemplo utilizado durante la demostración está disponible en: https://github.com/BnkTCh/secure-deploy-demo

Te invito a explorarlo, probarlo y adaptarlo a tus propios proyectos.

Y si estuviste presente en la charla durante el GitHub Community Day Perú 2026, gracias por acompañarme y por todas las preguntas y conversaciones que hicieron la sesión aún más interesante.

Prompts que construyen: cómo dominar Amazon Q Developer en tu día a día

Bianca Torres — Mon, 05 Jan 2026 02:22:14 +0000

¿Sabías que el 40% del tiempo de un desarrollador se va en tareas repetitivas como leer documentación, generar boilerplate y debuggear errores?

Como DevOps Engineer, he descubierto que Amazon Q Developer puede transformar estas tareas tediosas en procesos eficientes. No es solo "otra IA más": es un asistente especializado que entiende el ecosistema AWS.

En este artículo te muestro cómo usarlo de forma práctica y, más importante, cómo escribir prompts que generen resultados reales, no respuestas genéricas.

Este artículo está basado en una charla que di sobre Amazon Q Developer y Prompt Engineering.

Si prefieres el formato video, aquí puedes verla completa:
https://www.youtube.com/live/M3sr0p8G5OU?si=YI9GLC-6PN8ygRql

¿Qué es Amazon Q Developer?

Amazon Q Developer es un asistente de IA generativa enfocado en:

Desarrollo de software
Administración de AWS
Mejores prácticas oficiales

Se integra directamente en:

IDEs como VS Code
AWS Console
CLI

A diferencia de otras herramientas genéricas, Amazon Q está entrenado con:

Documentación oficial de AWS
Ejemplos reales
Buenas prácticas del ecosistema cloud

¿Cómo funciona Amazon Q Developer?

Amazon Q Developer funciona sobre Amazon Bedrock, utilizando distintos Large Language Models (LLMs), entre ellos:

Amazon Titan
GPT (y otros modelos disponibles)

Algunos puntos clave:

No usa un único modelo fijo
Cuanto más popular es un lenguaje o framework, mejor entrenado estará el modelo.
Más datos de entrenamiento → mejores sugerencias

Por eso, tecnologías comunes como Terraform, Kubernetes o Python suelen tener respuestas de muy buena calidad.

¿Qué podemos hacer con Amazon Q Developer?

En el día a día, Amazon Q puede ayudarte a:

Autocompletar código más rápido
Obtener soluciones simples sin salir del IDE
Explicar y documentar código
Explicar mensajes de error
Generar pruebas
Crear código base (boilerplate)
Mejorar tu productividad en general

La clave no es solo qué hace, sino cómo se lo pides.

Casos de uso reales donde Amazon Q brilla

Para DevOps Engineers:

Infraestructura como código: Generar templates de CloudFormation/Terraform
Troubleshooting: Interpretar logs de CloudWatch y errores de servicios AWS
Automatización: Crear scripts de CI/CD y pipelines

Para Developers:

SDK de AWS: Generar código para interactuar con servicios AWS
Serverless: Crear funciones Lambda con mejores prácticas
Containerización: Dockerfiles optimizados para ECS/EKS

Para Cloud Architects:

Diseño de arquitecturas: Sugerir patrones y servicios apropiados
Optimización de costos: Identificar oportunidades de ahorro
Seguridad: Implementar controles y políticas IAM

¿Qué es un prompt?

Un prompt es simplemente:
La instrucción que le das a la IA para que realice una tarea.
Pero la diferencia entre frustración y productividad está en la calidad del prompt.

Prompt vago vs Prompt bueno

Prompt vago:

Explícame este error

Prompt bueno:

Explícame este error que ocurre en un pod de Kubernetes en EKS cuando intento 
desplegar una aplicación Spring Boot en Java 17 y el pod entra en estado 
CrashLoopBackOff.

👉 El contexto lo es todo.

Buenas prácticas de Prompt Engineering

La regla de las 4 C:

Estas son las prácticas que mejor resultado me han dado usando Amazon Q Developer:

Claro
Sé específico sobre lo que quieres.
Contexto
Incluye información clave como:
Lenguaje
Versión
Servicio
Entorno
Conciso
Evita el ruido innecesario.
Continuo
Itera. Ajusta el prompt según la respuesta que recibes.

Checklist antes de enviar un prompt

Antes de presionar Enter, pregúntate:

¿Qué quiero exactamente? (tarea + resultado esperado)
¿Dónde corre? (lenguaje, versión, servicio, entorno)
¿Es claro y corto?
¿Qué siguiente paso pediré si no es perfecto?

Prompt engineering es un diálogo, no una orden única.

Conclusión
Amazon Q Developer puede ahorrarte mucho tiempo si sabes cómo hablarle.

No se trata de escribir prompts "bonitos", sino prompts útiles, con intención clara, contexto técnico y capacidad de iteración.

Si eres DevOps Engineer, Cloud Engineer o Developer y trabajas con AWS, aprender a usar Amazon Q Developer bien es una ventaja real, no solo hype.

Próximos pasos:

Instala Amazon Q Developer en tu IDE favorito:
https://docs.aws.amazon.com/es_es/amazonq/latest/qdeveloper-ug/q-in-IDE-setup.html
Practica con un proyecto real - empieza con tareas simples
Documenta tus prompts exitosos - crea tu propia biblioteca
Comparte con tu equipo - la productividad se multiplica

¿Y tú?
¿Ya usas Amazon Q Developer en tu día a día?