Setting the file. One moment.
Subchapter 55.27
references/service-recommendations/detection-and-vulnerability.mdMarkdown7 KBView on GitHub
Use the parent skill’s focused-recommendation rules. Load the full workflow only for collection, broad review or cost reduction. own the scoped reads; the matrix owns priorities. Threat detection, vulnerability scanning and aggregated findings answer different questions.
An enabled detector or scanner is only the starting observation. Compare the actual workload with its plan, eligibility and coverage record before recommending another deployment.
| Evidence to compare | Recommendation consequence / false-gap trap |
|---|---|
| Compute type, OS/platform, plan and agent health for the same resource | Split eligibility from rollout failure. EKS Fargate is not the ECS Fargate runtime path; ECS on EC2 follows EC2 agent handling. Do not prescribe an automated ECS setting for it. Runtime Monitoring needs a node to host the agent, so it is unsupported for EKS clusters running only Fargate profiles — recommend EKS audit log monitoring for those, not Runtime Monitoring or a sidecar/add-on. |
| EC2 SSM state and runtime agent-management choice | SSM is a prerequisite for GuardDuty EC2 agent management; a missing SSM registration calls for prerequisite review, not repeated plan enablement. |
| ECS Fargate platform and execution role, task deployment time and coverage error | If platform eligibility or rollout/agent evidence is missing, report recovery as unresolved; the next action is to collect and reconcile the affected tasks’ evidence. Do not prescribe redeployment in the recommendation or handoff. Only after eligibility is established and a rollout gap diagnosed should the reviewed guide’s supported-Fargate-platform and new-task deployment guidance inform recovery; confirm the current minimum supported Fargate platform version from AWS documentation rather than assuming a fixed value. Enabled agent management does not prove old tasks are monitored. |
| EKS member automated-agent configuration and delegated-administrator evidence | Only the delegated admin manages automated EKS agent configuration for members in the reviewed guidance. Separate authority to configure from evidence that member workloads are covered. |
| Coverage error plus shared-VPC owner, resolver/endpoint path or image-pull context | Direct the owner to the implicated registration, network or execution-role dependency. Do not replace a specific failure with an account-wide enablement recommendation. |
| VM Scanner versus legacy SSM plugin, supported OS and custom install paths | Manual VM Scanner installation does not require SSM; CIS still needs the SSM plugin. Deep Inspection enabled does not prove custom software paths are scanned. Recommend path or scanner review only for the demonstrated coverage mismatch. |
| ECR running-image mapping, push/pull windows, lifecycle deletion and build cadence | Prioritize deployed-image coverage over registry count. Reconcile architecture-specific manifests before treating an image total as exposure. A longer rescan window needs retained, relevant images and the current pricing model. |
| Lambda package and code scan status plus runtime eligibility | Assess both separately; one active scan type or a bundled price is not proof of the other type’s coverage. |
For example, healthy new Fargate tasks alongside older uncovered tasks supports a rollout reconciliation recommendation. It does not support reporting the parent detector disabled. The GuardDuty runtime guidance (opens in a new tab) and Inspector coverage guidance (opens in a new tab) retain operational detail.
| Confirmed use and evidence | Eligibility or selection decision |
|---|---|
| Managed or self-hosted AI use, plan/signals, model-cache or package paths | Provisioning lists cannot exclude on-demand use. Separate management-event detection from AI data coverage; compare actual use with supported producers before claiming coverage or absence. |
| Enforced prompt-attack guardrails, applicable organization policies and channel evidence | The reviewed AI guidance conditions prompt-attack detection on enforcement. A configured but unused guardrail does not establish that protection; unresolved enforcement remains UNKNOWN. |
| Untrusted S3 upload buckets and their individual malware configuration/results | Target those buckets rather than the whole estate. S3 Malware Protection can stand alone; FAILED, ACCESS_DENIED or UNSUPPORTED outcomes are not clean scans. |
| Recovery-critical vaults and workload/recovery-point scope | Prioritize relevant backup malware protection using the vault requirement; do not infer every recovery point is covered from plan presence. |
| RDS engine/version and replica context | Resolve eligibility using the current supported-database table (opens in a new tab), ahead of incomplete guide labels. Eligibility and plan enablement still do not prove effective coverage. |
Extended Threat Detection needs no separate enablement in the reviewed material; assess its producer signals rather than inventing a missing correlation switch. Investigation preview remains conditional on current capabilities/regions and the analyst need; compare existing investigation tooling (opens in a new tab) before advising it. Sources: GuardDuty protection plans and investigation (opens in a new tab), Inspector AI/package context (opens in a new tab).
Confirm repositories, languages and release ownership before extending advice beyond deployed EC2/ECR/Lambda scanning. Compare existing SAST/SCA/IaC coverage and build gates with the specific missing stage; a working runtime scanner does not establish repository coverage, and an existing equivalent gate can make another integration redundant.
For CI/CD, use supplied integration and artifact-boundary metadata to compare plugins, InspectorScan or an SBOM-based path. For CIS, match the required benchmark and image-build cadence to target tags, SSM/plugin prerequisites and existing results. A generic vulnerability report cannot establish benchmark conformance. SBOM inventory identifies packages; CVE intelligence and actual runtime applicability still need their own evidence.
For example, an existing dependency gate with no evidenced IaC coverage supports evaluating that missing capability, conditional on current language/integration support. It does not justify replacing the entire pipeline or starting a scan/export. The AppSec/CI owner receives the unmet coverage question and artifact scope. Sources: Inspector CI/CD, Code Security, CIS and SBOM guidance (opens in a new tab).