aegis-updates-patching

Scope & Objectives

Assess patch discipline and attack-surface minimization on one Linux server (or its config-as-code repo). Answer, in priority order:

1. Distro identity & lifecycle stage — which release is running, and is it plausibly within vendor support? Flag uncertainty honestly (Needs-Review with the exact release string), never assert an invented EOL date.
2. Reboot debt — does uname -r lag the newest installed kernel package? Installed-but-not-running fixes are dormant.
3. Pending update inventory — how many updates are outstanding, and how many belong to the security pocket / advisory stream.
4. Automation — is an unattended/automated security-update mechanism installed, configured with security origins, and armed (timer active)?
5. Restart honesty — uptime evidence for deferred kernel/libc/systemd restarts; maintenance-window posture.
6. Surface shrinkage — offender services (rpcbind, nfs-common, avahi-daemon, cups, postfix, xinetd, samba) and legacy protocol servers (telnet/rsh/tftp/ftp) in enabled/active/disabled/masked/purged states.
7. Kernel-module hardening option — uncommon filesystem blacklists (present as options with breakage caveats, not unconditional findings).
8. Host-level runtime currency — system python/node/php majors plausibly supported; Needs-Review when uncertain.

Out of scope (other modules): application dependency patching → supply-chain/code module; firewall/exposure rules → FW; sshd/PAM/sysctl baseline → BASE.

Operating rules: