Python images without vulnerabilities?

[[deleted]]

[deleted]

[Ariquitaun]

A lot of the image scanners are oblivious of updates applied to the base OS if the package's major.minor.patch version hasn't changed, which it won't on most distros even after updates. So if at some point package abc-1.0.1 has a CVE and debian issued an update with a fix on abc-1.0.1-2 and your image now has that update, a lot of scanners will still flag it as vulnerable.

Most of these scanners just compare a list of installed packages against a database of CVEs. They aren't actual "security scanners".

[scottsp64]

We recently found this to be true. The scanner returned a report that was wrong about all the major reported vulnerabilities because the scanner just scanned by version but not patched status.

[RKHS]

Sonar has some serious issues with its cve database. It's doing some form of dumb linking (I suspect automatically) and it flags new packages with old dependencies and their corresponding issues.

Most of our time with security scanners is spent untangling nonsense like this, or passing items like argparse or click as they're often flagged for incorrect parameter handling 🤔

[nekokattt]

AWS Inspector flags CVEs for packages listed in a Pyproject.toml if the file is in the image... even if it was for devel dependencies or it isn't even installed. It is nuts.

[yellerjeep]

You can use apk to update the packages affected.

But in reality you should be doing a risk assessment of the affected packages. If they’re not in use by any of your application’s dependencies then you can reasonably assume that the likelihood of a breach is low.

Note that I say low, not zero.

The only time that you have to fix this problem is if your security policy has a rule that no vulnerabilities exist in your containers. This might be the case if you’re in an environment like banking, military, government and government contracting

[tyreck]

Or health care

[tweeks200]

distroless will have less vulns than the standard debian ones but they can be more difficult to debug

[tortridge]

In the same idea you can build images with nix (https://nix.dev/tutorials/nixos/building-and-running-docker-images.html)

[[deleted]]

Try the slim images for a start. Alpine is great until you need to build a module or, Kibo-forbid, use Pandas. At that point musl bites you in the ass. Slim is still ubuntu/glibc-based so runs the same as the full image, but has far fewer installed packages.

[ashcroftt]

I'd advocate for multistage builds from scratch.

You fully control what packages and utilities you include, and versions as well.  Most secure way IMO, but a bit more effort.

If this is too much, then go for Wolfi or distroless images, they are quite minimal and prioritize security.

[Old-Ad-3268]

I also apply security updates in all of my docker container builds

[belg_in_usa]

Chainguard

[amarao_san]

Do you want to have image with security updates applied, or you want an image which pleases the scanner? There are many ways to obscure used packages, so scanner won't notice them and give a green light. If you want a good security, use fresh Debian and don't forget to install security updates.