Why are containers uniquely suitable for whitelist-based runtime security?

Question

Options

• ADevelopers typically define the processes used in their containers within the Dockerfile
• BDocker has a built-in runtime analysis capability to aid in whitelisting.
• CContainers typically have only a few defined processes that should ever be executed.
• DOperations teams typically know what processes are used within a container

• A
  92% (33)
• B
  6% (2)
• D
  3% (1)

Explanation

Containers are uniquely suited for whitelist-based runtime security because the Dockerfile explicitly declares every process, dependency, and entry point needed to run the application - giving security teams a pre-defined, authoritative list of what should ever execute at runtime. B is wrong because Docker has no native built-in runtime behavioral analysis or whitelisting engine - that capability comes from third-party tools like Falco or Aqua. C is partially true (containers do tend to have few processes), but it's a consequence of good container design, not the reason whitelisting works so well - the Dockerfile is the actual source of that predictability. D is wrong because it confuses who knows about processes with where that knowledge is formally documented; ops teams may have knowledge, but the Dockerfile is the concrete, version-controlled artifact that makes whitelisting implementable.

Memory tip: Think "Dockerfile = whitelist blueprint." The Dockerfile is essentially a security contract written by the developer - if a process isn't in the Dockerfile, it shouldn't be running.

No community discussion yet for this question.