# The advisories AWS itself has issued against this account — operational issues, scheduled changes and account notifications, each dated and scoped — together with the subscribers on the topic those alerts are published to and the confirmation state of each subscription, which is the difference between an address that was entered and an address that receives

> FedRAMP Consolidated Rules for 2026 v2026.07.14.01 · updated 2026-07-14
> Canonical page: /collect/security-advisories-receipt-and-dissemination

Recipe id: `security-advisories-receipt-and-dissemination` · cadence continuous · partial

> **Authored opinion.** AWS overlay v3.0.0, written
> against dataset 2026.07.14.01. The upstream
> FedRAMP rules name none of these tools; this mapping is ours.

## What it proves

- KSI `KSI-SCR-MON`
- control `si-5`

## Collection

Kind: `cli`

```sh
# describe-events
aws health describe-events --filter eventTypeCategories=issue,accountNotification,scheduledChange
# list-subscriptions-by-topic
aws sns list-subscriptions-by-topic --topic-arn <SECURITY_ALERT_TOPIC_ARN>
# get-subscription-attributes
aws sns get-subscription-attributes --subscription-arn <SUBSCRIPTION_ARN>
```

## Expected output

From describe-events, events[] with arn, service, eventTypeCode, an eventTypeCategory of issue, accountNotification, scheduledChange or investigation, region, availabilityZone, startTime, endTime, lastUpdatedTime, a statusCode of open, closed or upcoming, and an eventScopeCode of PUBLIC, ACCOUNT_SPECIFIC or NONE — the field that says whether an advisory is a general service event or one raised against this account in particular. The API is served from a global endpoint, global.health.amazonaws.com, which resolves by CNAME to whichever of the us-east-1 (active) and us-east-2 (passive) endpoints is current, and AWS notes that only the active endpoint carries the latest data. From list-subscriptions-by-topic, Subscriptions[] with SubscriptionArn, Owner, Protocol, Endpoint and TopicArn, up to 100 per call with a NextToken beyond that. Read SubscriptionArn carefully: for a subscription that has not been confirmed it is not an ARN at all but the LITERAL STRING PendingConfirmation, which AWS's own published response for an unconfirmed email subscriber shows. That is the discriminator, and it is on this list. From get-subscription-attributes, an Attributes MAP whose values are all strings — including PendingConfirmation, documented as "true if the subscription hasn't been confirmed", and ConfirmationWasAuthenticated, "true if the subscription confirmation request was authenticated" — which is why any clause on them would compare against the string "false" and not a boolean. This call is collected as supplementary evidence — ConfirmationWasAuthenticated is not derivable from the list — and carries no assertion, because it takes --subscription-arn and the unconfirmed case has no ARN to pass it.

## Assertions

- {"field":"list-subscriptions-by-topic.Subscriptions | [0].SubscriptionArn","op":"exists","controls":["si-5"],"description":"The security alert topic has at least one subscriber. A topic with none is an alerting path that terminates in nothing. Says nothing about WHO the subscribers are — that is a comparison against the personnel your policy names, and no call returns that roster — and on its own it does not even prove deliverability, since an unconfirmed subscription satisfies it too. Read it with the clause below, never alone."}
- {"field":"list-subscriptions-by-topic.Subscriptions[?SubscriptionArn=='PendingConfirmation']","op":"count_eq","value":0,"controls":["si-5"],"description":"No subscriber on the alert topic is still unconfirmed. AWS returns the literal string PendingConfirmation in the SubscriptionArn column for a subscription nobody has confirmed, so the failing case is a value in the list rather than an absence — which is why this clause reads the list and not the per-subscription attributes, whose call cannot even be made for an unconfirmed subscriber."}

## GovCloud

Amazon SNS operates in both AWS GovCloud (US) Regions and topic and subscription ARNs use partition arn:aws-us-gov. The AWS Health call is the one to check before this recipe is planned rather than after, and its constraint is commercial as much as GovCloud: AWS states that a Business, Business+, Enterprise On-Ramp, Enterprise or Unified Operations plan is REQUIRED to use the AWS Health API, and that an account not enrolled in one receives a SubscriptionRequiredException. A provider on Basic or Developer support cannot run the first command at all, and for them the advisory-receipt half of this recipe is a Health Dashboard record — which every customer can see — rather than an API result. In GovCloud the endpoint is different in kind, not just in name: AWS documents the Health API there as a single regional endpoint in us-gov-west-1, as opposed to the commercial global endpoint with failover-capable Regions behind it, so the global.health.amazonaws.com DNS-lookup pattern does not apply and us-gov-west-1 is the target. Two further GovCloud behaviours worth writing into the assessment: some Health events are global rather than Regional — IAM's among them — and receiving those requires a rule in AWS GovCloud (US-West), the twin of the CloudTrail Region rule the PS-04 recipe names; and the EventBridge channel there does not deliver public Service Health View events at all, so an alerting pipeline built on EventBridge sees account-specific events only and the API or the RSS feed is what carries the rest.

## Notes

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.

## References

- {"title":"AWS CLI: health describe-events (events[] with eventTypeCategory issue | accountNotification | scheduledChange | investigation, statusCode open | closed | upcoming, eventScopeCode PUBLIC | ACCOUNT_SPECIFIC | NONE)","url":"https://docs.aws.amazon.com/cli/latest/reference/health/describe-events.html"}
- {"title":"AWS Health User Guide: using the AWS Health API — a Business+, Enterprise, Unified Operations, Business, Enterprise On-Ramp or Enterprise Support plan is required or the call returns SubscriptionRequiredException; global endpoint global.health.amazonaws.com with active us-east-1 and passive us-east-2","url":"https://docs.aws.amazon.com/health/latest/ug/health-api.html"}
- {"title":"Amazon SNS API: ListSubscriptionsByTopic (up to 100 subscriptions per call with NextToken; throttled at 30 TPS)","url":"https://docs.aws.amazon.com/sns/latest/api/API_ListSubscriptionsByTopic.html"}
- {"title":"AWS CLI: sns get-subscription-attributes — PendingConfirmation \"true if the subscription hasn't been confirmed\" and ConfirmationWasAuthenticated, returned in an Attributes map of strings","url":"https://docs.aws.amazon.com/cli/latest/reference/sns/get-subscription-attributes.html"}
- {"title":"Amazon SNS Developer Guide: creating a subscription — \"HTTP(S) endpoints, email addresses, and AWS resources in other AWS accounts require confirmation of the subscription before they can receive messages\"","url":"https://docs.aws.amazon.com/sns/latest/dg/sns-create-subscribe-endpoint-to-topic.html"}
- {"title":"AWS SDK code library: ListSubscriptions — the published response for an unconfirmed email subscriber carries SubscriptionArn: 'PendingConfirmation' rather than an ARN","url":"https://docs.aws.amazon.com/code-library/latest/ug/sns_example_sns_ListSubscriptions_section.html"}
- {"title":"AWS GovCloud (US) User Guide: AWS Health — the API is a single regional endpoint in us-gov-west-1 rather than a global endpoint; Business or Enterprise support required; global events including IAM need a rule in GovCloud (US-West); the EventBridge channel does not send public Service Health View events","url":"https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-health.html"}
