This article is based on a post originally published on linux.com, written by a member of the Aqua Security team sharing early observations about container security practices.
Introduction
Container security is a broad discipline, and even experienced engineers can overlook practical risks hidden in everyday workflows. Whether you are just getting started with containerized deployments or have been running Kubernetes in production for years, a few less-obvious lessons are worth internalizing. This article covers three of them: personal identity exposure inside container images, the subtleties of vulnerability scanning false positives, and the critical role of runtime behavior detection alongside static prevention.
Lesson 1: Personal Email Addresses in Container Images Create Phishing Risk
Many engineers include contact information directly inside their container images. Docker’s MAINTAINER directive — now deprecated in favor of the more generic LABEL instruction — made it easy and seemingly harmless to record who built an image. The intention is good: users should be able to reach the person responsible for a given component.
The risk emerges when that contact information is a personal corporate email address like john.doe@giantcorp.com embedded inside a publicly available image. Anyone who pulls the image can extract that metadata and immediately learn:
- The full name of a real employee at the organization.
- Their role or ownership of a specific internal component.
- A direct email address to target.
This information is precisely what a spear-phishing campaign needs to craft a convincing, targeted attack. Even if the same person is already visible on LinkedIn, reducing the number of places where individual employee details are published shrinks the attack surface.
What to Do Instead
For corporate or enterprise images that may be shared publicly or with external partners, use a generic, role-based email address in image metadata:
LABEL maintainer="engineering@giantcorp.com"Code language: JavaScript (javascript)Options like hello@, security@, containers@, or a team alias tied to the relevant service are all reasonable choices. This keeps a point of contact available without exposing an individual. Open source maintainers publishing personal projects may reasonably weigh this differently — public attribution builds community trust and individual reputation — but the calculus changes significantly in a commercial context.
Lesson 2: Container Image Scanning Produces More False Positives Than You Expect
Image scanning tools — including those built into Docker Hub, CoreOS’s Clair, and third-party security platforms — search container images for packages that match entries in vulnerability databases such as the National Vulnerability Database (NVD) maintained by NIST. The concept sounds straightforward: if a known-vulnerable package version is present, flag it.
In practice, the detection logic is substantially more complex, and false positives are common. Understanding the three main categories helps you triage scan results more accurately.
False Positive Type 1: Backported Patches and Unofficial Version Numbers
Suppose a vulnerability called CVE-XXXX is fixed in upstream version 1.3.0 of a package, and any version below that is flagged as vulnerable. A developer who does not want all the changes in 1.3.0 may cherry-pick only the security fix, apply it to version 1.2.7, and release the patched build as 1.2.7.12345.
A scanner comparing version strings will conclude that 1.2.7.12345 < 1.3.0 and report the vulnerability as present. It is not. This is a false positive caused by a version string that does not follow the upstream numbering scheme.
False Positive Type 2: Layer-by-Layer Scanning Misses Package Replacements
Container images are built in layers. If a base image includes a vulnerable version of a package, and a child image replaces it with a fixed version in a later layer, a scanner that reports findings per-layer rather than resolving the final effective state of the image will still flag the vulnerability.
A well-designed scanner must resolve the final merged filesystem of the image — the state that actually runs — before evaluating which package versions are present. If it does not, any child image built on a vulnerable base will appear vulnerable even after the package has been updated.
False Positive Type 3: Unexploitable Vulnerabilities Given the Deployment Context
Some vulnerabilities are only exploitable under specific conditions — for example, a flaw that requires network access to trigger. If the container in question has no network interfaces configured, the vulnerability cannot be exploited regardless of whether the vulnerable code is present.
Context-aware scanners attempt to account for this, but many do not. The result is a report that technically identifies a real vulnerability in the code, but one that poses no practical risk in that particular deployment configuration.
Why False Positives Are a Real Problem
False positives are more than an inconvenience. When teams are regularly confronted with scanner output that turns out to be irrelevant, they develop the habit of dismissing alerts without full investigation. This alert fatigue means that when a genuine, high-severity vulnerability does appear in a scan, it risks being ignored along with the noise. Accurate scanning and disciplined triage processes are both essential.
Lesson 3: Runtime Detection Is as Important as Pre-Deployment Prevention
Image scanning is a preventive control: it aims to stop known-vulnerable software from reaching production. But by definition, it cannot catch zero-day vulnerabilities — flaws that are not yet known and therefore not present in any database. There is always a window between the introduction of a zero-day exploit and its public disclosure and patching. During that window, scanning provides no protection.
This means that even with rigorous scanning policies, you will eventually run vulnerable code in production. The question is what happens next.
Defining Normal Behavior for Containers
When a vulnerability is exploited, the attack almost always changes what the process does: it may write to unexpected file paths, spawn new processes, open connections on unusual ports, or attempt to read credentials from locations the application would never normally access.
A containerized microservice architecture actually makes behavioral baselining more tractable than it would be for a large monolith. Because each container has a narrow, well-defined responsibility, the set of expected behaviors is small and enumerable:
- Which ports does this service legitimately communicate on?
- Which other services does it call?
- Which files or directories does it read and write?
- Which executables does it invoke?
Any deviation from that baseline is a signal worth investigating. Runtime security tools can monitor for these anomalies and either alert on them or enforce policies that actively block unexpected behavior before damage is done.
Detection Enables a Faster Response
Spotting anomalous behavior as it happens — rather than discovering a breach during a post-incident audit — compresses the time available for an attacker to move laterally, exfiltrate data, or establish persistence. Combining runtime detection with automated response (such as isolating a misbehaving container or triggering an incident workflow) turns the monitoring capability into an active defense layer.
Summary
Container security requires attention at multiple stages of the delivery pipeline and beyond. Three practical takeaways from this discussion:
- Audit image metadata for personal corporate email addresses and replace them with generic team aliases to reduce spear-phishing exposure.
- Understand your scanner’s limitations — backported patches, layer resolution, and deployment context all influence whether a flagged vulnerability is actually exploitable in your environment.
- Invest in runtime behavior monitoring alongside static scanning; prevention alone cannot protect against unknown vulnerabilities, but anomaly detection can limit the damage when they are exploited.
These are not exhaustive — container security is a deep field — but addressing these three areas will meaningfully improve the security posture of most containerized deployments.