chore(deps): lock file maintenance

[renovate]

This PR contains the following updates:

Update	Change
lockFileMaintenance	All locks refreshed

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

🔧 This Pull Request updates lock files to use the latest dependency versions.

---

Configuration

📅 Schedule: Branch creation - "before 4am on monday" in timezone Europe/London, Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

Open in Overmind ↗

---

model|risks_v6
✨Encryption Key State Risk ✨KMS Key Creation

🔴 Change Signals

Routine 🔴 ▇▅▃▂▁ Multiple compute resources showing unusual configuration changes at 1-2 events/week for the last 2-3 months, which is infrequent compared to typical patterns.
Policies 🔴 ▃▂▁ Multiple S3 buckets are missing server-side encryption and required tags, while security groups allow SSH access from anywhere, which is unusual compared to typical patterns.

View signals ↗

---

🔥 Risks

Replacing the only healthy ALB target will cause a period with zero healthy backends ‼️High Open Risk ↗
The change replaces the only currently healthy instance target behind api-207c90ee-tg by swapping i-08c49ffb6f2242b1e to a new EC2 instance with a new AMI. The ALB still expects HTTP on port 80 with /health, and the target group attachment for that instance is also being replaced, but there is no redundant second healthy target in this target group to carry traffic during the cutover.

When Terraform destroys or deregisters the old instance before the replacement finishes bootstrapping and passing health checks, the ALB will have zero healthy targets and start serving failures until the new instance is registered and healthy. This is a real availability risk caused by replacing a singleton ALB-backed EC2 target without a rolling mechanism or spare capacity, which conflicts with the org’s high-availability guidance (REL10-BP03/REL10-BP01).

Replacing the ALB's only registered backend will cause a temporary zero-healthy-target outage ❗Medium Open Risk ↗
The ALB service behind 540044833068.eu-west-2.elbv2-target-group.api-207c90ee-tg currently has only one healthy backend: 540044833068.eu-west-2.ec2-instance.i-08c49ffb6f2242b1e on port 80. This change replaces that EC2 instance because its AMI changes, and it also replaces the matching aws_lb_target_group_attachment. There is no second target currently registered and no evidence in the plan of additional capacity being added first.

When Terraform replaces the attachment, AWS will deregister the existing target and stop routing new traffic to it while the replacement instance is created, attached, and waits to pass /health checks. During that window the ALB will have zero healthy targets, so requests to api-207c90ee-alb will fail until the new instance finishes coming up and becomes healthy.

---

🧠 Reasoning · ✔ 2 · ✖ 1

EC2 AMI and instance replacement risks: configuration, security, data, and network identity

Observations 9

Hypothesis

Multiple EC2 instance changes introduce configuration, security, and lifecycle risks when replacing AMIs and instances without a validated, hardened baseline or careful migration of settings and data. Replacing the AMI (e.g., from ami-0dd010f28b091c0fd to ami-09ce8939d5ab2791c) can change OS patch level, installed packages, default services, and behaviors such as hibernation and startup provisioning (user_data changed from a plaintext script to a base64 blob/placeholder). This can alter how services run (e.g., httpd installation, /health endpoint creation, network configuration), affect health checks and ELB/ALB routing expectations, and introduce new vulnerabilities, especially when instances already expose SSH to 0.0.0.0/0 via security groups. Instance replacement with DeleteOnTermination=true for the root EBS volume (vol-001472dbbdffc4149) risks deleting application or configuration data if snapshots or alternative persistence mechanisms are not used. Private network identity can also change (e.g., loss of private IPs like 10.0.101.213 or 10.0.101.211 and associated DNS names such as ip-10-0-101-213.eu-west-2.compute.internal), breaking internal name resolution and service discovery if the IPs are ephemeral and not preserved via ENI or explicit assignment. These changes conflict with compute configuration best practices recommending hardened, regularly updated AMIs and safe replacement patterns that preserve necessary data, identity, validated configurations, and expected service behavior (SEC06-BP02).

Investigation

I treated the hypothesis as a concern about service availability and unsafe EC2 replacement, then checked relevant organizational knowledge first. The org standards make two points directly relevant here: EC2 instances must not have public IPs or open SSH from 0.0.0.0/0, and EBS volumes must be encrypted. Current blast-radius state shows those are already non-compliant on the shared internet-access security group (sg-0437857de45b640ce) and both root volumes are currently unencrypted. However, those security/compliance findings are pre-existing and are not being introduced by this change, so they are not by themselves proof that this particular AMI replacement will break anything.

I then compared the planned changes to the current runtime configuration. Both instances are being replaced because the ami changes from ami-0dd010f28b091c0fd to ami-09ce8939d5ab2791c. The API instance i-08c49ffb6f2242b1e is currently healthy behind the ALB target group api-207c90ee-tg, which checks GET /health on port 80, and the target is currently healthy. The diff does not show any change to the ALB target group health check path or port. The user data is redacted to a base64 blob, but the change does not show removal of user data, and there is no concrete evidence in the plan that the bootstrap behavior stops creating /health or stops starting httpd. Because the replacement is caused by the AMI change itself, the many (known after apply) fields for IPs, ENIs, and volume IDs are expected computed values on replacement and are not sufficient evidence of failure.

The stronger, concrete risk is that these replacements are for standalone EC2 instances, not an Auto Scaling Group or another rolling deployment primitive, and one of the affected workloads currently has only a single healthy ALB target. The target group api-207c90ee-tg currently contains just i-08c49ffb6f2242b1e as a healthy instance target, and the attachment resource for that instance is also being replaced in the same plan. During replacement Terraform must deregister/destroy the old instance target before the new instance can become healthy, creating a window with zero healthy targets. That is a closely related mechanism to the hypothesis' service-behavior concern: even if the new AMI boots correctly, this change still creates availability loss because the service has no redundant target during instance replacement. This aligns with the org high-availability guidance against applying changes to all capacity for a service at once and against relying on single-target ELB capacity.

✔ Hypothesis proven

---

ALB/ELBv2 target group and attachment replacement causing availability and routing issues

Observations 13

Hypothesis

Changes to ALB/ELBv2 target groups and target group attachments can cause transient or prolonged unavailability for services behind the load balancer and can alter network exposure or segmentation. Terraform-driven replacement of aws_lb_target_group_attachment resources may briefly deregister EC2 instances, causing the ALB to mark targets unhealthy and stop sending traffic during the replacement window, leading to failed in-flight requests. Replacing target group attachments or the target group itself (e.g., api-health-terraform-example affecting instances such as 10.0.101.106 or 10.0.102.97 and i-08c49ffb6f2242b1e) can change health-check configuration, deregistration behavior, and the set of registered targets or AZ coverage. If the new targets are misconfigured or in different AZs, this can cause transient outages and health check failures. When instance AMIs and user_data are also changed (e.g., httpd install and /health endpoint creation removed or altered), backends can fail ALB health checks, reducing capacity and causing downtime or degraded availability. Broad or mis-scoped security groups on backend instances (e.g., sg-089e5107637083db5 allowing 10.0.0.0/8 ingress on ports 8080, 9090, 443 with all outbound) mean that when target group membership or health-check behavior changes, traffic can reach unintended ports or instances, weakening network segmentation. If not done in a rolling manner with tuned deregistration delays and health checks, these operations can cause app downtime, failed health checks, routing to unintended or insufficient targets, and potential exposure of instances in inappropriate subnets or security groups, violating reliability, availability, and network-segmentation best practices (REL2, REL02-BP03, REL10, REL11, SEC05-BP01, SEC05-BP02, REL2/SEC5).

Investigation

I treated the concern area as service availability behind load balancers, with a secondary concern about weakened network segmentation. I first loaded the relevant organizational knowledge. The reliability guidance says production changes should not deploy to all instances simultaneously and specifically flags single-AZ ELB targeting as a risk (REL10-BP01, REL10-BP03). The security guidance flags broad security-group exposure as a risk, and the compliance file says EC2 instances should not be directly reachable from the internet. The quick reference also notes that some shared security groups have unusually large blast radius, but this specific change does not modify those security-group rules.

I then examined planned changes and current state. The changed EC2 instance 540044833068.eu-west-2.ec2-instance.i-08c49ffb6f2242b1e is the only currently registered target in ALB target group 540044833068.eu-west-2.elbv2-target-group.api-207c90ee-tg; blast radius shows exactly one healthy target health entry for that group, pointing to i-08c49ffb6f2242b1e on port 80. The instance itself is being replaced because the AMI changes from ami-0dd010f28b091c0fd to ami-09ce8939d5ab2791c. In the same plan, the corresponding aws_lb_target_group_attachment is also replaced. Even though the target group diff body is empty, the resource is marked replaced, so there is no evidence of a no-op. AWS documentation confirms that deregistering a target causes the load balancer to stop routing new traffic immediately and places the target into draining; target health can move through deregistration and initial health-check states while the new target registers. That means there will be a period with zero healthy backends if the only registered instance is detached before the replacement instance becomes healthy. I found no autoscaling group, no second ALB target, and no other planned attachment to preserve capacity during the swap.

I also checked whether the hypothesis's more specific mechanism about broken health checks or changed backend behavior is supported. For i-08c49ffb6f2242b1e, the explicit diff does not show a concrete change to the HTTP service or /health endpoint; user_data is redacted rather than visibly removed, so I cannot prove health-check breakage from the data provided. Likewise, the broad internal security group sg-089e5107637083db5 is currently permissive, but it is not being changed here, so that segmentation concern is not caused by this plan. However, the core availability concern is still real through a closely related mechanism: this is a single-target ALB service, and Terraform is replacing both the instance and its target-group attachment. With only one current healthy target, replacement will create a registration gap and temporary loss of service until the new instance passes ALB health checks. That is strong evidence of a real availability risk, with medium severity because it is transient downtime/degraded availability rather than permanent failure or security breach.

✔ Hypothesis proven

---

External SNS alert routing and public EIP association exposing sensitive endpoints and data

Observations 6

Hypothesis

Creating a new SNS email subscription (alerts@example.com) for the production-api-alerts topic exposes production alert content to an external email address. This may violate security and compliance requirements if external recipients are not authorized to receive internal operational or security data. Such subscriptions can leak incident details, infrastructure information, or customer-impacting events outside controlled channels, conflicting with aws-network-security best practices around alert routing and data exposure (SEC05-BP01). Separately, multiple changes to Elastic IP 13.134.236.98 associated with ENI eni-0714cc06176804efa (AllocationId eipalloc-05a1609afb54e84ed) introduce public endpoint exposure and availability risks. Re-associating or releasing the EIP can change the public IP and DNS records for attached instances/ENIs, breaking external connectivity for services that depend on that address. Security groups such as sg-0159f0e3d8224d441 allowing 0.0.0.0/0 ingress on ports 80, 443, 1234 and full egress, or other groups that permit 0.0.0.0/0 SSH/HTTP, significantly increase attack surface when instances are directly reachable via the EIP. Using EC2 instances as direct public endpoints without a managed edge (ALB/CloudFront, WAF, DDoS protections) violates network-security best practices on public endpoints, least-privilege security groups, and recommended use of load balancers for internet exposure (SEC05-BP01, SEC05-BP02, REL02-BP01).

Investigation

I investigated both concern areas from the hypothesis and found that neither is supported by the actual planned change.

First, I loaded the relevant organizational guidance. The security knowledge explicitly says EC2 instances must not be directly reachable from the internet and that public IP plus open security group is critical. The AWS network security guidance also flags direct public EC2 endpoints and broad 0.0.0.0/0 security-group exposure as risks. Current blast-radius data confirms those bad patterns already exist in this environment: the EIP 13.134.236.98 is attached to ENI eni-0714cc06176804efa on instance i-0c326c28fef2cb7ee, and there are separate security groups with broad internet ingress. There is also already an internet-facing ALB for part of the API stack. However, the change under review does not create or widen that exposure. The EIP diff only changes the instance field from a concrete ID to (known after apply), while the AllocationId stays the same and there is no planned delete/recreate of the EIP, no new EIP allocation, no route/DNS change, and no security-group rule change. The associated instance replacement shown in planned changes is i-0ea52e0eb6476a224, but blast-radius data shows the EIP is currently attached to i-0c326c28fef2cb7ee, so the hypothesis tied the EIP risk to the wrong instance/resource path. This looks like ordinary Terraform recomputation during instance replacement, not evidence that the public IP will be released or changed.

Second, the SNS concern is also unproven. The plan does create an aws_sns_topic_subscription with protocol: email and endpoint alerts@example.com on topic production-api-alerts. But the authoritative AWS SNS documentation says email subscriptions remain unconfirmed until the recipient explicitly confirms, and no notifications are delivered until that confirmation occurs. The current SNS topic has SubscriptionsConfirmed: "0" and no existing subscriptions. So this Terraform apply does not by itself exfiltrate alert content to that address; it only creates a pending confirmation request. I did not find any organizational knowledge file that forbids creating pending external email subscriptions outright, only broad network/compliance guidance. Because the hypothesis claims an immediate exposure and connectivity break from this change, and the actual diffs do not show those mechanisms, I conclude the specific concern area is not a confirmed real risk for this change. The environment may already have separate security posture issues, but they are pre-existing and not introduced by this lock-file-maintenance PR.

✖ Hypothesis disproven

---

💥 Blast Radius

Items 92

Edges 260

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Routine score (-5) is below minimum (-1)

---

📊 Signals Summary

Routine 🔴 -5

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

💥 Blast Radius

Items 7 · Edges 23

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Found 2 high risks requiring review

---

📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3

---

🔥 Risks Summary

High 2 · Medium 0 · Low 0

---

💥 Blast Radius

Items 83 · Edges 189

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Found 1 high risk requiring review

---

📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3

---

🔥 Risks Summary

High 1 · Medium 1 · Low 0

---

💥 Blast Radius

Items 92 · Edges 260

---

View full analysis in Overmind ↗