Most patching mistakes start with a belief that holds for one layer and fails for the other. The short version: OS updates do not fix your libraries, automatic does not mean running, and delay compounds risk. Here are five myths, each with the fact and a better move.
Myth 1: Patching the OS patches everything
Fact. OS updates cover packages from the system repositories. Libraries installed through npm, pip, Maven or similar sit in the project or image and need their own update. See does patching the OS fix vulnerable app dependencies.
Do instead. Scan both layers.
Myth 2: Automatic updates mean we are protected
Fact. Ubuntu's automatic updates install security updates, but automatic reboot is off by default, so some fixes may not be running yet. Third party sources are excluded unless you add them.
Do instead. Decide the restart policy and list your extra repositories.
Myth 3: Delaying routine patches is harmless
Fact. NIST SP 800-40 Rev. 4 says routine patching is often postponed and neglected, which gives attackers many additional windows, and that delay makes emergency patching harder because earlier patches may be prerequisites.
Do instead. Allow flexibility, then force installation after a grace period.
Myth 4: A lockfile keeps us safe
Fact. A lockfile makes installs repeatable. npm describes it as recording the exact tree so later installs recreate it even after dependencies publish new versions. That also freezes a vulnerable version until you update it.
Do instead. Commit the lockfile and keep an update flow running.
Myth 5: Emergency patching means skipping testing
Fact. NIST suggests the same general approach as routine patching on a highly accelerated schedule, with a quick canary stage that could last minutes to hours to confirm the patch is not corrupted and does not break the software.
Do instead. Keep a minimum test, make it fast.
Summary table
| Belief | Reality | Better move |
|---|---|---|
| OS patch covers libraries | It does not | Scan both layers |
| Automatic equals done | Restart and third party gaps | Define restart policy |
| Delay is harmless | It compounds risk | Grace period with enforcement |
| Lockfile equals safety | It pins versions | Pair it with updates |
| Emergency skips testing | Testing shrinks, not vanishes | Fast canary |
A caution on certainty
Vendor behavior changes. Treat the facts above as true on the date below and check current documentation before you encode them in policy.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, asset discovery and reachability analysis help test these beliefs against what your own estate actually runs. Related: patch everything immediately: myth vs fact.
Quick check
Which myth is most costly?
Usually the first. Teams with a clean host report assume the application layer is clean too.
Is delaying ever right?
Short, tracked delays for testing are normal. Open ended delays with no owner are the problem.
Sources
- NIST SP 800-40 Rev. 4 full text
- Ubuntu Server documentation: automatic updates
- npm documentation: package-lock.json
Last reviewed: 19 October 2026.
