DEV Community: Adrian

Cómo construí un ecosistema de agentes de IA para automatizar la seguridad del código

Adrian — Fri, 26 Jun 2026 13:10:02 +0000

🔐 Automaticé la seguridad del código con Agentes de IA — y esto es lo que aprendí.

En los últimos meses lideré el diseño y la implementación de un ecosistema completo de agentes de inteligencia artificial que transformó la forma en que gestionamos la seguridad del código en la empresa.

El problema que resolvimos: Los equipos de desarrollo desplegaban código sin una capa consistente de análisis de seguridad. Las revisiones manuales no escalaban, los hallazgos se perdían entre herramientas desconectadas, y no existía trazabilidad centralizada de las vulnerabilidades detectadas.

La solución: 4 agentes de IA especializados, orquestados por GitHub Actions y conectados a Jira.

🧠 Cada agente usa Google Gemini (Vertex AI) como motor de razonamiento, pero no se limita a "preguntar a la IA". Integra herramientas de análisis estático de referencia en la industria (Semgrep, Trivy, detect-secrets) y usa la IA para triar, contextualizar y generar remediaciones accionables.

Los agentes en acción:

🔐 PR Security Analyzer — Analiza cada Pull Request buscando fallas OWASP Top 10, secretos expuestos y bugs lógicos. El desarrollador recibe feedback de seguridad antes de mergear.

🐳 Dockerfile Security Analyzer — Audita contenedores en cada PR. Propone builds multi-stage, ejecución non-root y optimizaciones específicas para AWS ECS Fargate.

📦 Dependency Vulnerability Analyzer — Escanea lockfiles de cualquier lenguaje (Node, Python, Go, Ruby, PHP). Diferencia entre dependencias directas y transitivas para no bloquear builds innecesariamente.

🔒 Production Security Scanner — Escaneo profundo programado (cron semanal) o a demanda. Combina 3 herramientas + triaje con Gemini Flash + análisis de explotación con Gemini Pro. Genera reportes completos con código de remediación.

La parte que más valor genera: la automatización de Jira 🎫

No alcanza con detectar vulnerabilidades — hay que gestionarlas. Implementé un flujo inteligente donde:

✅ Si el escáner encuentra vulnerabilidades → crea un ticket en el tablero de Jira con enlace directo al Issue de GitHub ✅ Si las vulnerabilidades persisten en el próximo escaneo → actualiza el ticket existente (sin duplicados) ✅ Si el equipo resolvió todas las vulnerabilidades → el ticket se cierra automáticamente con transición al estado RESUELTO

Cero intervención manual. Ciclo de vida 100% autónomo.

Lo que viene: Drift Detection Agent 🧭

Estamos diseñando un agente de drift de seguridad que compara líneas base entre escaneos. ¿Apareció una nueva CVE que antes no estaba? ¿Un fix anterior reapareció como regresión? ¿Cambió una configuración de seguridad sin aprobación? El drift agent lo detecta y alerta automáticamente cuando el delta supera un umbral definido.

Stack técnico: Google Vertex AI · Gemini Flash & Pro · GitHub Actions · Semgrep · Trivy · detect-secrets · Jira Cloud API · Google Chat Webhooks · Workload Identity Federation (GCP) · Node.js

Impacto medible: 📉 Reducción del tiempo de detección de vulnerabilidades de días a minutos 📊 Tablero SECOP centralizado con visibilidad ejecutiva 🔄 Ciclo de vida de incidentes completamente automatizado 🛡️ Cobertura de seguridad en cada PR, cada Dockerfile, cada dependencia y cada repositorio en producción

Flujo 1: Pipeline de Seguridad en Pull Requests

Flujo 2: Escaneo de Producción + Jira Automation

Flujo 3: Drift Detection Agent (Próxima Fase)

# ECS vs Kubernetes

Adrian — Tue, 14 Apr 2026 14:25:05 +0000

No toda plataforma de contenedores necesita la complejidad operativa de Kubernetes.

Cuando el objetivo es desplegar aplicaciones de forma rapida, segura y con bajo overhead operativo, Amazon ECS suele ofrecer una relacion mucho mas simple entre valor y esfuerzo:

Menor complejidad de operacion y mantenimiento.
Integracion nativa con servicios de AWS.
Curva de aprendizaje mas corta para equipos pequenos o medianos.
Menos componentes que administrar.
Menor tiempo de puesta en marcha.
Muy buena opcion para workloads HTTP, APIs internas, backends y procesos batch.

Kubernetes sigue siendo una excelente alternativa cuando hay requerimientos claros de portabilidad, ecosistemas multi-cluster complejos, operadores avanzados o estandares de plataforma muy maduros. Pero no deberia ser la eleccion por default.

La mejor decision no es "usar la tecnologia mas popular", sino elegir la que resuelve el problema con la menor friccion operativa posible.

Beneficios De Usar ECS

1. Menos carga operativa

Con ECS el equipo puede enfocarse mas en la aplicacion y menos en administrar el orquestador. En muchos casos no hace falta ocuparse de:

upgrades del control plane
administracion de etcd
networking avanzado entre multiples componentes
capas extra de observabilidad y add-ons solo para que el cluster funcione bien

Si ademas se usa AWS Fargate, tambien se elimina la administracion de nodos.

2. Mejor alineacion con AWS

ECS se integra de forma natural con:

Application Load Balancer
CloudWatch
IAM
ECR
Auto Scaling
Secrets Manager
VPC

Eso simplifica mucho el diseño de una plataforma estandar para publicar servicios.

3. Menor costo de complejidad

Muchas veces el costo mas alto no esta en la infraestructura sino en la complejidad operativa:

mas piezas para aprender
mas riesgos de configuracion
mas tiempo para diagnosticar incidentes
mas esfuerzo de onboarding

Si el caso de uso no necesita las capacidades avanzadas de Kubernetes, ese costo no siempre se justifica.

4. Time to market mas rapido

Para equipos que quieren publicar microservicios o aplicaciones internas con rapidez, ECS permite construir una plataforma repetible con menos decisiones tecnicas y menos puntos de falla.

5. Escala suficiente para muchisimos casos reales

Existe una idea comun de que "si hay contenedores, entonces tiene que haber Kubernetes". En la practica, muchisimas cargas productivas funcionan perfectamente sobre ECS, especialmente cuando:

el entorno ya vive mayormente en AWS
el equipo prioriza simplicidad
no existe necesidad real de portabilidad multi-cloud
los servicios comparten patrones de despliegue similares

6. Infraestructura y despliegues mas predecibles

Cuando la infraestructura se define como codigo y los despliegues se automatizan con GitHub Actions, el beneficio no es solo tecnico: tambien mejora la forma de operar del equipo.

Esto aporta:

entornos repetibles y versionados
menor riesgo de configuraciones manuales inconsistentes
trazabilidad completa de cambios
revisiones por pull request antes de modificar infraestructura o aplicaciones
despliegues mas rapidos y estandarizados
menos dependencia de pasos manuales y conocimiento tribal

La combinacion de ECS + Terraform + GitHub Actions permite construir una plataforma simple de entender y facil de escalar operativamente.

Cuando ECS Tiene Mucho Sentido

ECS suele ser una decision muy solida para:

APIs y backends de negocio
aplicaciones internas
microservicios HTTP
workers y jobs programados
equipos de plataforma pequenos o en crecimiento
organizaciones que quieren estandarizar despliegues sin operar una plataforma demasiado compleja

Cuando Kubernetes Puede Ser Mejor

Kubernetes puede ser la mejor opcion cuando hay necesidades concretas como:

portabilidad fuerte entre clouds o datacenters
ecosistema basado en operadores, CRDs o service mesh avanzado
requerimientos de plataforma multi-tenant mas sofisticados
estandarizacion corporativa ya consolidada sobre Kubernetes
equipos con experiencia profunda administrando clusters y sus componentes

La clave es que esas necesidades sean reales, no asumidas.

how to launch elastic cache with terraform

Adrian — Mon, 27 Nov 2023 22:42:56 +0000

A developer from the compañy I work asked me about the posibility of adding a new database for a new requirement. After asking some question about what he needs to do, we decided to moved to elastic cache.

First.
we need to crete a security group to permit port 6379

resource "aws_security_group" "allow_cache" {
  name        = "allow_cache-${local.app_name}-${terraform.workspace}"
  description = "Allow cache inbound traffic"
  vpc_id      = var.vpc-id

  ingress {
    description      = "cache from VPC"
    from_port        = 6379
    to_port          = 6379
    protocol         = "tcp"
    cidr_blocks      = [var.allowed_cidr_block-1]
   }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
   }

  tags = {
    Name = "allow_cache"
  }
}

Lambda role

resource "aws_iam_role" "lambda_vpc_role" {
  name = "lambda-vpc-role-${local.app_name}-${terraform.workspace}"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

attachmet

resource "aws_iam_role_policy_attachment" "lambda_vpc_role_policy" {
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole"
  role       = aws_iam_role.lambda_vpc_role.name
}

Cluster elastic cache with output

resource "aws_elasticache_cluster" "hr_cache" {
  cluster_id           = "clusterforlambdatest-${local.app_name}-${terraform.workspace}"
  engine               = "redis"
  node_type            = "cache.t4g.micro"
  num_cache_nodes      = 1
  port                 = 6379
  #engine_version       = "3.2.10"
  subnet_group_name    = aws_elasticache_subnet_group.subnet-sg.id
  security_group_ids   = [aws_security_group.allow_cache.id]
    tags = {
    nombre  = "hr_cache"
    deploy  = "terraform"
  }
}


output "elasticache_endpoint" {
  value = aws_elasticache_cluster.hr_cache.cache_nodes.0.address
}

all code here:

resource "aws_security_group" "allow_cache" {
  name        = "allow_cache-${local.app_name}-${terraform.workspace}"
  description = "Allow cache inbound traffic"
  vpc_id      = var.vpc-id

  ingress {
    description      = "cache from VPC"
    from_port        = 6379
    to_port          = 6379
    protocol         = "tcp"
    cidr_blocks      = [var.allowed_cidr_block-1]
   }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
   }

  tags = {
    Name = "allow_cache"
  }
}


resource "aws_iam_role" "lambda_vpc_role" {
  name = "lambda-vpc-role-${local.app_name}-${terraform.workspace}"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_vpc_role_policy" {
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole"
  role       = aws_iam_role.lambda_vpc_role.name
}


#resource "aws_subnet" "example" {
#  vpc_id     = aws_vpc.example.id
#  cidr_block = "10.0.0.0/8"
#
#  tags = {
#    Name = "my-subnet"
#  }
#}

resource "aws_elasticache_subnet_group" "subnet-sg" {
  name       = "my-cache-subnet"
  subnet_ids = [var.subnet-t-app-net]
}



resource "aws_elasticache_cluster" "hr_cache" {
  cluster_id           = "clusterforlambdatest-${local.app_name}-${terraform.workspace}"
  engine               = "redis"
  node_type            = "cache.t4g.micro"
  num_cache_nodes      = 1
  port                 = 6379
  #engine_version       = "3.2.10"
  subnet_group_name    = aws_elasticache_subnet_group.subnet-sg.id
  security_group_ids   = [aws_security_group.allow_cache.id]
    tags = {
    nombre  = "hr_cache"
    deploy  = "terraform"
  }
}


output "elasticache_endpoint" {
  value = aws_elasticache_cluster.hr_cache.cache_nodes.0.address
}

in order to test this, we can install a tool called redis comander

redis-commander --redis-host clusterforlambdatest-xxxx-prd.xxxxxxxxxx.cache.amazonaws.com

If we are saving data correctly into the Elastic Cache, we can see it here.