A software acquisition is often evaluated through revenue, customer concentration, product-market fit, growth, and management projections. Yet the asset that ultimately has to deliver those projections is the software itself. If the codebase contains material architecture debt, fragile dependencies, weak security controls, unclear provenance, or expensive modernization requirements, the buyer may be acquiring a substantially different asset from the one presented during the transaction.
This is why modern software due diligence needs to move below architecture diagrams and management representations and into the evidence contained in repositories, dependencies, build systems, deployment pipelines, and source code.
Introduction
Software due diligence is the systematic assessment of the code, architecture, dependencies, security, intellectual property, technical debt, engineering practices, and software supply chain underlying a technology asset before an investment or acquisition. Its purpose is not merely to find bugs; it is to determine whether the software can support the business case, what liabilities the buyer is assuming, and whether those liabilities should change the transaction.
A hypothetical acquisition illustrates the problem. Assume a buyer is evaluating a SaaS company with attractive recurring revenue, strong customer retention, and an apparently modern cloud architecture. Management describes the platform as scalable and well-engineered.
A deeper examination finds that several critical services depend on undocumented legacy components, automated tests cover only the most recently developed paths, multiple production dependencies are difficult to replace, and significant portions of the codebase have accumulated architectural workarounds.
None of these findings necessarily makes the company uninvestable. But they change the investment question.
The relevant question becomes: What additional engineering capital, time, security remediation, integration effort, and operational risk will the buyer inherit after closing?
NIST’s Secure Software Development Framework explicitly recognizes software acquisition as a context in which secure-development practices and evidence can support communication between suppliers and acquirers.
A technical finding becomes transaction-relevant when it can change future cost, revenue capacity, operational resilience, legal exposure, integration complexity, or the buyer’s confidence in the software asset.
Software due diligence should establish the condition and economic implications of the software asset—not simply confirm that a product exists.
What Is Software Due Diligence?
Software due diligence is the evidence-based examination of a company’s software assets before an acquisition or investment. It evaluates source code, architecture, dependencies, security, technical debt, licensing, provenance, testing, infrastructure, ownership, and maintainability to determine whether the technology can support the business case and what technical liabilities the buyer may inherit.
Traditional technical due diligence can involve architecture reviews, interviews with engineering leadership, security questionnaires, infrastructure assessments, and product demonstrations. Software due diligence goes further by examining the implementation itself.
The distinction matters because an architecture diagram describes intended structure, while source code and repository history provide evidence of actual implementation.
A serious software due diligence assessment therefore asks:
What software exists?
How is it actually structured?
Which components are business-critical?
What dependencies does it rely on?
How secure and maintainable is it?
Who owns and controls the code?
How much engineering investment is required to sustain it?
NIST’s SSDF provides a useful reference point because it is explicitly intended to support secure software development as well as communication with software purchasers and acquirers.
The objective is not to produce the largest possible defect list. It is to identify the relatively small number of technical conditions that could materially affect the transaction.
Those three findings may matter more to an investment committee than hundreds of low-severity code-quality observations because they can affect integration cost, business continuity, and the credibility of the growth plan.
The Acquisition Mistake: When the Business Looks Better Than the Code
The most expensive acquisition mistakes occur when buyers evaluate software primarily through business performance, demonstrations, interviews, and architecture diagrams without validating the underlying implementation. A product can generate attractive revenue while its codebase carries technical debt, dependency risk, architecture constraints, security exposure, or modernization requirements that materially increase post-acquisition costs.
The Hypothetical Case
Consider a fictional SaaS company, “Atlas Systems,” being evaluated by a strategic buyer.
The seller presents:
Strong recurring revenue
A growing customer base
A cloud-native architecture
Automated CI/CD
A modern engineering organization
A roadmap built around rapid product expansion
The buyer initially views the technology as a competitive asset.
Repository-level analysis changes the picture.
The platform contains several tightly coupled services that appear independent on the architecture diagram. A legacy database remains a critical dependency. Some high-value business logic exists in relatively few modules maintained by a small number of engineers. Several third-party components require modernization, while portions of the deployment process lack strong provenance evidence.
The finding is not “bad code.”
The finding is concentration of technical and operational risk.
This distinction is important in M&A. The buyer is not purchasing code quality in isolation. The buyer is purchasing the ability of that code to continue generating business value.
A software asset should be evaluated through a chain of evidence:
Business Claim → Technical Evidence → Risk → Cost/Exposure → Transaction Decision
What Should Buyers Examine Before Acquiring a Software Company?
Buyers should examine the source code, architecture, dependencies, security controls, software supply chain, IP and licensing, technical debt, testing, infrastructure, documentation, engineering governance, compliance evidence, AI-assisted development practices, ownership, and maintainability. The assessment should connect each material technical finding to its operational, financial, legal, or integration consequence.
A practical diligence model has 15 dimensions:
| Area | Core Question |
|---|
| Codebase | What software actually exists? |
| Architecture | Does implementation match the stated architecture? |
| Security | Are material vulnerabilities and control gaps present? |
| Dependencies | Which external components create concentration or replacement risk? |
| Supply chain | Can software components and builds be traced? |
| IP/licensing | Does the company have defensible rights to the software? |
| Technical debt | Which debt requires material future investment? |
| Testing | What critical business logic is actually validated? |
| Engineering practices | How reliably does the organization change software? |
| Cloud/infrastructure | What operational assumptions underpin the product? |
| Documentation | Can another organization understand and operate the system? |
| Compliance | Can claimed controls be evidenced? |
| AI-generated code | Where has AI-assisted development entered the lifecycle? |
| Ownership | Who controls repositories, credentials, build systems, and critical knowledge? |
| Maintainability | Can the buyer sustain and evolve the asset? |
The assessment should prioritize materiality rather than volume. A technically sophisticated diligence report is not necessarily useful if it cannot tell decision-makers which findings matter.
This prioritization allows investment committees to distinguish remediation work from transaction-changing risk.
Buyers should evaluate software as an interconnected asset rather than as a collection of isolated repositories.
How Code Intelligence Changes Software Due Diligence
Code intelligence applies automated analysis and repository-level relationships to understand what software contains, how components interact, where technical debt resides, and which parts of the codebase are business-critical. In due diligence, it can provide evidence that complements interviews and documentation by revealing patterns that are difficult to establish from presentations alone.
Code intelligence can establish relationships across:
Repository → File → Function → Dependency → Service → Business Capability → Risk
This is particularly valuable when an acquisition involves hundreds of repositories or multiple programming languages.
A buyer may need to discover:
Which repositories are production-critical
Which services depend on legacy components
Where code ownership is concentrated
Which modules have high change frequency
Where duplication exists
Which dependencies are obsolete or difficult to replace
Which business capabilities depend on fragile components
Where architecture differs from documentation
The Code Registry’s focus on code intelligence and software governance fits this broader shift toward evidence-based software assessment: the repository becomes an analytical source rather than merely an artifact handed to reviewers.
Code intelligence is most valuable when it creates relationships between technical observations and business capabilities.
This helps identify concentration risk, modernization priorities, and integration dependencies before those issues become post-closing surprises.
Code intelligence changes diligence from repository inspection into software-asset analysis.
AI-Generated Code Is Now a Software Due-Diligence Issue
AI-generated code is not inherently defective, but it introduces additional diligence questions around verification, provenance, security, maintainability, licensing, and governance. Buyers should establish how AI coding assistants and autonomous coding tools were used, what review controls existed, and whether generated changes entered production through the same engineering assurance mechanisms as human-authored code.
GitHub’s documentation explicitly describes hallucination as a known limitation of Copilot suggestions and states that developers remain responsible for reviewing and validating generated output. It also notes that generated suggestions may not identify larger architectural problems.
That creates a useful diligence principle:
AI-assisted development should be assessed through its control environment, not through the assumption that AI-generated code is good or bad.
Relevant questions include:
Which AI coding assistants are authorized?
Were developers required to review generated code?
Are AI-assisted changes visible in repository history?
Are security-sensitive changes subject to additional review?
How are generated dependencies assessed?
Are AI-generated tests independently validated?
Are developers permitted to provide sensitive source code to external systems?
Does the organization have AI coding policies?
Are autonomous coding agents permitted to modify repositories?
Is provenance available for important software artifacts?
GitHub’s current documentation also describes controls related to public-code matching and emphasizes review and validation of suggestions.
Microsoft’s 2026 security guidance similarly describes AI as introducing issues around insecure code, opaque systems, data exposure, compliance, shadow AI, and tool sprawl.
For M&A, the important question is not “Was AI used?” but “What assurance controls governed AI-assisted changes?”
AI-assisted development can affect code provenance, security assurance, engineering governance, and the buyer’s confidence in the asset's maintainability.
AI-generated code should become a diligence attribute alongside architecture, dependencies, security, and technical debt.
Technical Debt, Architecture, Security, and Supply Chain Risk
Technical debt becomes an acquisition liability when it creates measurable future engineering work, constrains scalability, increases security exposure, or complicates integration. Architecture and supply-chain risks should be assessed alongside debt because dependencies, build systems, provenance, and deployment processes can create liabilities that are not visible in conventional code-quality reviews.
Technical Debt
Technical debt should be classified by business consequence rather than by the number of issues.
A useful model is:
Acceptable → Strategic → Accidental → Critical
Critical debt is debt that threatens security, reliability, scalability, compliance, maintainability, or a major product commitment.
Architecture
Architecture diligence should compare:
Declared Architecture vs Implemented Architecture
The assessment should examine actual service dependencies, database coupling, API relationships, cloud services, deployment paths, single points of failure, and legacy components.
Supply Chain
An SBOM provides structured information about software components and their relationships. CISA describes an SBOM as a formal record of the components and supply-chain relationships involved in building software.
SLSA adds another important dimension: provenance provides verifiable information about where, when, and how software artifacts were produced.
OWASP’s 2025 Top 10 explicitly elevates software supply-chain failures as a major application-security category, extending the concern beyond simply finding vulnerable dependencies.
Visual Risk Chain
Technical Condition
↓
Security / Architecture / Debt / Dependency Risk
↓
Operational Consequence
↓
Engineering Investment
↓
Financial Exposure
↓
Transaction Decision
A vulnerability, dependency, or architecture issue becomes financially relevant when it creates a credible path to cost, disruption, regulatory exposure, lost revenue, or delayed integration.
Technical debt, architecture, security, and supply-chain analysis should be evaluated as interconnected sources of acquisition risk.
The Enterprise Software Due-Diligence Framework
A practical enterprise software due-diligence framework should move from discovery to analysis, validation, quantification, decision, and post-acquisition monitoring. This prevents technical diligence from becoming a disconnected defect report and instead creates a traceable path from repository evidence to business risk and transaction action.
Discover
Establish the actual software estate:
Repositories
Services
Applications
Dependencies
Infrastructure
Build systems
CI/CD
Ownership
Production artifacts
Analyze
Determine what the software actually does and how it is connected.
Validate
Separate genuine material findings from false positives, stale issues, and low-impact observations.
Quantify
Estimate the implications in terms of:
Engineering effort
Modernization
Integration
Security remediation
Operational exposure
Compliance
Timeline
Decide
Translate findings into:
Proceed
Proceed with mitigation
Renegotiate
Require remediation
Escrow/holdback
Additional diligence
Do not proceed
Monitor
After closing, track whether the identified liabilities are being reduced and whether new technical risks emerge.
DISCOVER
↓
ANALYZE
↓
VALIDATE
↓
QUANTIFY
↓
DECIDE
↓
MONITOR
flowchart TD
A[Discover Software Estate] --> B[Analyze Code and Architecture]
B --> C[Validate Material Findings]
C --> D[Quantify Business and Financial Exposure]
D --> E[Transaction Decision]
E --> F[Post-Acquisition Monitoring]
F --> B
NIST’s SSDF is useful as part of the evidence model because its practices are designed to support secure software development and communication between software producers and acquirers.
The strongest diligence model creates a direct audit trail from technical evidence to executive decision.
Decision-grade reporting allows boards and investment committees to incorporate technical findings into valuation, risk allocation, and integration planning.
Software due diligence should produce decisions, not merely observations.
Turning Technical Findings Into Acquisition Decisions
Technical findings become acquisition decisions when they are translated into risk, business impact, financial exposure, and an appropriate transaction response. The strongest reporting chain is: technical finding → risk → business consequence → expected remediation or exposure → deal action.
| Technical Finding | Risk | Business Impact | Potential Deal Response |
|---|
| Critical dependency exposure | Security | Customer/regulatory exposure | Remediation condition |
| High architecture coupling | Integration | Higher integration cost | Price/risk adjustment |
| Severe technical debt | Maintainability | Increased engineering investment | Valuation adjustment |
| Weak provenance | Integrity/IP | Evidence uncertainty | Additional diligence |
| Unclear OSS licensing | Legal | IP/compliance exposure | Legal review |
| Concentrated code ownership | Operational | Key-person risk | Retention/transition plan |
| Poor testing around core logic | Reliability | Regression risk | Remediation plan |
| Uncontrolled AI-assisted development | Governance | Assurance uncertainty | Governance requirement |
The Code Registry’s emphasis on software asset valuation is relevant here because the technical condition of software should inform how much future investment the asset requires.
The purpose is not to produce a simplistic formula in which every technical defect reduces valuation by a fixed amount. Instead, technical evidence should inform the buyer’s estimate of future cash requirements, integration complexity, operational risk, and strategic flexibility.
Technical diligence and financial diligence should not operate as separate universes. Material technology findings should have a clear path into the investment committee’s risk model.
The value of technical due diligence lies in changing decisions before capital is committed.
Common Software Due-Diligence Mistakes
Common diligence failures include trusting management representations without code evidence, reviewing architecture diagrams without validating implementation, treating technical debt as ordinary engineering work, ignoring software provenance and licensing, focusing only on CVEs, and overlooking AI-assisted development. The underlying mistake is confusing the presence of software with evidence that the software is sustainable, secure, and economically maintainable.
The most consequential mistakes are:
Trusting the architecture diagram. Diagrams describe intended systems; repositories reveal implementation.
Counting defects instead of assessing materiality. Ten thousand low-impact findings can matter less than one critical dependency embedded in a core revenue path.
Ignoring technical debt. Debt becomes expensive when it constrains future product and integration decisions.
Treating security as a questionnaire. Security controls require evidence.
Ignoring provenance. Buyers should understand how important software artifacts were produced and controlled.
Overlooking open-source licensing. Software ownership is not simply equivalent to repository ownership.
Ignoring AI-assisted development. AI use introduces additional questions around review, provenance, governance, and security.
Measuring engineering speed rather than sustainability. High commit velocity does not demonstrate maintainability.
The recurring pattern behind these mistakes is an overreliance on indirect evidence.
Good software due diligence challenges assumptions with evidence rather than replacing one set of assumptions with another.
Future Outlook: From Technical Due Diligence to Continuous Software Intelligence
Software due diligence is likely to evolve from a transaction-stage investigation into continuous software intelligence. Code intelligence, AI-assisted analysis, software provenance, automated governance, policy as code, and continuous technical-debt monitoring can create a persistent view of software condition before, during, and after an acquisition.
The shift is already visible in secure software development.
NIST has published an SSDF community profile specifically addressing generative AI and dual-use foundation models, while its newer SSDF 1.2 revision is being developed to improve secure and reliable software practices.
Meanwhile, software supply-chain frameworks increasingly emphasize verifiable provenance. Google Open Source Security Team research has highlighted the importance of knowing whether delivered artifacts correspond to their expected origin, while SLSA formalizes provenance as verifiable information about how artifacts were produced.
The next generation of software due diligence will therefore increasingly examine not only:
What code exists?
but also:
Continuous software intelligence can reduce the gap between transaction-time technical diligence and post-acquisition reality.
This creates a technology governance mechanism that supports both integration management and ongoing software asset valuation.
The future of software diligence is continuous evidence about software condition, not a one-time technical review.
Conclusion
A software acquisition is not simply an acquisition of revenue, customers, contracts, and intellectual property. It is an acquisition of a living technical system whose future performance depends on the quality, security, architecture, dependencies, governance, and maintainability of its software.
The most important diligence question is therefore not whether the target has good technology. It is whether the buyer has sufficient evidence to understand the technology it is actually acquiring.
That requires looking beyond product demonstrations and architecture diagrams into source code, repositories, dependencies, build systems, software provenance, technical debt, security controls, and engineering practices.
AI-assisted software development makes this evidence requirement more important, not less. AI-generated code can accelerate engineering, but buyers still need to understand how generated changes were reviewed, tested, governed, and incorporated into the software lifecycle. GitHub itself emphasizes validation of Copilot output, while Microsoft has highlighted the expanding security and governance challenges associated with AI-assisted development and agentic systems.
For buyers, boards, and investment committees, the practical principle is straightforward:
The codebase is one of the strongest sources of evidence about what a software asset actually is—and therefore what it may ultimately be worth.
Organizations evaluating this question can use The Code Registry’s code intelligence and software governance perspective to structure a more evidence-driven software due-diligence assessment.
10 Frequently Asked Questions
1. What is software due diligence?
Software due diligence is the systematic assessment of a company’s software assets before an acquisition or investment. It examines source code, architecture, dependencies, security, technical debt, licensing, software provenance, infrastructure, testing, ownership, and maintainability to determine the technology’s condition and potential liabilities.
Unlike a product demonstration or management presentation, software due diligence examines evidence from the underlying technology. The objective is to identify risks that could increase post-acquisition costs, delay integration, constrain growth, or affect the value of the software asset.
2. What does software due diligence include?
Software due diligence typically includes source-code analysis, architecture assessment, technical debt analysis, security review, dependency analysis, licensing assessment, software supply-chain analysis, testing evaluation, infrastructure review, and software ownership assessment. The scope should reflect the strategic importance and complexity of the target’s technology.
A comprehensive assessment should also examine repository governance, CI/CD pipelines, software provenance, documentation, code ownership, cloud dependencies, compliance evidence, and AI-assisted development practices.
3. How do you audit source code before an acquisition?
Source code should be audited by first establishing the software inventory, then analyzing architecture, dependencies, security, technical debt, testing, ownership, and maintainability, and finally translating material findings into business and transaction risks. Automated analysis should be combined with expert technical validation.
A practical process is:
Discover repositories and production components.
Map dependencies and architecture.
Analyze security and technical debt.
Validate material findings.
Assess business and financial implications.
Present transaction-level recommendations.
4. What is technical due diligence in M&A?
Technical due diligence in M&A evaluates whether a target company’s technology can support its business strategy and whether hidden technical liabilities could affect the transaction. It typically covers architecture, software development practices, infrastructure, security, scalability, technical debt, engineering organization, and technology roadmap.
Software due diligence is a deeper component of this process because it examines the actual software asset rather than relying exclusively on interviews, documentation, and architecture presentations.
5. How does technical debt affect software valuation?
Technical debt can affect software valuation when it creates material future costs, constrains growth, increases operational risk, or requires significant modernization after acquisition. The existence of technical debt does not automatically reduce an asset’s value; its financial significance depends on severity, business impact, remediation effort, and strategic importance.
For example, technical debt concentrated in a non-critical internal application may have limited transaction impact. Debt embedded in the platform’s core revenue-generating services can represent a substantially different risk.
6. How do you identify hidden software risks in an acquisition?
Hidden software risks are identified by comparing management representations with evidence from source code, repositories, dependencies, architecture, security controls, infrastructure, and software-development practices. The goal is to identify discrepancies between the stated technology position and the technology actually operating the business.
Common areas include:
Undocumented dependencies
Architecture drift
Excessive technical debt
Concentrated code ownership
Weak testing
Security vulnerabilities
Open-source licensing exposure
Legacy infrastructure
Poor software provenance
Undocumented business logic
AI-generated code without adequate governance
7. How does AI-generated code affect software due diligence?
AI-generated code introduces additional questions around verification, security, provenance, licensing, maintainability, and governance. AI-generated code is not inherently unsafe or poor quality, but buyers should understand how coding assistants and autonomous agents were used and what controls governed their output.
Diligence should examine whether AI-generated changes received appropriate peer review, testing, security analysis, dependency assessment, and repository controls. It should also establish whether developers or agents were permitted to access sensitive source code or make changes to production systems.
8. What should buyers check in a software codebase?
Buyers should examine code quality, architecture, dependencies, security, technical debt, testing, documentation, ownership, licensing, software provenance, maintainability, and business-critical logic. They should also determine whether the implementation matches the architecture and product capabilities described by the seller.
The most important question is not simply whether the code contains defects. It is whether the codebase can sustainably support the business assumptions underlying the acquisition.
9. What is code intelligence?
Code intelligence is the analysis of software repositories and their relationships to understand how an organization’s codebase is structured, connected, maintained, and governed. It can combine source-code analysis, dependency mapping, architecture discovery, ownership analysis, technical-debt detection, and software inventory.
For software due diligence, code intelligence can help transform a large collection of repositories into an evidence-based view of the software asset, allowing buyers to identify critical components and relationships that may not be visible in conventional technical documentation.
10. How can software due diligence prevent acquisition mistakes?
Software due diligence can prevent acquisition mistakes by identifying material technical liabilities before the transaction closes. It gives buyers evidence about the condition of the software and helps translate technical findings into remediation costs, integration risks, security exposure, operational constraints, and potential transaction actions.
The result is not necessarily a recommendation to reject an acquisition. A strong diligence process may instead support:
Additional investigation
Purchase-price adjustment
Remediation requirements
Escrow or risk allocation
Engineering transition planning
Post-acquisition modernization funding
Continued monitoring
The central principle is simple: buyers should understand the software asset they are acquiring before they commit capital to it.
Join the conversation! Your thoughts help the community grow.