Los scanners nunca fueron el cuello de botella. Encontrar vulnerabilidades hoy es la parte fácil — un agente saca a la luz más problemas explotables en una tarde que los que un equipo puede triagear en una semana. El cuello de botella es todo lo que viene después del hallazgo: validar que es real, priorizarlo, y arreglarlo lo bastante rápido como para sostener un SLA mientras el backlog crece.
Este post trata de cerrar ese loop en AWS de punta a punta: Security Agent de AWS lo encuentra, FaradAI corre su propio pentest autónomo y después prueba, encadena y triagea cada hallazgo, y AWS Systems Manager lo parchea — con los pasos de prevención que evitan que vuelva. Y como AWS Security Agent viene con una prueba gratuita de 2 meses (hasta 400 task-hours/mes), podés correr todo el loop sin gastar un peso (ver la sección Costo más abajo).
1. Dos capas agénticas, y después el fix
El modelo viejo era un scanner tirando una pared de CVEs por encima del cerco. El modelo nuevo es un pipeline de agentes, cada uno haciendo una cosa bien:
AWS Security Agent escanea el entorno de AWS ↓ hallazgos importados mediante el conector aws_security_agent de Faraday FaradAI ejecuta SU PROPIA prueba de penetración autónoma + valida y encadena los hallazgos del Agente de Seguridad ↓ prueba la explotabilidad real con PoCs funcionales Triage de FaradAI: enriquecer, desduplicar, priorizar, etiquetar por SLA — un solo espacio de trabajo ↓ AWS Systems Manager aplica la solución (parche / runbook de automatización) ↓ Prevención: higiene de claves, IMDSv2, IaC — para que no vuelva a ocurrir
¿Por qué dos capas ofensivas en lugar de una? Son complementarias y se validan mutuamente:
| Capa | En lo que es bueno |
|---|---|
| Agente de seguridad de AWS | Visibilidad nativa del entorno de AWS; muestra explotable vulnerabilidades con mucho menos ruido que un escáner tradicional (tipo Inspector/Tenable) |
| FaradAI | Ejecuta su propia prueba de penetración autónoma contra el objetivo and lleva los hallazgos del Agente de Seguridad más allá —encadenándolos, demostrando la explotabilidad con PoCs funcionales— y luego realiza el triaje: enriquecimiento, capturas de pantalla, deduplicación, consolidación y remediación en un solo espacio de trabajo |
El agente de seguridad te dice qué falla en AWS. FaradAI lo ataca él mismo — ejecutando una prueba de penetración autónoma — y te indica qué hallazgos (los suyos propios y los del Agente de Seguridad) un atacante puede realmente usar, convirtiendo cada uno en un elemento priorizado, respaldado por evidencias y apto para ser convertido en un ticket.
2. Conectar la infraestructura de AWS: de la manera correcta
Antes de que se escanee nada, necesita acceso al entorno. La decisión más importante aquí es cómo lo concedes — porque las claves de acceso estáticas de AWS son una de las causas raíz más comunes de incidentes reales.
- Usa un rol de IAM con credenciales temporales, no claves de acceso de larga duración. Asumir roles (assume-role) / federación OIDC para el escáner y para los ejecutores (runners) de FaradAI; sin secretos estáticos almacenados en una configuración.
- Acótalo estrictamente — lectura/enumeración para el análisis, y un rol separado y de alcance limitado para el paso de remediación (más sobre esto a continuación).
- Autorice el ámbito explícitamente. Al escanear dominios, valide la propiedad con un registro DNS para que la actividad esté claramente autorizada, tanto para su propio registro de auditoría como para AWS Trust & Safety cuando hay hosts de terceros involucrados.
3. Obtener los hallazgos del Agente de Seguridad en — el conector
No extraes datos de un panel ni exportas un archivo CSV. Faraday incluye un oficial aws_security_agent un conector (un ejecutor despachador) que se comunica directamente con el servicio de Agente de Seguridad de AWS: el boto3 agente de seguridad cliente — e importa sus resultados como vulnerabilidades de Faraday. Recorre el servicio tal como está estructurada la API (ListAgentSpaces → ListPentests → ListPentestJobsForPentest → BatchGetFindings + ListDiscoveredEndpoints) y mapea cada hallazgo, con su nivelDeRiesgo, en el espacio de trabajo.
De manera crucial, autentica la forma en que la Sección 2 argumentó: el conector utiliza el rol de IAM del despachador por defecto — dejas en blanco los campos de claves de AWS y dejas que el rol del contenedor (o STS AssumeRole) proporcione credenciales de corta duración. No hay claves de acceso estáticas en ninguna parte del ciclo.
Ejecútalo como cualquier agente de Faraday:
faraday-cli agent run \ -a "$DISPATCHER_AGENT_ID" \ -e aws_security_agent \ -w aws-prod- \ -p '{ "AWS_REGION": "us-east-1", "AWS_SECURITY_AGENT_AGENT_SPACE": "as-", "AWS_SECURITY_AGENT_MODE": "findings,endpoints" }'
Salir AWS_SECURITY_AGENT_AGENT_SPACE me voy a barrer cada espacio de agente en la cuenta, o alfiler AWS_SECURITY_AGENT_PENTEST_ID / _JOB_ID para importar una ejecución. Los hallazgos del Agente de Seguridad ahora son vulnerabilidades de Faraday, en un espacio de trabajo, listas para la siguiente capa.
4. Pentest autónomo + triaje con FaradAI
FaradAI funciona como una jaula de Faraday Security Scanner contra los mismos objetivos, en dos ejecuciones — Primero la prueba de penetración, luego la clasificación. Los escáneres de seguridad se activan a través de la API REST con curl (no les impulsa faraday-cli); obtén el id de cada agente de Escáneres de seguridad en la interfaz de usuario o GET /_api/v3/cloud_agents.
Primera ejecución — la prueba de penetración autónoma
Hace dos cosas en una sola pasada: un prueba de penetración autónoma de sí mismo (reconocimiento → ataque → cadena → prueba), and validación de lo que el Agente de Seguridad ya reveló:
curl -sS -X POST "$FARADAY_URL/_api/v3/cloud_agents/$FARADAI_AGENT_ID/run" \
-H "Authorization: Token $FARADAY_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"args": {
"TARGET": "target",
"INSTRUCTION": "Run a full autonomous pentest of the target; also validate and chain the Security Agent findings already in the workspace; prove exploitability with working PoCs",
"MODE": "Dual",
"ROUNDS": 40,
"DRY_RUN": false,
"TIME_LIMIT_SECONDS": 86400
},
"workspaces": ["aws-prod-fecha"]
}' -w "\nHTTP %{http_code}\n"
La llamada es de tipo "disparar y olvidar": regresa inmediatamente (HTTP 200 con un id_comando y el identificador de ejecutor) mientras la prueba de penetración se ejecuta en segundo plano. FaradAI hace sus rondas —con memoria compartida entre pasadas y control humano en el circuito cuando lo deseas— encontrando nuevas rutas de ataque por sí mismo mientras corrobora las del Agente de Seguridad, y enviando cada comprobado buscando en el espacio de trabajo.
Segunda ejecución: clasificar todo el espacio de trabajo
Una llamada separada apunta a los de FaradAI triaje Escáner de seguridad en el mismo workspace, por lo que enriquece, desduplica y prioriza todo junto — los hallazgos del Agente de Seguridad y los resultados de las propias pruebas de penetración de FaradAI:
curl -sS -X POST "$FARADAY_URL/_api/v3/cloud_agents/$FARADAI_TRIAGE_AGENT_ID/run" \
-H "Authorization: Token $FARADAY_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"args": {
"WORKSPACE_NAME": "aws-prod-",
"MODE": "Dual",
"PATCHING_MODE": "dry-run"
},
"workspaces": ["aws-prod-"]
}' -w "\nHTTP %{http_code}\n"
NOMBRE_ESPACIO_DE_TRABAJO es lo que se triajea. El triaje añade evidencia en capturas de pantalla, elimina duplicados en ambas fuentes y clasifica según la explotabilidad validada, convirtiendo una pila de hallazgos en una cola priorizada de comprobado problemas, cada uno con la evidencia que necesita el responsable de la solución. MODO_APLICACION_PARCHES estancias simulación en seco aquí porque en AWS aplicamos la solución real con Systems Manager (sección siguiente); cámbialo a aplicar solo si quieres que FaradAI impulse la corrección por sí mismo.
5. Un espacio de trabajo: junto con los hallazgos de DevSecOps que ya recopila
Los hallazgos del Agente de Seguridad y las pruebas de penetración de FaradAI ahora viven en un solo espacio de trabajo, pero su equipo ya está produciendo más: SAST en el código fuente, SCA en las dependencias, análisis de secretos y de IaC en CI, CSPM en la cuenta. Esos pertenecen a la igual lugar, no en cuatro paneles separados.
faraday-cli lee los formatos que tu pila ya emite, así que impórtalos al mismo espacio de trabajo:
faraday-cli tool report semgrep.sarif -w aws-prod- # SAST faraday-cli tool report trivy.json -w aws-prod- # SCA / containers / IaC faraday-cli tool report gitleaks.json -w aws-prod- # secrets faraday-cli tool report prowler.json -w aws-prod- # AWS posture (CSPM)
Ahora un solo workspace responde la pregunta que ninguna herramienta sola puede: de todo lo que sabemos que está mal —en AWS, el código y las dependencias—, ¿qué demostró realmente un atacante que podía explotar? Prowler señala cien problemas de postura; FaradAI muestra cuál se encadenó a una apropiación de rol de IAM. El SCA enumera cuarenta paquetes vulnerables; la prueba de penetración muestra cuál era accesible y condujo a la ejecución remota de código (RCE). Esa correlación — amplitud de los escáneres, pruebas de FaradAI y del Agente de Seguridad, todo deduplicado y priorizado — es lo que convierte un montón de hallazgos en un programa de seguridad, y es lo que alimenta el siguiente paso de parcheo.
6. Triage → parche con Systems Manager
Este es el paso que realmente mueve la aguja del SLA. El resultado de triaje de FaradAI impulsa AWS Systems Manager, que ya tiene el alcance para cambiar la flota. Dos sabores, adaptados al tipo de hallazgo:
CVE de SO / paquetes → Patch Manager. Para un paquete vulnerable en EC2, ejecute la línea base de parches administrada en las instancias afectadas:
aws ssm send-command \ --document-name "AWS-RunPatchBaseline" \ --parameters "Operation=Install" \ --targets "Key=InstanceIds,Values=i-0abc123,i-0def456"
Errores de configuración → Manuales de ejecución de automatización. Para los hallazgos de clase de exposición que valida FaradAI, active un documento de Automatización de SSM (o una llamada directa a la API) que corrija la condición específica:
# Aplicar IMDSv2 a una instancia que filtró credenciales de rol a través de SSRF aws ec2 modify-instance-metadata-options \ --instance-id i-0abc123 --http-tokens required --http-put-response-hop-limit 1 # Bloquear el acceso público a un bucket expuesto aws s3api put-public-access-block --bucket acme-prod-backups \ --public-access-block-configuration \ BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
El rol de remediación permanece separado y con un alcance mínimo, de modo que lo que encuentra el problema nunca es la cosa que puede cambiar producción. FaradAI propone la solución y la evidencia; la acción de SSM la aplica contra los recursos exactos nombrados en el hallazgo; un nuevo análisis confirma que está cerrado. Esa es la parte automatizada de la aplicación de parches que mantiene los SLA intactos a medida que aumenta el volumen.
Automatizar con una barrera de protección. Aplica automáticamente las correcciones seguras y bien conocidas (líneas base de parches, bloques de acceso público, IMDSv2); supedita las más riesgosas a la aprobación humana. El objetivo no es eliminar a las personas, sino evitar que sean el cuello de botella para el 80% obvio.
7. Prevenir, no solo curar
Parchar la instancia es la solución. La prevención es lo que evita que el mismo hallazgo vuelva a aparecer en el próximo despliegue:
- Elimina las claves de acceso estáticas. Rota lo que existe, cámbiate a credenciales temporales y roles. Esta es la prevención de mayor impacto en AWS, punto.
- Hacer cumplir IMDSv2 en el momento del lanzamiento (en la plantilla de lanzamiento / AMI), no solo de forma reactiva por instancia.
- Implementa la corrección en IaC. Para cualquier cosa que provenga de Terraform o CloudFormation, implementa la corrección como una solicitud de extracción (pull request) para que el estado corregido sea el predeterminado la próxima vez — la cura se convierte en prevención.
8. Coste — y cómo ejecutar todo el ciclo gratis
Puedes probar todo este flujo de trabajo en coste cero, porque AWS Security Agent (prueba de penetración bajo demanda) incluye un Prueba gratuita de 2 meses para nuevos clientes:
- Hasta 400 horas de trabajo de pruebas de penetración al mes, gratis, por primera 2 meses.
- Revisiones de diseño (hasta 200 al mes) y revisiones de código (hasta 1.000/mes) en sin costo adicional.
- Después de la prueba, o una vez que superes el límite, es $50 USD por hora de tarea.
400 horas-tarea al mes es un margen considerable: más que suficiente para montar el laboratorio vulnerable de abajo, ejecutar Security Agent + Pentest autónomo de FaradAI + triaje + Systems Manager de extremo a extremo, y afina el bucle antes de gastar nada. Las propias pruebas de penetración y triaje de FaradAI se ejecutan en tu instancia de Faraday (Personal), por lo que la prueba de AWS cubre el análisis del lado de la nube mientras validas todo el flujo de trabajo.
(Precios según AWS al momento de la publicación; confirme las cifras actuales en el Página de precios de AWS Security Agent antes de planificar en torno a eso.
Probá FaradAI
Todo esto —el pentest autónomo, la validación de explotabilidad y el triage— es FaradAI, corriendo dentro de Faraday. En vez de armar el flujo a mano, dejá que un agente ofensivo autónomo pentestee cada target y te deje los hallazgos priorizados en un solo lugar.
👉 Conocé a FaradAI: faradaysec.com/faradai
Un lugar para configurarlo todo: FaradAI
Configuras FaradAI una vez, en Faraday Personal, y todo lo anterior solo apunta a ello:
- Crea tu inquilino en scan.faradaysec.com.
- Su instancia vive en scan.apps.faradaysec.com.
- En Security Scanner, el FaradAI Autonomous Pentest es donde configuras los objetivos, el alcance, las rondas y el workspace destino, y luego lo inicias manualmente desde la interfaz de usuario o automáticamente desde la integración continua (CI)
- Para acceder al panel de FaradAI (https://faradai-scan.apps.faradaysec.com/_ai/), debe hacer clic en FaradAI desde la interfaz de usuario. No se admite el acceso directo a la URL.
Dale a tu pentester con IA un lugar para sus hallazgos — Faraday Community · Faraday Personal →
