Why is DREAD's Discoverability dimension criticised as security by obscurity?

## What the dimension claims to measure Discoverability is DREAD's fifth dimension: how easily an attacker locates the flaw in the first place. A parameter sitting in a visible URL rates high. A weakness reachable only through an undocumented binary protocol, or one that requires knowing an internal memory layout, rates low. Because the classic DREAD score is the mean of the five ratings, a low Discoverability drags the whole score down and pushes the threat down the queue. That is the mechanism, and stating it plainly is most of the criticism: **the scheme grants a discount for being hard to find.** That is the definition of treating obscurity as a mitigation. ## Why that is unsound **Nothing about the vulnerability changed.** A threat's Damage, Reproducibility and Exploitability describe properties of the system. Discoverability describes a property of the *attacker's current knowledge*. Rating it low does not make the system stronger; it records that, so far as you know, nobody has looked. **Knowledge only moves one way.** Damage can go down when you shrink what a component stores. Exploitability can go down when you add authentication. Discoverability effectively only rises: once the detail is written down somewhere public, it never becomes secret again. A rating that can silently collapse to its maximum, without any change on your side and without any notification, is a poor basis for deferring work. **You are the worst-placed person to estimate it.** You are guessing what a motivated stranger knows. Defenders systematically overestimate how obscure their internals are, because the details feel arcane from the inside and are simply the subject matter to anyone who has spent a weekend on it. ## A concrete case: an anti-cheat team A game studio's anti-cheat team is scoring a threat where a player running the game client edits values in the process memory of their own machine to manufacture in-game currency and rare items. The attacker position here is unusual and worth naming: the attacker fully owns the device the code runs on, and the asset is the integrity of the in-game economy plus the anti-cheat logic itself as intellectual property. The team rates Damage high - a manufactured-currency exploit debases the economy for every paying player and directly undercuts revenue. Reproducibility is high; the edit works every launch. Then someone argues Discoverability should be a 2, "because nobody knows the struct offsets", and the averaged score drops enough for the threat to slip below the sprint line. Every assumption in that argument is wrong in this setting. The attacker holds the binary and can run a debugger against it indefinitely with no rate limit and no logging. There is an organised community that reverse-engineers exactly this for reputation and for money. Offsets that took the first person a week to find get posted, then packaged into a tool that a thousand people who could never have found them run in one click. For an attacker population that is *actively searching*, Discoverability is 10 for anything valuable, and the studio's real defences are server-side authority over the economy and detection - not the hope that the layout stays private. This is also why the dimension misleads in the opposite direction: it is scored lowest exactly where the asset is most attractive, because valuable targets attract the sustained reverse-engineering that destroys obscurity fastest. ## The standard remedy The common practice is to fix Discoverability at its maximum value for every threat - assume the flaw will be found. That is a sensible defensive posture, and it deserves to be named for what it does to the scheme: if a dimension takes the same value on every row, it contributes nothing to the ordering. Pinning it is functionally the same as deleting it, and teams that reach that conclusion usually notice that a rating scheme they have already amputated one fifth of may not be the right instrument. ## Where obscurity does legitimately appear Be careful not to overcorrect in an interview. Not publishing internal details is a reasonable *hygiene* choice, and raising an attacker's cost is a real effect - a private protocol does buy you time against opportunistic attackers. The rule is that obscurity may be a layer on top of a control, never the control itself and never a reason to lower a rating. In threat-model terms: model the threat as though the design document were public, decide the controls on that basis, and treat any delay obscurity buys you as luck rather than defence. Kerckhoffs's principle is the older form of the same idea - a system should stay secure when everything except the key is known.