Split ownership by layer. The platform team owns the base image, its contents and its patch cadence. Each app team owns everything it adds on top, and owns the act of rebuilding and redeploying onto a patched base. Findings need a named owner on both sides, or they sit in a shared queue and nobody moves.
Why "everyone" fails
A Dockerfile starts with FROM, and the Docker documentation on base images defines the base as the image your image extends. A finding in an operating system package therefore lives in a layer the app team did not write. Asking them to fix it alone is unrealistic. Asking the platform team to fix every deployed service is just as unrealistic, because only the app team can rebuild, test and ship their service.
So the fix has two halves. Somebody publishes a patched base. Somebody else adopts it. Name both.
A responsibility split
| Task | Platform team | App team |
|---|---|---|
| Choose and publish approved base images | Owns | Consults |
| Rebuild base on a schedule and on critical advisories | Owns | Informed |
| Announce which services are behind the current base | Owns | Informed |
| Add packages in the app layer | Consults | Owns |
| Bump dependencies in application code | Consults | Owns |
| Rebuild and redeploy onto the new base | Informed | Owns |
| Exceptions with expiry | Approves | Requests |
If there is no platform team, one named engineer can own the base for a small company. The point is a name, not an org chart.
Making findings routable
Group scan results by layer so each finding reaches the right queue. For an image built from several layers, record which finding came from the base and which from the application. Then a base finding goes to the platform queue, with a count of affected services, and an application finding goes to the service owner.
Labels help here. A required owner label on every workload turns "which team runs this" into a lookup. See require owner labels.
Agree a clock
Ownership without a deadline is a suggestion. Agree two timers:
- Platform: time from a fix being available upstream to a patched base being published.
- App teams: time from a patched base being published to the service running on it.
Write both down. Measure both. Report them separately, because when the total is slow you want to know which half is slow.
Common failure patterns
- The platform team publishes a patched base and tells no one. Teams keep building on the old tag.
- App teams pin a base digest for repeatability and never move it. Pinning is good, but it needs a refresh process. See keeping pinned digests current.
- Exceptions are granted forever. Give each one an expiry.
Where Safeguard fits
Safeguard attributes findings to images and their packages and supports policies and gates, so a base image finding can be routed to its owner and an exception can carry an expiry. You can start with a free scan.
Quick check
Who fixes a vulnerability in the operating system layer?
The platform team publishes a patched base. The app team rebuilds and redeploys onto it. Both steps need an owner.
What if we have no platform team?
Name one person as base image owner. A named owner with a schedule beats a shared responsibility with none.
Sources
Last reviewed: 19 October 2026.
