Triaging Privileged Container

You received a Privileged Container Detected detection. A workflow step ran docker with --privileged, which gives the container full host capabilities. A real --privileged invocation from a compromised dependency is a well-known runner-takeover technique. A larger share of these detections is benign than for other Suspicious Process Events, because several legitimate workloads (Docker-in-Docker, kernel-module tests) require the flag by design. Use this runbook to decide which case you have.

How it's detected

While processing runner process events, the Harden-Runner agent looks for a docker invocation (case-insensitive) whose arguments contain --privileged and emits a detection citing the offending process.

Triage

Likely a compromise (true positive)

A workflow step runs docker run --privileged ... introduced by a compromised dependency or a malicious PR. Full host capabilities inside a CI container are a well-known pivot for container-to-host escape and runner takeover: from a privileged container an attacker can read host memory, access secrets stored on the host, install persistence, or pivot to other workloads on the same runner.

Actions to take:

• Identify the workflow step that issued the docker command.

• Trace it back to a specific dependency, action, or PR. Be especially careful with recent dependency upgrades or PRs from forked branches.

• Rotate any secrets the affected workflows had access to.

• On self-hosted runners, treat the runner host as potentially compromised and reimage it. Hosted runners are ephemeral and do not need this step.

• Block the offending action or dependency, and check the Threat Center for related advisories.

Consider enabling Lockdown Mode for Privileged Container so future occurrences terminate the job automatically. Apply Lockdown selectively if you have repositories that legitimately require --privileged.

Likely benign (false positive)

Some workflows legitimately need elevated capabilities and pass --privileged by design:

• Docker-in-Docker (DinD) builds, including BuildKit configurations.

• Nested-virtualization tests (e.g., running QEMU or KVM inside CI).

• Kernel-module compilation and testing.

• Hardware or device access for embedded toolchains.

If the detection fits one of these patterns:

• Confirm the workflow file explicitly includes the --privileged flag and the author added it deliberately.

• Confirm the workflow's stated purpose requires elevated capabilities.

• Confirm no recent change introduced new uses of --privileged that do not match the workflow's stated purpose.

If all checks pass, suppress the detection with the reason "Legitimate privileged workload." Document which repositories and workflows have an approved exception.

Next steps

• If confirmed compromise: rotate secrets, follow your incident response process, and reimage any self-hosted runner that ran the step. Resolve the detection once remediation is complete.

• If false positive: suppress per How to Suppress a Detection. Consider scoping the suppression to the specific repository or workflow rather than the whole organization.

• If uncertain: escalate to your security team with the workflow step, full docker command, and run URL.