SI-05 Security Alerts, Advisories, and Directivessi-5

SI-05 has four movements: receive security alerts, advisories and directives from external organizations on an ongoing basis; generate internal security alerts; disseminate them to the personnel your policy names; and implement directives or notify the issuing organization of the degree of nonconformance. This output touches the first and the third, and only for one external organization. That organization is AWS. Health events are the vendor's own notifications to this account — operational issues, scheduled changes, account notifications — dated, scoped by eventScopeCode to this account or to the service generally, and enumerable. That is a real answer to 'are you receiving advisories from your suppliers, on an ongoing basis, and can you show it'. The supply-chain indicator is claimed on one limb of its statement and not the whole: KSI-SCR-MON allows for mechanisms that 'may include contractual notification requirements', and a vendor health feed is exactly such a mechanism. It is NOT the other limb — none of Health's four event categories is a vulnerability category, and this evidence monitors AWS's service health rather than the provider's third-party software inventory. Read the claim as the notification limb only. What it is not is the control. CISA emergency directives, US-CERT advisories, vendor bulletins for every other component in the stack, and the entire question of implementing a directive or reporting nonconformance to the issuer are correspondence and decisions. No API returns them, and a collection that presents Health events as SI-05 evidence without saying which limb they serve has answered a quarter of a control. The dissemination half is where the honest telemetry is, and it is smaller than it looks. A topic with subscribers proves an alert has somewhere to go. It does not prove the subscribers are the personnel the policy names — that is a roster comparison — and it does not prove they receive anything unless the subscription is CONFIRMED. AWS requires confirmation for HTTP(S) endpoints, email addresses and cross-account resources. The unconfirmed case is visible, and it is visible in the place you would not look for it. An unconfirmed subscription appears in the topic's subscription list with SubscriptionArn set to the literal string PendingConfirmation instead of an ARN — not a missing field, not a flag, a sentinel value in the identifier column. So the completeness clause below is written against the LIST. An earlier draft asserted the PendingConfirmation attribute from get-subscription-attributes instead, which cannot work: that call takes --subscription-arn, the unconfirmed subscription has no ARN to pass, and the failing case therefore never reaches the assertion at all. The third call stays as supplementary evidence for ConfirmationWasAuthenticated, which the list genuinely does not carry, and it carries no clause. If a clause is ever written on those attributes, note that they come back as a map of STRINGS — PendingConfirmation is "true" or "false", not a boolean, and a comparison against a boolean matches nothing while returning green. One gap the assertions cannot see, named here because a partial rating owes it: nothing collected joins the Health feed to the topic. SECURITY_ALERT_TOPIC_ARN is supplied by the operator, and no output here shows an EventBridge rule on the aws.health source targeting it. The two halves of this recipe are adjacent in the assessment's head and unjoined in the data; collect the EventBridge rule and its targets if that join needs to be evidence rather than assertion. Two emptiness traps. describe-events as written sets no time bound — the filter selects categories, not a window — so what comes back is what AWS Health currently holds, and an empty events[] means the same thing on an account receiving advisories perfectly as on one whose Health access was never wired up. Add startTimes to the filter if the assessment needs the evidence pinned to a period. And the third call must be repeated per subscription: one confirmed subscription proves nothing about the other nine, and the assertion below is written against a single subscription ARN because that is what the API takes — walk the list from the second call and collect one response each, or the evidence covers one address. KSI-SVC-ACM was deliberately not claimed. It asks that configuration be managed by automation and reviewed for drift; an advisory feed and a subscriber list say nothing about configuration, and claiming it would put this recipe on an indicator page as evidence for a question it never asks.