How would you decide whether an S3 public-write exposure is a supply-chain security incident requiring broader notification, versus a contained issue?

The deciding factor is what the bucket's contents are actually used for downstream — specifically, whether anything in the bucket is consumed by other systems or external parties in a way that trusts its integrity (software artifacts, container images, installer packages, configuration files pulled by other services, public documentation embedded elsewhere) — if so, any unauthorized write during the exposure window could mean a malicious actor tampered with something that gets trusted and executed or consumed downstream, which is the defining characteristic of a supply-chain incident, distinct from a plain data-confidentiality exposure.

The core question: was anything in the bucket trusted and consumed downstream?: a supply-chain incident specifically means something a consumer trusted (software, configuration, an artifact) may have been tampered with in a way that then propagates trust in something malicious — if the bucket only held static content nobody else's systems consume or execute, the exposure is confidentiality/availability-focused (data was public or could have been deleted), not supply-chain, even if it was still a serious incident.

Enumerate what actually changed during the window, using whatever reconstruction is possible: the investigation into exactly which objects were added or modified during the exposure window (covered elsewhere) directly feeds this classification — if the changed objects include anything that other systems fetch and use (a package registry artifact, a CI pipeline's downloaded dependency, a container image layer, a public SDK download), that's the specific evidence needed to escalate the classification.

Consider both direct and indirect downstream consumers: direct consumers are systems that explicitly pull from the bucket (an internal deployment pipeline, a customer-facing download link); indirect consumers are less obvious — a public documentation page embedding a link to a file in the bucket, or a customer's own automation that happens to reference the bucket's contents — both need to be considered, since supply-chain risk isn't limited to your own systems' direct usage.

Assume compromise is possible, don't wait for proof of actual tampering: given how difficult full reconstruction can be (especially without versioning or logging, per the object-changes investigation), waiting for definitive proof that a specific downstream-consumed artifact was actually tampered with, versus treating any plausible possibility as requiring the supply-chain response, is the wrong default — the cost of an unnecessary broader notification is much lower than the cost of a real supply-chain compromise going unaddressed because certainty wasn't reached in time.

Notification scope follows from the classification, not the reverse: once classified as a supply-chain incident, the notification scope needs to include whoever consumes the potentially-tampered artifacts (which may mean customers, partners, or in an open-source context, the broader public) — this is a substantively different and broader notification requirement than a contained internal data-exposure issue, which is why getting the classification right (rather than defaulting to the narrower, more comfortable interpretation) matters early in the response.

Involve legal/security leadership early when the classification is ambiguous: cases genuinely on the boundary (a bucket that's mostly internal-only but has one unexpected external consumer) benefit from bringing in people with broader visibility into contractual/regulatory notification obligations, rather than an individual engineer or team making the call in isolation — the consequences of misclassifying in either direction (under- or over-notifying) can be significant.

• The defining question is whether the bucket's contents are trusted and consumed downstream (as software, config, or artifacts) — that's what makes it a supply-chain incident rather than a plain data exposure.
• Reconstruction of what actually changed during the exposure window directly feeds this classification.
• Consider both direct consumers (systems that explicitly pull from the bucket) and indirect ones (embedded links, external automation).
• Default to treating plausible compromise as requiring the broader response rather than waiting for definitive proof, given how hard full reconstruction can be.

• CISA: Software Supply Chain Security Guidance
• AWS: Logging requests using server access logging