Cybersecurity Triage
Prove a Package Candidate Is From Security
A package is upgradable and you need to confirm whether the candidate version comes from the security pocket.
Command
apt-cache policy openssl | sed -n '/Installed:/p;/Candidate:/p;/security/p'
What changed
Nothing changes. apt-cache reads local apt metadata and sed extracts the version and security-origin lines.
Danger
safe
When to use it
Use when documenting why a specific package is being patched or when comparing update and security pockets.
When not to use it
Do not use it to install the package; this is only metadata inspection.
Undo or recovery
No undo needed because the command is read-only.
Expected output
Installed and candidate versions plus a security repository line for the candidate.
demo script
Disposable terminal steps
apt-cache policy opensslapt-cache policy openssl | sed -n '/Installed:/p;/Candidate:/p;/security/p'
simulated output
What it looks like
::fixture-ready::
$ apt-cache policy openssl
openssl:
Installed: 3.0.13-0ubuntu3.5
Candidate: 3.0.13-0ubuntu3.6
Version table:
3.0.13-0ubuntu3.6 500
500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
*** 3.0.13-0ubuntu3.5 100
100 /var/lib/dpkg/status
::exit-code::0
$ apt-cache policy openssl | sed -n '/Installed:/p;/Candidate:/p;/security/p'
Installed: 3.0.13-0ubuntu3.5
Candidate: 3.0.13-0ubuntu3.6
500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
::exit-code::0
YouTube Short
Verify the security candidate.
For one package, apt-cache policy shows the installed version, candidate version, and where that candidate comes from.
LinkedIn hook
The package name is not enough; the candidate repository tells the patch story.
Question: When reviewing a security patch, do you prove the candidate origin or just trust the package name?
experiments
A/B tests to run
Metric: copy_rate
A: Prove the candidate origin.
B: Installed vs candidate vs security pocket.