A patch corrects a known flaw or defect in software, replacing the vulnerable behavior with a vendor supplied fix after release.
It is the change itself, a package or an update, and not the organizational process that decides when every system will receive it.
How it works
Vendors ship a patch after they understand a flaw, and the notes should say which versions are affected and whether a restart is required.
Until the running system actually has the new code, the flaw remains, even if the patch file is sitting in a download folder.
Some patches close a security hole, and others only fix a crash or a feature, so the security ones need a faster path than cosmetic updates.
Knowing what a single patch changes helps a later program schedule it, which is why the patch and the management of patches are different pages.
Concrete examples
- A browser update replaces a library function that allowed a malicious page to escape the sandbox, and the old function is gone after restart.
- A network appliance stays vulnerable because the image was downloaded but never activated on the standby unit.
- A small library patch is easy to miss because the application embeds its own copy instead of using the system package.
Protective measures
- Read the vendor note far enough to learn the affected versions, the severity, and whether a workaround exists until you can apply the change.
- Confirm the running version after installation, not only that the installer reported success.
- Prefer the vendor fix over a long lived workaround, and remove the workaround when the fix is truly in place.
- Treat a security patch as urgent relative to cosmetic updates, and record the system that still lacks it.