El modelo serverless, también llamado FaaS (Function as a Service), se ha consolidado como columna vertebral de muchas arquitecturas en producción. AWS Lambda, Azure Functions y GCP Cloud Functions ejecutan hoy desde APIs públicas hasta pipelines de datos críticos, integraciones de pago y flujos de IA. El equipo escribe la función, el proveedor se ocupa de servidores, sistema operativo y escalado. Esa misma abstracción reordena la superficie de ataque y la metodología de pentest.
Auditar serverless no es replicar un pentest de contenedores ni uno cloud genérico. El atacante deja de pelear contra puertos abiertos y empieza a pelear contra políticas IAM, eventos malformados, layers de dependencias y permisos efectivos entre cuentas. Esta guía cubre por qué serverless exige una aproximación distinta, qué vectores aparecen una y otra vez, qué tooling usar y cómo blindar funciones en AWS, Azure y GCP en 2026.
Lo esencial: en serverless desaparece la superficie de host y aparece la superficie de evento + IAM + dependencia. Si el pentest no cubre validación de eventos, granularidad de roles, supply chain de layers y exposición de URLs de función, el informe deja fuera el 80% del riesgo real.
Por qué serverless requiere pentest distinto
La diferencia frente a contenedores o VMs son tres propiedades estructurales.
La primera son las funciones efímeras. Una Lambda vive el tiempo de procesar un evento, milisegundos a pocos minutos. No hay EDR persistente, no hay log local que sobreviva y no hay forma de entrar a la máquina para investigar después. La telemetría se externaliza en tiempo real o no existe.
La segunda es la naturaleza event-driven. La función no se invoca por una petición HTTP previsible, se dispara por eventos heterogéneos: objeto subido a S3, mensaje en SQS, mutación en DynamoDB Streams, llamada de API Gateway, trigger de Cosmos DB, push de Pub/Sub. Cada fuente trae su esquema y sus pitfalls. Un atacante que controla cualquiera de esas fuentes controla parcialmente el input.
La tercera es que el modelo es IAM heavy. La función necesita un rol de ejecución con permisos sobre el resto del estate. Toda la lógica de privilegios que antes vivía en cuentas de sistema, sudoers y firewalls se ha trasladado a políticas JSON. Un solo wildcard mal puesto convierte una función inocua en vector de toma de cuenta completa.
A eso se suma una observabilidad típicamente más pobre, porque las funciones las escriben equipos de producto y la instrumentación queda como tarea de segundo orden.
OWASP Serverless Top 10
La referencia formal sigue siendo el OWASP Serverless Top 10 publicado en 2017, vigente conceptualmente. Las categorías originales (inyección, autenticación rota, exposición de datos, XXE, control de acceso, mala configuración, XSS, deserialización insegura, componentes vulnerables y logging insuficiente) se reinterpretan: la inyección se vuelve event injection, los componentes vulnerables pasan a ser dependencias y layers, el control de acceso se convierte en IAM mal configurado.
OWASP mantiene también el Serverless Goat, aplicación deliberadamente vulnerable en Lambda útil para entrenar equipos rojos y azules. Complementa con la CSA Serverless Application Security Top 10 y con AWS Well-Architected Serverless Lens y Azure Serverless Security best practices.
Vectores específicos de pentest serverless
Event data injection
El atacante manipula el evento que dispara la función. Si la función procesa el nombre de un objeto S3 sin sanitizar y lo pasa a os.system() o a una query SQL, hay RCE o inyección sin tocar nunca la API. Puntos típicos: nombres de archivo en eventos S3, atributos en mensajes SQS, payloads JSON en API Gateway sin validación de esquema, campos en DynamoDB Streams. Cualquier campo del evento es input no confiable.
Función con rol IAM sobre-privilegiado
Es el fallo más recurrente. La función necesita escribir en una tabla DynamoDB y se le asigna dynamodb:* sobre Resource: *. El día que se compromete, el atacante accede a todas las tablas de la cuenta. Multiplicado por decenas de funciones, el resultado es una red de privilegios laterales que un atacante con un solo punto de entrada recorre hasta admin.
Lambda layers supply chain poisoning
Las layers comparten código entre funciones. Si una layer mantenida por un tercero o una cuenta interna comprometida se actualiza con código malicioso, todas las funciones consumidoras lo heredan en la siguiente invocación en frío. El atacante no necesita tocar tu cuenta, basta con publicar una versión nueva de una layer que tu cuenta importa por ARN público.
Dependencias vulnerables (NPM, PyPI en layers)
Lambda Node.js arrastra módulos NPM, Python arrastra PyPI, .NET arrastra NuGet. CVEs sin parchear se ejecutan dentro del contexto de la función con su rol IAM asociado. La rotación tiende a ser peor que en contenedores porque no hay imagen base reconstruida regularmente.
Cold start side-channels
El cold start es la primera invocación tras inactividad o cambio de versión, e implica provisionar contenedor, cargar runtime, importar dependencias y ejecutar código de inicialización. Investigadores han demostrado side-channels donde el patrón revela información interna o donde un atacante con capacidad de invocar repetidamente infiere cuándo ocurre el aprovisionamiento. No suele ser vector primario pero entra en informes serios cuando se procesan datos sensibles.
Cross-account assume role abuse
Lambda y Cloud Functions asumen roles en otras cuentas mediante sts:AssumeRole o equivalentes. Si la trust policy del rol destino acepta una condición laxa, una función comprometida en cuenta A pivota a cuenta B. Los pivots multi-cuenta son el escenario que más sorprende porque los controles suelen estar pensados por cuenta, no por federación efectiva.
Hardcoded secrets en variables de entorno
Variable de entorno con cadena de conexión, API key o token de Slack. Las env vars de Lambda y Azure Functions son legibles por cualquier identidad con lambda:GetFunctionConfiguration o equivalente, y aparecen en logs cuando una excepción imprime el contexto. El patrón correcto es Secrets Manager, Azure Key Vault o GCP Secret Manager con permisos granulares y caché en memoria.
Resource exhaustion y cost runaway
Una función serverless cobra por invocación y duración. Un atacante que dispara invocaciones masivas, por ejemplo enviando millones de mensajes a la cola consumida, genera una factura de cinco o seis cifras en horas. Es el ataque "denial of wallet". Controles: alarmas de presupuesto, throttling por función, límites de concurrencia y validación de origen en el trigger.
Tooling para pentest serverless
Pacu es el framework de explotación AWS por excelencia con módulos para enumerar Lambda, dump de env vars, descarga de código y detección de roles vulnerables. CloudGoat y Serverless Goat son entornos vulnerables intencionalmente para practicar y validar tooling propio.
Lambda Probe hace reconocimiento contra funciones expuestas vía Function URLs o API Gateway, fingerprinting de runtime y enumeración de timeout y memoria. Snyk y Checkov escanean código fuente y configuración IaC (Terraform, Serverless Framework, SAM, CDK) detectando dependencias vulnerables y permisos excesivos. cloudsplaining analiza políticas IAM. Scripts custom en Python con boto3, azure-identity y google-cloud-functions complementan cuando la lógica del cliente es atípica.
En blue team, Falco con plugins serverless, AWS GuardDuty con detección Lambda y Azure Defender for App Service cubren runtime detection.
AWS Lambda specifics
El pentest de Lambda gira en torno a tres ejes. El primero es el execution role: auditamos política por política con iam:SimulatePrincipalPolicy, identificamos wildcards y permisos excesivos. La práctica recomendada es rol por función con permisos mínimos al recurso concreto.
El segundo es la VPC config. Una Lambda fuera de VPC tiene acceso a Internet por defecto y no llega a recursos privados. Dentro de VPC, llega a recursos privados pero pierde Internet salvo NAT Gateway. En VPC puede ser pivote a bases internas; fuera, puede exfiltrar sin restricción de red.
El tercero es la exposición vía Function URLs. Desde 2022 una Lambda puede tener endpoint HTTPS público sin API Gateway. Muchas aparecen con AuthType: NONE, accesibles sin autenticación. Auditarlas implica enumerar lambda:GetFunctionUrlConfig y validar CORS y autenticación.
Complementariamente revisamos dead letter queues, provisioned concurrency mal usada que mantiene contenedores calientes con secretos en memoria, y CloudWatch Logs con retención y permisos de lectura adecuados.
Azure Functions
Lo primero es el modelo de identidad: managed identity frente a connection strings. La práctica correcta es System-assigned o User-assigned Managed Identity con RBAC granular sobre los recursos consumidos. Lo que aparece en realidad son connection strings con secretos en local.settings.json versionados en Git o en Application Settings sin caducidad.
Lo segundo es el modelo de hosting: Consumption Plan, Premium Plan y App Service Plan. Consumption escala automáticamente y comparte infraestructura con otros tenants. Premium garantiza warm instances y networking VNet. App Service Plan corre sobre instancias dedicadas. Consumption es susceptible a cold start side-channels y a denial of wallet por escalado masivo; App Service Plan hereda toda la superficie de App Service y exige hardening de plantilla.
Aspectos adicionales: function keys (master, function, host) que actúan como secretos de invocación si no se usa Entra ID, integración con Application Insights para telemetría, y Networking con Service Endpoints o Private Endpoints según plan.
GCP Cloud Functions
El primer eje es el service account scoping. Por defecto, una Cloud Function gen1 corre con la service account de App Engine, que tiene rol Editor sobre el proyecto. Todas las funciones comparten un rol con permisos amplísimos salvo configuración explícita. Auditar GCP empieza por listar funciones y verificar que cada una corre con su propia service account scoped al mínimo.
Lo segundo son los IAM bindings. Una Cloud Function puede ser invocada por allUsers (público sin auth), allAuthenticatedUsers (cualquier cuenta Google) o por identidades específicas con roles/cloudfunctions.invoker o roles/run.invoker. El fallo recurrente es desplegar con allUsers en pruebas y olvidar restringirlo.
Lo tercero son las diferencias entre gen1 y gen2. Gen2 corre sobre Cloud Run, hereda su modelo de seguridad, soporta concurrencia mayor a 1, escalado a cero más eficiente y mejor integración con VPC. Gen1 sigue disponible con defaults históricos. Distinguir generación es parte del checklist porque las recomendaciones cambian.
Completan el pentest VPC Service Controls alrededor de servicios sensibles (BigQuery, Cloud Storage), Eventarc para triggers basados en eventos del proyecto y cobertura de Cloud Audit Logs (Admin Activity y Data Access) hacia destino externo.
Hardening serverless
El hardening efectivo descansa en seis bloques que conviene aplicar en conjunto.
Un rol IAM por función. Romper el patrón cómodo del rol compartido. Cada función con su rol, scoped a recurso y acción concretos. AWS IAM Access Analyzer facilita generar políticas mínimas desde el uso real en CloudTrail.
Secretos fuera del código y fuera de variables de entorno. Migración a Secrets Manager, Key Vault o Secret Manager con caché en memoria para no penalizar latencia. Rotación automatizada donde el destino lo soporte.
Escaneo de dependencias. Snyk, Trivy, Grype o Dependabot/Renovate en pipeline. Bloqueo de despliegue si hay CVE crítica sin parchear. Para layers compartidas, versionado estricto y validación previa de toda layer importada de fuera de la cuenta.
Validación de event source. Esquemas JSON con jsonschema o cerberus, validación de tipos, longitudes y campos esperados antes de procesar nada. Tratar el evento como input HTTP no confiable.
Rate limiting y límites de concurrencia. En AWS, reserved concurrency y throttling en API Gateway. En Azure, functionAppScaleLimit. En GCP, max-instances. Con presupuestos y alarmas cuando el coste se desvía de la línea base.
Observabilidad. AWS X-Ray con tracing activo, Application Insights con sampling correcto, Cloud Trace y Cloud Profiler en GCP. Logs estructurados (JSON) a destino centralizado con retención adecuada. Sin trazas el detect and respond es ciego.
Seguridad en CI/CD
El despliegue serverless se hace desde un pipeline. Si el pipeline está mal configurado, no importa lo seguro que sea el código. La regla operativa hoy es OIDC en lugar de claves estáticas.
En GitHub Actions se configura un OIDC provider en AWS (rol federado con condición token.actions.githubusercontent.com:sub que limita a repo y branch concretos), en Azure (federated credentials sobre App Registration) y en GCP (Workload Identity Federation). El pipeline obtiene credenciales temporales por ejecución, sin claves de larga duración en secretos del repo.
En AWS CodePipeline y Azure DevOps, la equivalencia son roles de servicio con scope mínimo. Cualquier AWS_ACCESS_KEY_ID o AZURE_CLIENT_SECRET con caducidad infinita en un pipeline es hallazgo crítico.
Completa el bloque la validación previa: checkov, tfsec, cfn-nag sobre plantilla IaC, escaneo de secretos con gitleaks o trufflehog, firma de artefactos con Cosign y aprobaciones manuales en producción.
Preguntas frecuentes
¿Es serverless más seguro o menos que contenedores?
Ninguno en absoluto. Reduce superficie de host (parches de SO, kernel) que asume el proveedor. Aumenta superficie de configuración (IAM, eventos, dependencias) que asume el cliente. Bien gobernado puede ser más seguro; mal gobernado, más expuesto porque la abstracción esconde decisiones que en un contenedor verías explícitas.
¿La granularidad de roles por función es obligatoria?
En cualquier pentest serio aparece como recomendación de severidad alta cuando se incumple. No es obligatoria por norma legal, lo es por principio de menor privilegio. La diferencia es entre un atacante leyendo una tabla DynamoDB o leyendo las cincuenta tablas de la cuenta.
¿Cold start es un vector de ataque real?
Sí, raramente primario. Aparece en pentests avanzados como side-channel o como vector de denial of wallet. El cold start no es vulnerabilidad en sí. Lo que sí se reporta es cuando el código de inicialización carga secretos en memoria que persisten durante warm executions y quedan expuestos si la función se compromete después.
¿Cómo se previene supply chain en layers?
Tres controles combinados. Primero, política estricta de qué layers se aceptan: solo internas o de proveedores auditados. Segundo, pin de versiones por SHA en lugar de "latest" o ARN sin versión. Tercero, escaneo automatizado de cada layer antes de promoverla. Donde sea viable, mantener layer en cuenta propia con replicación controlada.
¿Cuánto tarda un pentest serverless?
Una aplicación con 10 a 20 funciones se cubre en cinco a siete días laborables. Una organización con cientos de funciones en varias cuentas, triggers diversos y pipelines asociados requiere tres o cuatro semanas. La fase más larga suele ser la revisión IAM cuando los roles han crecido por inercia durante años.
¿El denial of wallet por escalado masivo es un riesgo real?
Es de los más subestimados. Funciones disparadas por colas o eventos sin throttling generan facturas de cinco cifras en pocas horas si un atacante satura la fuente. Controles: alarmas de presupuesto agresivas, límites de concurrencia por función, validación de origen en el trigger y throttling explícito en lugar de escalado infinito donde el negocio lo permita.
Recursos relacionados
- Pentesting cloud (AWS, Azure y GCP): guía técnica para empresas
- Errores típicos de configuración cloud en AWS y Azure
- Pentesting Kubernetes: ataques al cluster y hardening en producción
- Ataques a la cadena de suministro software y DevSecOps
- Qué es Zero Trust: arquitectura e implementación
Auditoría serverless con Secra
En Secra ejecutamos auditorías ofensivas específicas de arquitecturas serverless en AWS Lambda, Azure Functions y GCP Cloud Functions. El alcance cubre revisión exhaustiva de roles IAM y permisos efectivos por función, análisis de event sources y validación de inputs, escaneo de dependencias y layers, revisión de pipelines de CI/CD con foco en OIDC y secretos estáticos, y plan de hardening priorizado integrable con NIS2, ENS e ISO 27001. Cada hallazgo va con cadena de ataque reproducible y severidad justificada por impacto.
Si tu equipo opera funciones serverless en producción y quieres conocer la postura real de seguridad, hablemos y diseñamos el alcance del pentest.
Sobre el autor
Equipo de Secra Solutions
Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.