Third-party repository risk · Linux

Third-party repositories are how production hosts get software that is not in the base distribution — Docker, NodeSource, Elasticsearch, Kubernetes. They are also one of the most common attack vectors: a compromised or malicious repository pushes backdoored packages to every host that trusts it.

The risk

A third-party repository has access to every host that trusts it. The compromises are well-documented:

Compromised legitimate repository — the repository’s signing key or build infrastructure is breached.
Malicious actor disguised as legitimate — fake repositories mimicking popular projects.
Supply-chain compromise — a package maintainer’s account is compromised, allowing a backdoored version to be pushed.

Read-only / Safethird-party repo— The Docker package is available from download.docker.com, not from the Ubuntu archive. The priority (500) is the default; the URL is the source. If the docker.com signing key is compromised, every host that trusts this repository installs compromised packages.

$ apt-cache policy 'docker*' | head; dnf repolist

docker-ce:
Installed: (none)
Candidate: 5:26.1.3-1
Version table:
5:26.1.3-1 500
500 https://download.docker.com/linux/ubuntu noble/stable amd64 Packages
docker-ce-cli:
...

Illustrative output

Why Docker is the textbook example

Docker, Kubernetes, NodeSource, and similar third-party projects ship their own APT/YUM repositories. Production hosts commonly add them. The compromise scenarios:

A Docker maintainer’s account is phished; a backdoored docker-ce package is pushed.
The download.docker.com infrastructure is compromised; the repository index is replaced.
The signing key is rotated or compromised; packages cannot be verified.

Every host that adds the Docker repository is potentially affected. The discipline: rank the third-party repository below the base distribution, scope its packages to only what you need, and audit regularly.

Be careful here — apt and dnf express “below” with opposite numbers. In apt a higher Pin-Priority wins (default 500), so a third-party repo is demoted with a lower number. In dnf the lowest priority value wins (default 99), so a third-party repo is demoted with a higher number. Carrying the apt mental model into a .repo file is the single most common way to hand a vendor precedence over the OS.

Scoping with apt preferences

Configuration changepin third-party— Pin docker packages to priority 50 (lower than the default 500). In apt the HIGHEST Pin-Priority wins, so 50 demotes these packages below the archive. They are still installable but only if no higher-priority candidate provides them. This keeps the base distribution's versions in preference and uses Docker's only when explicitly installed.

$ sudo tee /etc/apt/preferences.d/docker-pin.pref >/dev/null <<'EOF'
Package: docker-ce
Pin: origin download.docker.com
Pin-Priority: 50

Package: docker-ce-cli
Pin: origin download.docker.com
Pin-Priority: 50

Package: containerd.io
Pin: origin download.docker.com
Pin-Priority: 50
EOF
sudo apt update

...

Illustrative output

Confirm the result rather than assuming it:

Read-only / Safeverify apt pin— The number in front of the repository URL is the effective priority after preferences.d is applied. 50 confirms the pin took effect. A Candidate of (none) is expected: at priority below 100 apt will not select the version automatically, so it installs only when you name the version explicitly.

$ apt-cache policy containerd.io

containerd.io:
Installed: (none)
Candidate: (none)
Version table:
1.7.27-1 50
50 https://download.docker.com/linux/ubuntu noble/stable amd64 Packages

Illustrative output

Scoping with dnf

Read-only / Safepriority field— dnf repositories support a priority field in the .repo file. The LOWEST value wins, and the default for every repository — including BaseOS and AppStream — is 99. priority=200 therefore ranks Docker BELOW the base distribution. Writing priority=50 here does the opposite of what it looks like: it makes download.docker.com outrank the OS repos for every package it also ships.

$ cat /etc/yum.repos.d/docker-ce.repo

[docker-ce-stable]
name=Docker CE Stable - $basearch
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
priority=200

Illustrative output

priority=50 on a .repo file promotes the vendor, it does not demote them

man 5 dnf.conf defines priority as: if more than one candidate package exists for an operation, the one from the repository with the lowest priority value is picked. Every repository defaults to 99.

So priority=50 on docker-ce.repo puts Docker ahead of BaseOS and AppStream. Docker ships containerd.io and has historically shipped its own runc and library builds; NodeSource and Elastic ship their own OpenSSL-linked binaries. With priority=50 a dnf upgrade --security quietly prefers the vendor build over the RHSA-patched distribution package — which is precisely the supply-chain exposure the pin was meant to close.

To demote a repository, give it a value above 99. Then confirm the effective value rather than trusting the file:

Read-only / Safeverify dnf priority— config-manager --dump prints the effective configuration after all .repo files and dnf.conf defaults are merged, which is what actually decides package selection. Compare it with the OS repos: dnf config-manager --dump baseos should show priority = 99. The third-party number must be the larger one. On RHEL 8/9 the priority key is native to libdnf and needs no separate plugin.

$ dnf config-manager --dump docker-ce-stable | grep -E '^(name|priority|enabled|gpgcheck)'

enabled = 1
gpgcheck = 1
name = Docker CE Stable - x86_64
priority = 200

Illustrative output

Auditing the trust store

The audit has to be format-agnostic. Since Ubuntu 24.04 the default is the deb822 .sources format in /etc/apt/sources.list.d/, not the one-line .list format, so any sweep that globs *.list reports zero repositories on a current host — while Docker and NodeSource sit there configured. A glob with no directory prefix is worse still: it matches against the current working directory, not the repository directory.

Read-only / Safeaudit repos (both formats)— One sweep that catches both the legacy one-line deb entries and the deb822 Types/URIs/Signed-By stanzas, across both the file and the directory. Note the Signed-By line: it names the keyring that repository is trusted against, which is what you verify fingerprints from. -r covers the directory; -h drops filename prefixes so the stanzas read cleanly.

$ grep -rhE '^(deb|deb-src) |^(Types|URIs|Suites|Components|Signed-By):' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: noble
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Illustrative output

Read-only / Safeauthoritative repo list— The file sweep tells you what is written down; apt-cache policy and dnf repolist -v tell you what the package manager actually resolved, including effective priorities. Reconcile the two — a repository that appears in one and not the other is either a disabled file or a stale cache. Audit quarterly: remove any repository no longer in use; verify each repository's signing key fingerprint against the vendor's published source.

$ apt-cache policy; ls /etc/yum.repos.d/ && dnf repolist -v

...

Illustrative output

Inventory every third-party repository on each host, in both the one-line and deb822 formats. Remove ones no longer in use
Verify each signing key fingerprint against the vendors published source, using the Signed-By keyring named in the stanza
Demote priorities so the base distribution wins by default — Pin-Priority 50 on apt, priority=200 on dnf
Confirm the effective value with apt-cache policy and dnf config-manager --dump, not by reading the config file
Scope packages — only the specific packages from the third-party repo, not the entire repository
Document the rationale for each repository in the runbook

The risk

Scoping with apt preferences

Scoping with dnf

Auditing the trust store

Knowledge check