Docker Containers in Medical Devices: What the FDA Expects You to Test

Published June 11, 2026

Key Takeaways

• Containers are in scope whenever they ship in, on, or alongside a cyber device, including SaMD cloud backends, on-device edge inference, hospital-deployed gateway appliances, and update or telemetry sidecars.
• Section 524B(b)(3) requires the SBOM to include every image layer, base image, OS package, and language dependency, not just the application code.
• The 2026 guidance expects evidence that container hardening controls (non-root, read-only filesystem, dropped capabilities, seccomp/AppArmor) are implemented, not just claimed.
• Container escape and registry compromise are the two container-specific attack paths reviewers most often flag as missing from the threat model.
• The patch and update mechanism under Section 524B(b)(1) must cover base-image CVE drift, not only application code.

Table of Contents

• Key Takeaways
• Where containers show up in medical devices
• Why the FDA cares about containers
• The six classes of container testing
• Mapping container evidence to eSTAR v7.0
• Deficiency patterns we see on container-heavy submissions
• How Blue Goat Cyber tests containerized medical devices
• FAQ

Where containers show up in medical devices

Containers rarely sit inside a regulated firmware blob, but they show up in four common places that the FDA considers part of the cyber device:

1. SaMD cloud backend. A web or AI/ML inference service that the device or clinician app calls. The container image is part of the device's intended use and part of the submission.
2. On-device edge inference. A Docker or OCI runtime on a gateway, kiosk, or imaging workstation that hosts a model server or analytics pipeline.
3. Hospital-deployed gateway appliance. A turnkey box (often a hardened Linux distro with Podman or k3s) installed in the hospital network as part of the cleared system.
4. Build, deploy, and update tooling that ships in the device. Update agents, telemetry collectors, and remote-management sidecars are often containerized and burned into the device image.

If the container is in any of these four places, it is in scope for the cybersecurity submission. The 2026 guidance does not give container-based components a lighter treatment.

Why the FDA cares about containers

Three reasons:

• SBOM completeness. Containers expand the software bill of materials by an order of magnitude. A 200 MB Python image typically pulls in 300 to 600 OS and language packages on top of the application code. Section 524B(b)(3) requires all of it.
• Attack surface. Containers introduce attack paths that do not exist for monolithic firmware: image tampering between build and deploy, registry credential leakage, container escape into the host, orchestrator API exposure, and shared-kernel vulnerabilities.
• Patchability under Section 524B(b)(1). Base images age. A CVE published against debian:bookworm-slim after submission still affects every device running that image, and the manufacturer must have a documented mechanism to patch it without disrupting clinical use.

The six classes of container testing

The FDA does not prescribe specific tools, but the 2026 guidance and the deficiency letters we see in practice converge on six testing categories for containerized components.

1. Image SBOM generation

Generate a CycloneDX 1.5+ or SPDX 2.3+ SBOM for every image that ships, at every layer. Tools like Syft, Trivy, or Docker Scout work. The SBOM must include OS packages (apk, deb, rpm), language packages (PyPI, npm, Maven, Go modules), and any binaries you added with COPY or ADD. Vendor-supplied base-image SBOMs are acceptable for the base layer only, and only when they are conformant; a Dockerfile is not an SBOM.

2. Vulnerability scanning (SCA)

Scan the assembled image with Trivy, Grype, Snyk, or an equivalent. Every High or Critical finding belongs in the unresolved-anomalies attachment with a VEX justification (affected, not affected, fixed, under investigation) and a clinical-impact rationale. The FDA expects to see CVEs you decided not to patch, with the reasoning, not a clean scan report that hides them.

3. Hardening and configuration testing

Evidence that the container is built and run with defensive defaults. CIS Docker Benchmark and the NSA/CISA Kubernetes Hardening Guidance are the de facto references. Reviewers look for:

• Non-root USER directive in the Dockerfile
• Read-only root filesystem at runtime (--read-only or readOnlyRootFilesystem: true)
• Dropped Linux capabilities (--cap-drop=ALL, add back only what is needed)
• seccomp and AppArmor or SELinux profiles
• No --privileged flag, no host network, no host PID namespace
• Resource limits set (memory, CPU, pids)

4. Secrets scanning

See also: SBOM for Third-Party Chip Firmware in Medical Devices, Patch and Update Mechanism Testing for FDA Section 524B(b)(1), and DAST vs Penetration Testing: What the FDA Requires.

Run gitleaks, trufflehog, or an equivalent against the image layers and the build context. Baked-in API keys, signing keys, JWT secrets, and database credentials are a recurring deficiency, especially in images built from internal monorepos.

5. Runtime DAST against the containerized service

Once the container is running, the exposed API or web surface gets the same dynamic security testing as any other web service. ZAP, Burp, or a custom harness against the OpenAPI spec. The container boundary does not change what DAST tests, but it does scope the surface: only the ports the container actually exposes.

6. Penetration testing scoped to container and orchestrator boundaries

This is the test most often missing from submissions. A pen test of a containerized medical device should cover:

• Container escape attempts against the runtime (runc, containerd, Docker) and the kernel
• Image registry attacks (anonymous pull, credential reuse, image substitution if pull-by-tag instead of pull-by-digest)
• Orchestrator attacks if Kubernetes, k3s, or Docker Swarm is in scope (RBAC misconfiguration, exposed API server, service-account token abuse)
• Sidecar and inter-container attacks if multiple containers share a pod, namespace, or volume
• Supply-chain attacks on the build pipeline (poisoned base image, malicious dependency, unsigned image)

Mapping container evidence to eSTAR v7.0

The 2026 guidance reorganized the cybersecurity submission into eight eSTAR attachment categories. Container evidence lands in four of them:

eSTAR attachment	What to include for containers
Slot 5: SBOM	One CycloneDX or SPDX file per shipped image, with PURL or CPE identifiers, plus VEX statements for unresolved vulnerabilities
Slot 6: Security controls	CIS Docker Benchmark results, Dockerfile excerpts showing non-root user and dropped capabilities, runtime policy (seccomp, AppArmor), image-signing evidence (Cosign, Notary v2)
Slot 7: Testing	SCA scan reports, secrets-scan reports, DAST against the running service, pen-test report covering escape and registry attacks
Slot 8: Unresolved anomalies and metrics	Every accepted CVE with VEX status, clinical-impact rationale, and the patch-mechanism reference (which ties back to Section 524B(b)(1))

The threat model (Slot 3) and risk assessment (Slot 4) must independently address container-specific attack paths, not just application-layer threats.

Deficiency patterns we see on container-heavy submissions

Across the deficiency letters our team has reviewed, four container-specific patterns recur:

1. Incomplete image SBOM. The submission lists application dependencies but omits the OS packages from the base image. Reviewers can usually tell because the SBOM has 40 components when a python:3.12-slim image alone contains over 100.
2. No hardening evidence. The threat model claims "containers are hardened" but the submission lacks a Dockerfile excerpt, a CIS Benchmark result, or a runtime security context manifest.
3. No container escape rationale. The pen-test report covers the web API but says nothing about whether escape attempts were attempted, scoped out, or deemed not applicable. Reviewers want to see the decision, not silence.
4. No patch mechanism for base-image CVE drift. Section 524B(b)(1) requires a documented update mechanism. Submissions often describe how application updates ship but say nothing about how a new base image gets rebuilt, signed, and pushed when a glibc or openssl CVE drops.

How Blue Goat Cyber tests containerized medical devices

For sponsors shipping containerized SaMD, edge inference, or gateway appliances, our engagement typically covers:

• Image SBOM generation and reconciliation against the vendor build
• SCA and VEX triage with clinical-impact framing
• CIS Docker Benchmark and runtime-policy review
• Secrets scanning across image layers and build context
• DAST against the running service in a representative deployment
• Penetration testing scoped to container escape, registry, orchestrator, and supply-chain paths
• eSTAR attachment package assembly across Slots 3, 4, 5, 6, 7, and 8

The deliverable is the evidence reviewers expect to see, in the format the 2026 guidance expects to see it.

FAQ

Does the FDA require containers to be tested differently from monolithic firmware? No, the testing categories are the same (SBOM, controls, vulnerability, DAST, pen test, anomalies). The difference is scope: containers add attack paths (escape, registry, orchestrator) that monolithic firmware does not have, and reviewers expect those paths to appear in the threat model and the pen-test report.

If we use a vendor base image like python:3.12-slim or nvidia/cuda, do we need to SBOM it ourselves? You are responsible for the SBOM of the image you ship. A vendor SBOM for the base image is acceptable if it is conformant (CycloneDX 1.5+ or SPDX 2.3+ with NTIA minimum elements) and represents the exact digest you pulled. Most public registry images do not ship a conformant SBOM, so you regenerate one.

Is Kubernetes in scope for the cybersecurity submission? If the orchestrator ships as part of the cleared device (for example, k3s on a hospital-deployed appliance), yes. If the orchestrator is part of the customer hospital's IT environment, it is generally out of scope but you still address the interface in the threat model.

Does the FDA require image signing (Cosign, Notary)? The guidance does not name a specific signing scheme, but it does require evidence of integrity controls on software shipped to the device. Signed images with verified pulls is the standard way to demonstrate this for containerized components.

How do containers affect the patch mechanism under Section 524B(b)(1)? The mechanism must cover base-image CVE drift, not only application updates. Reviewers want to see how a new base image gets rebuilt, signed, pushed, and rolled out (and rolled back) without disrupting clinical use.

What about WebAssembly, OCI artifacts, or unikernels? The same logic applies. If it ships in the device and contains software components, it needs an SBOM, controls evidence, testing, and an unresolved-anomalies treatment. The 2026 guidance is technology-neutral.