Diverse Vendor Review¶
Checklist — instantiates Common-Mode Failure Analysis
Assesses whether vendor diversity is real across ownership, infrastructure, code lineage, hosting, support, credentials, and failure response capability.
Buying from two vendors is not the same as being protected by two vendors. A Diverse Vendor Review is a scoring checklist that tests whether a claimed multi-vendor arrangement is diverse on the dimensions that matter — ownership, code and design lineage, hosting, support organization, credentials, and failure-response capability — rather than just two logos on two contracts. Its defining move is to set an explicit standard for what counts as "diverse enough" and then score each vendor pair against it dimension by dimension, so a pair that differs on the label but converges underneath (same parent company, same open-source core, same hosting provider) fails the review even though procurement counts it as two. It is a static assessment against a rubric, not a trace of a physical chain: it evaluates the reality of the diversity claim, catching vendors who look independent and share the decisive lineage.
Example¶
A security team runs incoming email through what it believes are two independent malware-detection engines, on the theory that a threat missed by one will be caught by the other. The Diverse Vendor Review scores that belief against a rubric rather than accepting the two-vendor headline. Ownership: different companies — pass. Hosting: different clouds — pass. Then the code-and-design-lineage row: both engines, it turns out, license the same upstream commercial signature feed and rely on overlapping detection heuristics. On the dimension that decides whether a novel threat slips past, the two engines are near-copies.
The review scores the pair as failing the diversity standard where it counts, with a specific reason: shared detection lineage. That single finding reframes the investment. Adding a third engine from the same signature ecosystem would spend money without buying independence; what the rubric shows is needed is an engine built on a genuinely different detection approach. This is the empirical lesson of design-diversity research — that independently sold does not guarantee independently failing, because shared assumptions and shared sources correlate the misses.[n1]
How it works¶
The review is a rubric applied uniformly across a vendor set:
- Fix the diversity standard. Decide, before scoring, which dimensions must differ and how much — ownership, infrastructure, code/design lineage, hosting, support, credentials, failure response — so a pair can concretely pass or fail.
- Score each dimension per pair. For every pair of "alternate" vendors, mark same-or-different on each dimension, with evidence, refusing to accept a different brand as proof of a different substance.
- Weight by decisiveness. Emphasize the dimensions that actually carry the independence claim (shared code lineage often matters far more than shared office location).
- Report pass/fail with the binding dimension. Output is not a count of vendors but a judgment: diverse enough, or not, and on which dimension the diversity collapses.
Tuning parameters¶
- Dimension set — which axes the rubric scores. More axes catch subtler convergence; too many turn the review into box-ticking.
- Pass threshold — how many (and which) dimensions must differ to count as diverse. A strict threshold rejects cosmetic diversity but may reject workable arrangements.
- Dimension weighting — how heavily each axis counts. Mis-weighting (rewarding different logos over different lineage) produces a review that passes the dangerous pairs.
- Evidence bar per dimension — vendor attestation versus independently verified fact. A higher bar prevents "trust me, we're different" but costs verification effort.
- Re-score cadence — one-time versus periodic. Vendors merge, migrate, and adopt shared platforms; a stale pass becomes wrong.
When it helps, and when it misleads¶
Its strength is puncturing cosmetic multi-sourcing: it is fast, repeatable, and turns "we use two vendors" into a defensible or indefensible claim with a named weak dimension. It encodes the hard-won insight of design diversity — that independence must be demonstrated across substance, not assumed from separate purchase orders.
Its failure mode is checklist literalism: a pair scores "different" on every listed dimension yet shares something the rubric never thought to ask about, so a green scorecard certifies a coupling. A classic misuse is scoring vendor attestations — accepting each vendor's claim of independence at face value — which reproduces exactly the false confidence the review exists to break. The guarding discipline is to verify the decisive dimensions against evidence rather than attestation, and to treat the rubric as a floor that must evolve as new shared platforms emerge, not a fixed certificate.
How it implements the components¶
diversity_or_isolation_requirement— it defines and applies the explicit standard for what counts as enough separation, the yardstick every pair is scored against.common_design_lineage_check— its code-and-design-lineage row directly tests whether "separate" vendors share the same core, heuristics, or origin.
It scores the diversity claim statically and does not follow the chain: it does not trace physical common_environment_check across regions and sub-tier suppliers or define the alternate-source redundancy_set — that multi-tier tracing belongs to its near-neighbor Supply-Chain Dependency Review, which walks the goods downstream while this review scores the vendors against a rubric; nor does it run the live independence_validation_probe of Backup Independence Test.
Related¶
- Instantiates: Common-Mode Failure Analysis — this review supplies the pass/fail judgment on whether claimed vendor diversity is genuine.
- Sibling mechanisms: Backup Independence Test · Common-Cause FMEA · Correlated Risk Register · Credential and Infrastructure Dependency Audit · Fault Tree with Common-Cause Branching · Supply-Chain Dependency Review · Tabletop Cascade Exercise
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Diverse Vendor Review operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it assesses whether vendor diversity is real across ownership, infrastructure, code lineage, hosting, support, credentials, and failure response capability.
Independent corroboration: The frozen evidence defines Diverse Vendor Review as 'Assesses whether vendor diversity is real across ownership, infrastructure, code lineage, hosting, support, credentials, and failure response capability', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Reliability engineering established common-mode failure analysis: nominally separate backups are not diverse when they share hidden dependencies.
Related originating lineages:
- Computer Science & Software Engineering — N-version research exposed correlated failures across independently developed implementations.
- Logistics & Supply Chain Management — Supplier-risk practice supplied ownership, provenance, geography, and sub-tier checks.
- Security Studies & Intelligence Analysis — Security assurance supplied evidence-based review of ownership, credentials, hosting, and response.
Review resolution: The original multiversion experiment directly established correlated failure, while NIST formalizes supplier due diligence; reliability engineering remains primary.
Attribution caveat: The checklist applies a reliability principle through software, security, and supplier evidence.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] N-version programming is the fault-tolerance idea of running several independently developed program versions and voting on their outputs. Knight and Leveson's well-known experiment found that such independently written versions still failed together on the same hard inputs more than statistical independence would predict — the empirical basis for scoring shared design lineage rather than assuming diversity from separate authorship. ↩