Spectra Detect AMI Scanner Security Model
The scanner mounts disk images that may contain malware, and it holds permissions to create and delete block storage. This page describes how those two facts are kept apart, what the scanner can and can't reach, and what leaves your account.
What the Scanner Can't Touch
Three properties hold regardless of how the deployment is configured. All three are enforced by the scanner itself, so a deployment can't open them by leaving something unset.
The asset under scan is never mounted. The scanner works on a copy - a snapshot it took or copied itself - and mounts that. A change to the copy can't reach the original.
An asset must be tagged to be scanned. The scanner only touches assets carrying RLScan=true, as a tag on the asset itself. The key and value are fixed in the scanner: no variable, setting, or environment override changes them or opens the gate. An asset that can't be tagged can't be scanned.
The scanner can't delete what it didn't create. Every resource it creates carries scanner:managed=true, and its permission to delete snapshots and volumes is conditional on that tag being present on the resource. A snapshot you created can't be deleted by the scanner, even by mistake.
Permission Model
Permissions are split across five roles rather than concentrated in one. The split is the security boundary: a compromised scan of an untrusted disk image must not be able to queue more work or launch anything, and a compromised host must not itself hold snapshot or secret access.
| Role | Holds | Used by |
|---|---|---|
| Instance role | Permission to assume the scan role, log writes, and the AWS managed Systems Manager policy. Nothing else. | The scanner instances. |
| Scan role | The scan itself: snapshot and volume operations, report writes to S3, secret retrieval, notification publishing, and queue consumption. | Assumed by the scanner at startup. |
| Dispatcher role | Read-only discovery and permission to place messages on the queue. | The short-lived scheduled-dispatch instance. |
| Scheduler role | Permission to launch the dispatch instance, and to pass only the dispatcher role - never the scan role, so a compromised scheduler can't launch a privileged host. | EventBridge Scheduler. |
| Deploy role | Continuous integration. Created only when you name a principal to trust, and it has no part in a scan. | Continuous integration. |
The only interaction between them is the first: the instance role assumes the scan role, and holds nothing else itself.
A permission granted to the instance role stops applying the moment the scanner assumes the scan role. The call comes back with an access error even though the grant is plainly there. Queue and scan permissions belong on the scan role.
How Destructive Actions Are Scoped
Every destructive action is scoped by tag. The scanner tags everything it creates with scanner:managed=true, and:
ec2:CreateSnapshotandec2:CreateVolumeare permitted only when the request applies that tag, so the scanner can't create an untagged resource it would then be unable to clean up.ec2:DeleteSnapshotandec2:DeleteVolumeare permitted only on resources that already carry it.ec2:AttachVolumeandec2:DetachVolumeare permitted only on volumes carrying it, and only against instances belonging to this deployment.
Two read operations can't be scoped this way. Copying a snapshot, and the source-volume side of taking a snapshot, don't support a request-tag condition, because AWS authorizes them against the source resource - which the scanner neither owns nor can tag. Both are read-only, and what they produce is tagged at creation.
Discovery is read-only and unscoped: the scanner has to be able to describe assets to decide which carry the scan tag.
Preflight Permission Check
The scan role can call iam:SimulatePrincipalPolicy against itself. This is what lets a missing grant surface at startup, with a clear message, rather than mid-scan after a snapshot has already been copied.
Elevated Privileges on the Scanner Host
The scanner runs as root on its instance. That's required to attach a per-scan EBS volume and to run the mount and unmount system calls a scan depends on. This is kernel-level access on the scanner instance, and it's separate from - and much broader than - any AWS permission.
Treat scanner instances as sensitive. They mount filesystems that may contain malware, and they run the mount path as root. Dedicate them to scanning, and don't share them with other workloads.
Reach a scanner instance through AWS Systems Manager Session Manager. The instance role carries the AWS managed policy for it, so a shell needs no inbound access, and the deployment opens no SSH path - its security group has no rule for port 22.
Mount Hardening
Every mount of a scanned filesystem is forced to carry three options, whatever else the mount needed. They can't be configured away, and they're applied in the one place every mount converges on, so an option set added later can't miss them:
| Option | Prevents |
|---|---|
nodev | A device node in the scanned image resolving against the scanner host's devices. The scanner runs privileged, so opening such a node would read raw host memory or disk - and those bytes would then be reported and uploaded as though they were file content from the image. |
nosuid | A setuid binary in the scanned image gaining privilege on the scanner host. |
noexec | Anything in the scanned image being executed on the scanner host. |
The mount options already stop the kernel from honoring device nodes. As a second line of defense, the scanner also skips device nodes, pipes, and sockets without opening them, along with any symbolic link that points to them.
Other Limits on the Privilege
- Nothing from the scanned image is executed. Files are read, hashed, and uploaded.
- Symbolic links that escape the mount root are dropped, not followed. Opening such a link by name would read a file on the scanner host rather than one in the image. These files are counted as skipped and aren't reported, because reporting one would disclose the host path it aimed at.
Data Handling
What Leaves Your Account
The scanner does two things that move data:
- It discovers assets in the account and region it's deployed to, reading their tags to decide which are in scope. Discovery is read-only.
- It submits files to Spectra Detect for analysis - the files selected by the scan mode and filters, uploaded to the endpoint you name in
reversinglabs_api_url. The scanner submits nowhere else.
Everything the scan produces stays in your account: reports in your S3 bucket, notifications on your SNS topic, logs in your CloudWatch log group.
That's where the scanner's reach ends. Once a file reaches Spectra Detect, what happens to it is determined by that deployment's configuration and by the environment it runs in - neither of which the scanner controls or can report on. If you need to be certain no file or file metadata leaves your environment, verify it at the Spectra Detect endpoint and in the network around it, not here.
Use the scan mode and file filters to control what's uploaded. See Configuration.
Transport Security
Transport Layer Security (TLS) verification is on by default. The tls_insecure_skip_verify setting exists for internal deployments with self-signed certificates, and shouldn't be used in production.
tls_insecure_skip_verify applies to every host the scanner contacts, including Worker hosts named by a Hub - not only the configured endpoint.
Token Handling in Hub Deployments
A Hub names the Worker that holds each analysis report, and polling that Worker sends it the API token. The scanner therefore refuses any task host that's neither the configured endpoint's own host nor listed in the allowed task hosts, and refuses a plain HTTP task URL when the endpoint is HTTPS. See Hub Deployments.
Secrets
The API token is stored in AWS Secrets Manager and read by the scanner at startup. It's never a Terraform variable held in state, and never written to the report or the logs.
Report Contents
Reports and notifications describe what was found, and that means they're sensitive:
- A report names paths inside the scanned image, the threat names of anything flagged, and file hashes.
- A notification carries the asset ID and the counts. It doesn't carry file paths.
- The report's
mount_rootfield puts a scanner-host path into every report delivered to S3 and SNS. That's the cost of making a finding's path unambiguous.
Encrypt the results bucket and the notification topic, and restrict read access to them the way you would any other security finding store. Topic encryption isn't optional in this deployment - see Topic Encryption.
Network Placement
- Run the scanner in the same region as the assets it scans.
- Keep the instances in private subnets.
- Use VPC endpoints for EC2, STS, S3, CloudWatch, and KMS where your network policy calls for it.
- The scanner needs outbound access only to the AWS APIs and to your Spectra Detect endpoint.
Audit Trail
Every AWS action the scanner takes is attributable. Enable AWS CloudTrail to record them. Within the scanner's own output:
- Each scan logs a structured
asset scan finishedline carrying the outcome. - A scan that came off the queue carries a trace ID through its logs and into its report, which joins a report back to the request that caused it.
- Reports record which scanner build ran, on which host, in which zone, against which asset.
Build provenance is omitted entirely rather than guessed at. An absent scanner_version means "provenance unknown", and a placeholder is never emitted as though it were a real version.