v0.5.0 - ExternalId Propagation for Cross-Account Replication

What's New in v0.5.0

Security Fixes

• ExternalId now propagates through STS AssumeRole — Cross-account replication accepted account_role_arn but silently dropped the External ID, so any destination trust policy requiring sts:ExternalId failed at runtime. DestinationConfig now supports an external_id field (both external_id and externalId are accepted in the destinations config secret), and the handler passes it through to the SecretsManagerClient factory. Reported by Chang Li, Xidian University (25151213672@stu.xidian.edu.cn). A CVE will be requested via GitHub Security Advisory; this section will be updated with the CVE ID once assigned.

Bug Fixes

• Corrected SECURITY.md reporting contact. The previous devopspolis@example.com pointed at the RFC 2606 reserved domain and bounced. New contact: security@devopspolis.com. GitHub Private Vulnerability Reporting is now enabled on the repo and is the preferred channel.

Documentation

• SECURITY.md updated: External ID language softened from "required" to "supported" to match actual code behavior, and the new external_id field is documented.

Tests

• Added 4 unit tests covering the new external_id data path:
  • test_destination_with_external_id
  • test_parses_external_id_snake_case
  • test_parses_external_id_camel_case
  • test_external_id_absent_yields_none

Upgrading

No breaking changes. To enable ExternalId for cross-account replication, add external_id to the destination configuration secret:

[
  {
    "region": "us-west-2",
    "account_role_arn": "arn:aws:iam::999:role/SecretsReplicatorDestRole",
    "external_id": "unique-external-id-of-your-choice"
  }
]

Then require the same value in the destination role's trust policy:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::<source-account>:role/<lambda-role>"},
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {"sts:ExternalId": "unique-external-id-of-your-choice"}
  }
}

---

Full Changelog: v0.4.0...v0.5.0