Container security has two moments: before deployment, when you scan the image, and after, when it is live. Pre-deployment scanning catches known-vulnerable packages baked into the image, but it misses what only becomes visible at runtime — the file that gets written, the dependency pulled in, the payload dropped after the container starts.

Twistlock, Ltd.'s US10915628B2, “Runtime detection of vulnerabilities in an application layer of software containers” (issued February 9, 2021; CPC G06F 21/554 — detecting malicious behavior, and G06F 21/52 — monitoring program execution), describes detecting application-layer vulnerabilities in containers at runtime. Read it at US10915628B2.

“A system and method for detecting vulnerabilities in software containers at runtime are provided.”— U.S. Patent No. 10,915,628 source

The mechanism exploits a fact about how containers are built. A container image is a stack of read-only layers plus one writable top layer — the application layer — and, as claim 1 puts it, “changes are made only to the application layer.” So the detector does not have to watch the whole filesystem; it watches the one layer that can change. It monitors “events triggered as a result of changes to an application layer,” and the specification names the concrete mechanism on Linux: filesystem events captured via the kernel's fanotify component, plus events on mounted volumes mapped into the container.

When a file is added or modified, the system scans that file against “intelligence information” pulled from external sources — the claims list “a common vulnerabilities and exposures database, a reputation service, and a security system.” A match generates a detection event carrying, per claim 7, “an identifier of the software container, a name of the at least one file, and the type of the detected vulnerability.” Because the scan is triggered by the change rather than scheduled, the filing argues it provides “a defense against zero-day attacks… in real-time as the files are detected.”

The design runs as a detector container that proxies traffic in and out of each application container — intercepting “system calls, access to a filesystem… inbound and outbound network traffic” — so it sees behavior without being part of the workload. And it handles a second, harder case: unknown vulnerabilities with no signature. For those, a newly launched container is migrated into a “quarantined environment” — an isolated VM with a “dummy container” designed to trap attempts to infect neighbors — where its runtime behavior is watched for unauthorized actions such as “system calling the OS kernel,” reaching “an external network address,” or opening port 22. If it runs clean for a predefined period, the specification gives 24 hours as an example, it is migrated back and the quarantine is deleted.

The filing is explicit that the two halves work in synergy. Its worked example: an attacker exploits a remote-code-execution hole to push code that opens a connection and downloads an agent. The quarantine catches the suspicious outbound behavior; failing that, the downloaded agent file is caught when it lands and the filesystem-change scan inspects it. Either the behavior or the artifact trips the detector — which is the runtime argument in one sentence.

The dependent claims round out the response side. The intelligence the scanner consults can come from “a common vulnerabilities and exposures database, a reputation service, and a security system” (claim 4), and the vulnerability types it looks for explicitly include “previously known and newly discovered malware” (claim 5). The monitored events are pinned to “filesystem events and mounted volume events” (claim 6). And the mitigation is concrete: claim 8 adds “performing at least one mitigation action upon generation of the detection event,” with claim 9 enumerating “halting the software container, quarantining the software container, and quarantining the at least one file.” The specification also stresses the architectural reason this is safe at scale: because base image layers are shared and read-only across many containers, only the small writable delta per container needs watching, so the detector's cost scales with change, not with fleet size.

The background section is candid about why prior tools missed this. Existing security solutions, it argues, “are designed to protect the organization's infrastructure (servers, networks, etc.) against cyber-attacks carried out by external sources” — an intrusion-detection system “can detect a malware intrusion to a server… from an external source, but… cannot detect any virus/malware intrusion caused by execution of a software container,” because that container “is deployed in the server in a legitimate manner.” The threat is internal and legitimate-looking. It also flags the shared-kernel risk: because all containers on a host share one OS kernel, “a malicious container” can “infect or alter a container through the OS kernel,” and the prevalence of third-party image repositories means much container content arrives pre-built and untrusted. Watching the writable layer and quarantining unknowns is the filing's answer to a threat model that legacy perimeter and host tooling structurally could not see — which is the conceptual core of the cloud-workload-protection category.

Why this is a business story: this pairs with Twistlock's process-profiling IP as the technical foundation of Palo Alto's Prisma Cloud, acquired in the roughly $410 million Twistlock deal. The runtime-versus-static distinction is also the competitive battleground in cloud security — agentless scanners (Wiz, Orca) sell on breadth of scan coverage, while runtime vendors sell on catching the post-launch behavior and dropped files that a static image scan, by construction, cannot see. This grant stakes the runtime side of that argument with a concrete mechanism: watch the one writable layer, scan on change, and quarantine the unknowns.

The grounded read: runtime container vulnerability detection watches the container's single writable application layer for file changes, scans each change against CVE and reputation feeds, and quarantines new containers to catch unknown threats by behavior — surfacing flaws a static image scan misses. Twistlock's 2021 grant names that runtime-layer detection in mechanical detail — a pillar of the cloud-workload-protection thesis Palo Alto bought into.