Rank DAST findings by confirmed exploitability first, then by exposure, the data at stake, the access an attacker needs and the effort to fix. A scanner severity label is a starting point, not a verdict. A small scoring table keeps the decisions consistent and easy to explain.
Why scanner severity is not enough
A scanner rates a finding by the type of flaw. It does not know that the page is behind a login that only five people hold, or that the same flaw on your public checkout page could expose customer data. Two findings with the same label can deserve very different treatment. The OWASP Web Security Testing Guide makes the same point about testing in general: there are endless ways an application could fail, and teams have limited time, so spend it on issues that present real risk to the business, judged in the context of the application and its use cases.
Definitions
- Confirmed: a person has reproduced the finding by hand.
- Exposure: who can reach the affected page or endpoint, such as the internet, customers, staff or nobody outside a private network.
- Impact: what an attacker gains, such as data, control of an account, or the ability to run code.
- Effort: time and risk to fix.
A scoring table
Give each factor a score from 0 to 3, then add them up. The weights below are a starting point for your team to adjust, not a standard.
| Factor | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| Confirmed | Could not reproduce | Partly | Reproduced with effort | Reproduced easily |
| Exposure | Private network only | Staff only | Logged-in customers | Anyone on the internet |
| Impact | Cosmetic | Minor data or function | Sensitive data or account | Broad data loss or control |
| Access needed | Admin and special setup | Standard login plus effort | Standard login | None |
Sort by total, then adjust by effort. Cheap fixes with a middling score go early, since they remove risk quickly. Expensive fixes with a high score go early too but need planning.
A worked example
A team has five findings after a staging scan. The numbers below are an illustrative example of the method.
| Finding | Confirmed | Exposure | Impact | Access | Total | Effort |
|---|---|---|---|---|---|---|
| Order lookup shows other users' orders | 3 | 2 | 3 | 2 | 10 | Medium |
| Reflected input on public search page | 3 | 3 | 2 | 3 | 11 | Low |
| Verbose error with file paths | 3 | 3 | 1 | 3 | 10 | Low |
| Missing header on admin page | 3 | 1 | 1 | 1 | 6 | Low |
| Possible injection, not reproduced | 1 | 3 | 3 | 3 | 10 | Unknown |
The team's decision follows the table with some judgment.
- The reflected input on the public page goes first. It is cheap and exposed to everyone.
- The order lookup flaw goes next. It scores almost as high, and customer data is involved, so it is scheduled in the same week even though the fix is medium effort.
- The verbose error is a quick fix, so it rides along with item one.
- The admin header waits for the next sprint.
- The possible injection is not dropped. Someone is assigned to try to reproduce it within three days, because an unconfirmed finding with high exposure and impact is a risk until it is ruled out.
Add context from other tools
DAST sees the running app. Other information can change a ranking.
- Dependency findings. If a finding points to a library issue, check whether the vulnerable code is reachable in your app.
- Threat news. If a flaw class is under active exploitation, raise its rank.
- Compensating controls. A WAF or network restriction may reduce exposure today, but treat that as temporary.
- Business events. A launch or a customer audit may raise urgency.
Set time targets by rank
Agree target times in advance, so ranking leads to action. For example, the top band within days, the next band within a month and the rest in the normal backlog. Write down who may approve an exception and for how long. These targets are your own policy, not a rule from this post.
A weekly routine
- Pull new findings from the latest scans.
- Confirm each, or assign someone to confirm within a set time.
- Score and sort.
- Group by root cause, so one fix closes several findings.
- Assign owners and due dates.
- Review overdue items and exceptions.
- Report the numbers: open by band, time to fix, reopened items.
Common mistakes
- Sorting only by the scanner label.
- Treating unconfirmed findings as true or as false without checking.
- Fixing many low items while a high item waits for a perfect solution.
- Accepting risk with no owner or end date.
- Never reviewing the weights, so they drift away from what actually hurts.
Where Safeguard fits
DAST findings describe the running application. For the open source inside it, Safeguard offers SBOM and dependency scanning with reachability analysis, which helps you rank library findings by whether the vulnerable code is actually used, plus 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 listed, prioritized and tracked to closure, and compare it with the scoring table above.
Quick check
Should I fix every medium finding before any low finding?
Not always. A cheap low finding on an exposed page can go ahead of a costly medium one on a private page. Use exposure, impact and effort together.
What do I do with a finding I cannot reproduce?
Assign someone to try for a set time. If it stays unconfirmed, record what was tried and decide whether to keep it open given its exposure and impact.
Can I use the same scoring table for every application?
Start with it, then adjust the weights per application, since a public payment system and an internal tool carry different risks.
Sources
Last reviewed: 19 October 2026.
