Docker Containers in Medical Devices: FDA Testing

Published June 11, 2026

Why container testing matters for FDA cybersecurity

Container-based medical devices look modern to your engineering team and untested to a reviewer. The FDA's Cybersecurity in Medical Devices final guidance dated February 3, 2026 requires that every third-party component in a cyber device, including base images, language runtimes, and OS packages inside a container, appear in your SBOM with a VEX statement for any known CVE. Reviewers also expect the container runtime (Docker, containerd, Podman, Kubernetes) to be part of the threat model, not assumed-safe infrastructure. NIST SP 800-190 is the reference reviewers cite back in deficiency letters, and CIS Docker Benchmark v1.6.0 is the configuration baseline they expect you to test against. The Sysdig 2024 Cloud-Native Security and Usage Report found 87 percent of container images in production carried at least one high or critical vulnerability, exactly the kind of statistic that turns "containers are isolated" into a Section 524B(b)(2)(iii) deficiency. Container evidence belongs in your premarket submission, not your engineering wiki.

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

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

See also: FDA SIR Cybersecurity Response: eSTAR Prep Guide, FDA Section 524B Subsections Explained, and SBOM for Third-Party Chip Firmware.

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 use 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:

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.

Need help? Our team supports manufacturers with FDA cybersecurity submissions end-to-end. Explore our medical device cybersecurity services or book a discovery call.

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.

To see how we test for these weaknesses on real hardware, see our medical device penetration testing service.

FAQ

Does the FDA require containers to be tested differently from monolithic firmware?

If we use a vendor base image like `python:3.12-slim` or `nvidia/cuda`, do we need to SBOM it ourselves?

Is Kubernetes in scope for the cybersecurity submission?

Does the FDA require image signing (Cosign, Notary)?

How do containers affect the patch mechanism under Section 524B(b)(1)?

What about WebAssembly, OCI artifacts, or unikernels?