Every new service inherits the template's old dependencies and base image on day one. The fix is to treat the template as a living service: update its own dependencies on a schedule, rebuild it in CI, and scan the output.
How template rot happens
A team builds the template, ships it, and moves on. Months later the language runtime has a new patch, the base image has been replaced, and a few libraries have disclosed vulnerabilities. Nothing in the template repository complains, because nobody runs it. New services copy the stale pieces, and the platform team has effectively seeded fresh debt.
Docker's build guidance explains one mechanism: if you pin a base image to a digest, you opt out of automated security fixes unless you add something that refreshes the pin. A template that pins once and never refreshes is the clearest case.
Symptoms to look for
| Symptom | What it suggests |
|---|---|
| New services fail the scan on their first pull request | Template ships known vulnerable versions |
| Several services share the same old version | They all copied the same stale default |
| Developers update the same file the same way after creating a repo | The template is behind and people patch it by hand |
| Template repository has no recent commits | Nobody owns it |
The second symptom is the most useful. Search your inventory for versions that appear in many services created in a short window. A shared outlier usually points to the template.
Keep it current
- Give the template repository the same update automation you ask of others, so its own dependencies and base image get update pull requests.
- Run a scheduled CI job that generates a sample service and scans it. See how to test a golden path template before release.
- Fail the job when the scan finds anything above your threshold.
- Assign an owner and a response time for template failures, shorter than for ordinary services because the impact spreads.
- Publish a changelog so teams know what changed and when.
What about services already created
A fix in the template does not change repositories that already exist. Use your inventory to find services still carrying the old version and send them the same bulk pull request. The wave approach in moving existing services onto a golden path works here too, in a smaller form.
Prevent the recurrence
- Pin versions in the template, but pair every pin with automated refresh.
- Keep the number of template dependencies small. Fewer pieces means less rot.
- Record the date of the last review inside the template README.
- Include the template in your vulnerability response drills. When a widely used library has a serious issue, the template is on the checklist.
Where Safeguard fits
Safeguard keeps an inventory of the components in your services through SBOM and dependency scanning, so you can see which services share a stale version, and it monitors them continuously for new advisories. Fix PRs are available (off by default, every category on Manual). Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and find a finding with a fix available, then picture that same fix being applied to the template once instead of to fifty repos.
Click through it at your own pace, or open it full screen.
Quick check
Does fixing the template fix existing services?
No. Existing repositories keep what they copied. They need a separate update.
How often should the template be rebuilt?
On a schedule, for example weekly, plus on every change. Pick a cadence you will actually keep.
Sources
Last reviewed: 19 October 2026.
