Use apt-get and apt-cache in scripts, Dockerfiles and CI. The apt manual notes that the apt command may change behaviour between versions and recommends apt-get and apt-cache for scripts because they try harder to stay backward compatible. Keep plain apt for interactive use.
Why it matters for security work
Patch automation is code. If a script that applies security updates silently changes behaviour after an operating system upgrade, you may stop patching without noticing. Pipeline stability is a security property here.
What the manual says
The apt manual describes apt as a command line tool for people, with commands such as update, upgrade, full-upgrade and list. It states that the tool may change behavior between versions, and that for scripts you should use apt-get and apt-cache.
In practice, you will see the difference in output formatting. Plain apt prints a progress bar and a warning when its output is piped, which is a hint that it does not promise a stable machine readable format.
Quick mapping
| Task | Interactive | Script or CI |
|---|---|---|
| Refresh package lists | apt update | apt-get update |
| Install updates | apt upgrade | apt-get upgrade |
| Install updates, allowing removals | apt full-upgrade | apt-get dist-upgrade |
| Install a package | apt install | apt-get install |
| Show candidate versions | apt policy | apt-cache policy |
| List what can be upgraded | apt list with the upgradable option | apt-get with the simulate option |
The upgrade versus full-upgrade difference is explained in apt upgrade versus full-upgrade.
Make scripts safe to run unattended
Package prompts can hang a pipeline. Set the environment for non interactive runs, pass the assume yes flag, and keep the update and install steps together. Docker's build guidance recommends exactly that combination in a Dockerfile, because a separate cached update step can leave stale lists. See how to run apt-get in a Dockerfile.
export DEBIAN_FRONTEND=noninteractive
apt-get update && apt-get install -y --no-install-recommends package-name
Check what your pipeline would do
Before putting an upgrade step on a schedule, simulate it and read the output:
apt-get -s upgrade
The Debian unattended upgrade tool has a dry run option for the same reason, covered in how to preview security updates before you install them.
Build checks around it
- Fail the pipeline if the upgrade step exits non zero.
- Log which packages changed.
- Scan the result, since a successful upgrade does not prove the image is clean.
- Pin the runner or base image version so tool behaviour changes only when you decide.
A short script review checklist
When you review a patching script or pipeline step, ask five questions.
- Does it use apt-get and apt-cache rather than plain apt?
- Does it run non interactively, so a prompt cannot hang the job?
- Does it fail loudly if the upgrade returns an error?
- Does it record what changed, so you can show it later?
- Does it end with a scan or a restart check, so you know the fix is in effect?
A script that passes all five is easy to defend in an audit and easy to debug at night. One that fails any of them tends to fail quietly.
Quick check
Is apt deprecated?
No. The manual describes it as a tool for interactive use, and says to prefer apt-get and apt-cache in scripts.
Why does this matter for security?
If scripted patching changes behaviour silently, updates can stop applying without an alert.
Safeguard watches for advisories against the packages your builds produce, so a quietly failing update step shows up as an open finding. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
