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 vez de una? Son complementarias — y se chequean entre sí:
| Capa | En lo que es bueno |
|---|---|
| AWS Security Agent | Visibilidad nativa del entorno AWS; saca a la luz vulnerabilidades explotables con mucho menos ruido que un scanner tradicional (tipo Inspector/Tenable) |
| FaradAI | Corre su propio pentest autónomo contra el target y lleva los hallazgos del Security Agent más lejos — encadenándolos, probando explotabilidad con PoCs que funcionan — y después hace el triage: enriquecimiento, screenshots, deduplicación, consolidación en un solo workspace |
El Security Agent te dice qué está mal en AWS. FaradAI lo ataca él mismo — corriendo un pentest autónomo — y te dice cuáles hallazgos (los propios y los del Security Agent) un atacante puede realmente usar, convirtiendo cada uno en un ítem priorizado, con evidencia y ticketeable.
2. Conectá la infra de AWS — de la forma correcta
Antes de escanear nada, hace falta acceso al entorno. La decisión más importante acá es cómo lo das — porque las access keys 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 access keys de larga duración. Assume-role / federación OIDC para el scanner y para los runners de FaradAI; nada de secrets estáticos en un config.
- Alcance acotado — read/enumerate para escanear, y un rol separado y bien acotado para el paso de remediación (más sobre esto abajo).
- Autorizá el scope explícitamente. Al escanear dominios, validá la propiedad con un registro DNS para que la actividad quede claramente autorizada — tanto para tu propio audit trail como para el Trust & Safety de AWS cuando hay hosts de terceros en juego.
3. Traé los hallazgos del Security Agent — el connector
No scrapeás un dashboard ni exportás un CSV. Faraday trae un connector oficial aws_security_agent (un executor de dispatcher) que habla directo con el servicio Security Agent de AWS — el cliente securityagent de boto3 Security Agent de AWS e importa sus resultados como vulnerabilidades de Faraday. Recorre el servicio tal como está la API (ListAgentSpaces → ListPentests → ListPentestJobsForPentest → BatchGetFindings + ListDiscoveredEndpoints) y mapea cada hallazgo, con su riskLevel, al workspace.
Clave: se autentica como argumentaba la Sección 2 — el connector usa el rol de IAM del dispatcher por defecto — dejás los campos de AWS key en blanco y dejás que el rol del contenedor (o STS AssumeRole) provea credenciales de corta duración. Cero access keys estáticas en todo el loop.
Ejecútalo como cualquier connector 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" }'
Dejá AWS_SECURITY_AGENT_AGENT_SPACE afuera para barrer todos los agent spaces de la cuenta, o fijá AWS_SECURITY_AGENT_PENTEST_ID / _JOB_ID para importar una sola corrida. Los hallazgos del Security Agent ya son vulns de Faraday, en un workspace, listos para la próxima capa.
4. Pentest autónomo + triage con FaradAI
FaradAI corre como un Security Scanner de Faraday contra los mismos targets, en dos ejecuciones — Primero el pentest, después el triage. Los Cloud Agents se disparan por la API REST con curl (no se manejan con faraday-cli); sacá el id de cada agente desde Cloud Agents en la UI o con GET /_api/v3/cloud_agents.
Primera ejecución — el pentest autónomo
Hace dos cosas en una sola pasada: un pentest autónomo propio (recon → ataque → encadenar → probar), y la validación de lo que el Security Agent ya sacó a la luz:
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 fire-and-forget: vuelve enseguida (HTTP 200 con un command_id y un id de runner) mientras el pentest corre en segundo plano. FaradAI hace sus rounds — con memoria compartida entre pasadas y con intervención humana cuando la quieras — encontrando caminos de ataque nuevos por su cuenta mientras corrobora los del Security Agent, y empujando cada hallazgo issues probados al workspace.
Segunda ejecución — triage de todo el workspace
Una llamada aparte apunta al FaradAI triage Security Scanner en el mismo workspace,, así enriquece, deduplica y prioriza todo junto — los hallazgos del Security Agent y los del propio pentest 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"
WORKSPACE_NAME es lo que se triagea. El triage suma evidencia con screenshots, deduplica entre ambas fuentes y ordena por explotabilidad validada — convirtiendo una pila de hallazgos en una cola priorizada de issues probados , cada uno con la evidencia que necesita el dueño del fix. PATCHING_MODE queda en dry-run acá porque en AWS el fix real lo aplica Systems Manager (próxima sección); pasalo a apply solo si querés que FaradAI maneje la remediación.
5. Un solo workspace: al lado de los hallazgos de DevSecOps que ya juntás
Los hallazgos del Security Agent y el pentest de FaradAI ya viven en un solo workspace — pero tu equipo ya produce más: SAST sobre el código, SCA sobre dependencias, escaneo de secrets e IaC en CI, CSPM sobre la cuenta. Todo eso va al mismo loop lugar, no a cuatro dashboards separados.
faraday-cli habla los formatos que tu stack ya emite, así que importalos al mismo workspace:
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, en el código y en las dependencias — ¿qué probó un atacante que podía explotar de verdad? Prowler marca cien issues de posture; FaradAI muestra cuál se encadenó hasta un takeover de rol IAM. El SCA lista cuarenta paquetes vulnerables; el pentest muestra cuál era alcanzable y llevó a RCE. Esa correlación — amplitud de los scanners, prueba de FaradAI y el Security Agent, todo deduplicado y priorizado — es lo que convierte una pila de hallazgos en un programa de seguridad, y es lo que alimenta el paso de patching.
6. Triage → patch con Systems Manager
Este es el paso que mueve la aguja del SLA. La salida del triage de FaradAI maneja AWS Systems Manager, que ya tiene el alcance para cambiar toda la flota. Dos variantes, según el tipo de hallazgo:
CVEs de SO / paquetes → Patch Manager. Para un paquete vulnerable en EC2, corré la patch baseline gestionada contra las instancias afectadas:
aws ssm send-command \ --document-name "AWS-RunPatchBaseline" \ --parameters "Operation=Install" \ --targets "Key=InstanceIds,Values=i-0abc123,i-0def456"
Misconfiguraciones → Automation runbooks. Para los hallazgos de clase exposición que FaradAI valida, disparás un documento de SSM Automation (o una llamada directa a la API) que arregla la condición puntual:
# 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 queda separado y con el mínimo alcance, así lo que encuentra el problema nunca es lo que puede cambiar producción. FaradAI propone el fix y la evidencia; la acción de SSM lo aplica contra los recursos exactos nombrados en el hallazgo; un re-scan confirma que quedó cerrado. Esa es la porción automatizada del patching que mantiene los SLAs a medida que el volumen sube.
Automatizá con un guardrail. Auto-aplicá los fixes seguros y bien entendidos (patch baselines, block public access, IMDSv2); dejá los más riesgosos detrás de aprobación humana. La idea no es sacar a las personas — es que dejen de ser el cuello de botella para el 80% obvio.
7. Prevenir, no solo curar
Parchear la instancia es la cura. La prevención es lo que evita que el mismo hallazgo reaparezca en el próximo deploy:
- Matá las access keys estáticas. Rotá lo que exista, pasá a credenciales temporales y roles. Es la prevención de mayor palanca en AWS, sin discusión.
- Forzá IMDSv2 en el launch (en el launch template / AMI), no solo reactivamente por instancia.
- Meté el fix en el IaC. Para todo lo que salió de Terraform o CloudFormation, dejá la remediación como un pull request para que el estado corregido sea el default la próxima vez — la cura se vuelve prevención.
8. Costo — y cómo correr todo el loop gratis
Podés probar todo este workflow a costo cero, porque AWS Security Agent (pentesting on-demand) viene con una prueba gratuita de 2 meses para clientes nuevos::
- Hasta 400 task-hours de pentesting por mesgratis, durante los primeros 2 meses.
- Design reviews (hasta 200 al mes) y code reviews (hasta 1.000/mes) en sin costo adicional.
- Después de la prueba — o al superar el límite — es $50 USD por task-hour..
400 task-hours por mes es muchísimo margen: de sobra para levantar un lab vulnerable, correr Security Agent + el pentest autónomo de FaradAI + triage + Systems Manager de punta a punta, y ajustar el loop antes de gastar nada. El pentest y el triage de FaradAI corren en tu instancia de Faraday (Personal), así que la prueba de AWS cubre el escaneo del lado cloud mientras validás el workflow completo.
(Precios según AWS a la fecha de publicación — confirmá los números actuales en la página de pricing de: AWS Security Agent antes de planificar en base a ellos.)
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 →
