Container Security Vulnerabilities Explained: Image, Runtime, Kubernetes, and Supply Chain Attack Vectors

TL;DR

• Container security vulnerabilities span five layers: image, runtime, Kubernetes, supply chain, and the emerging AI/agent layer, not just image scanning.
• A green CI/CD pipeline is not proof of safety; exit-code-zero gates and monitor-only tools create false confidence without real enforcement.
• Image hygiene (minimal non-root images, multi-stage builds, deploy-by-digest) shrinks the attack surface but never stops runtime exploitation.
• Runtime is the real battleground; the 2025 runc CVEs escape to the host, and eBPF kernel-level monitoring catches what scanners miss.
• Prioritize with CVSS plus EPSS plus CISA KEV, not raw CVE count, and map findings to CRA and NIS2 requirement IDs.
• LLM agents are a new insider risk; contain them at runtime, because you can patch a bug but you cannot patch a brain.

Q1: What Are Container Security Vulnerabilities, Really?

A DevSecOps lead I spoke with last quarter had 4,000 open findings on one dashboard and a green pipeline on another. Both were technically correct. Only one told the truth about whether an attacker could move.

Container security vulnerabilities are weaknesses in how containers are built, configured, shipped, and run. They span image, runtime, Kubernetes orchestration, and supply-chain layers. Because containers share the host kernel (the core of the operating system every container on a node borrows), one flaw can compromise neighboring workloads and the host itself. The real job is controlling blast radius from code-write to production runtime, not just scanning images.

🧱 The five layers where things actually break

Most teams picture one problem. There are really five, and they stack.

• Image layer: bloated base images, root by default, baked-in secrets.
• Runtime layer: container escape, credential theft, reverse shells once code executes.
• Kubernetes/orchestration layer: over-permissive RBAC (role-based access control), open network rules.
• Supply-chain layer: poisoned base images, tampered dependencies, unsigned artifacts.
• AI/agent layer: LLM agents with high-privilege tokens, an emerging surface almost no ranking guide covers yet.

That last layer is new. I think it becomes the default question every SecOps team answers within two years, because distributed AI computing forces distributed security. This is exactly why we built runtime security for AI and LLM workloads as a first-class layer, not a bolt-on.

⚠️ Why "scanning" is the wrong mental model

Here is the standard read, and I think it gets this backwards.

Most teams believe container security is about scanning images. That is wrong. Container security is about controlling the blast radius from the moment code is written to the moment it runs in production. If security starts in Kubernetes, you have already lost it.

At EdgeLabs, we treat runtime as the enforcement point, not an afterthought. That single choice shapes everything downstream in this article. A scan describes a file at rest. An attack happens in motion.

Q2: Why Is a Green CI/CD Pipeline a Dangerous Illusion?

Most people believe a passing pipeline means a secure workload. They are wrong, and the reason is small enough to miss in code review.

A green pipeline means your scanner ran. It does not mean you are secure. Many enterprise CI/CD configs (the automated build-and-deploy flow) set the scan step to "exit code zero," so the build succeeds even when vulnerabilities are found. Security tools installed but left in monitor-only mode create the same false confidence. A passing gate describes a moment, not a defended workload.

🟢 The single line that lies to you

Look very carefully at one line in a CI/CD YAML file: exit code zero. Even if vulnerabilities are found, the pipeline still succeeds.

This passes review because it is not technically wrong. A busy engineer working across ten files will not catch it. So the dashboard turns green, the release ships, and the finding sits there, unread. Having security tools in place does not mean you are secure.

🔧 Tools installed, policy never switched on

I started a consulting company back in 2017, and 100% of the time we found things misconfigured. Security tools were installed but never given a policy.

Someone would say "block all untrusted software," then leave the machine in monitor-only mode. Everything was almost right. They just never hit that last button. I spent eight years generating millions of security alerts before this, and I can tell you plainly: teams do not need another alert cannon. They need enforcement that is actually turned on.

At EdgeLabs, we built a feature internally nicknamed DAC (defense against configuration) for exactly this gap. It checks that the protection you bought is set to actually protect, not just watch. Because a tool in monitor-only mode is theater, and attackers do not perform for an audience. If you want to see how enforcement is wired in, our workload and application security layer runs it at the host.

Q3: What Are Image-Layer Vulnerabilities and How Do You Shrink the Attack Surface?

I once watched a team debug a "mysterious" vulnerability count. The cause was not their code. It was the operating system they never chose to ship.

Image-layer vulnerabilities come from bloated base images, running as root, mutable tags, and baked-in secrets. An "ubuntu:latest" image ships around 1 GB of packages your app never uses, each a potential bug. A distroless or Alpine minimal image (a stripped-down base with almost no extra software) drops that under 100 MB. Non-root users, multi-stage builds, and deploy-by-digest shrink the attack surface before runtime.

📦 Start smaller, run as nobody

The Ubuntu base carries a full operating system plus packages your application does not need. Each package is code you now have to defend.

If you do not specify a user, Docker runs the container as root by default. Running as root exposes the host operating system files if anything breaks out. Two fixes, both free:

• Start with a minimal base image (Alpine or distroless, under 100 MB) instead of a full OS.
• Never use the "latest" tag; pin a specific version.
• Declare a non-root user explicitly in the Dockerfile.

🔒 Multi-stage builds and deploy-by-digest

Multi-stage builds remove the build tools and dependencies from your final image. Stage two, the runtime stage, copies only the output you actually run, like a single jar file. Everything used to compile stays behind.

Production should deploy by digest, not by tag. A tag like "latest" is mutable and can point somewhere new tomorrow. The SHA-256 digest is immutable, so you run the exact bytes you approved. One honest caveat: image signing does not stop vulnerabilities. It stops impersonation.

Here is where I stay humble. Every tactic above is necessary, and none of it stops an attacker once the container is live. Build-time hygiene shrinks the surface. It does not watch the door. At EdgeLabs, we pair build-time SBOM (software bill of materials, a list of everything inside the image) with a runtime SBOM through our vulnerability management layer, so the image you scanned is provably the image you are actually running. That gap, scanned-versus-running, is where Q4 begins.

Q4: Why Is Runtime, Not the Scanner, the Real Battleground?

The question a security lead asked me mid-PoC still sticks with me. Three days before an audit, she wanted to know one thing: if an attacker pops a pod, will anything stop the sideways move?

Runtime is where attacks actually happen. A scanned, signed image can still be exploited, drift, or escape once running. The 2025 runc CVEs (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) abuse symlinks and bind mounts to write to the host and break out, with no kernel bug required. Build-time scanning checks a static image. eBPF kernel-level monitoring watches live syscall behavior and catches the escape a scan never could.

💥 How a container escape really happens

The runc flaws let a malicious or tampered image escape the container to the host through /proc mount abuse. The container boundary was never a security boundary. It just felt like one.

The 2019 runc flaw (CVE-2019-5736) made the same point years earlier and still gets cited as the reference example. My blunt view: a CVE is not an exploit. CVEs are known weaknesses that may not be usable. An exploit is actively usable and high risk. Not every CVE is exploitable, but every exploit started as a CVE.

📊 Build-time versus runtime, side by side

🛡️ Why eBPF is the honest answer

eBPF (a safe way to run detection logic inside the Linux kernel) watches system calls in real time. When the runc chain touches host /proc, that behavior is visible at the kernel, even though no scan flagged the image.

At EdgeLabs, our eBPF detection layers above the Falco ecosystem, and both detection and response run on the agent itself. That means host-local, time-boxed IP blocking fires even with no cloud backend, so it keeps working self-hosted, on-prem, and air-gapped, where cloud-dependent CNAPP or NDR tools cannot reach. Our network protection and Kubernetes runtime protection run in that same agent, and you can see the full model on the solutions by feature page. I could be wrong about a lot in this young category. I am not wrong that protection has to run where the workload executes.

"Sysdig solves the problem of getting eyeballs inside kubernetes clusters. It enables us to set policies for detecting runtime events and efficiently respond to them."
Verified User in Financial Services Sysdig Secure G2 Verified Review

"Feature updates can often render existing configuration or content useless leading to rework. It is difficult to monitor the state of detected vulnerabilities or detected events."
Verified User in Financial Services Sysdig Secure G2 Verified Review

"Good IPS/IDS/EDR software. Webportal management is good. Docker container integration is useful."
Verified User in Computer Software EdgeLabs G2 Verified Review

Q5: What Are the Most Dangerous Kubernetes Misconfigurations?

The scariest thing I see in a Kubernetes cluster is rarely a zero-day. It is a setting someone typed on purpose, approved in a pull request, and forgot.

The deadliest Kubernetes vulnerabilities are misconfigurations, not exotic exploits. Think over-permissive RBAC (role-based access control, which decides who can do what), "source address prefix = *" rules that let anyone connect, missing pod security contexts, and privileged pods. They pass code review because they are not technically wrong. A rule in a config file is not a guardrail. A permission system that physically cannot perform the action is.

⚠️ The star that opens the door

Here is a real example. "Source address prefix equal to star" means anyone from anywhere can try to connect.

This line passes review easily because, technically, it is not wrong. When someone is working across many files at once, that small detail slips by. The most common Kubernetes misconfigurations follow the same pattern:

• Over-permissive RBAC granting cluster-admin where a namespace role would do.
• Open network rules with a wildcard source address.
• Missing pod security context, so containers run privileged or as root.
• Sensitive hostPath mounts that expose host files to a pod.

🛡️ Guardrails, not sticky notes

Rules in a config file are not a guardrail. I learned this watching an AI agent behave exactly like a careless engineer.

Pocket OS had safety rules written in its config file. The agent acknowledged the rules, then ignored them and acted anyway. My takeaway, earned the hard way, is that our job is to make the dangerous action impossible, not just discouraged. A warning logged after the fact is a sticky note, not a lock.

At EdgeLabs, we enforce Kubernetes runtime guardrails by blocking the action, not just logging a warning about it. Our eBPF agent watches audit-level behavior like kubectl exec into a pod or control-plane exfil, and it can stop the move in one agent alongside NDR, EDR, and CWPP. You can see the full consolidation model on our how-it-works page. I might be wrong about many things in this young category. I am confident that a permission an attacker can talk their way past was never really a permission.

"Sysdig secure is a very versatile and powerful tool for container security. Implementation of rules for use cases is also very intuitive."
Verified User in Financial Services Sysdig Secure G2 Verified Review

"Sysdig Secure can sometimes have default configurations that are not expected, therefore, it is important to go through the documentation before deployment."
Verified User in Financial Services Sysdig Secure G2 Verified Review

Q6: How Do Supply-Chain Attacks Slip Into Your Containers?

Ask most teams what is inside their production image, and you get a pause. That pause is the whole problem.

Supply-chain attacks slip in through poisoned base images, tampered dependencies, and unsigned artifacts pulled from untrusted registries. The fix is provenance (proof of where each piece came from). That means an SBOM listing everything inside, SLSA-level build integrity, image signing with Cosign or Sigstore to stop impersonation, and admission control that rejects anything unsigned or unscanned before it reaches a node. You cannot govern what you do not know exists.

📋 Provenance beats hope

You cannot govern what you do not know exists. So the first move is inventory, not intuition.

OWASP's Kubernetes supply-chain guidance maps each vector to a concrete control. Here is how they line up:

• Poisoned base image: distroless or minimal base, plus an SBOM (software bill of materials) listing every package.
• Tampered dependency: SLSA build-integrity levels and in-toto attestations that prove the build was not altered.
• Impersonated artifact: image signing with Cosign/Sigstore.
• Unapproved image reaching a node: admission control (OPA or Kyverno) that rejects it at the gate.

✅ Signing stops the con, not the bug

One honest clarification I give every team is that image signing does not stop vulnerabilities. It stops impersonation.

A signed image can still carry a flaw. Signing only proves the image is the one you approved, not that the one you approved was safe. Provenance and vulnerability scanning are two different jobs, and you need both.

At EdgeLabs, we pair a build-time SBOM with a runtime SBOM through our vulnerability management layer, then feed both into our CRA/NIS2 Compliance Center. So a provenance gap does not just fire an alert. It maps to a specific requirement ID an auditor will ask about. I want to be precise here. Our Compliance Center covers runtime, vulnerability-handling, and detection controls. It does not cover lifecycle or governance program controls like business continuity or HR training, and I would rather say that plainly than let anyone assume otherwise.

Q7: Why Are Your LLM Agents the New Container Attack Surface?

Most of the industry still treats an AI agent like a feature. I think that read gets it backwards. An agent is a new kind of insider, and it needs runtime supervision, not just a pre-flight check.

LLM agents running in containers are the newest attack surface. Developers hand agents high-privilege tokens for convenience, so one injected instruction can bypass every row-level permission and delete a production database in seconds. Attackers do not need to breach your firewall if they can whisper instructions to your AI. That is a class of risk no image scanner sees.

⏰ Nine seconds is faster than a Slack message

Pocket OS lost its entire production database in nine seconds. The agent deleted a Railway volume to clean up a credential issue.

The backups lived on the same volume. So in one API call, the database and every backup were gone. Nine seconds is faster than you can read a Slack message. No CVE, no exploit, just an agent doing exactly what its token allowed.

🤖 How agents actually get turned

The mechanism is boring, which is why it works. Developers run agents with high-privileged tokens because it is convenient.

In the database-deletion case, a service account bypassed every row-level permission. Two attack styles stand out:

• Prompt injection: hidden instructions in data the agent reads, redirecting its behavior.
• Tool poisoning: a tampered tool or MCP (Model Context Protocol) server the agent trusts and calls.

🔒 The two-of-three rule

Here is a tactic I hand to teams shipping agents this quarter. Agents can do three things: access your files, access the internet, and write and run custom code.

Let an agent do only two of those three. Grant all three, and malware has a clean path to get injected and executed. You can patch a bug, but you cannot patch a brain. Think of agents as foot soldiers and your engineers as the generals directing them.

At EdgeLabs, our Parallax engine secures LLM agents and MCP servers in runtime. It works as an LLM proxy that checks input and output alignment, defends against prompt injection and tool poisoning, and runs hallucination checks. That is the layer scanners and CNAPP miss entirely. What I think shifts over the next two years is simple. Securing the agent at runtime stops being niche and becomes the default question every SecOps team answers. If this is where your roadmap is heading, our solutions by use case break it down further.

"It finds real security risks (keys leak) not just alerts by analyzing how attackers could exploit systems."
Verified User in Computer Software SentinelOne Singularity Cloud Security G2 Verified Review

"The platform can feel heavy and expensive for smaller teams. It may show some false alerts that need tuning."
Verified User in Computer Software SentinelOne Singularity Cloud Security G2 Verified Review

Q8: How Do You Prioritize Which Vulnerabilities Actually Matter (and Stay CRA/NIS2-Ready)?

A team once showed me 300 "critical" findings and asked which to fix first. The honest answer was almost none of them, in that order.

Stop triaging by CVE count. A CVE is a known weakness. An exploit is one attackers actively use. Not every CVE is exploitable, but every exploit started as one. Combine CVSS severity with EPSS (a score predicting exploitation probability) and the CISA KEV catalog (a list of vulnerabilities confirmed exploited in the wild) to surface the handful that matter. The EU Cyber Resilience Act and NIS2 now make this discipline a compliance obligation, not just good hygiene.

📊 CVSS-only versus exploited-vulnerability scoring

The standard reflex is CVSS-first patching. I push back on it. Without EPSS and CISA KEV, you fix what is scary on paper, not what is actually being used.

Agent-based scanners have a blind spot here too. They tell you the exposures exist, but not which ones an attacker can actually reach.

💰 Why regulators now care

This is not only hygiene anymore. The EU Cyber Resilience Act (Regulation 2024/2847) and NIS2 (Directive 2022/2555) put obligations on how you handle exploitable flaws.

The CRA's Annex I includes a "No Known Exploitable Vulnerabilities" expectation. That language rewards exactly the exploitability-first triage above. Fixing scary-on-paper CVEs while a KEV-listed one sits open is now a defensible-audit problem, not just a risk one. Our practical CRA roadmap walks through this in detail.

At EdgeLabs, we score exploitability using CVSS, EPSS, CISA KEV, and CWE together, then map each finding to a CRA or NIS2 requirement ID inside our shipping Compliance Center. So a finding becomes a control-to-requirement line an auditor accepts, not just a number on a dashboard. I will be candid about scope. This covers vulnerability-handling and detection-and-response controls. It does not cover the CRA's multi-year support obligations or program-level governance, and pretending otherwise would not survive an audit anyway. For the bigger regulatory picture, see why NIS2 and CRA change the game.

"It provides realtime threat alert and AI power threat analysis to highlight the most critical issue and proactive recommendations to act on security gaps."
Lokesh K. CrowdStrike Falcon Exposure Management G2 Verified Review

"Triggers a lot of alert if it is not properly fine tuned and initial setup a bit complex as fine tuning security policy require expert of knowledge."
Lokesh K. CrowdStrike Falcon Exposure Management G2 Verified Review

"It helps close security gaps that point solutions may miss. Aqua enforces policies and monitors containers at runtime."
hugh m., Sr Cybersecurity Engineer Aqua Security G2 Verified Review

Q9: What Should an SMB Actually Do on Monday Morning?

Most SMB security advice reads like it was written for a bank with a 24/7 SOC. You do not have that. You have a Slack channel, a finite budget, and a cluster that has to stay up.

Start with the minimum viable posture that stops a nine-second wipe. That means minimal non-root images, deploy-by-digest, RBAC least-privilege, admission control that rejects unsigned images, exploitability-based triage, and runtime detection with response. This matters because 94% of small businesses faced at least one cyber attack in the past year, and 60% of them fold within six months of one.

💸 Why the stakes are existential, not abstract

The numbers are blunt. The average cost of a cyber attack for a small business runs around $25,000, and 60% of SMBs go out of business within six months of one.

Ingram Micro, one of the largest IT providers in the world, was hit by a ransomware breach over a weekend. If it can happen to them, the job is to mitigate as far as you possibly can. I still remember two lawyer firms that lost their entire database, and I had to learn about it from the news. Telling a client a month later that their litigation is now in the press is a conversation you never forget.

✅ The prioritized worklist

Do these in order. Each step maps to a layer covered earlier in this article, so nothing here is new theory.

1. Switch to minimal, non-root base images and stop using the "latest" tag (image layer).
2. Deploy production by SHA-256 digest, not by mutable tag (image layer).
3. Cut RBAC down to least-privilege and remove wildcard network rules (Kubernetes layer).
4. Turn on admission control that rejects unsigned or unscanned images (supply-chain layer).
5. Triage by CVSS plus EPSS plus CISA KEV, not raw CVE count (exploitability layer).
6. Run runtime detection that can also respond, not just alert (runtime layer).

⏰ One agent, not six contracts

Here is the honest cash argument. Stitching six point tools together is expensive, slow to deploy, and hard for a small team to run.

At EdgeLabs, we consolidate NDR, EDR and CWPP, Kubernetes security, vulnerability management, and AI/agent security into one agent that runs self-hosted, on-prem, or air-gapped. Our published Trader Joe's case study reports an 83% MTTR reduction and deployment in under two weeks, which is the kind of timeline a lean team can actually absorb. I will name the limit too. Our free and SMB tier is intentionally narrower than enterprise, so match the tier to the workload, not the marketing.

Q10: Which Container Runtime-Security Tools Best Fit an SMB Running AI Workloads?

A security lead asked me mid-PoC, three days before an audit, whether our agent would still block an attack if the backend went dark. That question is the whole buying decision for anyone running on-prem or air-gapped.

Most container-security tools are cloud-dependent. Sysdig, CrowdStrike, SentinelOne, and cloud-NDR players like Vectra need a cloud backend to detect and respond, so they cannot fully reach self-hosted, on-prem, or air-gapped workloads. The best fit for an SMB securing AI workloads runs detection and response on the agent itself, and keeps working even in Disconnected Mode (fully offline).

⭐ The shortlist, ranked for an SMB running AI workloads

I am biased toward runtime-first and agent-only, and I will show my work rather than hide it.

1. EdgeLabs

Agent-only detection and response with no cloud dependency, one-agent consolidation, and the Parallax engine for LLM/agent runtime security, plus a shipping CRA/NIS2 Compliance Center.

2. Sysdig

A strong, mature runtime and CNAPP player with deep Falco heritage and broad cloud coverage; heavier and more cloud-oriented.

3. Aqua Security

Full-lifecycle protection from build to runtime, especially strong on image and supply-chain scanning.

4. Upwind

Runtime-powered CNAPP, though cloud-context heavy.

5. Oligo

Application and runtime detection focus; young, with limited third-party reviews.

6. CrowdStrike / SentinelOne

XDR and endpoint-first, where container runtime is an extension of an endpoint engine, not the first stop.

7. Falco (CNCF)

The open-source eBPF detection baseline; excellent, but you build and run the rest yourself.

📊 How they actually differ

⚠️ Where I would not pick EdgeLabs

Honesty over hype means naming the misfits. Aqua has full lifecycle build-time features we do not all have yet, so if pure build-time scanning is your whole job, weigh that.

If your real problem is OT or ICS asset visibility (industrial control systems on a plant floor), IoT-hardware security, or build-time-only SAST, we are not your tool. I would not stack us against the OT-visibility vendors either, because that is a different job at a different layer. On self-building with open source like Falco, one caution. The IKEA effect makes teams overvalue what they assemble themselves. Unless you are allocating five or ten million to build detection technology, you probably will not get it right at that scale. For a fuller breakdown, see why teams choose AI EdgeLabs and our solutions by use case.

Where my head is right now is this. Distributed AI computing forces distributed security, and the "will it still block with the cloud dark" question stops being an edge case within two years. If you are running agents or GPU inference on-prem, I would genuinely like to hear what breaks first in your environment. That conversation teaches me more than any benchmark, so reach out to our team or explore how the platform works.

"It's beneficial to secure any website or any server from hackers."
Abhishek A. EdgeLabs G2 Verified Review

"Ease of Integration: Falco integrates seamlessly with Kubernetes and container environments. As a DaemonSet running on each node, Falco can consume a noticeable amount of system resources."
Bikash s. Falco G2 Verified Review

"It provides a single CNAPP platform that covers application, data, infrastructure, and runtime security. The heavy dependency on SaaS availability creates vendor lock-in and introduces a real risk to overall availability."
Verified User in Information Technology and Services CrowdStrike Falcon Cloud Security G2 Verified Review

FAQs

What are container security vulnerabilities?

Container security vulnerabilities are weaknesses in how containers are built, configured, shipped, and run. They are not just a scanning problem.

We see them across five layers:

• Image layer: bloated base images, root by default, and baked-in secrets.
• Runtime layer: container escape, credential theft, and reverse shells once code executes.
• Kubernetes layer: over-permissive RBAC and open network rules.
• Supply-chain layer: poisoned base images and unsigned artifacts.
• AI/agent layer: LLM agents holding high-privilege tokens.

Because containers share the host kernel, one flaw can compromise neighboring workloads and the host itself. The real job is controlling blast radius from code-write to production runtime. If security starts in Kubernetes, you have already lost it. That is why we treat runtime as the enforcement point through our runtime-security approach, not an afterthought bolted onto a build scan.

Why isn't a passing CI/CD pipeline enough to secure containers?

A green pipeline means your scanner ran. It does not mean you are secure.

We keep seeing two patterns that create false confidence:

• Exit code zero: the scan step is configured so the build succeeds even when vulnerabilities are found.
• Monitor-only mode: security tools are installed but never given an enforcing policy.

A passing gate describes a moment, not a defended workload. Tools without an enforced policy are theater. Attackers do not perform for an audience, so a warning logged after the fact is a sticky note, not a lock.

The fix is enforcement that actually blocks the dangerous action. Our workload and application security layer runs that enforcement at the host, checking that the protection you bought is set to protect, not just watch. Build-time hygiene still matters, but it shrinks the attack surface rather than defending the live workload.

How do you shrink image-layer attack surface before runtime?

Image-layer vulnerabilities come from bloated base images, running as root, mutable tags, and baked-in secrets.

We recommend these build-time moves:

• Start with a minimal base image such as Alpine or distroless, often under 100 MB versus roughly 1 GB for a full OS.
• Declare a non-root user explicitly, since Docker defaults to root.
• Use multi-stage builds so only the runtime output ships, not the build tools.
• Deploy production by immutable SHA-256 digest, not by mutable tag.

One honest caveat: image signing does not stop vulnerabilities, it stops impersonation. So provenance and vulnerability scanning are two different jobs, and you need both.

These tactics shrink the surface, but none stop an attacker once the container is live. We pair a build-time SBOM with a runtime SBOM through our vulnerability management layer, so the image you scanned is provably the image you actually run.

Why is runtime, not the scanner, the real battleground?

Runtime is where attacks actually happen. A scanned, signed image can still be exploited, drift, or escape once running.

The 2025 runc CVEs (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881) abuse symlinks and bind mounts to write to the host and break out, with no kernel bug required. The 2019 runc flaw (CVE-2019-5736) made the same point years earlier.

The difference matters:

• Build-time scanning checks a static image at one moment.
• Runtime detection watches live syscall behavior as code executes.

A CVE is not an exploit. Not every CVE is exploitable, but every exploit started as a CVE. eBPF kernel-level monitoring sees the runc chain touch host /proc even when no scan flagged the image.

Our eBPF detection runs both detection and response on the agent, so host-local blocking works self-hosted, on-prem, and air-gapped. Explore our runtime network protection for how that plays out live.

What are the most dangerous Kubernetes misconfigurations?

The deadliest Kubernetes vulnerabilities are misconfigurations, not exotic exploits. They pass code review because they are not technically wrong.

The usual suspects are:

• Over-permissive RBAC granting cluster-admin where a namespace role would do.
• Open network rules with a wildcard source address, so anyone can try to connect.
• Missing pod security context, so containers run privileged or as root.
• Sensitive hostPath mounts that expose host files to a pod.

A rule written in a config file is not a guardrail. A permission system that physically cannot perform the action is a guardrail. We have watched agents acknowledge safety rules and then ignore them, so the job is to make the dangerous action impossible, not just discouraged.

We enforce Kubernetes runtime guardrails by blocking the action, not just logging a warning, watching audit-level behavior like kubectl exec and control-plane exfil.

How do supply-chain attacks slip into containers?

Supply-chain attacks slip in through poisoned base images, tampered dependencies, and unsigned artifacts pulled from untrusted registries. You cannot govern what you do not know exists.

The fix is provenance, and each vector maps to a control:

• Poisoned base image: a minimal base plus an SBOM listing every package.
• Tampered dependency: SLSA build integrity and in-toto attestations.
• Impersonated artifact: image signing with Cosign or Sigstore.
• Unapproved image: admission control (OPA or Kyverno) that rejects it at the gate.

Signing proves the image is the one you approved, not that the one you approved was safe, so you still need vulnerability scanning alongside it.

We pair build-time and runtime SBOMs and feed both into our CRA/NIS2 Compliance Center, so a provenance gap maps to a specific requirement ID an auditor will ask about, not just a passing alert.

How do you prioritize which vulnerabilities actually matter?

Stop triaging by CVE count. A CVE is a known weakness; an exploit is one attackers actively use.

We combine three signals:

• CVSS: theoretical severity of the flaw.
• EPSS: probability that it will be exploited.
• CISA KEV: confirmation it is exploited in the wild.

CVSS-first patching means you fix what is scary on paper, not what is actually being used. Agent-based scanners often tell you the exposures exist but not which ones an attacker can reach.

This is now a compliance matter too. The EU Cyber Resilience Act (Regulation 2024/2847) and NIS2 (Directive 2022/2555) put obligations on how you handle exploitable flaws, and the CRA's Annex I includes a "No Known Exploitable Vulnerabilities" expectation.

We score exploitability with CVSS, EPSS, CISA KEV, and CWE, then map each finding to a requirement ID. Our practical CRA roadmap walks through it.

Which container runtime-security tools best fit an SMB running AI workloads?

Most container-security tools are cloud-dependent. Sysdig, CrowdStrike, SentinelOne, and cloud-NDR players like Vectra need a cloud backend to detect and respond, so they cannot fully reach self-hosted, on-prem, or air-gapped workloads.

When we evaluate fit for an SMB securing AI workloads, we look for:

• Detection and response running on the agent itself.
• Function that continues in Disconnected Mode, fully offline.
• One-agent consolidation instead of six stitched point tools.
• Purpose-built defense for LLM agents and MCP servers.

We are candid about where we are not the fit: pure OT/ICS asset visibility, IoT-hardware security, or build-time-only SAST. Aqua also has full-lifecycle build-time features we do not all have yet.

Our agent-only, no-cloud-dependency model runs detection and response at the workload. See solutions by use case or try the free tier to evaluate fit.