Problema

Los equipos que gestionan entornos AWS suelen recibir auditorías SOC 2 que exigen configuraciones específicas: MFA obligatorio en usuarios IAM, CloudTrail activo en todas las regiones, buckets S3 sin acceso público, entre otros. En la práctica, esas configuraciones se pierden con cambios de infraestructura, despliegues automáticos o simplemente por desconocimiento. Cuando la auditoría llega, los hallazgos aparecen como “control no cumplido” y el equipo debe reaccionar bajo presión. La raíz del problema es la falta de una verificación continua y enfocada en los controles SOC 2, no un escaneo genérico de seguridad.

Causa

  1. Desconexión entre equipos de desarrollo y compliance – Los pipelines CI/CD crean recursos sin validar requisitos de auditoría.
  2. Herramientas de auditoría demasiado amplias – Soluciones como Prowler cubren cientos de controles, lo que dificulta extraer rápidamente los indicadores SOC 2.
  3. Ausencia de “guardrails” declarativos – Cuando la infraestructura se define en código, a menudo no se incluyen políticas que obliguen a habilitar MFA o CloudTrail.
  4. Credenciales de acceso con permisos excesivos – Permiten crear o modificar recursos sin que exista una revisión posterior, generando configuraciones fuera de línea con los criterios SOC 2.
  5. Falta de registro histórico – Sin exportar resultados a un formato legible (JSON/CSV), es imposible demostrar la evolución del cumplimiento a lo largo del tiempo.

Solución

Utilizar una CLI ligera que ejecute únicamente los controles relevantes para SOC 2 y devuelva un puntaje de preparación. La herramienta debe:

  • Operar en modo read‑only, sin capacidad de modificar recursos.
  • Mapear cada verificación a un control TSC de SOC 2 y ofrecer una descripción en lenguaje natural de la corrección.
  • Permitir exportar resultados a JSON o CSV para archivado.
  • No requerir Docker ni archivos de configuración externos; basta con las credenciales AWS configuradas en el entorno.

El flujo típico es:

  1. Instalar la CLI – clonando el repositorio y ejecutando el script de instalación.
  2. Configurar credenciales – mediante aws configure o variables de entorno (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY).
  3. Ejecutar el escaneo – especificando la región o dejando que la herramienta itere sobre todas.
  4. Revisar el informe – identificar los hallazgos con mayor puntaje de riesgo y aplicar las correcciones recomendadas.
  5. Automatizar – integrar el comando en pipelines de CI para generar un reporte diario o semanal.

Esta estrategia se adapta tanto a entornos pequeños (una cuenta con pocos recursos) como a organizaciones con varias cuentas y roles de auditoría.

Cuándo aplicar esta solución

  • Auditorías SOC 2 inminentes – cuando el equipo necesita una visión rápida de los controles críticos.
  • Equipos DevOps que carecen de políticas de guardrails – la CLI sirve como capa de verificación antes del despliegue.
  • Entornos con limitaciones de conectividad – al no depender de SaaS, la herramienta se ejecuta dentro de la VPC.
  • No es adecuada cuando se requiere un escaneo exhaustivo de vulnerabilidades de red o pruebas de penetración; en esos casos complementa con herramientas especializadas.

Código

# Clonar el repositorio
git clone https://github.com/1amplant/trailscan.git
cd trailscan

# Instalar dependencias (requiere Python 3.9+ y pip)
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

# Ejecutar el escaneo contra todas las regiones
./trailscan --output json > trailscan-report-$(date +%F).json

# Exportar a CSV (opcional)
./trailscan --output csv > trailscan-report-$(date +%F).csv

Verificación

  1. Revisar el código de salida – 0 indica que la CLI terminó sin errores internos; cualquier otro valor sugiere problemas de credenciales o permisos.
  2. Abrir el JSON/CSV – buscar la columna status. Los valores FAIL deben coincidir con los hallazgos que la auditoría SOC 2 marcaría como no cumplidos.
  3. Corroborar una muestra manualmente – por ejemplo, si el reporte indica “S3 bucket public-bucket permite acceso público”, ejecutar aws s3api get-bucket-policy-status --bucket public-bucket y validar que IsPublic sea true.
  4. Comparar puntaje de preparación – el campo readiness_score (0‑100) debe subir después de aplicar las correcciones recomendadas. Un incremento sostenido indica que la solución está funcionando.

Notas adicionales

  • Permisos mínimos – la CLI solo necesita permisos ReadOnlyAccess más iam:GetAccountPasswordPolicy. Evita usar credenciales con privilegios de escritura.
  • Control de versiones – fija la versión del repositorio (por ejemplo, tag v1.2.0) en los pipelines para evitar cambios inesperados.
  • Integración con GitHub Actions – un job sencillo puede ejecutar la CLI y subir el JSON a un bucket de S3 con versionado, creando un historial de cumplimiento.
  • Extensibilidad – si tu organización necesita validar controles adicionales (por ejemplo, Config Rules), puedes añadir módulos Python siguiendo la misma estructura de salida.
  • Limitaciones conocidas – la herramienta no detecta configuraciones de terceros (por ejemplo, recursos creados fuera de la cuenta principal) y no evalúa la configuración de GuardDuty más allá de su activación.

Con este enfoque, los equipos pueden transformar una auditoría SOC 2 de sorpresa a proceso repetible, manteniendo la infraestructura AWS alineada con los requisitos de seguridad sin depender de soluciones SaaS ni de escaneos masivos que generan ruido.