Notifications
Clear all
Topic starter
11/06/2026 12:01 am
TL;DR: RCE remains a recurring property of modern software, and Riptides argues that the real security boundary is what happens after execution, when attackers try to reuse ambient trust, internal network access, and discoverable credentials. Process-level workload identity and mutual TLS can collapse blast radius even when the original vulnerability still executes.
NHIMG editorial — based on content published by Riptides: When Remote Code Execution Isn’t the End, Designing for Containment
Questions worth separating out
Q: How should security teams contain remote code execution in workload environments?
A: They should design for compromise, not just prevention.
Q: Why do service-to-service trust assumptions fail after an RCE?
A: They fail because many platforms still treat being inside the environment as proof of legitimacy.
Q: What breaks when internal APIs trust the network instead of the workload?
A: A compromised process can pivot laterally without breaking authentication because the network boundary becomes the de facto identity control.
Practitioner guidance
- Bind internal service access to attested workload identity Require cryptographically verifiable identities for database and API calls so a process must prove who it is before it can authenticate, even when it is running inside the same pod or container.
- Remove location-based trust from service-to-service access Stop using IP address, namespace, or network position as a proxy for trust.
- Treat runtime secrets as breach accelerants Inventory environment variables, mounted secrets, and process arguments as part of the attack surface, because post-RCE reconnaissance usually starts with whatever the process can read locally.
What's in the full article
Riptides's full article covers the operational detail this post intentionally leaves for the source:
- The Support-Assistant demo flow, including how the reverse shell was triggered and how the lateral move was executed.
- The exact process-level identity enforcement model used to stop the malicious shell from authenticating to Postgres.
- The comparison between a compromised shell and the legitimate backend process under mutual TLS enforcement.
- The practical sequence of what changed once workload identity was enforced for internal communication.
👉 Read Riptides's analysis of containment after remote code execution →
Remote code execution containment: are workload identities enough?
Explore further
12/06/2026 6:32 am
Process location is not an identity boundary: This post shows that the real failure after RCE is not code execution itself, but the assumption that anything running inside a workload boundary deserves the same trust as the intended process. That assumption is built into many service-to-service designs that key access off IPs, namespaces, or proximity. Practitioners should treat location-based trust as a broken premise, not a security model.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Should organisations use workload identity, host hardening, or both for RCE containment?
A: They should use both, but for different failure modes. Host hardening limits what the attacker can do locally, while workload identity limits what the attacker can reach east-west. If only one is present, the containment model remains incomplete.
👉 Read our full editorial: Containment after remote code execution depends on workload identity
