Have we reached a point of no return on managing software dependencies?

paolomainardi.com

9 points·signa11··3 comments

> what is way bigger now is the number of packages carried back from the Debian base image (required to use PyTorch instead of Alpine), to be more precise 429 packages with an insane number of known vulnerabilities, even if this image is the latest stable Python 3.11 release.

Most security checking tools are incompatible with how Debian (and Ubuntu) deal with security issues: they backport security fixes to existing packages shipped with their stable distribution releases (so you'd have openfoo-1.4.3-debian4 instead of eg. openfoo-1.5.1, yet it wouldn't be vulnerable even if 1.4.3 upstream was).

While there is a caveat about false positives, I think it's irrelevant in the context of Debian since I trust Debian more than the tool author used.

This is a very interesting point, the vulnerability scan tool used on the article is this one: https://github.com/anchore/grype-db/blob/main/DEVELOPING.md and here you can see how it works: https://anchore.com/blog/build-your-own-grype-database As you can see there is a database specifically designed for Debian to take in charge the naming convention.

Thanks: it's not trivially clear how I could try it out to check if it works well: it seems to use Debian security tracker to note which CVEs have been fixed, so version numbering scheme should not come into play.

I'll try to find some time later to play with it in depth as it seems to be an interesting set of tools!

Reply on news.ycombinator.com