A good DAST ticket tells a developer what request to send, what they should see, what they actually see, why it matters, and how to confirm the fix. Anything less becomes a thread of questions. Use a template and fill every field.
Why raw findings get ignored
A scanner export says "Cross Site Scripting (Reflected), medium, 14 instances". A developer must work out where, how to reproduce it, and whether it is real. That takes an hour, so the ticket waits. The fix is not more pressure but a better ticket.
The template
| Field | What to write |
|---|---|
| Title | Plain statement: "Search page reflects the q parameter without encoding" |
| Where | Environment, URL path, HTTP method and parameter |
| How to reproduce | The exact request, a curl command or browser steps, with test account |
| Expected | What a safe response looks like |
| Actual | What came back, quoting the relevant snippet |
| Impact | What an attacker could do, in one or two sentences |
| Likely cause | The code area or pattern, if known |
| Suggested fix | The standard remedy for this class of flaw |
| Severity and basis | The scanner rating, and your adjustment with reasons |
| Retest | How to confirm the fix, and who will do it |
| Links | Scan record, related tickets |
Steps to write one
- Reproduce first. Run the request by hand. If you cannot reproduce it, say so, or do not file it yet.
- Trim to one issue. One ticket per root cause. If fourteen pages share one missing encoding function, file one ticket and list the pages.
- Write the evidence. Paste the request and the revealing part of the response. Remove secrets and personal data.
- State the impact plainly. "A visitor who clicks a crafted link runs script in the page" is clearer than a scoring label.
- Suggest the usual fix. Name the class of remedy, such as output encoding or parameterized queries, and point to a standard reference.
- Add a retest step. "Resend the request, expect an encoded value" saves a round trip.
- Assign an owner and a due date from your remediation policy.
An example title and body
Title: Order lookup returns another customer's order when the ID is changed.
Where: staging, GET on the order detail path, parameter id.
Reproduce: log in as test user A, request the order detail for an order ID owned by test user B.
Expected: a 403 or 404 response.
Actual: a 200 response with user B's order details.
Impact: any logged-in user can read other customers' orders.
Retest: repeat the request as user A, expect a 403.
Handle false positives with care
If you decide a finding is a false positive, close it with the reason, such as "the value is encoded in the response, see the attached screenshot". Add a scanner filter only if the same noise keeps returning. Record the decision so the next person does not repeat the investigation.
Common mistakes
- Pasting the scanner's generic description as the whole ticket.
- Filing one ticket per instance of the same root cause.
- Including real customer data in the evidence.
- Closing without a retest.
A worked example, from raw alert to useful ticket
The scanner output reads: "Cross Site Scripting (Reflected), Medium, 14 instances, URLs listed". Here is how it becomes one ticket.
- Reproduce. A security engineer opens the first URL, sends the flagged parameter with a harmless marker string, and sees it echoed unencoded inside a page heading.
- Find the root cause. All 14 URLs are search and filter pages that use the same template helper, so one fix covers them all.
- Write one ticket.
Title: Search and filter pages echo the query parameter without output encoding.
Where: staging, GET on the search path and filter paths, parameter q.
Reproduce: log in as a standard test user, open the search path with q set to a harmless marker, view the page source and find the marker unencoded in the heading.
Expected: special characters encoded in the response.
Actual: characters appear unencoded.
Impact: a visitor who follows a crafted link could run script in the page, with the permissions of that visitor.
Likely cause: the shared heading helper in the search template.
Suggested fix: encode output in the helper for the HTML context, then add a regression test.
Retest: resend the request, expect encoded characters. Retest by the security engineer after the fix is deployed to staging.
Links: scan record, list of the 14 URLs.
- Set priority. The team's remediation policy sets due dates by severity and exposure. This page is behind login, so the priority is medium.
Why one ticket beats fourteen
| Approach | Developer experience | Result |
|---|---|---|
| Fourteen tickets, one per URL | Duplicated effort, confusion about which to fix | Slow, partial fixes |
| One ticket with all URLs | One root cause, one fix, one test | Fast and complete |
| One export attached to a general ticket | No clear owner | Ignored |
Severity wording
Scanner severity is a starting point. Adjust it with the facts you have: is the page public, does it need login, does it handle sensitive data, is it protected by other controls. Write both the scanner rating and your adjusted rating, with the reason. That keeps trust high when ratings differ.
Evidence hygiene
Remove secrets, session tokens and personal data from request and response samples before pasting them. Use test accounts. Store large evidence files in a restricted location and link to them rather than attaching them to a widely visible ticket.
Closing the loop
Close a ticket only after a retest. The retest result goes into the ticket and the scan record. If the finding returns in a later scan, reopen the original ticket rather than starting a new one, so the history stays in one place.
Metrics worth tracking
Track time from detection to fix, the share of tickets reopened and the share closed as false positives. A high false positive share suggests tuning the policy. A high reopen share suggests fixes treat symptoms and not causes.
Where Safeguard fits
Ticket quality is a process matter. For dependency findings, Safeguard offers SBOM and dependency scanning with reachability analysis, which helps you decide which findings deserve a ticket, and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how findings are tracked from detection to closure and relate it to the steps above.
Quick check
Should I file one ticket per scanner instance?
No. Group instances that share a root cause into one ticket and list the locations.
What if I cannot reproduce a finding?
Say so in a note and do not assign it as a confirmed bug until you can.
Who should do the retest after a fix?
Whoever can run the original request reliably, usually the security engineer or QA. Record the result in the ticket before closing it.
Last reviewed: 19 October 2026.
