TL;DR:
Copy storage of server, mount it on another server, run a vulnerability scan, load results in database, present in a dashboard. Automate process using AWS services and open-source software.
Overview
Vulnerability scanning is a critical component of any cybersecurity program. An organization can identify and remediate security weaknesses in their systems before they can be exploited by malicious actors.
Traditional vulnerability scanning requires the installation and maintenance of software agents on servers. Moreover, supporting infrastructure such as gateways, routing rules and firewall gaps must be introduced to ensure agent traffic reaches the manager.
When thousands of servers spread across multiple cloud accounts are involved, one could see where pain points might arise.
Agentless vulnerability scanning offers an alternative approach by using cloud APIs to copy the storage of the target server and analyze it in a secure environment. This has no impact on the server’s performance, neither does it require any of the above-mentioned infrastructure.
The project
So how do we access the storage of thousands of servers, spread across multiple cloud accounts, and analyze it in a single environment?
We will use a combination of AWS services to orchestrate the scanning process:
- API Gateway to connect our frontend with the backend
- Step Functions to orchestrate the workflow
- Lambda to execute custom logic like creating snapshots, copying them and starting analysis
- Elastic Container Service (ECS) to run the analysis containers
- S3 to instantiate scan locks, similar to Terraform locks
- Database to store scan results
- CloudWatch Logs to retain execution logs
Workflow
1. Initiate
Scans are triggered in two ways:
- Ad-hoc request - user action in the frontend calls API Gateway, which invokes a Lambda function that sends a message to SQS.
- Scheduled execution - EventBridge sends a message directly to SQS on a predefined schedule.
2. Polling & Task dispatch
A Lambda poller continuously consumes messages from SQS and launches the appropriate ECS task based on the payload.
3. Copy storage
A role is assumed into the source account to asynchronously create encrypted snapshots of the target servers’ root EBS volumes, where the operating system is installed.
The snapshots are then shared with the service account, granting permission to access them and create new volumes from the source account snapshots.
4. Create analyzers
While the snapshots are being copied, the required number of analyzers are provisioned. These are EC2 instances responsible for mounting the volumes and hosting the vulnerability-scanning Docker containers.
5. Access data
Once the analyzers are ready and the snapshots are shared, new EBS volumes are created and attached to the analyzers.
After the volumes are created, the original snapshots in the source account are deleted to reduce storage costs.
5. Analyze
With the analyzers provisioned and volumes attached, Docker containers are deployed through ECS on each analyzer to perform the vulnerability scan.
6. Export
A poller monitors the status of the analyzers and, once processing is complete, copies the results to S3.
Each analyzer instance is terminated after the results are exported.
7. Load
Once all analyzers have been terminated, the results are loaded into a database, ready to be queried through a web interface.
Result
A scan extracts the following information for each server:
- operating system version
- installed software
- detected vulnerabilities
- passed / failed / not applicable CIS benchmarks
With the help of Query Builder from Cloud Security Posture Scanning, this data can be queried and correlated across both infrastructure and application layers. This provides the missing context needed to surface risks that can easily be missed.
Example: A public server with an overly permissive IAM role is running React 19.1 which is vulnerable to unauthenticated remote code execution (CVE-2025-55182). Ding ding ding.
The software
Vulnerability scanning
Since we’re only focusing on the pipeline and orchestration, we’ll use existing tools for the vulnerability scanning part.
Wazuh is an open-source security monitoring platform that can perform vulnerability scans (and much more) on endpoints. We create a docker image with Wazuh pre-configured to scan the required volumes. It is important to prevent Wazuh from scanning the host system and only focus on the attached volumes.
Later, this docker image is used as the template for the ECS tasks.
Database
To store the results, we use Neo4j, a graph database, allowing us to create relationships between the vulnerabilities and the servers.
This allows us to query the data in a more natural way and visualize it in a graph format. Additionally, it opens up the possibility of running graph queries to identify patterns or risks.
Hold up…
If you can automatically scan thousands of servers without the grunt work, why isn’t the whole world doing it?
There’s always a catch… In the linux world it’s called a pseudo file system (also known as /proc).
When you copy a server’s storage, you’re not copying the server’s memory. This means that any running processes, open files, network connections, etc. are not included in the snapshot. Your scans only get visibility into the server’s configuration and installed software, but not into its runtime state.
Engineers caught up on this and raised it as a red flag. This is why big players in agentless such as Wiz have now introduced agents.
News
The elephant enters the room…
On Nov 27, 2023 AWS announced the release of Amazon Inspector Agentless, a service that takes snapshots of servers and analyzes them in the background.