Security Doesn’t Start at Runtime. It Starts With What You Include

Two recent incidents had nothing to do with application code, yet both created real security and operational impact.

One allowed root access through a system component most workloads don’t need. The other disrupted access to the infrastructure those workloads depend on.

Neither problem starts at runtime.

Two Incidents, One Underlying Pattern

Consider the Pack2TheRoot vulnerability (CVE-2026-41651).

A local privilege escalation flaw in PackageKit made it possible for an unprivileged user to gain root access on multiple major Linux distributions. The issue persisted for years, affecting default installations across ecosystems.  

This was not a niche component. It was widely present.

In practical terms, this means that a minor foothold inside a container can turn into full control of the environment, not because of the application, but because of what was bundled alongside it.

At the same time, a separate event affected availability rather than privilege. During the Ubuntu DDoS attack, which affected access to repositories and update infrastructure, Canonical’s services experienced sustained disruption.

There was no indication of compromised packages. But access itself became unreliable.

The disruption highlights a different kind of risk. Even if your runtime is secure, reliance on external package infrastructure introduces a dependency you do not control. When that dependency is unavailable, your ability to build, update, or recover systems is affected.

Unlike vulnerabilities such as CVE-2026-41651, which originate within software components, this incident highlights risks in external dependency availability.

These incidents are different in nature. One is a vulnerability. The other is an availability attack.

But they expose a shared issue.

They both originate outside the application logic.

Security Is an Inclusion Problem Before It’s a Detection Problem

Modern containers often inherit large portions of a general-purpose operating system.

That includes:

• Package managers

• System services

• Background daemons

• Utilities designed for interactive or administrative use

Many of these components are not required for the application to run. They exist because they are part of the base image.

This creates two kinds of risk:

1. Excess runtime surface area
   Components like PackageKit expand what an attacker can interact with after gaining a foothold.

2. External dependency reliance
   Systems that depend on upstream infrastructure for updates or package access introduce availability and trust dependencies outside your control.

The issue is not just vulnerable software. It is unnecessary software.

Neither of these risks is introduced at runtime.

They are introduced at build time.

What You Include Defines Your Risk

Take a closer look at the PackageKit issue.

The vulnerability itself was serious, but the more important question is why that component existed in production environments where it was not needed.

PackageKit is a package management abstraction layer. It is useful on general-purpose systems. It is rarely required inside a production container.

That distinction matters.

This vulnerability did not emerge from the application. It came from an auxiliary component included in the runtime environment. A component that, in many cases, had no role in the workload itself.

If that layer is not present, this specific class of risk does not exist.

In many cases, these components run with elevated privileges or expose system interfaces such as D-Bus, increasing the potential impact of a compromise.

This is where minimal runtime construction, often implemented through minimal or distroless-style runtime images, becomes relevant. Not as a blanket security claim, but as a design principle. When you remove non-essential services such as package managers, background daemons, and system-level tooling, you reduce the number of pathways available after an initial foothold. You are not preventing compromise outright, but you are constraining how far it can go.

The same pattern shows up from a different angle in the Ubuntu disruption. In this case, the issue was not a vulnerability within the image, but dependence on external systems for package distribution and updates. Even without a compromise of package integrity, availability itself became a point of failure.

Together, these examples point to a broader reality.

Security is not only about identifying vulnerabilities in what you run. It is also about questioning why those components are present in the first place, and how much you rely on systems outside your control.

Reducing runtime components limits exposure. Reducing external dependencies improves resilience.

Both start earlier than runtime.

Why Runtime Controls Alone Are Not Enough

Runtime security tools are designed to observe and respond.

They can:

• Detect anomalous behavior

• Block suspicious activity

• Alert on policy violations

What they cannot do is remove unnecessary components that were included upstream.

If a package manager daemon exists inside the container, runtime controls can monitor its behavior. They cannot justify its presence.

This is the gap.

Security controls at runtime operate within the constraints of the system they are given. If that system includes unnecessary complexity, the control surface expands accordingly.

Shifting Left, But Meaningfully

“Shift left” is often reduced to scanning earlier in the pipeline.

But scanning earlier does not change what is being built.

A more meaningful shift is deciding what should exist in the system at all.

This means:

• Building from known, controlled inputs

• Excluding components that are not required at runtime

• Reducing reliance on external systems during execution

Security improves not just by finding issues sooner, but by introducing fewer of them in the first place.

Closing Thought

We have made real progress in securing containers at runtime. That progress should continue.

But runtime is only the final stage of a much longer process.

The security of a system is shaped long before it starts running. It is shaped by the components included, the dependencies introduced, and the assumptions carried forward from base images.

The question is not just whether a vulnerability exists.

It is whether the component containing it needed to exist in your system at all.

Because what you include is not just an implementation detail.

It is a security decision.