Who keeps your packages secure?

Distribution packages, Flatpak, the AUR, pip and npm, containers: who tracks vulnerabilities and backports fixes for each, and what that means for your updates.

The work behind a distribution package

When you install a package with apt, dnf or pacman, you get more than the software. Behind every package in a distribution's official repositories there's a maintainer, and usually a team, doing work that's easy to take for granted:

• Choosing the version. Picking a release that's stable and works with everything else in the distribution, rather than whatever upstream released last week.
• Integrating it. Making it follow the system's conventions for files, configuration, users and services, and building it against the same shared libraries as everything else.
• Testing it together. Every package in a release is built and tested alongside the others, so an update to one doesn't quietly break another.
• Tracking its security. Following every vulnerability that affects it, for as long as the release is supported - often five years or more.
• Backporting fixes. Applying just the security fix to the version you already run, so you get the fix without new behavior.

Shared libraries make this especially effective. When OpenSSL or zlib gets a security fix, the distribution updates one package, and every program on the system that uses it is fixed at once.

The alternatives below all have good reasons to exist. What they have in common is that some of this work moves from the distribution to someone else - often to you.

Flatpak and Snap

Flatpak (and Snap, which works similarly) bundles an application with the libraries it needs, so the same build runs on any distribution. Apps run in a sandbox, which limits what a compromised app can reach - a real security benefit.

The shared base, called a runtime, is maintained and updated regularly. But libraries an app bundles on top of the runtime are the app maintainer's responsibility, and there's no distribution security team tracking vulnerabilities in what each app bundles. A fix in a common library reaches each app only when its maintainer rebuilds it. Flatpak apps are also updated with flatpak update, separately from the system's package manager, so they're easy to forget. The flatpak-updates.sh and snap-updates.sh plugins list the pending updates for both.

The AUR

The Arch User Repository is a collection of build scripts contributed by users. It's one of Arch's strengths: almost any software is available, and many packages follow upstream releases quickly, often faster than official repositories would.

But AUR packages aren't reviewed or maintained by Arch, and Arch itself says to use them at your own risk. Whether a package gets updated - and how quickly a security fix arrives - depends entirely on its individual maintainer, and packages can be abandoned. The Arch security tracker doesn't cover them, and there have been cases of malicious packages uploaded to the AUR. Read the build script before installing, and prefer the official repositories for anything important.

Language package managers: pip, npm and friends

Applications often install their dependencies from the language's own package registry - PyPI for Python, npm for JavaScript, crates.io for Rust - into a virtual environment or project folder. That gives each project exactly the versions it needs, independent of the system.

The flip side is that those versions are frozen. A lock file pins every dependency to an exact version, which is great for reproducible builds and means nothing gets updated until someone updates it on purpose. There's no maintainer backporting fixes either: getting a security fix usually means moving to a newer upstream version, with whatever else changed along with it. Tools like pip-audit, npm audit, Dependabot and Renovate can flag known vulnerabilities in your dependencies, but only if you set them up and act on what they find. The pip-audit.sh and npm-audit.sh plugins run these audits on every checkin, so known vulnerabilities in a project's dependencies show up next to the machine's own packages.

Containers

A container image is a snapshot: a distribution's packages plus your application and its dependencies, frozen at the moment the image was built. That's what makes containers predictable - and it's also why they age.

The base images you build on are updated regularly, but a running container doesn't change until you rebuild the image and redeploy it. An image built a year ago still carries the packages it had a year ago, including every vulnerability fixed since. Image scanners can list them, but the fix is always the same: rebuild on a current base image, regularly, not only when something breaks. The container-image-age.sh plugin shows the age of the oldest image a machine is running, as a reminder. And the host underneath still needs its own updates - containers share the host's kernel.

Side by side

Choosing well

A sensible default is to use distribution packages for anything exposed or important - web servers, databases, SSH, the language runtime itself - and reach for the alternatives when you need something the distribution doesn't offer, or a newer version than it ships.

When you do, treat updating it as your job: schedule image rebuilds, turn on dependency auditing, and include those components when you check what's outdated. OS Checker tracks a machine's system packages against its distribution's security data; for everything else, the plugins mentioned above bring it into the same overview - see all ready-made plugins.