AWS Builder Center

Builder Center

Escanear una AMI sin encender nada: escaneo bajo demanda en Amazon Inspector

Amazon Inspector agregó el escaneo bajo demanda de imágenes de máquina (AMI): un escaneo único de una sola AMI, sin activar el servicio, pensado para revisar una imagen recién construida antes de desplegarla. Este artículo explica cómo funciona desde los snapshots de EBS, las operaciones StartOnDemandScan, GetOnDemandScanStatus y ListOnDemandScans, por qué los resultados llegan solo por EventBridge, un runbook de triaje para el pipeline y las limitaciones.

vtjean

El pipeline construye una AMI dorada un viernes. Pasan las semanas y para fin de mes hay doscientas instancias corriendo a partir de esa imagen. Si durante el build entró un paquete con una vulnerabilidad, cada una de esas instancias la heredó el día que arrancó. El escaneo continuo la va a encontrar, pero la encuentra en la instancia ya corriendo, cuando el problema ya se multiplicó por doscientos.
La pregunta de este artículo es otra: cómo revisar la imagen en sí, en el momento en que se construye, antes de que algo arranque desde ella. Amazon Inspector agregó el 17 de septiembre de 2026 el escaneo bajo demanda de imágenes de máquina (AMI), que permite escanear una sola imagen en un punto en el tiempo y sin activar el servicio. Este artículo explica qué es, en qué se diferencia del escaneo continuo, cómo se piden los resultados y por qué la entrega solo por eventos condiciona todo lo demás. Cierra con un procedimiento de triaje y con las limitaciones que conviene conocer.

Qué es un escaneo bajo demanda

Amazon Inspector es un servicio de gestión de vulnerabilidades que descubre cargas de trabajo y las escanea de forma continua en busca de vulnerabilidades de software y exposición de red no intencionada. En su modo normal, descubre tus recursos y los vuelve a escanear solo cuando algo cambia o cuando se publica una vulnerabilidad nueva que los afecta.
El escaneo bajo demanda es distinto. Es un escaneo único de una sola AMI que pides de forma explícita. No necesitas activar Amazon Inspector en la cuenta para ejecutarlo. El caso de uso que la documentación describe es justo el del pipeline: revisar una imagen recién construida sin meterla en el alcance del escaneo continuo.
La diferencia entre los dos modos no es solo cuándo corren. Cambia dónde empiezan, qué configuración aplican y a dónde van los resultados:
  • Cómo empieza: el escaneo bajo demanda arranca cuando llamas a la operación StartOnDemandScan para una imagen concreta. El continuo arranca solo cuando creas, copias, registras o habilitas una imagen, o cuando sale una vulnerabilidad nueva que la afecta.
  • Activación: el bajo demanda no requiere activar Inspector. El continuo sí, por cuenta.
  • Configuración de escaneo: el bajo demanda ignora las ventanas de elegibilidad, el modo de escaneo y las opciones de exclusión. El continuo las aplica.
  • Reescaneos: el bajo demanda no reescanea. Cada ejecución es una evaluación única y, si quieres repetirla, vuelves a llamar a StartOnDemandScan. El continuo reescanea solo.
  • A dónde van los resultados: el bajo demanda entrega solo por Amazon EventBridge. El continuo entrega en la consola de Inspector, en la API, en EventBridge y en AWS Security Hub CSPM.
Los dos modos son independientes. Aunque tengas activado el escaneo continuo de imágenes, puedes correr un escaneo bajo demanda, incluso de una imagen que tu configuración de escaneo excluye, y Inspector lo factura por separado del escaneo continuo de esa misma imagen.

Cómo funciona por dentro

Cuando llamas a StartOnDemandScan, Inspector devuelve un scanId que identifica el escaneo. A partir de ahí arma un inventario de software desde los snapshots de Amazon Elastic Block Store (Amazon EBS) que respaldan la imagen, evalúa ese inventario contra sus datos de vulnerabilidades y publica los resultados en EventBridge. No lanza una instancia a partir de la imagen para escanearla: lee los snapshots directamente.
La petición es sencilla. Le pasas el identificador de la imagen como resourceId y el tipo como resourceType con valor AMI:
1
2
3
4
{
"resourceId": "ami-0abcdef1234567890",
"resourceType": "AMI"
}
Y recibes el scanId:
1
2
3
{
"scanId": "9f1c4b8d2e6a4f0b7c3d5e1a8b2f6c4d"
}
Guarda ese scanId. Lo necesitas para consultar el estado del escaneo y, además, Inspector lo incluye en cada evento de EventBridge del escaneo, que es lo que permite correlacionar.
También puedes iniciar el escaneo desde la consola de Amazon Elastic Compute Cloud (Amazon EC2). En el panel de AMIs seleccionas la imagen, eliges Actions y luego Scan for vulnerabilities. La consola llama a StartOnDemandScan por ti.
Para seguir el escaneo hay dos operaciones. GetOnDemandScanStatus devuelve el estado a partir del scanId y el identificador de la imagen. ListOnDemandScans devuelve el historial de escaneos bajo demanda de una imagen, con el más reciente primero y paginado. Inspector guarda el registro de un escaneo, con su estado y el manifiesto que recolectó, durante 30 días. Pasados los 30 días, GetOnDemandScanStatus devuelve ResourceNotFoundException para ese scanId y el escaneo deja de aparecer en ListOnDemandScans.

Los estados del escaneo

GetOnDemandScanStatus devuelve un estado y, cuando falla, una razón. Estos valores son propios del escaneo bajo demanda y no son los mismos que Inspector reporta para el escaneo continuo de imágenes:
  • IN_PROGRESS: Inspector empezó y está recolectando el inventario o evaluándolo.
  • SUCCESSFUL: terminó y publicó los hallazgos en EventBridge.
  • FAILED con ACCESS_DENIED: no pudo leer la imagen o sus snapshots, por ejemplo porque una política de recurso o de llave de AWS Key Management Service (AWS KMS) se lo impide.
  • FAILED con UNSUPPORTED_OS: el sistema operativo de la imagen no es compatible, o alguno de los snapshots usa una configuración que Inspector no puede leer, como Logical Volume Manager (LVM).
  • FAILED con AGENTLESS_INSTANCE_STORAGE_LIMIT_EXCEEDED: el tamaño combinado de los snapshots supera el límite admitido.
  • FAILED con AGENTLESS_INSTANCE_COLLECTION_TIME_LIMIT_EXCEEDED: se agotó el tiempo recolectando el inventario.
  • FAILED con RESOURCE_TERMINATED: cancelaste el registro de la imagen o borraste un snapshot que la respalda mientras el escaneo corría.
  • FAILED con INTERNAL_ERROR: un error interno. Vuelves a llamar a StartOnDemandScan para reintentar.
Hay un requisito que vale la pena resaltar porque cambia el flujo en un entorno con varias cuentas: tu cuenta tiene que ser dueña de la imagen y de los snapshots que la respaldan. Si la imagen es de otra cuenta, Inspector devuelve AccessDeniedException. Para escanear una imagen que otra cuenta compartió contigo, primero la copias a tu cuenta y escaneas la copia. Y solo corre un escaneo bajo demanda por imagen a la vez: si ya hay uno en curso, devuelve ConflictException.

La entrega solo por eventos lo cambia todo

El punto que condiciona el diseño es este: Inspector entrega los hallazgos de un escaneo bajo demanda solo a través de EventBridge. No aparecen en la consola de Inspector, no los devuelve la operación ListFindings y no se envían a Security Hub CSPM. Para ver los hallazgos de una imagen en una consola, se usa la de EC2.
Inspector publica dos tipos de evento. Uno por cada vulnerabilidad que detecta, con el campo detail-type en OnDemand AMI Scan Findings. Y uno cuando el escaneo llega a un estado terminal, con detail-type en Inspector2 OnDemand Scan Complete. El evento de fin de escaneo exitoso trae un objeto findingSeverityCounts, y el que falla trae en su lugar un campo scanStatusReason. Todos los eventos llevan el scanId, lo que permite ligar los eventos de hallazgos con el de fin de escaneo del mismo escaneo.
Este es el esqueleto de un evento de fin de escaneo exitoso:
1
2
3
4
5
6
7
8
{
"detail-type": "Inspector2 OnDemand Scan Complete",
"source": "aws.inspector2",
"detail": {
"scanId": "9f1c4b8d2e6a4f0b7c3d5e1a8b2f6c4d",
"resourceId": "ami-0abcdef1234567890"
}
}
Para recibir estos eventos creas una regla de EventBridge en la misma Región y cuenta donde corre el escaneo. Un patrón de evento que capture los dos tipos se ve así:
1
2
3
4
{
"source": ["aws.inspector2"],
"detail-type": ["OnDemand AMI Scan Findings", "Inspector2 OnDemand Scan Complete"]
}
Que los hallazgos no vayan a la consola ni a Security Hub no es un inconveniente que haya que sortear. Es lo que convierte este escaneo en una pieza de pipeline: el resultado llega como un evento que tu automatización consume y sobre el que decide, en lugar de quedar esperando a que alguien lo mire en una consola.

Señal, objetivo y procedimiento

El hilo de esta serie encaja aquí sin forzarlo.
La señal es un hallazgo sobre la imagen recién construida, no sobre una instancia que ya lleva semanas corriendo. Se adelanta al despliegue.
El objetivo lo pone el equipo, porque Inspector no lo fija. Una regla razonable es no promover una AMI a producción si el escaneo bajo demanda devuelve hallazgos por encima de cierta severidad. El evento de fin de escaneo trae findingSeverityCounts, que es justo el dato con el que esa regla decide. Es una propuesta, no un umbral que el servicio imponga.
El procedimiento es la regla de EventBridge que recibe el resultado y actúa. Como no hay consola donde esperar, el procedimiento tiene que existir desde antes del primer escaneo: la regla, el destino que la recibe y la lógica que decide pasan a ser parte del pipeline, no un paso manual posterior.

Procedimiento de triaje

Un flujo que un equipo de CloudOps o de seguridad puede adaptar:
  1. Antes del primer escaneo, crea la regla de EventBridge en la Región y la cuenta donde vas a escanear, y conéctala al destino que va a procesar los resultados, por ejemplo una función de AWS Lambda o un tema de Amazon Simple Notification Service (Amazon SNS).
  2. En el pipeline, después de construir la AMI, llama a StartOnDemandScan con el resourceId de la imagen y resourceType en AMI. Guarda el scanId.
  3. Espera el evento de fin de escaneo con detail-type Inspector2 OnDemand Scan Complete y el mismo scanId. Si el estado es FAILED, lee scanStatusReason y trátalo como un fallo del paso, no como una imagen limpia.
  4. Si el estado es SUCCESSFUL, lee findingSeverityCounts y compáralo con el umbral que definió el equipo.
  5. Si supera el umbral, detén la promoción de la imagen. Los eventos de hallazgos individuales, con detail-type OnDemand AMI Scan Findings y el mismo scanId, traen el detalle para abrir los tickets.
  6. Si necesitas revisar la imagen en una consola, usa la de EC2. Recuerda que los hallazgos no están en la consola de Inspector.
  7. Registra el scanId y la fecha. El registro vive 30 días, así que si necesitas conservar el resultado más tiempo, guárdalo desde el destino de EventBridge cuando llega.

Limitaciones

  • Los hallazgos se entregan solo por EventBridge. No aparecen en la consola de Inspector, no los devuelve ListFindings y no van a Security Hub CSPM. Sin una regla de EventBridge, el escaneo corre pero el resultado no llega a ninguna parte accionable.
  • El registro de un escaneo vive 30 días. Después, GetOnDemandScanStatus devuelve ResourceNotFoundException y el escaneo sale de ListOnDemandScans.
  • Es un escaneo único. No hay reescaneo automático: para volver a evaluar la imagen, llamas otra vez a StartOnDemandScan.
  • Solo corre un escaneo bajo demanda por imagen a la vez. Si hay uno en curso, Inspector devuelve ConflictException.
  • La imagen y sus snapshots tienen que ser de tu cuenta. Una imagen compartida por otra cuenta hay que copiarla primero y escanear la copia.
  • La imagen debe cumplir los mismos requisitos de elegibilidad del escaneo continuo, incluido un sistema operativo compatible y un formato de sistema de archivos que Inspector pueda leer. LVM, por ejemplo, hace fallar el escaneo con UNSUPPORTED_OS.
  • El escaneo bajo demanda no es elegible para la prueba gratuita.
  • Al momento de escribir este artículo, las operaciones StartOnDemandScan, GetOnDemandScanStatus y ListOnDemandScans aparecen en la guía de usuario de Amazon Inspector, pero no en la lista de comandos de la referencia de la AWS Command Line Interface (AWS CLI) para inspector2. Verifica la referencia vigente antes de automatizar con la CLI. Por eso este artículo usa los nombres de las operaciones de API y la consola de EC2, no comandos de la CLI.

Recursos

# cloud-security# devops# security# security-and-compliance
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article