Notifications
Clear all
Topic starter
18/08/2026 2:59 pm
TL;DR: Runtime security tools that only validate exposures leave the decisive control gap untouched, because detection alone does not stop a live workload from continuing into harmful activity, according to ARMO. In its comparison with Upwind, the practical distinction is enforceable least-privilege policy generated from observed behavior, not just alerts, which makes runtime prevention the real decision point.
NHIMG editorial — based on content published by ARMO: ARMO vs Upwind: Why an Open, Enforcing Runtime Beats a Validation-First Platform
By the numbers:
- 69% of organisations now have more machine identities than human ones.
- Only 38% have automated certificate lifecycle management in place.
Questions worth separating out
Q: How should security teams tell whether a runtime platform really blocks attacks?
A: Ask the vendor to generate a least-privilege policy from a live workload’s observed behaviour and then enforce it in production with rollback available.
Q: When does runtime detection fail to reduce Kubernetes risk?
A: It fails when alerts do not change policy, execution rights, or network reach.
Q: What do organisations get wrong about behavioural security baselines?
A: They often treat baselines as a detection feature instead of a governance model.
Practitioner guidance
- Separate detection from enforcement in your POC criteria Require the vendor to show a workload-specific policy generated from observed runtime behaviour, then prove it can be enforced with rollback enabled.
- Test least-privilege generation against a real Kubernetes workload Use one service with known dependencies and ask the platform to derive seccomp and network controls from its production behaviour.
- Map runtime signals to identity ownership Tie each workload, service account, and agent to a clear owner so generated controls and exceptions have accountable approval paths.
What's in the full article
ARMO's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step observe-to-enforce workflow for generating seccomp and NetworkPolicy controls from live workload behaviour
- Concrete proof-of-concept criteria for deciding whether a platform only validates or truly blocks runtime behaviour
- Details on ARMO's attack-story correlation across cloud, Kubernetes, container, and application layers
- Practical guidance on using runtime policy rollback without breaking production workloads
👉 Read ARMO's comparison of runtime enforcement versus validation-first detection →
Kubernetes runtime enforcement: are your controls actually blocking attacks?
Explore further
18/08/2026 3:39 pm
Detection parity is not the decision point when runtime policy can be enforced. If two platforms see the same workload behaviour, the differentiator is whether that signal becomes a blocking control or remains an investigation aid. That distinction matters most in Kubernetes, where workloads can move quickly and alerts age faster than remediation cycles. For identity programmes, the same principle applies to workload identities and service accounts: visibility without enforceability does not reduce standing risk.
A question worth separating out:
Q: Who should be accountable when runtime policy blocks a workload unexpectedly?
A: Accountability should sit with the owner of the workload or service account, not with the security tool alone. Teams need an approval path for policy promotion, a rollback process, and clear ownership for exceptions. That keeps enforcement from becoming an unmanaged operational surprise.
👉 Read our full editorial: Kubernetes runtime enforcement beats validation-first detection
