When a shared runtime, base image or library layer is vulnerable, the team that owns it publishes the fixed version, and each consuming service team rebuilds and redeploys to pick it up. Fixing the source does not fix the consumers. Agree that split before an incident, along with a deadline for each side.
Why one fix is really many
Shared components are efficient because many services reuse them. They also concentrate risk. AWS documents that a Lambda layer version is an immutable snapshot, and that when adding a layer to a function you must name the exact layer version. So publishing version 8 of a layer does nothing for functions pinned to version 7.
The same shape appears with base images (services keep the old digest until rebuilt), shared libraries (lock files hold the old version) and internal charts or modules (consumers pin versions).
Who does what
| Step | Owner | Output |
|---|---|---|
| Decide the component is affected | Platform team | Short advisory with affected versions |
| Publish the fixed version | Platform team | New image, layer or library version |
| List the consumers | Platform team with inventory data | List of services and versions |
| Rebuild and redeploy | Each service team | Deployed fixed version |
| Verify closure | Platform team | Report of consumers still on old versions |
The platform team should not edit service repositories without agreement, and service teams should not wait for a ticket they could have predicted. A list of consumers sent on day one avoids both problems.
Make the roll out cheaper
- Keep the consumer list current. If your inventory records which version of each shared component every service uses, the list is a query, not a project.
- Offer an automated update. A bot that opens a pull request bumping the version removes most of the effort. Keep a human review on the merge.
- Set a window. Say how many days service teams have for each severity, and publish it.
- Allow a documented exception. Some services cannot move quickly. Record why, the compensating control and a review date.
- Report openly. A visible list of teams still on old versions does more than reminders.
When the shared piece is a runtime
Language runtimes and system packages follow the same pattern. If the platform ships a patched runtime image, services still need to rebuild on it. If the runtime comes from the hosting provider and updates automatically, check what the provider documents about update modes before relying on it.
Try it yourself
Open the demo and look at how a fix becomes available and what it takes to apply it. Picture each consuming service repeating that step.
Click through it at your own pace, or open it full screen.
Quick check
Can the platform team just patch everything centrally?
Only for components that are injected at deploy time under its control. For anything pinned in a service's own build, the service team must rebuild.
What if a team misses the deadline?
Escalate through the contact route on the service record, and record an exception with a review date if the delay is justified.
Safeguard's autonomous remediation can open fix pull requests, which is off by default with every category set to manual, so teams stay in control of what merges. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
