Write one ticket per owning team and component, and put the deployments in a checklist inside it. One ticket per host buries the team; one ticket for everything has no owner. The checklist lets the team close the ticket only when every listed deployment is verified fixed.
Why the shape matters
A flaw in a shared component can touch dozens of deployments. If each becomes a ticket, the owning team sees a flood and closes them without reading. If it becomes one organisation wide ticket, no one owns it. The middle path matches how work actually happens: a team rebuilds a service once, then rolls it out to every place it runs.
The template
Title: Component and version, fix target, service name.
Summary: One sentence on what is wrong and why it matters for this service.
Fix: The target version and how to get it, such as the dependency bump or the base image to rebuild on.
Priority and due date: From your policy, with the reason, for example internet exposure.
Deployments checklist:
| Environment | Account or site | Artifact digest | Status |
|---|---|---|---|
| production | account A | the digest | to do |
| production | on premises site | the digest | to do |
| staging | account B | the digest | to do |
Owner and contact route: Team name and channel.
Evidence needed to close: A rescan result or a deployed version check per row.
Rules for closing
- Close on evidence. A rescan showing the component at the fixed version, per deployment.
- No silent partial close. If one site cannot move, split it into an exception with a review date.
- Link, do not copy. Link the advisory instead of pasting long text that goes stale.
- Record the dates. Opened, fix merged, last deployment verified. These feed your remediation metrics.
Who opens it
Automation should open tickets from grouped findings so humans do not copy lists. Keep an escape hatch for manual edits. If the finding comes from a known exploited list, say so in the title, since CISA describes that catalog as an input to prioritisation and the team will want to know.
Link to the upstream
If the fix is a platform change, open a parent ticket for the platform team and link service tickets under it. That gives leadership one line to track.
An example title and summary
Title: libxyz 1.2.3 fixed in 1.2.5, checkout-api. Summary: a flaw in the libxyz request parser lets crafted input crash the service, and this service parses untrusted input on a public route. Fix: bump to 1.2.5 and rebuild. Due: per the production internet exposed tier. Short, specific and checkable beats a pasted advisory.
Quick check
Should every environment have its own priority?
Yes, if exposure differs. Put the priority in the checklist row or use separate tickets when the owners differ.
What if the fix needs a code change?
Keep the same ticket and link the pull request. The deployment checklist still tracks the rollout.
Safeguard can raise fix pull requests that stay off until you turn them on, and findings can be grouped by component for this kind of ticket. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
