Your first mobile app security scan will almost certainly produce dozens of findings. Some will be Critical. Some will be Informational. Most will fall somewhere in between. The question that follows immediately is: which ones do we fix first?
Severity ratings are a starting point, but they are not the full picture. A Critical finding in a feature that only five internal users access is less urgent than a High finding in the payment flow that every customer uses. A vulnerability that requires physical access to the device is less exploitable than one that can be triggered remotely. Context matters and the DREAD risk scoring model is how you capture that context in a structured, auditable, defensible way.
This post explains the DREAD model, walks through how to apply it to real mobile app findings, and shows why regulators and auditors increasingly expect structured risk assessment rather than a raw list of vulnerabilities.
What Is DREAD?
DREAD is a risk assessment model that scores each vulnerability across five dimensions. Each dimension captures a different aspect of the threat, and together they produce a composite risk score that reflects the real-world impact of the finding not just its technical severity.
D Damage. If this vulnerability is exploited, how severe is the damage? A vulnerability that leads to full account takeover scores higher than one that exposes a user’s display name. A vulnerability that allows modification of financial transactions scores higher than one that allows read-only access to non-sensitive data. The damage dimension forces you to think about the worst-case outcome not the theoretical classification, but the actual business impact.
R Reproducibility. How consistently can this vulnerability be exploited? A finding that can be triggered every time, by any user, in any environment, is more dangerous than one that requires a specific device configuration, a specific Android version, or a specific sequence of user actions. High reproducibility means the attacker can rely on the exploit and so should your risk assessment.
E Exploitability. How much skill and effort does exploitation require? A vulnerability that can be exploited using freely available tools (Frida, Burp Suite, a standard proxy) by someone with basic technical knowledge scores higher than one that requires custom exploit development, advanced reverse engineering, or zero-day research. The exploitability dimension captures the barrier to entry for the attacker.
A Affected Users. How many users are exposed to this vulnerability? A finding in the main login flow affects every user of the application. A finding in an administrative feature used by three people affects three people. A finding in an old API endpoint that has been deprecated but not removed may affect no active users at all. The affected users dimension ensures that high-traffic features receive proportionally more attention.
D Discoverability. How easy is it for an attacker to find this vulnerability? A finding that is visible through basic static analysis of the APK such as a hardcoded API key in the source code is trivially discoverable. A finding that requires deep dynamic analysis, specific runtime conditions, or access to backend infrastructure is harder to find. The discoverability dimension captures how likely it is that an attacker will encounter the vulnerability in the first place.
How to Score: A Practical Example
Consider a finding: the application stores the user’s authentication token in Android SharedPreferences without encryption, in a file that is accessible to other applications on rooted devices.
Damage: High. If the token is stolen, the attacker can impersonate the user accessing their account, initiating transactions, and viewing personal data. For a banking application, this is account takeover.
Reproducibility: High. The token is stored in the same location every time, for every user. The exploit is deterministic it works the same way on every device where the app is installed.
Exploitability: Medium. Exploitation requires either root access to the device or another application with storage permissions that can read the file. This is not trivial for a remote attacker, but it is straightforward for malware already present on the device or for anyone with physical access to a rooted device.
Affected Users: High. Every user who logs into the application has their token stored in the same insecure location. The entire user base is exposed.
Discoverability: High. SharedPreferences storage is one of the first things any security analyst or attacker checks. The file location is predictable, and the contents are trivially readable on a rooted device.
The composite DREAD score for this finding would be high across most dimensions confirming that it should be prioritised for immediate remediation despite being classified as a “Medium” severity finding in a purely technical assessment. The DREAD score captures the business context that a generic severity rating cannot.
Why Auditors Want DREAD (or Something Like It)
Regulators and auditors have become increasingly sophisticated in their expectations. A decade ago, a vulnerability scan report with severity ratings was sufficient evidence for most compliance frameworks. Today, auditors expect to see something more: evidence that the organisation has assessed each finding in the context of its own business, made a documented decision about prioritisation, and tracked that decision through to resolution.
DREAD provides exactly this evidence. When a NESA auditor reviews your mobile app security report, they do not just want to see the findings they want to see that you understood the findings, assessed their impact on your specific operations, and made defensible decisions about which ones to address first.
The DREAD workflow in HEXMobileSuite creates this audit trail automatically. Each finding can be scored, annotated, and assigned a validation status Confirmed (the finding is valid and will be remediated), Inconclusive (further investigation is needed), or Not Confirmed (the finding is a false positive or is mitigated by other controls). Every action is timestamped and attributed, creating the documented decision chain that auditors expect.
DREAD in Practice: The Triage Workflow
When your security team receives a scan report with fifty findings, the DREAD workflow structures the triage process into a repeatable, defensible sequence.
First pass: Critical and High findings. Review all findings classified as Critical or High severity by the scanning engine. For each one, assess the five DREAD dimensions in the context of your application and business. Score each dimension. Findings with high composite DREAD scores become the immediate remediation priority.
Second pass: Medium findings in high-impact features. Review Medium severity findings that affect critical business features authentication, payments, personal data handling, administrative functions. Apply DREAD scoring. Findings with high Affected Users and high Damage scores may be elevated to the remediation queue despite their Medium technical classification.
Third pass: Validation and disposition. For findings that the team believes are false positives or are mitigated by compensating controls, apply the Not Confirmed status with a documented rationale. This is essential auditors will ask why certain findings were dismissed, and “we didn’t think it was important” is not a defensible answer. “We assessed the finding using DREAD scoring, determined that the exploitability is negligible due to compensating control X, and documented our rationale” is.
Fourth pass: Tracking through remediation. For Confirmed findings, track remediation through the development team’s workflow Jira tickets, GitHub issues, or whatever system the team uses. When the fix is deployed, re-scan the application and verify that the finding is resolved. Close the finding in the DREAD workflow with evidence of remediation.
This four-pass workflow transforms a raw scan report into a structured risk assessment programme. It is repeatable on every scan cycle, produces documentation that satisfies auditors, and ensures that the highest-risk findings receive attention first.
The Difference Between Severity and Risk
This is the conceptual point that separates mature security programmes from immature ones.
Severity is a technical property of the vulnerability itself based on the type of flaw, the potential impact category, and the theoretical exploitability. Severity is assigned by the scanning engine and is the same for every organisation that has the same finding.
Risk is what happens when you combine severity with context your business, your users, your regulatory obligations, your threat model. Risk is different for every organisation, even when the underlying vulnerability is identical.
A cleartext HTTP connection in an internal tool used by five employees is a different risk than a cleartext HTTP connection in a banking app used by half a million customers. The severity is the same. The risk is profoundly different.
DREAD is the bridge between severity and risk. It takes the scanning engine’s technical findings and adds the business context that turns a vulnerability report into a risk assessment.
Getting Started with DREAD Scoring
If your organisation has not previously used structured risk scoring, the most practical starting point is to apply DREAD to your next scan’s Critical and High findings only. Score each one across the five dimensions, document your assessment, and use the composite scores to prioritise your remediation queue.
As your team builds familiarity with the model, extend DREAD scoring to Medium findings in high-impact features. Over time, the workflow becomes second nature and your compliance evidence becomes significantly stronger.
HEXMobileSuite includes the DREAD scoring workflow as a built-in feature. Every finding can be scored, annotated, and tracked through the validation cycle directly within the platform no separate spreadsheet, no manual documentation, no audit trail gaps.
Start scoring your mobile app risks today: hexmobsuite.hiesencyber.com
Hiesen Cyber Security | Hoisting Digital Fortresses Through the Storm hiesencyber.com