If you discover a security vulnerability in @nanohype/cdk-constructs, please report it privately.

Do not open a public issue.

Email security concerns via the contact details on the GitHub organization profile. Include:

• The construct affected
• A description of the vulnerability (what it exposes, what it lets an attacker do)
• Steps to reproduce, or a minimal synth that demonstrates the issue
• Potential impact (e.g. data exfiltration, escalation, credential leak)
• Whether you've deployed the affected construct to production

We aim to acknowledge reports within 48 hours and provide an initial assessment within 5 business days.

This policy covers the CDK constructs exported by this package. Vulnerabilities in the underlying AWS services, aws-cdk-lib, or the AWS CDK CLI are out of scope — report those to AWS directly.

Constructs in this library encode security-relevant decisions (encryption defaults, IAM scopes, network reachability, removal policies). A vulnerability is a case where those decisions produce insecure AWS infrastructure by default, or where a reasonable reading of the prop surface leads a caller to an insecure configuration.

Examples of in-scope findings:

• A construct provisions a data plane that accepts unauthenticated public traffic when the documented defaults should have made it private.
• A construct grants IAM permissions wider than the documented surface (privilege escalation via a construct's default role).
• A construct's props allow a caller to pass a value that silently disables a security control that the construct claims to enforce.
• Sensitive values (credentials, KMS key material) are emitted as CfnOutput without gating.
• A construct with isProd: true produces output that does not match its documented prod posture (e.g. deletion protection off).

Out of scope:

• Generic CDK best-practice suggestions unrelated to a specific construct defect.
• Issues with downstream consumer stacks that don't use this library's defaults.

Only the latest main and the most recent tagged release receive security fixes. During the 0.1.x foundation phase, the expectation is that consumers track main or the current tag.

We'll coordinate on disclosure timing with the reporter. The default window is 30 days from triage to public advisory, extended as needed for complex fixes or coordinated upstream disclosures.