Skip to content

Common-Driver Decomposition

Method — instantiates Vulnerability Hotspot Mapping and Hardening

Tests whether the vulnerabilities stacked on a hotspot are genuinely independent or all traceable to one shared cause — so hardening targets the driver, not the symptoms.

Once a hotspot is found, the map shows that several vulnerabilities pile up on one unit but not why. Common-Driver Decomposition answers the why-question that decides how to harden: are the co-located weaknesses independent — so the compounding is real and every layer needs its own fix — or are they all downstream of one shared cause, so the "five problems" are really one? Its defining move is separating apparent stacking from a concealed common cause, because the two demand opposite responses. When one driver dominates, the method flags it as a hidden single point of concentration: strengthen that, and the whole cluster relaxes at once. This is not detection (the cluster is already found) and not validation (whether it is statistically real) — it is attribution.

Example

A service team watches a dashboard hotspot: five nominally independent subsystems — checkout, search, notifications, the mobile API, and the recommendation feed — all degrade during the same peak hours. The instinct is five hardening projects. Decomposition instead asks whether the five failures move together and share an upstream. Tracing dependencies and correlating the incident timeline, the team finds all five read from one shared configuration service that saturates under load. The pile-up was one driver wearing five costumes. Hardening that config service — caching, a read replica, a load ceiling — quiets all five symptoms, where five separate efforts would have spent five budgets and left the real chokepoint untouched. Had the decomposition instead shown the five failures were genuinely uncorrelated, the correct conclusion would have been the reverse: a real compound hotspot needing layered, independent fixes.

How it works

The method turns a co-location map into an attribution:

  • List the stacked vulnerabilities on the hotspot as separate candidate contributors.
  • Test for dependence. Look for shared inputs, correlated failure timing, and common upstream components — not just that they co-occur, but that they move together.
  • Attribute the variance. Partition the hotspot's risk between a dominant shared driver and genuinely independent contributions.
  • Route the hardening. A dominant driver is marked as the concealed single point to strengthen; genuine independence means the compounding is real and calls for defense in depth across layers.

Tuning parameters

  • Dependence test strength — correlation vs. mechanistic tracing. Correlation is cheap but confounded; tracing the actual pathway is costlier and more convincing.
  • Driver granularity — how deep to trace before stopping. Stop too shallow and you name a symptom as the cause; chase too deep and every driver dissolves into "the environment."
  • Independence prior — whether you start assuming the vulnerabilities are independent or shared. This sets the balance between inventing a false common driver and missing a real one.
  • Evidence source — incident history, architecture/dependency graph, or expert judgment, and how much each is weighted.

When it helps, and when it misleads

Its strength is preventing the expensive category error of hardening many symptoms when one cause drives them all — and, conversely, of applying a single fix to a hotspot whose layers are genuinely independent. It is the step that distinguishes a concealed single point from real compounding, which a co-location map alone cannot tell apart.

Its failure modes are the classic hazards of causal attribution. Correlation is not common cause: things can move together because of a lurking third factor, and a decomposition run on correlations alone can crown a spurious driver.[1] There is a pull toward monocausal bias — collapsing a genuinely multi-cause hotspot onto one tidy root and then under-hardening the other layers — and the method is easily run backwards to blame a convenient cause someone already wanted to fix. The discipline is to require a plausible mechanism, not just a correlation, and to keep the independent-compounding hypothesis alive until the shared driver is actually demonstrated.

How it implements the components

Common-Driver Decomposition realizes the attribution components of the archetype — the ones that explain a cluster rather than find, map, or harden it:

  • independence_and_shared_driver_check — this is the check: does the co-located risk share a driver, or is it independently stacked?
  • single_point_or_concentration_marker — a dominant shared driver is flagged as the hidden single point of concentration to target.

It does NOT locate or map the cluster (Layered Risk Heatmap, Spatial or Network Cluster Detection) or confirm it is statistically real (Multiple-Testing Holdout Check); it does NOT harden the driver it names — that falls to Single-Point-of-Failure Elimination and Exposure Pathway Breakpointing.

Notes

Decomposition should precede resource targeting, because its result changes the shape of the plan: a shared-driver verdict argues for one deep fix, an independence verdict for many shallow ones. Skipping it doesn't just lose information — it silently biases the whole hardening budget toward whichever framing was assumed.

References

[1] In reliability engineering a common-cause failure is one shared condition that defeats several nominally redundant elements at once — the failure mode this method exists to surface. Correctly used, it is the reason co-located failures must be tested for a shared driver before they are treated as independent. ↩