Root Cause vs. Contributing Factors

In multiplication, to get a non-zero product, all factors must be greater than 0. If one factor is 0, nothing else matters.

\[\begin{align} 5 \times 2 \times 229 \times 0.2 &= 458.0\\ 5 \times 2 \times 229 \times 0.0 &= 0.0 \end{align}\]

This xz/liblzma incident and the public post-morten discussion is a great illustration of why incident post-mortens shouldn’t be carried as a search for a root cause, but as a comprehensive enumeration of all contributing factors.

You can model successful attacks as the observed occurrence of an event with non-zero probability — a possible incident that occurred.¹ In that model, the probability of an incident occurring is the product of all the contributing factors’ probabilities.

The nature of multiplication allows anyone to pick one factor and proclaim:

If the probability of this factor were 0, none of this would have happened, this must be the root cause.

The contributing factor you elect as the root cause says more about you, than it says about the shape of the effective solution or mitigating measures.

An open-source contributor will say the root cause is contributor burnout. An engineer that never worked on open-source will claim that open-source itself is the problem. A VP at a big corporation will say the problem is hobbyists not taking software maintenance seriously enough. A security researcher will blame the insufficient threat models that software distribution systems assume.

Getting the chances of that root cause happening down to zero would fully prevent the incident from ever happening again, except that it might be impossible to get it down to zero, and reducing all the contributing factors as much as possible can have a bigger impact on the final product than an imperfect attempt at reducing the chances of a single contributing factor. Because a root cause really is just an arbitrarily chosen contributing factor. ²