Software Due Diligence Dependency Disclosure

How to automate the third-party dependency disclosures required during M&A software due diligence.

What Is a Third-Party Dependency Disclosure?

A third-party dependency disclosure is a report listing every external software library, framework, or package used in a company's codebase, along with the version number and license type. This report is a standard requirement during M&A due diligence when a buyer needs to verify the seller's legal right to transfer its software intellectual property. Without a complete dependency disclosure, buyers face unknown license risks that can delay or derail an acquisition.

Why Dependency Disclosure Matters During M&A

Modern software applications rely on hundreds or even thousands of third-party libraries. Each library carries its own license terms, and some of those terms can create complications during an IP transfer. For example, if a seller's proprietary SaaS product incorporates a library licensed under the GNU General Public License (GPL), the buyer's legal team must assess whether that usage creates a copyleft obligation that could affect the proprietary nature of the software. Similarly, the GNU Affero General Public License (AGPL) has implications for network-distributed software that can surprise acquirers who are not aware of its presence.

Software licensing verification is a standard item on technical due diligence checklists. Buyers, their technical advisors, and legal counsel expect a complete inventory of third-party dependencies before closing. Failing to produce one signals either poor engineering governance or potential hidden risk, both of which can reduce the seller's negotiating position or trigger price adjustments.

The Traditional Approach to Dependency Disclosure

Without an automated tool, producing a third-party dependency disclosure typically involves running command-line tools like license-checker (for npm), pip-licenses (for Python), or composer licenses (for PHP) on each repository individually. A developer or technical lead then aggregates the results into a spreadsheet, manually reconciling differences in format across languages and package managers.

This manual process is time-consuming, error-prone, and often incomplete. Repositories get missed. Lock files are not always checked alongside manifest files. And when the seller has dozens or hundreds of repositories across a GitHub organization, the effort can stretch from hours to days. Under the tight timelines typical of M&A transactions, this manual approach puts the seller at a disadvantage.

How DependencyDesk Automates Dependency Disclosure

DependencyDesk eliminates the manual effort by connecting directly to a GitHub organization and analyzing every repository's dependency manifest files automatically. The process works in four steps: connect your GitHub organization via a secure read-only GitHub App, select the repositories to analyze, run the analysis, and export the resulting report as a CSV or view it as an interactive HTML report.

DependencyDesk completes organization-wide analysis in minutes rather than days. It supports JavaScript (package.json), PHP (composer.json), Ruby (Gemfile), and Python (requirements.txt, Pipfile, pyproject.toml). DependencyDesk never executes code or runs package manager install commands — it only reads static manifest files. After analysis, sellers can immediately delete all cached repository data from DependencyDesk's servers, ensuring no intellectual property is retained.

What the Report Includes

A DependencyDesk dependency disclosure report lists each third-party dependency along with its version number, license type, and the specific repository that uses it. Reports can be exported as CSV files for sharing with buyers, legal counsel, or advisory firms, or viewed as HTML reports in the browser. For dependencies where the license is not declared in the manifest file, DependencyDesk marks them as "Unknown" so the seller can follow up and verify manually.

Who Uses DependencyDesk for Disclosure?

DependencyDesk is used by sellers preparing for acquisition who need to produce third-party dependency disclosures quickly. Buyers and their technical advisors use it to independently verify a target's dependency landscape. Private equity and venture capital firms use it to audit dependency risk across portfolio companies. M&A advisory firms use it to manage the dependency disclosure workstream across multiple concurrent transactions.