Infrastructure or IT operations usually owns operating system patches, and the engineering team that ships the application owns its dependencies. The split follows who can change the thing: ops controls the host and base image, developers control the manifest and lockfile. Write it down, because gaps appear at the seams.
Why the split exists
An operating system patch arrives through a vendor repository, touches a shared host, and often needs a restart. A dependency patch arrives as a new version of a library, touches one application, and needs a rebuild and a deploy. Different change paths mean different owners.
NIST SP 800-40 Rev. 4 treats patching as preventive maintenance and suggests grouping assets with similar characteristics into maintenance groups, each with its own plan. It does not prescribe which department owns which group. That part is your call, so make it explicit.
A simple ownership table
| Layer | What changes | Usual owner | Change vehicle |
|---|---|---|---|
| Host OS and kernel | Vendor security updates | Infrastructure or IT ops | Package manager, update service |
| Container base image | Base image tag or digest | Platform team | Image rebuild |
| Language runtime | Runtime minor version | Platform or service team | Image or build change |
| Application dependencies | Library versions | Service team | Pull request to manifest and lockfile |
| Build and CI tooling | Actions, plugins, scanners | Platform or DevEx | Pipeline change |
Treat the table as a starting draft. Small teams often have one group doing every row, and that is fine as long as each row has a name next to it.
Where the gaps appear
Three seams cause most missed patches.
- The base image. Ops assumes developers rebuild it. Developers assume ops patched it. Neither rebuilds, and the image keeps old packages. Pick one owner and a rebuild trigger.
- The runtime. A language runtime is neither host nor library. Assign it on purpose.
- Vendored or bundled copies. A library copied into the repo is invisible to the OS patch process and to most update bots. The service team owns it.
How to write the agreement
Keep it to one page.
- List every layer in the table above for your environment.
- Name one accountable team per layer and one backup.
- State the trigger for each layer: a monthly cycle, an advisory, or an alert.
- State the handoff: who tells whom when a layer needs a rebuild or restart.
- Record exceptions in one register, with an owner and a review date. NIST suggests tracking exceptions closely and reviewing them regularly.
Review the page when a team reorganises. Ownership drifts quietly after reorgs.
Where Safeguard fits
Safeguard's asset discovery and SBOM and dependency scanning show which services carry which components, so each finding can be routed to the layer owner instead of a shared queue. You can try a free scan at gold.safeguard.sh/scan. Related reading: shared responsibility model: who patches what and patch maintenance groups explained.
Quick check
Can one team own both OS and dependency patching?
Yes. Small teams often do. The ownership table still helps, because it forces you to name the base image and runtime rows that otherwise fall through.
Who owns a vulnerable library inside a vendor appliance?
The vendor ships the fix, and you own applying it and tracking it. If no fix exists, record an exception and consider isolation, as NIST describes for unpatchable assets.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- NIST SP 800-40 Rev. 4 full text
Last reviewed: 19 October 2026.
