SI-03 Malicious Code Protectionsi-3

The trap in SI-3 is reading GuardDuty Malware Protection as antivirus. It is not a scheduled sweep of your file systems. A GuardDuty-initiated scan fires only after GuardDuty has already produced a finding indicative of malware on that resource, at most once every 24 hours per resource, and it works agentlessly against snapshots of the attached EBS volumes — so an empty describe-malware-scans list is the expected steady state of a healthy estate and proves nothing about coverage. The two enablement reads prove capability; the scan list proves exercise; neither proves protection. Coverage has a second silent hole: the global GuardDutyExcluded:true tag and your own inclusion or exclusion scan-option tags make GuardDuty initiate a scan and then skip it, so read the scan options next to the tag inventory or a deliberately excluded estate looks like a clean one, and Fargate workloads under EKS or ECS are not scanned at all. Malware Protection for S3 is the closest thing here to SI-3's entry-point requirement — it scans each newly uploaded object and each new version in a configured bucket — but it covers only buckets with an active plan, in the same Region as the plan, in your own account (a delegated GuardDuty administrator cannot enable it on a member account's bucket), and when run independently of GuardDuty there is no detector, so malware produces an EventBridge event, a CloudWatch metric and the optional object tag rather than a GuardDuty finding. What no command here produces is the rest of SI-3: signature or engine currency, since AWS operates the scan engines and exposes no version for you to attest to; periodic full scans; false-positive handling; and the documented response when malicious code is found. Rate those from the plan and the incident record, and keep these reads as the machine half of the answer.