Tabla de Contenidos
Introducción
Todo ingeniero tiene ese proyecto — el que comienza como una idea simple y evoluciona hasta convertirse en un laboratorio de aprendizaje invaluable. Para mí, ese proyecto es esta Publisher Web App: un sistema diseñado para publicar anuncios en múltiples canales de redes sociales simultáneamente. ¿El caso de uso principal? El AWS Certification Announcer, una herramienta comunitaria donde los miembros envían sus logros de certificación AWS y la plataforma los publica automáticamente en Facebook, Instagram, WhatsApp, LinkedIn, Email, etc.
Lo que comenzó como una necesidad práctica para el AWS User Group rápidamente se convirtió en un ejercicio conveniente para aplicar cada principio DevSecOps que siempre quise poner en práctica, pero no había podido hasta ahora. Este artículo recorre los fundamentos del proyecto — la arquitectura, los lineamientos de seguridad, la estrategia de despliegue y las lecciones aprendidas en el camino.
El proyecto completo es open source y está disponible en github.com/Walsen/devsecops-poc .
La Visión: Más Que Solo Publicar
El objetivo nunca fue construir “otro notificador de redes sociales más”. La visión era crear una plataforma que sirviera como implementación de referencia para el desarrollo cloud-native moderno — una que demuestre cómo construir software que sea seguro por diseño, portable entre modelos de despliegue y mantenible a lo largo del tiempo.
La plataforma necesitaba:
- Publicar en varios canales: Facebook, Instagram, WhatsApp, LinkedIn, Email y más
- Soportar autenticación social: Google, GitHub, LinkedIn o email/contraseña vía Amazon Cognito
- Programar mensajes: Encolar anuncios para entrega futura
- Aplicar control de acceso basado en roles: Roles de Admin y Community Manager con límites estrictos
- Ser segura desde el día uno: Redes Zero Trust, cifrado en todas las capas, protección WAF y una cadena de suministro robusta
- Ejecutarse en dos modos de despliegue: Contenedores (ECS Fargate) o Serverless (Lambda + DynamoDB), intercambiables al momento del despliegue
Arquitectura Hexagonal: La Base
Si hay una decisión arquitectónica que hizo posible todo lo demás, es la adopción de la arquitectura hexagonal (también conocida como Patrón de Puertos y Adaptadores).
Este patrón separa el sistema en tres zonas concéntricas:
| Zona | Responsabilidad | Dependencias |
|---|---|---|
| Adaptadores de Entrada | Reciben input externo (HTTP, eventos Kinesis, cron) | Dependen de Puertos de Entrada |
| Núcleo de Aplicación | Lógica de negocio, casos de uso, modelo de dominio | Cero dependencias externas |
| Adaptadores de Salida | Implementan integraciones de salida (BD, colas, APIs) | Implementan Puertos de Salida |
El núcleo de la aplicación — entidades de dominio, casos de uso e interfaces de puertos — no tiene absolutamente ningún conocimiento del mundo exterior. No sabe si está corriendo en ECS o Lambda. No sabe si la base de datos es PostgreSQL o DynamoDB. Solo conoce abstracciones.
El Modelo de Dominio
El dominio está construido con dataclasses puras de Python:
| Entidad / Value Object | Descripción |
|---|---|
Message (Aggregate Root) |
Rastrea contenido, canales, programación, estado y entregas por canal |
Certification (Entity) |
Logro de certificación AWS con información del miembro y tipo |
ChannelType (Value Object) |
Enum: facebook, instagram, linkedin, whatsapp, email, sms |
MessageStatus (Value Object) |
Ciclo de vida: DRAFT → SCHEDULED → PROCESSING → DELIVERED / FAILED |
DeliveryResult (Value Object) |
Resultado por canal con ID externo o error |
Puertos y Adaptadores en la Práctica
El puerto MessageRepository es la misma interfaz independientemente del modo de despliegue. Solo cambia el adaptador:
# Puerto (compartido entre ambos modos)
class MessageRepository(ABC):
@abstractmethod
async def get_by_id(self, id: UUID) -> Message | None: ...
@abstractmethod
async def save(self, message: Message) -> None: ...
# Adaptador para contenedores
class PostgresMessageRepository(MessageRepository):
def __init__(self, session: AsyncSession):
self._session = session
# Adaptador serverless
class DynamoMessageRepository(MessageRepository):
def __init__(self, table_name: str):
self._table = boto3.resource("dynamodb").Table(table_name)
Este es el habilitador clave para la estrategia de despliegue de modo dual. La lógica de negocio está completamente desacoplada de la infraestructura.
Tres Servicios, Un Stream
La plataforma está compuesta por tres microservicios conectados por Amazon Kinesis Data Streams:
REST + Auth"] end subgraph Queue["Stream de Eventos"] KINESIS["Kinesis
Data Streams"] end subgraph Worker["Servicio Worker"] CONSUMER["Consumidor Kinesis
Entrega por Canal"] end subgraph Scheduler["Servicio Scheduler"] CRON["APScheduler
Escáner de Mensajes Pendientes"] end subgraph DB["Capa de Datos"] RDS[("PostgreSQL
o DynamoDB")] end FASTAPI -->|"Publicar Evento"| KINESIS KINESIS -->|"Consumir"| CONSUMER CRON -->|"Consultar mensajes pendientes"| RDS CRON -->|"Publicar Evento"| KINESIS FASTAPI --> RDS style Queue fill:#fff3e0 style DB fill:#fce4ec
- Servicio API: Maneja las solicitudes HTTP, autenticación y programación de mensajes. Implementa el stack hexagonal completo con rutas FastAPI, middleware y validación de JWT de Cognito.
- Servicio Worker: Consume mensajes de Kinesis y los entrega a los canales correspondientes. Soporta dos estrategias de publicación — llamadas directas a APIs o adaptación de contenido con IA vía Amazon Bedrock.
- Servicio Scheduler: Consulta la base de datos en busca de mensajes programados y los publica en Kinesis cuando llega su hora de entrega.
Cada servicio tiene su propio main.py que sirve como composition root — el único lugar donde se importan e inyectan las implementaciones concretas. Ningún otro módulo importa directamente desde infrastructure/.
Despliegue de Modo Dual: Contenedores o Serverless
Aquí es donde la arquitectura hexagonal rinde frutos de manera muy tangible. La plataforma soporta dos modos de despliegue completamente independientes, intercambiables al momento del despliegue mediante un solo parámetro de CI/CD:
Contenedores (infra/) |
Serverless (infra-fs/) |
|
|---|---|---|
| Cómputo | ECS Fargate | Lambda |
| Base de Datos | PostgreSQL (RDS) | DynamoDB (Single-Table) |
| API Gateway | ALB + CloudFront | API Gateway + CloudFront |
| Scheduler | Servicio ECS (APScheduler) | EventBridge + Lambda |
| Costo (bajo tráfico) | ~$180-200/mes | ~$5-15/mes |
Ambos modos comparten las mismas capas de dominio y aplicación. Solo cambian los adaptadores de infraestructura. El workflow de despliegue selecciona el modo vía el input infra_type (containers o serverless), enrutando al proyecto CDK correspondiente. Los nombres de stack son completamente independientes, por lo que ambos pueden coexistir en la misma cuenta AWS durante una migración.
Por Qué Esto Importa
Diferentes etapas de un proyecto tienen diferentes necesidades:
| Etapa | Modo Recomendado | Razón |
|---|---|---|
| Desarrollo / Prototipado | Serverless | Costo casi nulo, despliegues instantáneos |
| Staging / QA | Cualquiera | Igualar producción o ahorrar costos |
| Producción (tráfico estable) | Contenedores | Latencia predecible, sin cold starts |
| Producción (tráfico variable) | Serverless | Pago por uso, auto-scaling |
Puedes comenzar barato con serverless y migrar a contenedores cuando el tráfico justifique el costo fijo — o viceversa — sin reescribir una sola línea de lógica de negocio.
Ejecutando Ambos Simultáneamente
Dado que los nombres de stack son independientes, puedes ejecutar ambos modos en paralelo durante una ventana de migración. Esto permite hacer smoke testing contra el nuevo modo antes de hacer el corte, migración gradual de tráfico usando enrutamiento DNS ponderado (Route 53) y rollback instantáneo cambiando el DNS de vuelta.
Seguridad Zero Trust: No Confíes en Nada, Verifica Todo
La seguridad no es una funcionalidad que se agrega al final. Es un principio de diseño que permea cada capa del sistema. La plataforma implementa una arquitectura Zero Trust basada en tres pilares:
Autorizar basado en contexto
Autenticación multifactor"] LEAST["Mínimo Privilegio
Acceso justo a tiempo
Permisos basados en roles"] BREACH["Asumir Brecha
Minimizar radio de explosión
Segmentar acceso
Cifrado de extremo a extremo"] end
Seguridad de Red
Todo el tráfico fluye a través de múltiples capas de seguridad:
+ Shield"] CF --> WAF["WAF
Reglas OWASP"] WAF -->|"TLS 1.3"| ALB["ALB"] ALB -->|"TLS 1.3"| ECS["ECS Fargate"] ECS -->|"TLS"| RDS[("RDS
PostgreSQL")] style CF fill:#e8f5e9 style WAF fill:#e8f5e9
La VPC está segmentada en subredes públicas, privadas y aisladas. Los security groups aplican micro-segmentación — el ALB solo puede comunicarse con la API, la API solo puede comunicarse con el Worker y la base de datos, y la base de datos solo acepta conexiones de servicios autorizados.
Flujo de Autenticación
Email/Contraseña"] GOOGLE["Google
OAuth 2.0"] GITHUB["GitHub
OIDC"] LINKEDIN["LinkedIn
OIDC"] end subgraph Pool["Cognito User Pool"] FEDERATE["Capa de Federación"] USERS["Directorio de Usuarios"] GROUPS["Grupos
admin, community-manager"] end subgraph Tokens["Emisión de Tokens"] JWT["Tokens JWT
• Access Token (1h)
• ID Token (1h)
• Refresh Token (30d)"] end COGNITO --> FEDERATE GOOGLE --> FEDERATE GITHUB --> FEDERATE LINKEDIN --> FEDERATE FEDERATE --> USERS USERS --> GROUPS GROUPS --> JWT
Cada solicitud se valida contra JWTs de Cognito con restricción estricta de algoritmo (solo RS256), validación de audience e issuer, y caché de JWKS con refresco por TTL. Las credenciales OAuth para proveedores sociales se almacenan en AWS Secrets Manager.
Middleware de Seguridad de la API
El servicio API implementa un stack completo de middleware de seguridad:
| Aspecto | Implementación |
|---|---|
| Autenticación | Validación JWT de Cognito con restricción de algoritmo |
| Protección CSRF | Double Submit Cookie con tokens firmados por HMAC |
| Rate Limiting | Ventana deslizante por usuario (60 req/min) |
| Validación de Requests | Límite de 1MB, sanitización de input, escape de HTML |
| Headers de Seguridad | CSP, HSTS, X-Frame-Options, Permissions-Policy |
| Filtrado de Contenido | Detección de prompt injection + escaneo de PII |
| Idempotencia | Deduplicación basada en hash de message_id + channels |
Protección de Datos
El cifrado se aplica en cada capa:
- En Tránsito: TLS 1.3 en todas partes — CloudFront a ALB, ALB a ECS, ECS a RDS, ECS a Kinesis
- En Reposo: Cifrado KMS para S3, RDS y Kinesis
- En Uso: Sin PII en logs, cifrado a nivel de campo para datos sensibles
Cadena de Suministro Segura
El pipeline de build está endurecido contra ataques a la cadena de suministro con múltiples puertas de seguridad:
Commits Firmados"] PR["Revisión de PR
Requerida"] end subgraph Scan["Escaneo de Seguridad"] DEP["Auditoría de
Dependencias"] SAST["Análisis
Estático"] SECRET["Escaneo de
Secretos"] end subgraph Build["Build de Contenedor"] BASE["Imagen Base
Distroless"] NONROOT["Usuario
Non-root"] READONLY["Sistema de Archivos
Solo Lectura"] end subgraph Sign["Firma"] SIGN["Firma de
Imagen"] SBOM["Generación
de SBOM"] end Source --> Scan --> Build --> Sign
Defensa en Profundidad: Múltiples Escáneres
Ningún escáner individual lo detecta todo. El proyecto utiliza seis herramientas complementarias:
| Escáner | Tipo | Propósito |
|---|---|---|
| Semgrep | SAST | Patrones OWASP Top 10, reglas personalizadas |
| Bandit | SAST | Problemas de seguridad específicos de Python |
| pip-audit | SCA | Base de datos de CVEs de Python (PyPI Advisory) |
| Trivy | SCA | Escaneo de vulnerabilidades en SBOM |
| Gitleaks | Secrets | Detección de secretos hardcodeados en historial git |
| Checkov | IaC | Misconfiguraciones de seguridad AWS en CDK/CloudFormation |
Cada herramienta cubre puntos ciegos que las demás no detectan. Semgrep captura patrones de SQL injection y XSS. Bandit encuentra problemas específicos de Python como carga insegura de YAML. pip-audit y Trivy manejan CVEs conocidos. Gitleaks previene fugas de credenciales. Checkov asegura que la infraestructura misma sea segura — sin buckets S3 públicos, sin cifrado faltante, sin IAM excesivamente permisivo.
Seguridad de Contenedores
Los contenedores de producción se construyen con la seguridad como prioridad:
- Imágenes base distroless: Sin shell, superficie de ataque mínima
- Usuario non-root: Los contenedores corren como
nonrootpor defecto - Sistema de archivos de solo lectura: Sin escrituras al filesystem raíz
- Dependencias fijadas: Lock files con hashes para reproducibilidad
- Límites de recursos: Restricciones de CPU y memoria para prevenir abuso
CI/CD con GitHub Actions OIDC
El proyecto usa GitHub Actions OIDC para asumir roles IAM de AWS sin almacenar credenciales de larga duración. Un stack de bootstrap CDK (GitHubOIDCStack) crea el proveedor OIDC y dos roles IAM:
- Rol de Despliegue (
github-actions-deploy): Para despliegues CDK y pushes a ECR - Rol de Escaneo de Seguridad (
github-actions-security-scan): Para auditorías Prowler con acceso de solo lectura
No se almacenan access keys de AWS en GitHub Secrets. Cada despliegue usa credenciales de corta duración (1 hora) obtenidas vía federación OIDC.
El Golden Thread: Trazabilidad Distribuida de Seguridad
Uno de los aspectos más interesantes del proyecto es el Golden Thread — un ejercicio de trazabilidad distribuida que demuestra la correlación de solicitudes de extremo a extremo a través de todas las capas de infraestructura usando un único ID de correlación (X-Request-ID).
El ID de correlación fluye a través de:
- Capa Edge: Logs del WAF (CloudFront + ALB)
- Capa de Aplicación: Logs estructurados de la API (structlog JSON)
- Capa Asíncrona: Evento Kinesis → Logs del Worker
- Capa de Base de Datos: Logs de auditoría de PostgreSQL (pgaudit) con comentarios SQL
/* correlation_id=golden-thread-test-1739... */ INSERT INTO messages (id, content_text, ...) VALUES (...)
Todo consultable desde CloudWatch Logs Insights con un solo filtro:
fields @timestamp, service, event, correlation_id, method, path, status_code
| filter correlation_id = "YOUR_TRACE_ID"
| sort @timestamp asc
Ejercicios de Simulación de Ataques
El proyecto incluye ejercicios prácticos que simulan ataques reales y los rastrean a través de las capas:
- SQL Injection: Enviar un payload
' OR 1=1--, verificar que el WAF lo bloquea, confirmar que la solicitud nunca llega a la aplicación - Intentos de XSS: Enviar
<script>alert(1)</script>, rastrear el bloqueo del WAF en CloudWatch - Detección de Fuerza Bruta: Enviar 60 solicitudes rápidas, observar cómo se activa el rate limiting, verificar las alarmas de CloudWatch
- Traza Completa del Pipeline: Programar un mensaje con un ID de correlación conocido, rastrearlo desde CloudFront WAF → ALB WAF → API → Kinesis → Worker → PostgreSQL
La documentación también incluye ejercicios usando herramientas profesionales de penetration testing — nmap, nikto, sqlmap, ffuf, nuclei e hydra — cada una con las consultas CloudWatch correspondientes para rastrear las firmas de ataque a través de la infraestructura.
Adaptación de Contenido con IA
El servicio Worker soporta dos estrategias de publicación, seleccionables vía configuración:
Mismo contenido, todos los canales"] AGENT["AgentPublisher
Adaptado por IA según plataforma"] end subgraph Tools["Funciones @tool"] FB["post_to_facebook()"] IG["post_to_instagram()"] LI["post_to_linkedin()"] WA["send_whatsapp()"] end subgraph Gateways["Gateways de Canal"] FB_GW["Facebook Gateway"] IG_GW["Instagram Gateway"] LI_GW["LinkedIn Gateway"] WA_GW["WhatsApp Gateway"] end DIRECT --> Gateways AGENT --> Tools --> Gateways
El AgentPublisher usa el Strands Agents SDK con Amazon Bedrock (Claude) para adaptar inteligentemente el contenido para cada plataforma:
| Plataforma | Adaptación |
|---|---|
| Posts más largos, emojis, hashtags al final | |
| Enfoque visual, muchos emojis, hashtags | |
| Tono profesional, lenguaje formal | |
| Corto, celebratorio, personal |
El agente razona sobre qué herramientas llamar, las ejecuta, observa los resultados y continúa hasta completar la tarea. El middleware de filtrado de contenido protege contra prompt injection y fuga de PII en la salida generada por IA.
Agente de Testing de Seguridad con IA
Quizás la adición más novedosa al proyecto es el Agente de Testing de Seguridad — un asistente interactivo de penetration testing impulsado por IA, construido con el Strands Agents SDK y Amazon Bedrock. En lugar de ejecutar pruebas de seguridad manualmente e interpretar resultados, tienes una conversación con un agente que puede ejecutar tests, diagnosticar fallos, consultar recursos AWS e incluso auto-corregir código de pruebas.
• Razonamiento
• Selección de Herramienta
• Ejecución"] end subgraph Tools["Funciones @tool"] TEST["Ejecutores de Tests
run_pytest_test
run_all_tests_parallel
run_fast_tests"] AWS["AWS Solo Lectura
Outputs de CloudFormation
CloudWatch Logs
WAF Web ACLs"] CODE["Herramientas de Código
read_test_file
fix_test_code"] end subgraph Infra["Recursos AWS (Solo Lectura)"] CF["CloudFormation"] CW["CloudWatch Logs"] WAF["WAF v2"] end CLI --> LOOP LOOP --> TEST LOOP --> AWS LOOP --> CODE AWS --> CF AWS --> CW AWS --> WAF style Agent fill:#e3f2fd style Tools fill:#fff3e0 style Infra fill:#e8f5e9
La interacción se ve así:
🔒 Penetration Testing Agent Ready!
Tú: Ejecuta todos los tests rápidos
Agente: Voy a ejecutar la suite de tests rápidos en paralelo, omitiendo escaneos lentos...
✅ Todos los tests pasaron en 8 segundos!
Tú: El test de TLS está fallando, ¿puedes debuggearlo?
Agente: Déjame ejecutar el test de TLS y revisar los logs...
[ejecuta test, consulta CloudFormation para endpoints, revisa CloudWatch]
El certificado para api.ugcbba.click expiró. Esto es lo que encontré...
Guardrails Estrictos
El agente aplica límites de seguridad estrictos:
- Solo puede ejecutar tests de una lista blanca predefinida — sin ejecución arbitraria de comandos
- El acceso a AWS es de solo lectura — no puede crear, modificar ni eliminar ningún recurso
- El acceso a archivos está restringido al directorio
testing/— el path traversal está bloqueado - Rechaza tareas no relacionadas con penetration testing
La Suite de Tests
El agente envuelve una suite completa de tests de seguridad basada en pytest que corre dentro de un contenedor Kali Linux:
| Categoría | Tests | Duración |
|---|---|---|
| Rápidos (< 10s c/u) | Health, headers de seguridad, TLS, CORS, cookies, divulgación de errores, métodos HTTP, acceso por origen, SQLi, XSS | ~10s total |
| Medios (15-30s) | Rate limiting, CSRF end-to-end, protección IDOR | ~1 min |
| Lentos (30s-10min) | Escaneo de puertos nmap, escaneo web Nikto, inyección automatizada sqlmap | ~15 min |
El agente es inteligente sobre qué tests ejecutar — prioriza tests que fallaron recientemente, omite escaneos lentos a menos que se soliciten explícitamente, y cachea resultados exitosos por 5 minutos para evitar ejecuciones redundantes. La ejecución paralela vía pytest-xdist hace que la suite rápida completa termine en unos 8 segundos.
Framework de Penetration Testing Automatizado
Más allá del agente de IA, el proyecto incluye un framework independiente de penetration testing automatizado usando Kali Linux dockerizado. Esta es la base sobre la que el agente se construye, pero también puede usarse de forma independiente en pipelines de CI/CD.
# Construir el contenedor Kali
docker build -f testing/Dockerfile.kali -t pentest:latest testing/
# Smoke test rápido
docker run --rm -e TARGET_URL=http://your-alb.amazonaws.com pentest smoke
# Suite completa de tests
docker run --rm -e TARGET_URL=http://your-alb.amazonaws.com pentest all
# Generar reporte
docker run --rm -v $(pwd):/tests -e TARGET_URL=$TARGET_URL pentest report
El framework se integra con GitHub Actions para escaneos semanales programados y testing bajo demanda, con resultados subidos como artefactos del workflow.
Detección de Amenazas y Respuesta a Incidentes
La plataforma implementa detección y respuesta automatizada de amenazas:
IPs maliciosas, llamadas API inusuales"] SH["Security Hub
Hallazgos agregados, cumplimiento"] CT["CloudTrail
Log de auditoría de API"] end subgraph Response["Respuesta Automatizada"] EB["Regla EventBridge"] LAMBDA["Lambda de Respuesta"] WAF["Actualización de IP Set WAF"] end subgraph Alert["Alertas"] SLACK["Slack"] end GD -->|"Hallazgo"| EB EB -->|"Severidad >= 4"| LAMBDA LAMBDA -->|"Bloquear IP"| WAF LAMBDA -->|"Notificar"| Alert SH -.-> GD CT -.-> SH
GuardDuty monitorea amenazas. Cuando se detecta un hallazgo con severidad >= 4, una regla de EventBridge dispara una función Lambda que automáticamente bloquea la IP ofensora en el IP set del WAF y envía una alerta detallada a Slack. Security Hub agrega hallazgos de GuardDuty, CloudTrail y reglas de AWS Config para una vista unificada de cumplimiento.
Observabilidad de Seguridad
Dashboards y alarmas de CloudWatch proporcionan visibilidad en tiempo real:
| Métrica | Umbral | Acción |
|---|---|---|
| Fallos de autenticación (5min) | >= 20 | Alarma + SNS |
| Fallos CSRF (5min) | >= 20 | Alarma + SNS |
| Acceso denegado (5min) | >= 30 | Alarma + SNS |
| Hits de rate limit (5min) | >= 100 | Alarma + SNS |
| Tasa de errores (5min) | >= 10 | Alarma + SNS |
| Errores críticos (1min) | >= 1 | Alarma + SNS |
| Latencia API p95 | > 1000ms | Alarma + SNS |
La Experiencia del Desarrollador
Un buen proyecto DevSecOps no se trata solo de seguridad y arquitectura — también se trata de hacer la vida del desarrollador más fácil. El proyecto usa Devbox para entornos de desarrollo aislados y Just como task runner.
El justfile proporciona un conjunto completo de comandos:
# Desarrollo
just dev # Iniciar servicios locales y seguir logs
just up # Iniciar PostgreSQL + LocalStack
just test # Ejecutar todos los tests
just lint-local # Lint de todos los servicios localmente
# Seguridad
just security-scan # SAST + SCA + Escaneo de secretos
just trivy-scan # Escaneo de vulnerabilidades de contenedores
just sbom-scan # Generar y escanear SBOMs
just iac-scan # Escaneo de infraestructura con Checkov
just pentest-full # Ejecutar la suite completa de penetration testing
# Gestión de Recursos AWS (Ahorro de Costos)
just aws-up # Escalar servicios ECS + iniciar RDS
just aws-down # Escalar a cero (ahorrar dinero)
just aws-status # Verificar estado de recursos
Los comandos aws-up y aws-down son particularmente útiles — permiten escalar toda la infraestructura a cero cuando no está en uso, ahorrando costos significativos durante el desarrollo.
Estructura del Proyecto
El código está organizado para claridad y separación de responsabilidades:
.
├── api/ # Servicio API (FastAPI + hexagonal)
│ ├── src/
│ │ ├── domain/ # Entidades de negocio, value objects
│ │ ├── application/ # Casos de uso, puertos, DTOs
│ │ ├── infrastructure/ # Adaptadores (BD, Kinesis, Secrets)
│ │ └── presentation/ # Rutas HTTP, middleware
│ └── tests/
│
├── worker/ # Servicio Worker (consumidor Kinesis)
│ ├── src/
│ │ ├── domain/ # Puertos para canales, publishers
│ │ ├── application/ # Servicio de entrega
│ │ ├── infrastructure/ # Adaptadores de publisher (Directo, Agente IA)
│ │ └── channels/ # Gateways de canal (FB, IG, LI, Email, SMS)
│ └── tests/
│
├── scheduler/ # Servicio Scheduler (cron + ECS)
├── api-lambda/ # Handler Lambda de API (serverless)
├── worker-lambda/ # Handler Lambda de Worker (serverless)
├── scheduler-lambda/ # Handler Lambda de Scheduler (serverless)
├── web/ # Frontend (React + Vite + TypeScript)
│
├── testing/ # Framework de penetration testing
│ ├── pentest_agent.py # Agente de testing de seguridad con IA (Strands SDK)
│ ├── test_pentest.py # Casos de test de seguridad (pytest)
│ ├── Dockerfile.kali # Contenedor Kali Linux con herramientas
│ └── justfile # Task runner de pentest
│
├── infra/ # Infraestructura CDK (contenedores)
│ └── stacks/ # Network, Security, Auth, Data, Compute, Edge, Monitoring
│
├── infra-fs/ # Infraestructura CDK (serverless)
│ └── stacks/ # Data, Auth, API, Worker, Scheduler, Security, Frontend
│
├── docs/ # Documentación completa
├── .github/workflows/ # CI/CD (despliegue + escaneo de seguridad)
├── devbox.json # Entorno de desarrollo
├── docker-compose.yml # Servicios locales
└── justfile # Task runner
Lecciones Aprendidas
Construir este proyecto reforzó varias convicciones:
La arquitectura hexagonal no es overhead académico. Es la decisión única que habilitó el despliegue de modo dual, testing limpio y un código base que permanece navegable a medida que crece. La inversión inicial en definir puertos y adaptadores se paga muchas veces.
El escaneo de seguridad debe ser por capas. Ninguna herramienta individual lo detecta todo. La combinación de SAST, SCA, escaneo de secretos, escaneo de IaC y DAST proporciona una genuina defensa en profundidad. La clave es hacer estos escaneos rápidos y automáticos — si ralentizan al desarrollador, serán evitados.
Los IDs de correlación son innegociables. La capacidad de rastrear una sola solicitud desde CloudFront a través de la API, hacia Kinesis, a través del Worker y hasta la base de datos es invaluable para debugging, respuesta a incidentes y análisis forense de seguridad. Impleméntalos desde el día uno.
La gestión de costos es una funcionalidad. El patrón aws-up / aws-down para escalar recursos a cero cuando no están en uso es simple pero efectivo. Para un proyecto como este, es la diferencia entre una factura de $200/mes y una de $5/mes durante el desarrollo.
Los agentes de IA necesitan guardrails. La integración con Strands Agents es poderosa, pero sin filtrado de contenido, detección de prompt injection y validación de salida, es un riesgo. El agente solo puede ejecutar operaciones pre-aprobadas a través de interfaces de herramientas bien definidas — nunca llamadas directas a APIs. El mismo principio aplica al Agente de Testing de Seguridad: opera dentro de una lista blanca estricta de tests y acceso de solo lectura a AWS, demostrando que la automatización impulsada por IA y los límites de seguridad pueden coexistir.
Conclusión
Este proyecto es un laboratorio viviente. No está terminado, y probablemente nunca lo estará — porque el panorama de amenazas, herramientas y mejores prácticas está siempre evolucionando. Pero cumple su propósito: una referencia concreta y open source de cómo construir aplicaciones cloud-native modernas con seguridad tejida en cada capa.
Si estás comenzando un nuevo proyecto y te preguntas por dónde empezar con DevSecOps, mi consejo es simple: comienza por la arquitectura. Implementa bien la arquitectura hexagonal, define tus puertos y adaptadores, y el resto — seguridad, testing, flexibilidad de despliegue — se vuelve dramáticamente más fácil.
El código es open source. Haz fork, rómpelo, mejóralo. Para eso está.
Enlaces
- Repositorio: https://github.com/Walsen/devsecops-poc
- Referencia de Arquitectura Hexagonal: docs/hexagonal-architecture.md
- Documentación de Seguridad: docs/security.md
- Trazabilidad Golden Thread: docs/golden-thread-tracing.md
- Guía de Despliegue de Modo Dual: docs/dual-mode-deployment.md
- Guía de Penetration Testing: docs/penetration-testing.md
- Agente de Testing de Seguridad: docs/security-testing-agent.md
- Penetration Testing Automatizado: docs/automated-penetration-testing.md
- Guía de Testing: docs/testing.md
- Documentación de Agentes IA: docs/ai-agents.md
Publicaciones recomendadas al azar
Keyboard Shortcuts
| Command | Function |
|---|---|
| ? (Shift+/) | Bring up this help modal |
| g+h | Go to Home |
| g+p | Go to Posts |
| g+e | Open Editor page on GitHub in a new tab |
| g+s | Open Source page on GitHub in a new tab |
| r | Reload page |