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 api_server resources showing unusual infrequent routine changes at 1 event/week for the last 2-3 months, which is rare compared to typical patterns.

View signals ↗

---

🔥 Risks

Tip

✔ All risks disproven

We investigated 3 potential risks across 7 resources and verified each was safe. See the investigation details below.

---

🧠 Reasoning · ✔ 0 · ✖ 3

Public SSH exposure on EC2 instance

Observations 1

Hypothesis

EC2 instance i-0464c4413cb0c54aa is reachable over SSH (port 22) from 0.0.0.0/0 via security group sg-0437857de45b640ce. This exposes the instance’s SSH service directly to the internet, increasing the risk of brute-force attacks, credential guessing, and unauthorized administrative access. This contravenes compute hardening best practices that require restricting SSH access to trusted networks or using more controlled access methods (e.g., SSM Session Manager, bastion hosts).

Investigation

Evidence Gathered

I checked the organizational guidance first. aws-compute-configuration explicitly says security groups allowing SSH from 0.0.0.0/0 are a High-severity hardening issue, aws-network-security says unrestricted ingress to SSH is a High-severity network-security issue, and security-compliance-requirements states EC2 instances must not be directly reachable from the internet and that having both a public IP and open SSH is critical severity.

I then queried the current blast-radius state for the EC2 instance 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa, its security group 540044833068.eu-west-2.ec2-security-group.sg-0437857de45b640ce, network interface, subnet, and VPC. The current state confirms the hypothesis about the existing environment: the instance has public IP 18.175.147.19, the attached security group allows inbound TCP 22 from 0.0.0.0/0, and the instance has no IAM instance profile attached. I also checked the planned changes for both EC2 instances in this PR. The only planned diff on i-0464c4413cb0c54aa is that public_ip and public_dns become (known after apply), which is normal Terraform behavior for recomputed public-address fields; there is no change to the security group, subnet, instance profile, or any network rule.

To verify the semantics, I checked AWS documentation. AWS VPC guidance says port 22 should be restricted to specific IP ranges rather than 0.0.0.0/0, AWS Support guidance recommends Session Manager instead of leaving 22 open, and AWS Security Hub includes explicit controls for “EC2 instances should not have a public IPv4 address” and “Security groups should not allow ingress from 0.0.0.0/0 to port 22.” These sources confirm the current setup is insecure, but they do not show that this change introduces or worsens that exposure. (docs.aws.amazon.com)

Impact Assessment

Directly affected by the existing exposure is 1 EC2 instance: i-0464c4413cb0c54aa (api-server). Its current network path is directly internet-reachable because it has a public IPv4 address and a security group permitting TCP 22 from anywhere. Operationally, that means the instance is presently exposed to unsolicited SSH scanning and brute-force attempts.

However, the proposed change itself does not modify the security posture that creates this exposure. No security group rule is added, removed, or widened. No subnet routing or public-IP-association setting is being changed. No new public endpoint is introduced. The only changed attributes are computed public_ip and public_dns values becoming unknown until apply, which indicates Terraform may refresh or reassign the public address but does not itself create a new exposure category. The blast radius is therefore limited to the same already-exposed instance, with no evidence that this lock-file-maintenance PR increases the number of exposed resources from 1 to 2 or expands access beyond what already exists.

Conclusion

I conclude the risk is not real for this change. The instance is indeed currently non-compliant and internet-exposed, but the PR does not introduce, worsen, or even touch the SSH exposure mechanism; it only shows harmless recomputation of public IP/DNS fields during apply.

✖ Hypothesis disproven

---

EBS DeleteOnTermination risk during instance update

Observations 1

Hypothesis

EBS volume vol-0a61278f4602fc12b, attached to EC2 instance i-0464c4413cb0c54aa, is configured with DeleteOnTermination=true. The instance is being updated (status: updated) without a clear diff, which may involve instance replacement or termination. If the instance is terminated as part of this process, the volume will be deleted, risking loss of any data not captured in snapshots or backups. This undermines data protection and durability expectations for any important state stored on that volume.

Investigation

Evidence Gathered

I first checked the relevant organizational guidance in aws-data-protection and aws-compute-configuration because the hypothesis is about possible EBS data loss during an EC2 change. The guidance does make data durability a concern when EBS-backed data could be destroyed, so I treated the DeleteOnTermination=true root volume as important context.

I then inspected the current state of the affected resources with blast-radius-query for 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa, 540044833068.eu-west-2.ec2-volume.vol-0a61278f4602fc12b, and 540044833068.eu-west-2.ec2-volume-status.vol-0a61278f4602fc12b. That confirmed the volume is the instance's root device (/dev/xvda), is attached, and does have DeleteOnTermination: true. It also confirmed the volume was created from snapshot snap-0bb6bd2e6892b2ed1, is only 8 GiB, and is currently healthy. I also examined the planned diffs for both changed EC2 instances in this PR. For i-0464c4413cb0c54aa, the only visible planned change is public_dns and public_ip becoming (known after apply); there is no diff showing instance replacement, termination, block device changes, AMI changes, instance type changes, subnet changes, or any root volume configuration change. The second instance in the same PR shows the same pattern.

To verify what this Terraform pattern means, I checked HashiCorp and AWS documentation. HashiCorp documentation shows that for aws_instance, public_ip and public_dns commonly become (known after apply) during an in-place update as well as during replacement, because those values are provider-computed and may be reassigned at apply time. AWS EC2 documentation also confirms that public IPv4 addressing is not stable in the absence of an Elastic IP and can change when instance networking is reprovisioned or the instance is stopped/started. That means these computed fields alone are not evidence of replacement.

Impact Assessment

The concern area here is potential data loss on 1 EBS volume: 540044833068.eu-west-2.ec2-volume.vol-0a61278f4602fc12b, attached to 1 production EC2 instance: 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa (api-server). If the instance were actually replaced or terminated, the root volume would indeed be deleted because DeleteOnTermination=true, and any state stored only on that root disk would be lost. That would affect the single instance directly.

However, I did not find evidence that this change triggers that outcome. The blast radius shows one directly attached root volume and one ENI, but the planned change does not include any force-new attributes or block device modifications. The scope of the actual planned disruption appears limited to recomputation of public addressing metadata for two standalone EC2 instances, not destruction of storage. There is no evidence in the diffs of a replacement action, no additional planned resource creates/deletes that would indicate instance recreation, and no sign that Terraform is changing the root block device or attachment semantics.

Conclusion

I conclude the risk is not real for this change. The volume's DeleteOnTermination=true setting is real and would matter if the instance were replaced, but the available evidence does not show that this PR is replacing or terminating the instance; it only shows computed public IP/DNS values becoming unknown until apply, which is not sufficient evidence of destructive change.

✖ Hypothesis disproven

---

Simultaneous EC2 public endpoint rotation and IP-based dependency risk

Observations 5

Hypothesis

Two EC2 instances are configured as direct internet-facing endpoints whose public IP and public DNS values are changing in the same apply, with no stable DNS name or load balancer abstraction apparent. Both endpoints losing their existing public identities simultaneously can break any external consumers that reference the old IPs or hostnames, such as partner allowlists, scripts, SSM parameters, or manual admin tooling. Coordinated rotation of both addresses removes endpoint diversity and can cause wholesale failures in automation that contacts both nodes in parallel, hinder manual recovery and troubleshooting workflows that rely on one old endpoint while adjusting the other, and weaken security controls based on static allowlists or firewall rules tied to the prior addresses. This design relies on ephemeral per-instance public endpoints instead of stable, managed front doors, creating reliability and security fragility under patterns like REL02-BP01 (use of IP addresses instead of stable names).

Investigation

Evidence Gathered

I first checked the relevant organizational guidance. The most relevant files were aws-network-security, aws-high-availability, aws-compute-configuration, security-compliance-requirements, and infrastructure-quick-reference. Those standards do confirm that using direct EC2 public endpoints is an anti-pattern and that EC2 instances should ideally not have public IPs at all. However, they describe the standing architecture as fragile in general; they do not establish that this specific change introduces a new breakage.

I then examined the only planned diffs in this apply. For both 540044833068.eu-west-2.ec2-instance.i-09d6479fb9b97d123 and 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa, the only shown changes are public_dns and public_ip becoming (known after apply). There are no diffs for security groups, Route 53 records, Elastic IP associations, load balancers, or any consumer resources that reference these endpoints. The blast-radius query confirms both instances currently have auto-assigned public IPv4 addresses and EC2-generated public DNS names, and confirms they are ordinary EC2 hostnames derived from the public IP. I also verified AWS documentation: AWS states that when an instance without an Elastic IP is stopped and started, it receives a new public IPv4 address, and the public DNS name changes accordingly; private IPs and ENIs persist.

The blast radius additionally revealed an important environmental detail from infrastructure-quick-reference: these scale-test EC2 instances are created for relationship density and are typically not real serving nodes. That weakens the claim that there are real external consumers depending on both public endpoints. I also found a separate security issue on sg-0437857de45b640ce because SSH is open to 0.0.0.0/0 on a public instance, but that is pre-existing and unrelated to the public-IP rotation mechanism raised by this hypothesis.

Impact Assessment

The directly affected resources are 2 EC2 instances: i-09d6479fb9b97d123 and i-0464c4413cb0c54aa. Their current public identities are 35.179.137.86 / ec2-35-179-137-86.eu-west-2.compute.amazonaws.com and 18.175.147.19 / ec2-18-175-147-19.eu-west-2.compute.amazonaws.com. If Terraform performs a stop/start or replacement-like operation that causes public IP reassignment, those two public endpoints will indeed change together.

But the evidence stops there. There are 0 downstream dependency resources in the provided plan showing references to these public IPs or public DNS names, 0 Route 53 records, 0 load balancer resources, and 0 SSM parameters or firewall objects in blast radius proving consumers depend on the old values. The private IPs remain stable, and the only explicit DNS objects in blast radius are AWS-generated records that naturally follow the EC2 addresses. So while the architecture is brittle in principle, I could not substantiate the claimed operational blast radius such as partner allowlist failures, automation failures, or loss of endpoint diversity for actual consumers from the available evidence.

Conclusion

I conclude the risk is not proven for this specific change. The apply may rotate two ephemeral EC2 public endpoints, but there is no concrete evidence in the diffs or blast radius that any real dependent resources or consumers reference those public identities, so the hypothesis remains speculative rather than a confirmed change-specific failure.

✖ Hypothesis disproven

---

💥 Blast Radius

Items 7

Edges 23

[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 ↗