The Dependency Nexus

A Quantifiable Framework for Liability in the Software and AI Supply Chain doc_id: AVT-CS-2025-002 date: Q4 2025 classification: PUBLIC author: Alpha Vector Advanced Projects status: VALIDATED

Executive Summary The average enterprise application contains thousands of transitive dependencies, creating a supply chain attack surface of unprecedented complexity. When breaches occur through this dependency graph, liability attribution remains legally ambiguous, creating significant costs in unresolved supply chain security incidents globally.

Major Supply Chain Breaches (Selected)

Incident	Date	Attack Vector	Liability Status
SolarWinds Orion	Dec 2020	Build system compromise	Litigation
Kaseya VSA	July 2021	Supply chain ransomware	Settlements
Log4Shell (Log4j)	Dec 2021	Vulnerability in OSS library	Unclear
3CX	March 2023	Compromised installer	Investigation
MOVEit Transfer	May 2023	Zero-day exploitation	Settlements
XZ Utils	March 2024	Backdoor in compression library	Prevented

Sources: Chainalysis, Sonatype, CISA, Alpha Vector Tech incident database Critical Pattern: In 87% of major supply chain incidents, liability remained unresolved or settled without clear precedent, leaving fundamental questions unanswered: - Who is responsible when an open-source library causes a breach? - How should liability be distributed across the dependency chain? - What duty of care do commercial vendors owe when incorporating OSS? This paper introduces the Nexus Score - a quantifiable framework for liability distribution based on Foreseeability, Controllability, Commercialization, and Conduct.

1. The Supply Chain Attribution Crisis

1.1 The Complexity Problem

Modern applications rely on thousands of direct and transitive dependencies. The Attribution Problem: When a breach occurs via a dependency deep in the tree, maintained by a volunteer using a sub-dependency that was compromised years ago, legal liability remains ambiguous. Traditional legal frameworks struggle to assign responsibility fairly between end vendors, open source authors, and integrators.

1.2 Real-World Case Study: Log4Shell

Background (December 2021):

Vulnerability: CVE-2021-44228 (Critical) in Apache Log4j 2.x
Impact: widespread remote code execution risk across millions of systems.

The Liability Question:

Apache Software Foundation: Disclaimed liability via Apache License 2.0 ("AS IS").
Cloud Providers: Generally shifted responsibility to customers for application security.
Application Vendors: Argued reliance on industry standards.
End Enterprises: Faced remediation costs and potential exposure.

1.3 The SBOM Regulatory Revolution

Executive Order 14028 (May 2021): "The term ‘Software Bill of Materials’ or ‘SBOM’ means a formal record containing the details and supply chain relationships of various components used in building software."

Requirements (Federal procurement):

All software sold to federal government should include SBOM.
SBOM must be machine-readable (SPDX or CycloneDX format).

EU Cyber Resilience Act (CRA):

Manufacturers must provide SBOM.
Post-market monitoring of components required.

FDA Medical Device Requirements:

SBOM required for medical device software.

2. The Nexus Score: Mathematical Framework

2.1 Core Formula


Execution RecordFRE 902(14) Ready
Nexus_Score = (w_F × F) + (w_C × C) + (w_M × M) + (w_D × D)

Chain-of-Custody Recorded

Where: F = Foreseeability (0.0-1.0) C = Controllability (0.0-1.0) M = Commercialization (0.0-1.0) D = Due Diligence / Conduct (0.0-1.0)

Weights (suggested, can be adjusted per jurisdiction): w_F = 0.30 # 30%ce
w_C = 0.30 # 30% w_M = 0.25 # 25% w_D = 0.15 # 15% Liability Distribution: Party_Liability_% = (Party_Nexus_Score / Σ All_Parties_Nexus_Scores) × 100

2.2 Factor Definitions

Factor 1: Foreseeability (F) Definition: The extent to which a party should have anticipated the vulnerability or risk. Scoring Criteria:

Indicator Score Impact Justification Component has +0.25 Pattern of security issues indicates history of foreseeable risk vulnerabilities

Indicator Score Impact Justification CISA Known +0.30 Government warning makes risk Exploited foreseeable Vulnerabilities (KEV) list CVE published >30 +0.20 Reasonable time for awareness days before incident Industry threat +0.15 Sector-specific warnings intelligence available CVSS score >7.0 +0.10 Severity indicates importance (High/Critical)

Example Calculation (Log4j post-disclosure):


Simulation ChannelRef. MRV-Ω.12
def calculate_foreseeability_log4j(days_since_cve_published):
    score = 0.0

    # Log4j had historical vulnerabilities
    score += 0.25

    # CISA added to KEV list within 24 hours of disclosure
    score += 0.30

    # Time factor
    if days_since_cve_published > 30:
        score += 0.20
    elif days_since_cve_published > 7:
        score += 0.10

    # CVSS 10.0 (Critical)
    score += 0.10

    # Widespread industry alerts
    score += 0.15

    return min(score, 1.0)      # Cap at 1.0

# Day 1: F = 0.80 (high foreseeability even immediately)

# Day 31+: F = 1.0 (maximum foreseeability)
Legal Foundation: Based on Palsgraf v. Long Island Railroad Co. (1928) - foreseeability as
requirement for negligence.

Factor 2: Controllability (C)     Definition: The degree of control a party had over the vulner-
able code or component.
Integrity Verified

Control Hierarchy:

Role Control Level Score Example Original Au- Direct code control 1.0 Apache Foundation thor/Maintainer for Log4j Active Commit/review access 0.75 Frequent contributors Contributor with merge rights Commercial Packaging/integration control 0.50 Red Hat Redistribu- redistributing OSS tor Dependency Version selection control 0.30 Enterprise choosing Manager which version to use Configuration Deployment configuration 0.20 IT team configuring Manager application End User No control 0.05 Customer using SaaS product

SolarWinds Example: Orion Software (compromised build process) � �� SolarWinds Corp: C = 1.0 (complete control of build process) �� Microsoft (Azure, where Orion was compromised): C = 0.15 (infrastructure provider) �� End Customer (US Treasury, etc.): C = 0.05 (software consumer only) Legal Foundation: Restatement (Third) of Torts §19 - “Control is a prerequisite for duty of care.”

Factor 3: Commercialization (M) Definition: The extent of financial benefit derived from the component or system. Revenue Attribution Models: Model A: Direct License Revenue M = Component_License_Revenue / Total_Company_Revenue

Example: Commercial database library

License revenue: $5M/year
Company revenue: $50M/year
M = 0.10 (10%) Model B: Embedded Component Value

For components embedded in products


Simulation ChannelRef. MRV-Ω.12
def calculate_component_value(product_revenue, component_criticality, alternatives_available):
    """
    Component criticality: 0.0 (nice-to-have) to 1.0 (product would fail without it)
    Alternatives available: 0.0 (unique) to 1.0 (many substitutes)
    """
    base_value = product_revenue * component_criticality
    scarcity_premium = 1.0 - (alternatives_available * 0.5)


    return (base_value / product_revenue) * scarcity_premium

# Example: Proprietary compression algorithm in enterprise software

component_value = calculate_component_value(
    product_revenue=100_000_000, # $100M
    component_criticality=0.8, # Product barely works without it
    alternatives_available=0.2 # Few viable alternatives
)
# M = 0.72 (high commercialization)

Integrity Verified

Model C: Open Source with Commercial Support


Execution RecordFRE 902(14) Ready
M = (Support_Revenue + Donation_Income) / (Company_Revenue + 1)

# Example: Redis Labs (open core model)

# OSS Redis: M = 0.05 (minimal direct monetization)
# Redis Enterprise (commercial): M = 0.90 (primary product)

SolarWinds Example: - Orion product revenue: ~$341M (2019) - SolarWinds total revenue:
~$1B (2019) - M = 0.34 (34% - significant commercialization)
Legal Foundation: Proximate cause doctrine - “benefit from risk = responsibility for harm”

Factor 4: Due Diligence / Conduct (D) Definition: Actions taken to identify and mitigate
risks (negative score = good practices, positive = negligence).
Chain-of-Custody Recorded

Scoring Matrix:

Practice Score Modification Verification Method SBOM -0.20 Machine-readable SBOM with maintained & timestamp current Automated -0.15 CI/CD integration logs vulnerability scanning Timely patching -0.15 Patch management records (within 30 days of CVE) Security audits -0.10 Third-party audit reports (annual minimum) Responsible -0.10 Published security.txt / policy disclosure program Bug bounty -0.05 HackerOne / Bugcrowd presence program Known issues +0.30 Internal emails / Jira tickets ignored showing awareness

Practice Score Modification Verification Method No vulnerability +0.25 Absence of scanning tools management Delayed +0.20 Incident response timelines patching (>90 days)

Example: Equifax Breach (2017) Vulnerability: Apache Struts CVE-2017-5638 (disclosed March 2017, breached May 2017) Conduct Analysis: equifax_conduct_score = 0.0

Negative practices (increase liability):

equifax_conduct_score += 0.30 # Patch available 2 months, not applied (known issue ignored) equifax_conduct_score += 0.20 # Delayed response to vulnerability disclosure

Positive practices (none applicable):

- No automated scanning detected vulnerability

- No timely patching process

- Security audit failed to identify exposure

Final: D = +0.50 (high negligence score)

Compare to: Apache Foundation (Struts maintainer) apache_conduct_score = 0.0

Positive practices:

apache_conduct_score -= 0.20 # SBOM available apache_conduct_score -= 0.15 # Patch released within 5 days of discovery apache_conduct_score -= 0.10 # Security advisories published apache_conduct_score -= 0.10 # Responsible disclosure process

Final: D = -0.55 (diligent conduct)

2.3 Worked Example: SolarWinds Liability Distribution

Scenario: $100M in damages from SolarWinds Orion breach Parties: 1. SolarWinds Corp (software vendor) 2. Microsoft (Azure infrastructure where build was compromised) 3. FireEye (security vendor, first victim to detect breach) 4. US Government Agencies (victims) Nexus Score Calculation:

Party F C M D Weighted Nexus Liability % Amount SolarWinds0.85 1.0 0.34

0.45 0.684 62% $62M

Microsoft 0.40 0.15 - 0.08

0.129 12% $12M


Execution RecordFRE 902(14) Ready
                    0.10
Chain-of-Custody Recorded

Nation- N/A N/A N/A N/A (uncollectable) — — State Attacker End 0.55 0.05 0.0 0.35 0.285 26% $26M Agen- cies

Explanation: SolarWinds (62% liability): - F = 0.85: High - build security is foreseeable responsibility for software vendor - C = 1.0: Complete control over build process - M = 0.34: Significant commercialization - D = +0.45: Evidence showed known security deficiencies in build environment

Result: Primary liability Microsoft (12% liability): - F = 0.40: Moderate - infrastructure providers should anticipate some abuse - C = 0.15: Limited control (provided platform, not application logic) - M = 0.08: Minimal Azure revenue from SolarWinds specifically - D = -0.10: Had security controls in place (though bypassed) - Result: Contributory liability for infrastructure provision End Agencies (26% liability): - F = 0.55: Moderate-high - sophisticated agencies should anticipate supply chain risk - C = 0.05: Minimal control (consumers only) - M = 0.0: No commercialization - D = +0.35: Deployed without adequate vendor security assessment - Result: Contributory negligence in procurement and deployment Legal Note: This is a theoretical application. Actual SolarWinds litigation is ongoing with no final judgment as of Nov 2024.

3. AI/ML Supply Chain: Special Considerations

3.1 The AI Dependency Problem

Modern AI Application Supply Chain: Your AI Application �� Foundation Model: GPT-4 (OpenAI API) �� Fine-tuning Data: Internal + Scraped web data �� Vector Database: Pinecone �� Embedding Model: sentence-transformers (Hugging Face) �� Application Framework: LangChain � �� Dependencies: 47 libraries �� Deployment: Cloud provider (AWS/Azure/GCP) New Liability Questions: 1. If GPT-4 generates defamatory content, who is liable? 2. If fine- tuning data contained copyrighted material, who faces IP claims? 3. If the embedding model has bias leading to discrimination, who is responsible?

3.2 Nexus Score Adjustments for AI

AI-Specific Foreseeability Factors:

Risk Score Impact Example Bias in training +0.30 Historical hiring data data contains gender bias Hallucination/confabulation +0.40 LLM known to generate false information Prompt injection +0.35 Model susceptible to jailbreak vulnerability attacks Copyright/IP +0.25 Training data provenance infringement risk unclear

AI-Specific Controllability:

Role Control Level Score Example Foundation Model architecture/training 0.95 OpenAI for GPT-4 Model Provider Fine-tuner Adaptation layer 0.45 Enterprise fine-tuning on internal data Prompt Input/output shaping 0.25 Application developer Engineer crafting prompts API Endpoint usage only 0.10 End application using Consumer OpenAI API

3.3 Case Study: AI Medical Diagnosis Liability (Hypothetical)

Scenario: AI diagnostic tool (built on GPT-4) misdiagnoses 1,247 patients, leading to delayed treatment and 14 deaths. Parties & Nexus Scores:

Party Role F C M D Nexus Liability % OpenAI Foundation 0.90 0.95 0.70 0.30 0.754 48% model MedTech Fine- 0.85 0.45 0.95 0.50 0.715 45% Co tuning & deploy- ment Hospital Clinical 0.60 0.10 0.25 0.45 0.352 22% deploy- ment

Total Damages: $380M ($27K per patient × 14 deaths = $378M + $2M legal costs)

Liability Distribution: - OpenAI: $182M (48%) - MedTech Co: $171M (45%) - Hospital: $27M (7%) Key Factors: - OpenAI: High liability due to foreseeable hallucination risk in medical context and significant control over base model - MedTech: Highest commercialization (charging hospitals), high negligence (insuﬀicient testing) - Hospital: Lower liability but not zero (deployed without adequate clinical validation) Legal Precedent: This framework anticipates future litigation. As of Late 2024, no comparable AI medical liability case has reached judgment.

4. SBOM Evolution: From Inventory to Legal Instrument

4.1 Current SBOM Standards

Formats: - SPDX (Software Package Data Exchange) - ISO/IEC 5962:2021 - CycloneDX - OWASP standard, designed for security Typical SBOM Content (Current): { "bomFormat": "CycloneDX", "specVersion": "1.5", "version": 1, "components": [ { "type": "library", "name": "log4j-core", "version": "2.14.1", "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1", "hashes": [{"alg": "SHA-256", "content": "…"}], "licenses": [{"license": {"id": "Apache-2.0"}}] } ] } What’s Missing for Liability: - � No Nexus Scores - � No liability assumptions - � No due diligence documentation - � No maintenance commitments

4.2 Proposed: Legal SBOM (L-SBOM) Standard

Enhanced SBOM with Liability Metadata: { "bomFormat": "CycloneDX-Legal", "specVersion": "2.0", "version": 1, "legalMetadata": { "nexusScoreVersion": "1.0", "jurisdictions": ["US-Federal", "EU"],

"liabilityFramework": "AVT-Nexus-v1.0" }, "components": [ { "type": "library", "name": "log4j-core", "version": "2.17.1", // Patched version "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",

"nexusScore": { "foreseeability": 0.25, // Updated version, historical issues known "controllability": 1.0, // Apache Foundation maintains "commercialization": 0.05, // Open source, minimal monetization "dueDiligence": -0.35, // Excellent security practices post-Log4Shell "overallScore": 0.287, "calculatedDate": "2024-11-15T00:00:00Z" },

"liabilityProvisions": { "warranty": { "type": "LIMITED", "scope": "Critical security vulnerabilities will be patched within 72 hours", "limitations": "AS-IS for all other defects", "cap": 0 // No monetary warranty }, "indemnification": { "provider": "Apache Software Foundation", "coverage": "NONE - Apache License 2.0 standard disclaimer", "insuranceBacked": false }, "supportCommitment": { "securityPatches": "Best effort, community-driven", "endOfLife": "2027-12-31", "escalationPath": "security@apache.org" } },

"provenance": { "supplier": "Apache Software Foundation", "manufacturer": "Apache Software Foundation", "buildSystem": "Apache Maven", "buildAttestation": { "type": "SLSA", "level": 3, "attestationURL": "https://…" } },


Execution RecordFRE 902(14) Ready
        "vulnerabilityHistory": {
          "knownVulnerabilities": 8,
          "criticalVulnerabilities": 2,
          "averageTimeToFix": "4.2 days",
          "lastCriticalCVE": "2021-12-09"      // Log4Shell
        }
    }
]
Chain-of-Custody Recorded

} Legal Value: 1. Transparency: All parties can assess risk upfront 2. Contractual: Liability provisions can be incorporated into procurement 3. Insurance: Enables underwriting of supply chain risk 4. Litigation: Provides evidence of due diligence or negligence

4.3 L-SBOM Market Opportunity

Implementation Requirements: - � SBOM generation tools (existing): $2.1B market - � Nexus Score calculation (new): $840M market (projected) - � Legal metadata standardization (new): $400M market (projected) - � L-SBOM compliance platforms (new): $1.2B market (projected) Total Addressable Market: $4.5B by 2028

5. Insurance Industry Transformation

5.1 Current Cyber Insurance Gap

Problem: Cyber insurance policies typically exclude or severely limit coverage for: - Software vulnerabilities (pre-existing conditions) - Supply chain attacks (third-party liability) - Open source components (no clear responsible party) Result: Enterprises bear 100% of supply chain breach costs despite paying cyber insurance premi- ums.

5.2 Nexus-Enabled Insurance Products

Proposed: Supply Chain Liability Insurance (SCLI) Underwriting Criteria:


Simulation ChannelRef. MRV-Ω.12
def calculate_scli_premium(enterprise_sbom, coverage_amount):
    """
    Premium calculation based on Nexus Score risk assessment
    """
    total_risk_score = 0.0

        for component in enterprise_sbom.components:
            # Calculate risk contribution
            component_risk = (
                component.nexus_score.foreseeability * 0.4 +
                component.nexus_score.controllability * 0.3 +



               component.nexus_score.commercialization * 0.2 +
               max(0, component.nexus_score.dueDiligence) * 0.1                # Only count poor conduct
          )

          # Weight by component criticality
          criticality_weight = assess_component_criticality(component)

          total_risk_score += component_risk * criticality_weight

     # Normalize to 0-1
     normalized_risk = total_risk_score / len(enterprise_sbom.components)

     # Base premium rate
     base_rate = 0.05 # 5% of coverage amount

     # Adjust for risk
     risk_multiplier = 1 + (normalized_risk * 4)              # 1x to 5x

     annual_premium = coverage_amount * base_rate * risk_multiplier

     return {
         'annual_premium': annual_premium,
         'risk_score': normalized_risk,
         'components_analyzed': len(enterprise_sbom.components),
         'high_risk_components': count_high_risk(enterprise_sbom),
     }
Example: - Coverage: $50M - Components: 9,161 (analyzed via L-SBOM) - Risk Score: 0.42
Integrity Verified

(moderate) - Premium: $10.5M annually (4.2% of coverage) Subrogation: When breach occurs, insurer uses Nexus Scores to recover from responsible parties:

Upstream vendor with M=0.90, D=+0.45 → 60% recovery target - OSS project with M=0.05, D=-

0.30 → 5% recovery (mostly unrecoverable) - Enterprise itself with D=+0.20 → 35% self-insured

5.3 Market Projections

Supply Chain Cyber Insurance: - 2024: $2.1B premiums written - 2028: $14.7B (projected - 48% CAGR) - Nexus-based products: 25% market share by 2028 = $3.7B

6. Conclusion

The Dependency Nexus framework transforms supply chain liability from legal ambiguity to quan- tifiable, fairly-distributed responsibility. By systematically analyzing Foreseeability, Controllability, Commercialization, and Conduct, we provide:

1. Legal Certainty: Courts can assign liability proportionally

2. Insurance Viability: Actuarial pricing becomes possible

3. Market Eﬀiciency: Parties internalize costs, improving security

4. Fairness: Liability distributed based on control and benefit

Market Opportunity


Execution RecordFRE 902(14) Ready
      Segment                       TAM                Addressable     Revenue
      L-SBOM Platforms              $4.5B              20%             $900M
      Nexus Calculation SaaS        $2.1B              30%             $630M
      Legal Consulting              $3.8B              15%             $570M
      Insurance Products            $14.7B premiums    5% commission   $735M
      Total                         —                  —               $2.8B

 In an interconnected digital economy, liability cannot remain at the edges—
 it must be distributed throughout the supply chain in proportion to control,
 benefit, and conduct.
Chain-of-Custody Recorded

References

1. EO 14028 (2021). Improving the Nation’s Cybersecurity. White House.

2. EU Cyber Resilience Act (2024). Regulation (EU) 2024/2847.

3. Synopsys (2024). Open Source Security and Risk Analysis Report.

4. Sonatype (2024). State of the Software Supply Chain.

5. CISA (2024). Supply Chain Risk Management Guidelines.

The Coercion Doctrine: Achieving Forensic Certainty in an Era of