How do I install dependencies into python hardened images?

[catmanjan]

I have an image based on the hardened python images

I have the standard 2 stages, build and runtime

I have a runtime dependency on ffmpeg, whats the proper way to get it into my runtime layer?

[encodebot]

I have an image based on the hardened python images

I have the standard 2 stages, build and runtime

I have a runtime dependency on ffmpeg, whats the proper way to get it into my runtime layer?

The exact "proper" approach depends on what you mean by "hardened Python image":

Debian/Ubuntu-based hardened image with apt available → install FFmpeg in the runtime stage.
Distroless runtime → use a static FFmpeg build or copy FFmpeg plus all shared libraries.
Chainguard/Wolfi → install via Wolfi packages or use a Chainguard image that already contains FFmpeg-compatible libraries.

Which hardened base image are you using? (Distroless, Chainguard Python, Docker Hardened Images, Red Hat UBI, etc.) That determines the recommended pattern.

[encodebot]

I’m using the dockerhub hardened image presumably maintained by the python foundation

For your setup:
Install ffmpeg in the runtime stage via apt-get install --no-install-recommends ffmpeg and clean up apt lists.
If Possible share the exact FROM ... line to confirm whether the image is Debian slim or a distroless/hardened variant, so appropriate suggestions can be made instead of assuming.

[catmanjan]

FROM dhi.io/python:3.12

so you’re meant to just copy libs from base to runtime?

[encodebot]

FROM dhi.io/python:3.12

so you’re meant to just copy libs from base to runtime?

Yes, pretty much.

The DHI model is intentionally:

• dev image = shell, package manager, build tools.
• runtime image = only the stuff needed to run Python, no package manager, minimal filesystem.

So you can Install ffmpeg in the 3.12-dev stage and copy the required binaries/libs into runtime.

One thing you should know before you do that for DHI, copying random binaries and libraries from a Debian image isn't ideal. The safest approach is to use a dhi.io/python:3.12-dev stage so the build and runtime stages share the same base OS, libc version, library layout, etc.
If Possibel avoid copeying the entire /usr/lib/x86_64-linux-gnu directory unless you're in a hurry. It works, but it tends to drag hundreds of megabytes of unrelated libraries into the final image.
A proper approach will be like that..
ldd /usr/bin/ffmpeg
ldd /usr/bin/ffprobe

In the build stage and copy only the libraries listed. Many teams automate this with a small script that gathers the transitive dependencies and copies them into a staging directory before the final COPY --from.

Out of topic, are you actually invoking the ffmpeg CLI from Python (e.g. via subprocess, moviepy, pydub, etc.), or are you using a Python binding such as PyAV? That affects the best packaging strategy.

[catmanjan]

Ok thanks, it seems weird to me but ok… for example if I run trivy on my container it won’t detect cves in usr/bin so I get green tick from operations… but the cves are in there, they just weren’t captured in the final image cache… i guess Thats more of a trivy issue

[encodebot]

Ok thanks, it seems weird to me but ok… for example if I run trivy on my container it won’t detect cves in usr/bin so I get green tick from operations… but the cves are in there, they just weren’t captured in the final image cache… i guess Thats more of a trivy issue

I know its a bit weird, but You're not imagining it—this is a real concern and it's not just a Trivy issue. When you install packages via a package manager, scanners like Trivy can usually identify Package name, Source repository, Associated CVEs etec because they're reading package metadata (dpkg, apk, RPM databases, SBOMs, etc.). When you copy binaries and libraries between stages, like for example..
COPY --from=build /usr/bin/ffmpeg /usr/bin/
COPY --from=build /usr/lib/... /usr/lib/...
you've effectively detached those files from their package metadata.Operations may see a green dashboard, but that doesn't mean the ffmpeg build is actually free of CVEs. A good approach can be like this

1. Generate an SBOM during the build stage.
2. Carrey the SBOM into the final image or publish it alongside the image.
3. Scan the SBOM rather than relying solely on package metadata in the runtime imaege.
   Tools like Trivy, Syft & Grype are increasingly moving into this direction.
   For example so you can understand what I mean
   syft myimage:latest -o spdx-json > sbom.json
   trivy sbom sbom.json
   That gives the scanner a much better chance of understanding what's actually present.

[LaurentGoderre]

Just an FYI, this repo is for the Docker Official Image version of Python, not the hardened one. Issues for hardened images are tracked in the following repo: https://github.com/docker-hardened-images/catalog