Generic Vulnerabilities: Software Failure & Hardware Failure

Two Causes, One Word: "Imperfection"

Both IT Risk Events share a generic vulnerability that can be stated in one sentence:

Software Axiom:

"All software contains latent defects." — This is a logical axiom.

Hardware Axiom:

"All physical components degrade and will eventually fail." — This is a thermodynamic axiom.

Both are inherent imperfections — not assumptions, not probabilities, but certainties. The question is never whether failure occurs but when, where, and who controls the fix. That's it. That's the cause side of the Bow-Tie.

But the moment you take that simplicity seriously — the moment you apply the same causal rigor the TLCTC demands for adversarial threats — consequences unfold that most frameworks quietly avoid.

The Nature of Each Imperfection

Despite sharing the label "imperfection," these are fundamentally different phenomena, and that difference shapes everything downstream.

Software imperfection is frozen in time. A bug introduced on day one is exactly the same bug on day ten thousand. Software doesn't degrade — it was always broken in that specific way, waiting for the right input to reveal it. The defect population in a codebase is static (absent changes) but unknowable in advance. This is Rice's theorem operationalized: non-trivial semantic properties of programs are undecidable. The generic vulnerability is therefore logical imperfection.

Hardware imperfection is time-dependent. A component that works perfectly today is measurably closer to failure tomorrow. Thermal cycling, electromigration, mechanical wear, material fatigue — physics guarantees progressive degradation. Unlike software, hardware failure has a statistical predictability (bathtub curve, Weibull distributions) that enables preventive strategies. The generic vulnerability is material imperfection.

The Structural Consequence of INT / 3PC Sub-Types

Both IT Risk Events split into Internal (INT) and Third-Party (3PC) sub-types based on who controls the fix. But the trust boundary geometry differs in a way that reveals something about ITIL, ISO 20000, and most service management frameworks.

For Software Failure, INT means you own the code and the fix. The domain boundary for 3PC is ||[@Vendor→@Org]|| — the non-adversarial analog of TLCTC #10 Supply Chain Attack. Same boundary, zero intent.

For Hardware Failure, even INT hardware — equipment you own and operate — was manufactured by a vendor. You own the asset but not the manufacturing origin. This means INT hardware has an inherent secondary 3PC dependency for parts and firmware that INT software does not have.

What Happens When You Apply TLCTC Rigor

The TLCTC's insistence on cause-based classification, Bow-Tie separation, and generic vulnerability identification forces several uncomfortable observations when extended to non-adversarial IT Risk Events:

1. "Incident" is not a cause.

Most ITSM frameworks (ITIL included) begin with incidents and work backward. The Bow-Tie demands the opposite: begin with the cause (imperfection), pass through the central event (failure), and only then arrive at consequences (DREs). An incident is a detected consequence, not a cause. This inversion restructures how you think about every ITSM practice — detection is consequence-side observation, not cause-side prevention.

2. "Infrastructure failure" conflates two distinct causes.

When ITIL or ISO 20000 speaks of "infrastructure" they silently merge hardware and software into a single service layer. But a server outage caused by a kernel bug (Software Failure) and a server outage caused by a failed power supply (Hardware Failure) have different generic vulnerabilities, different control profiles, different time dynamics, and different fix models. Treating them as one thing prevents precise control mapping. The Bow-Tie makes the split mandatory.

3. The same DRE can have categorically different causes.

Loss of Availability from a software crash and Loss of Availability from a disk failure look identical from the consequence side. Outcome-based classification (which dominates ITSM) would file both under "availability incident." Cause-based classification reveals they require entirely different preventive controls — testing and code review for software, maintenance and environmental controls for hardware. This is why outcome-based taxonomies systematically fail at prevention: they cannot distinguish causes that require different treatments.

4. ITIL has a measurable hardware gap.

When you map ITIL 4's 34 practices against Hardware Failure with the same granularity applied to Software Failure, four structural gaps emerge: no preventive maintenance practice, no environmental management practice, no hardware-specific testing guidance, and no predictive health monitoring guidance. These aren't obscure edge cases — they are foundational preventive and detective controls for physical infrastructure. The gaps exist because ITIL's evolution has tracked the industry's abstraction away from physical hardware toward software and cloud services. The abstraction is useful but creates blind spots that the Bow-Tie makes visible.

5. Non-adversarial and adversarial controls can share practices but never share causes.

A WAF protects against adversarial server exploits (TLCTC #2). A redundant power supply protects against non-adversarial hardware failure. Both are "Protect" controls. But the cause each addresses is categorically different — and this matters because risk assessment requires cause-level granularity. Mixing adversarial and non-adversarial causes in the same risk register, under the same label, is how organizations end up with control frameworks that are simultaneously comprehensive and useless.

For Readers Who Want to Go Deeper

The methodology presented here establishes a template: take any non-adversarial IT Risk Event, identify its generic vulnerability, split by control ownership (INT/3PC), map through the Bow-Tie, and test your control catalog against it.