Hulumi is an open-source toolkit that ships secure-by-default cloud and platform infrastructure components for Pulumi. Prior to version 1.4.0, there is a bypass via decoy sibling resources targeting a different bucket. This issue has been patched in version 1.4.0.

Affected: npm: @hulumi/policies

**Affected:** `@hulumi/policies` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** High — **CWE-284 (Improper Access Control)**

#### Summary

HULUMI-H1 forbids raw `aws:s3:Bucket` outside of Hulumi's `SecureBucket` component, with one exemption: a raw bucket that's a child of a `SecureBucket` is allowed because the component is responsible for the hardening. HULUMI-H5 is the defence-in-depth check that closes the H1 exemption — for any raw bucket claiming it, H5 verifies the five hardening sibling resources a real `SecureBucket` always emits (public-access block, SSE-KMS, ownership controls, versioning, TLS-only bucket policy) are actually present.

The bug: H5 only checked the siblings' _types_. It never verified that those siblings actually applied to the bucket being exempted. A consumer (or compromised PR) could pair an unhardened raw bucket with five hardening sibling resources whose `bucket` property pointed at a _completely different_ bucket, and H5 would report no violation while the actual bucket shipped with zero hardened defaults.

#### Impact

Consumers using `HulumiHardeningPack` could ship a raw S3 bucket with no public-access block, no SSE-KMS, no ownership controls, no versioning, and no TLS-only bucket policy — while the policy pack reported the stack as compliant.

#### Patches

Upgrade to `@hulumi/policies@1.4.0`. The H5 sibling check now requires both (a) the sibling to share the same parent `SecureBucket` instance via the anchored URN helper from GHSA-2…