Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Affected: @hulumi/baseline < 1.4.0 — Fixed in: 1.4.0 — Severity: Medium — CWE-693 (Protection Mechanism Failure) Summary AccountFoundation can either create AWS detective services (GuardDuty for threat detection, Security Hub for compliance dashboards) or reuse pre-existing ones via opt-in flags. The reuse paths just imported the existing resources and reported success — they never checked whether the existing services were actually doing their job. 1. GuardDuty reuse. If the existing detector was suspended, or set to the slower 6-hour publishing cadence instead of the baseline 15-minute one, or otherwise misconfigured — Hulumi never noticed. The deployment succeeded with a misleadingly-positive guardDutyDetectorId output as if the baseline were active. 2. Security Hub reuse. Although the account import was read-only, Hulumi unconditionally created the CIS / NIST StandardsSubscription resources with default delete behaviour. Pulumi then treated those subscriptions as its own — a…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected: @hulumi/baseline < 1.4.0 — Fixed in: 1.4.0 — Severity: High — CWE-1059 (Insufficient Technical Documentation / Behavioral Inconsistency) Summary The S3 bucket that AccountFoundation creates to receive CloudTrail and AWS Config audit logs is meant to be tamper-resistant — if someone with delete access can erase from it, the forensic trail is gone. There were three independent ways the protection could be silently weakened: 1. No Write-Once-Read-Many on the startup-hardened audit bucket. The startup-hardened tier hard-coded objectLock: false on the audit bucket. (The reason was real — bucket-wide Object Lock blocks an AWS Config write-then-delete probe — but the fix was a sledgehammer that disabled WORM for all objects, not just the probe key.) 2. forceDestroy was forwarded to the audit bucket. Nothing prevented a downstream stack from setting logBucketForceDestroy: true, which made pulumi destroy purge every audit-log object on teardown. 3. Sandbox tier dropped everything.…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact: @hulumi/baseline versions before 1.3.2 could miss some CloudTrail event-selector tampering evidence, reducing coverage for changes to audit logging configuration. Patched in 1.3.2: detection coverage and regression tests were expanded. Remediation: upgrade @hulumi/baseline to 1.3.2 or later and rerun affected previews/checks.
Recommended action: Upgrade to 1.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.