11.6 Risk Assessment for Mergers and Acquisitions¶

When organizations acquire another company, they acquire its software supply chain—dependencies, technical debt, security vulnerabilities, and all. A target company's attractive revenue or technology can obscure significant hidden liabilities buried in their codebase. Supply chain risks that seem manageable in isolation can become critical when multiplied across an acquisition portfolio or integrated into systems with different security postures.

This section addresses supply chain risk assessment specific to M&A contexts, where inherited dependencies become balance sheet liabilities and remediation costs affect deal valuations.

Supply Chain Due Diligence¶

Traditional M&A due diligence examines financials, legal obligations, and business operations. Software supply chain due diligence has become equally important as software-driven businesses dominate acquisition activity.

Why Supply Chain Due Diligence Matters:

• Hidden costs: Unpatched vulnerabilities require remediation investment post-close
• Compliance gaps: License violations create legal liability
• Integration complexity: Incompatible dependency policies slow integration
• Security incidents: Pre-acquisition vulnerabilities become acquirer's problem
• Valuation accuracy: Technical debt affects true enterprise value

Due Diligence Checklist:

Information Requests:

Request from the target company:

1. Software Bill of Materials for all products
2. Vulnerability scan results from last 12 months
3. License compliance audit results
4. Security incident history (last 3 years)
5. Dependency management policies and procedures
6. Third-party software agreements
7. Open source contribution policies
8. Security team structure and responsibilities

Due Diligence Timing:

Supply chain assessment should begin early in the process:

• Letter of Intent stage: High-level risk assessment based on public information
• Due diligence period: Detailed codebase analysis with target cooperation
• Pre-close: Remediation planning and cost estimation
• Post-close: Execution of remediation plan

Assessing Acquired Codebases¶

Detailed codebase analysis reveals supply chain risks that questionnaires miss.

Analysis Approach:

1. Generate comprehensive SBOMs: Scan all repositories using multiple tools
2. Identify all dependency ecosystems: npm, Maven, pip, Go, containers, etc.
3. Map dependency depth: Understand transitive dependency exposure
4. Scan for vulnerabilities: Run SCA tools against complete inventory
5. Audit licenses: Identify all licenses and potential conflicts
6. Assess freshness: Measure how current dependencies are
7. Evaluate build systems: Understand how software is built and deployed

Red Flags in Codebase Analysis:

Beyond Automated Scanning:

Automated tools miss important context:

• Why decisions were made: Talk to engineering leadership about architectural choices
• Known issues: Ask about dependencies they're concerned about
• Technical roadmap: Understand planned changes that affect dependencies
• Undocumented knowledge: Identify dependencies that "only one person understands"

Technical Debt as Supply Chain Risk¶

Technical debt in the supply chain context includes accumulated deferred maintenance, outdated dependencies, and architectural decisions that create ongoing security and operational burden.

Quantifying Technical Debt:

Several approaches help quantify supply chain technical debt:

Remediation Cost Estimation:

Estimated Cost = Σ (Vulnerability Count × Average Fix Time × Loaded Labor Cost)
               + (Major Version Updates × Update Effort × Loaded Labor Cost)
               + (Dependency Replacements × Replacement Effort × Loaded Labor Cost)

Example Calculation:

Technical Debt Categories:

• Vulnerability debt: Unpatched known vulnerabilities
• Freshness debt: Outdated dependencies requiring updates
• Architecture debt: Structural issues limiting security improvement
• Documentation debt: Missing information about dependencies
• Process debt: Absent or inadequate dependency management processes

Impact on Valuation:

Technical debt should factor into deal terms:

• Reduce purchase price by estimated remediation cost
• Establish escrow for post-close remediation
• Include remediation milestones in earnout provisions
• Require seller warranties regarding security state

Integration Challenges¶

Merging organizations with different dependency policies creates friction and risk.

Common Integration Conflicts:

• Different approved package lists: One organization allows packages the other prohibits
• Version policy differences: Pinning strategies, update frequencies vary
• Tooling incompatibility: Different SCA tools, scanning processes
• Risk tolerance misalignment: What's acceptable risk differs
• License policy conflicts: Different approaches to copyleft, attribution

Policy Harmonization Strategies:

Option 1: Adopt Acquirer Policy

• Acquired organization adopts acquirer's policies
• Clear direction, consistent standards
• May require significant remediation in acquired codebase
• Can slow integration if policies are very different

Option 2: Adopt Best of Both

• Evaluate both policies, select stronger provisions
• May improve both organizations' practices
• Requires more analysis and negotiation
• Risk of creating inconsistent hybrid

Option 3: Phased Harmonization

• Establish minimum baseline immediately
• Full harmonization over 12-24 months
• Allows time for remediation
• Requires clear roadmap and milestones

Integration Checklist:

1. Document both organizations' current policies
2. Identify conflicts and gaps
3. Establish immediate security minimums
4. Create harmonization roadmap
5. Allocate resources for remediation
6. Define success metrics and milestones
7. Communicate clearly to both engineering organizations

Liability and Risk Transfer¶

Legal considerations around supply chain risk in M&A transactions continue to evolve.

Key Legal Considerations:

Representations and Warranties:

Acquire specific representations about software supply chain:

• "Software does not contain known vulnerabilities rated Critical or High"
• "Company has valid licenses for all third-party software"
• "Company maintains accurate inventory of all software dependencies"
• "No pending claims related to open source license violations"

Indemnification:

Seek indemnification for:

• Pre-existing security vulnerabilities that result in breaches
• License compliance issues discovered post-close
• Third-party claims related to inherited software
• Remediation costs exceeding estimated amounts

Disclosure Schedules:

Require detailed disclosure of:

• Known security vulnerabilities and remediation status
• Open source license compliance issues
• Security incidents in past 3-5 years
• Ongoing security investigations or audits

Insurance Considerations:

• Review target's cyber insurance coverage and claims history
• Assess whether coverage transfers or requires new policy
• Consider representations and warranties insurance for supply chain risks
• Evaluate adequacy of coverage given discovered risks

Post-Acquisition Remediation Planning¶

Plan remediation before closing; execute immediately after.

90-Day Remediation Plan:

Days 1-30: Assessment and Stabilization

• Complete comprehensive SBOM if not done in due diligence
• Run full vulnerability scan across all products
• Identify critical and high vulnerabilities requiring immediate action
• Implement emergency patches for actively exploited vulnerabilities
• Establish monitoring for new vulnerabilities in acquired codebase
• Document current state as baseline for improvement tracking

Days 31-60: Critical Remediation

• Remediate critical vulnerabilities in production systems
• Address high-severity vulnerabilities in customer-facing systems
• Resolve license compliance issues creating legal risk
• Begin updating severely outdated dependencies
• Implement basic security scanning if not present
• Integrate acquired systems into corporate security monitoring

Days 61-90: Process Integration

• Harmonize dependency management policies
• Integrate acquired repositories into corporate SCA tools
• Train acquired team on acquirer security practices
• Establish ongoing remediation cadence
• Create long-term technical debt paydown plan
• Report progress to leadership and integration team

Resource Requirements:

Plan for dedicated resources:

• Security engineers for vulnerability remediation
• DevOps support for tooling integration
• Legal review for license issues
• Project management for tracking progress
• Communication support for change management

Deal-Breaker Indicators¶

Some supply chain findings warrant walking away or significant deal restructuring.

Potential Deal-Breakers:

Risk Tolerance Factors:

Whether findings are deal-breakers depends on context:

• Strategic importance: More tolerance for strategically critical acquisitions
• Remediation feasibility: Fixable problems vs. architectural issues
• Time to value: Urgency of integration affects acceptable risk
• Deal size: Larger deals warrant more thorough diligence
• Acquirer capabilities: Strong security team can remediate what others cannot

Recommendations¶

For M&A Teams:

1. Include supply chain in standard diligence. Software supply chain assessment should be standard for any acquisition involving software assets.

2. Engage security expertise early. Bring security and engineering leadership into diligence process, not just legal and financial teams.

3. Quantify technical debt. Translate supply chain findings into dollar estimates that can inform deal terms.

4. Build remediation into deal structure. Use purchase price adjustments, escrows, or earnouts to address identified issues.

For Security Leaders:

1. Develop M&A playbook. Create standardized processes for supply chain due diligence that can be executed under deal timelines.

2. Build assessment capability. Ensure your team can rapidly assess acquired codebases using appropriate tools and expertise.

3. Plan for integration. Develop templates for post-acquisition remediation and integration planning.

4. Document your own house. Maintain current SBOMs and security posture documentation—you may be the target someday.

For Executives:

1. Recognize supply chain as material risk. Software supply chain issues can significantly affect acquisition value and integration success.

2. Allocate diligence resources. Technical due diligence requires time and expertise; budget appropriately.

3. Factor remediation into integration planning. Post-acquisition remediation competes with other integration priorities; plan accordingly.

4. Set clear risk tolerance. Define what supply chain findings are acceptable, concerning, and disqualifying for your organization.

M&A transactions create moments of maximum supply chain risk exposure. Organizations inherit years of decisions—good and bad—embedded in acquired codebases. Thorough due diligence, clear deal terms, and structured remediation planning transform supply chain risk from hidden liability into manageable challenge. The cost of proper assessment is trivial compared to the cost of inheriting a compromised or unmaintainable software supply chain.