01
The runtime rule declares the context it cares about
Namespace criticality, cluster environment, service-account reach, network-policy posture, and whether the image is running in production at all.
Contextual severity · container threatsA shell in a sandbox pod
A shell in a sandbox pod
is not a shell in production.
Runtime container detections carry one severity, so the same signal reads identically in a throwaway CI namespace and in a production pod whose service account can reach your data plane. Cloudanix scores the detection against the workload's actual reach — namespace, service account, network policy and cluster environment.
- Scored per workload, not per rule
- Service-account reach as a factor
- Kubernetes context from the same graph
cloudanix · container · effective severity
runtime ruleInteractive Shell Spawned In Running Containerbase: High
ns/payments · pod/api-7f4c
- production namespace↑
- SA reaches data plane↑
- no egress restriction↑
effective severityCriticalHigh → Critical · escalated
ns/ci-ephemeral · pod/build-2a1
- ephemeral CI namespace↓
- SA has no cluster reach↓
- network policy enforced↓
effective severityLowHigh → Low · contained workload
Same detection, same cluster. What differs is what the pod could do next.
The problem
Container runtime detection produces the highest-volume, lowest-context queue you own.
Clusters are busy and short-lived by design. A detection stream that cannot tell a build pod from a payments pod will bury the one signal that mattered.
01
Ephemeral workloads generate real volume
CI namespaces spin up, do something that looks unusual, and disappear. Treating those firings with production weight is how a team learns to ignore the whole detection class.
02
Namespace is context nobody joins
Everyone knows which namespaces matter. That knowledge usually lives in a platform team's head or a Helm value, not in the severity of the alert that just fired.
03
The real risk is the service account
What makes container compromise dangerous is what the pod's identity can reach outside the cluster. That is an entitlement question, resolved in the graph — not something a runtime sensor sees on its own.
How it works
How a container detection gets its severity.
The same model, resolved against the workload. The distinguishing inputs are Kubernetes-native, and they compound: a permissive service account plus unrestricted egress is materially worse than either alone.
02
Cluster context resolves from the graph
Workloads, namespaces, service accounts and their bindings are already modelled as assets and edges, so the factors read the same graph the rest of the platform uses.
03
Identity reach folds in
The pod's service account is walked outward the way any other principal is — cluster role bindings, and the cloud identity it federates to. Compromise of the pod is compromise of that identity.
04
Detections and thresholds agree
The detection list, the cluster summary views and the alert threshold read the same effective severity, so a page on Critical stays meaningful when the CI namespace gets noisy.
The factors
The context a container detection is weighed against.
Kubernetes-native context plus the identity reach Cloudanix already computes — so a detection in an ephemeral build namespace stops competing with one in your payments namespace.
Namespace criticality
Whether the workload runs in a namespace that matters — production application namespaces versus ephemeral build or preview namespaces.
Cluster environment
Production versus non-production clusters. The coarsest useful signal, and often the one that resolves most of the volume.
Service-account reach
How far the pod's identity can get — cluster-wide bindings and the cloud role it federates to. The factor that turns a curiosity into an incident.
Network containment
Whether egress and lateral traffic are actually restricted for this workload. Containment genuinely reduces consequence, so it should reduce severity.
Ingress exposure
Whether the workload is served to the internet through an ingress or load balancer, resolved through the graph rather than read off an annotation.
Image vulnerability state
Whether the running image carries a vulnerability under active exploitation — a runtime signal on an already-vulnerable image compounds.
Why Cloudanix
What changes when container detections know the workload.
Ephemeral noise stops competing
CI and preview namespaces are the dominant source of low-consequence firings. Discounting them by policy — rather than muting the rule — keeps the detection useful where it matters.
Containment is rewarded
Enforcing a network policy or tightening a service account should visibly lower the severity of future detections on that workload. Platform work that reduces blast radius shows up in the number.
Cluster and cloud in one model
A pod's risk does not stop at the cluster boundary. Because the service account's cloud reach is in the same graph, the severity can account for it.
What Our Users Are Saying
Customer Reviews
Cloudanix is trusted by security leaders worldwide to deliver proactive, reliable, and cutting-edge cloud security.
One day, I changed the password of a root account, and my CTO called me within less than a minute to confirm if I did so. I was not expecting a reaction this quick. He told me Cloudanix alerted him of this password change and that he wanted to confirm as it was a critical security notification. I couldn't believe it!
Ritesh Agarwal
CEO, Airgap Networks
Compliance is one way of staying secure, but what I want is the ability to go deeper and attain 'true security.' Cloudanix provides us the capability to do so.
Vishal Madan
Head of Engineering, iMocha
Cloudanix is building for the future of the cloud, which makes the product all the more desirable.
Ritesh Agarwal
CEO, Airgap Networks
Cloudanix gave us the visibility we were missing. Being able to move from permanent access to a robust Just-In-Time (JIT) workflow has fundamentally changed our security posture without slowing down our engineering velocity.
Pavan Kumar Lekkala
SRE Lead, HugoHub
We are excited to leverage Cloudanix's comprehensive multi-cloud DevSecOps solution to secure our production workloads on AWS. Cloudanix has demonstrated that it can solve many challenges that DevSecOps teams face while continually adding new features such as SOC2 compliance and drift detection.
Satish Mohan
Co-founder & CTO, Airgap Networks
Managing third-party partner access was once a major concern for our security posture. With Cloudanix JIT Cloud, we've effectively achieved zero third-party risk. We can now grant access confidently, knowing that it is temporary, audited, and automatically revoked, resulting in a 100% reduction in our privileged access exposure.
Okesh Badhiye
Head of Technical Engineering, Finfinity
The snooze feature and responsible alerts have helped us save time and prioritize what to tackle first.
Satish Mohan
Co-founder & CTO, Airgap Networks
Implementing Cloudanix JIT internally allowed us to practice what we preach. By eliminating permanent access to our own clouds and databases, we've neutralized the risk of standing privileges, ensuring our own 'keys to the kingdom' are never left exposed.
Girish Manghnani
Managing Partner, Tech Inspira
The problem with permissions is a lot of times, the gaps are left open due to oversights from inside the organization itself. With Cloudanix's CIEM, we get a complete view of user permissions and access. This enables us to update the permissions, reducing the attack surface.
Nilesh Pethani
Application Architect, iMocha
In the world of Fintech, trust is our currency. Cloudanix provided the frictionless visibility we needed to secure our EKS workloads across AWS, ensuring we stay audit-ready for SOC2 and GDPR without slowing down our engineering velocity.
Amol Naik
Head of Security & Infrastructure, HugoHub
Cloudanix delivered value within 5 minutes of onboarding. Continuous monitoring, timely detection, and excellent documentation helped us attain a great cloud security posture.
Divyanshu Shukla
Senior DevSecOps, Meesho
Technology strategies and business strategies are in a state of constant change which includes centralization and decentralization of responsibilities. Regardless of strategic shift, we still have intellectual property to protect. Cloudanix are critical partners for us in our public cloud security posture across our three cloud providers.
Jerry Locke
Senior Director Global Solutions Engineering, Eversana
Cloudanix has been amazing. They opened up a common Slack channel with us — and it feels like we are talking to our own team and getting things done with Cloud security. The support team is always available, friendly, helpful, and ready to go out of their way.
Satish Mohan
CTO, Airgap Networks
Beyond just access management, Cloudanix CSPM has given us a unified view of our AWS environment. The real-time alerting and anomaly detection allow us to prevent any untoward activity before it happens, which is critical for a marketplace connecting 50+ financial institutions.
Okesh Badhiye
Head of Technical Engineering, Finfinity
For a Fintech company, data is our most valuable — and most sensitive — asset. Cloudanix DAM hasn't just improved our visibility; it has given us control. The ability to mask data and prevent unauthorized queries in real-time is a game-changer for our compliance and customer trust.
Jiten Gala
President Engineering and Product, Kapittx
Our clients, especially in the Middle East financial sector, demand absolute accountability. Cloudanix JIT Cloud has been a competitive differentiator for us, allowing us to provide secure, governed access to customer accounts that meet their strictest audit and compliance requirements.
Girish Manghnani
Managing Partner, Tech Inspira
Cloudanix is always on my team's lips because of its exceptional support. Be it a small or big query, Cloudanix has gone above and beyond to resolve them. This one's a keeper for us.
Sujit Karpe
CTO, iMocha
For a long-lasting partnership, great support goes a long way. Cloudanix has delivered exceptional support whenever required. Their edge is their team is always ready to go beyond to solve any issues that we have. This speaks volumes about the culture at Cloudanix.
Akash Maheshwari
Co-founder, MoveInSync
Beyond the technology, Cloudanix feels like an extension of our own team. Their willingness to stand up a dedicated Middle East tenant for us and provide exceptional support at a sensible price makes them a long-term partner for Hugosave.
Surya Tamada
CTO, HugoHub
The real-time notifications that Cloudanix provides are a real lifesaver. Their adaptive notifications ensure that my team stays productive and doesn't get interrupted all the time.
Digvijay Singh
Staff Security Engineer, Meesho
The whole point in technological evolution is to help improve the world we live in. We must protect that and to do so requires an effective and efficient security strategy. The Cloudanix team helped make our public cloud security posture management strategy a reality. The symbiotic relationship we have allows for a continuous feedback loop which is how business should operate.
Larry Wheat
Staff Solutions Engineer, Eversana
Common questions
Asked plainly.
What is contextual severity for container threats?
It is runtime container detection severity computed from the workload's context — namespace, cluster environment, service-account reach, network containment and exposure — instead of a single value on the rule. The general model is on the overview.
How does this handle ephemeral CI and preview namespaces?
They are the dominant source of low-consequence firings, and they are discounted by policy rather than muted — so the detection stays useful in the namespaces that matter while your build namespaces stop competing for attention. Runtime container detection itself is part of Workload Protection and container security.
How does this relate to Kubernetes security more broadly?
Contextual severity is the ranking layer, not the detection layer. Detection, admission control and posture for Kubernetes are covered under Kubernetes security; this page is about how loudly a given detection should be reported once it fires.
Would a de-escalated container detection still be investigable?
Yes. The detection is recorded, queryable and filterable regardless of severity, and it carries the factors that moved it. Severity governs urgency and paging, never retention or visibility.
Ready to see your graph?
Connect a cloud account in under 30 minutes. See every finding rooted in identity, asset, and blast radius — with a fix path attached.
Book a Demo