A security ticket is ready for a sprint when it names the affected asset, the risk, a proposed fix path, an owner, and how success will be verified. If any of those is missing, the team spends the sprint asking questions instead of closing the issue.
Why security tickets bounce
Security findings often arrive from a scanner, a report or an email. They are written for a security reader, not an engineer who must act. The engineer opens the ticket, cannot tell which service it affects, and sends it back. The ticket then ages while both sides wait.
The Scrum Guide says refinement is the act of breaking down and further defining backlog items into smaller, more precise ones, adding details such as description, order and size, and that the developers who will do the work are responsible for the sizing. A readiness checklist is simply refinement made repeatable for security.
The checklist
Copy this into the ticket template.
| Field | What good looks like |
|---|---|
| Asset | Service, repository, environment and version, not just a package name |
| Risk | What an attacker could do, in one or two sentences |
| Evidence | Link to the finding, advisory or report; whether it is reachable |
| Exposure | Internet facing, internal, or isolated |
| Fix path | Upgrade version, config change or code change, with a link if known |
| Owner | One named person or team, who has agreed to it |
| Verification | How we will know it is fixed: a test, a rescan, or a check |
| Due date | From the service level that applies to this asset |
| Dependencies | Other teams or releases that must move first |
If a field cannot be filled, the ticket is a refinement task, not a sprint task. Mark it so.
Who fills what
Security fills asset, risk, evidence and exposure. The owning engineer confirms the fix path and sizes the work. The product owner or manager confirms priority and date. Splitting it this way keeps security from guessing code details and keeps engineers from rewriting risk statements.
For who should own the fix in the first place, see who should fix a vulnerability, the developer or the security team.
A good ticket, shortened
- Title: Upgrade the file upload library in the billing API to a patched version.
- Asset: billing-api, production, current version in the lockfile.
- Risk: A crafted upload could let an attacker read files on the server.
- Evidence: Advisory linked. The upload route calls the affected function.
- Fix path: Move to the first patched version. Check callers of the changed parser.
- Owner: Payments team.
- Verification: Existing upload tests pass, plus one new test with a malformed file. Rescan shows the finding closed.
Notice that nothing here needs a meeting.
Keep the bar proportionate
Do not demand a full memo for a one line version bump. For routine low risk fixes, a shorter form is fine: asset, version, owner. Use the full checklist for items that need design work. Also resist turning the checklist into a gate that blocks urgent work. An emergency fix can start with a partial ticket as long as the gaps are filled before it closes.
Safeguard's findings include the affected component, a fix version where one exists and reachability evidence, which covers several of these fields automatically. Its fix pull requests, off by default, can attach the change to the ticket as a reviewable diff.
Quick check
Who decides a ticket is ready?
The engineers who will do the work, in refinement. Security can propose it, but the team confirms it has enough detail to act on.
What if the fix path is unknown?
Create a time-boxed spike to find it, as described in the spike story guide, and schedule the fix only after the spike reports.
Sources
Last reviewed: 19 October 2026.
