# DependencyDesk > DependencyDesk is a SaaS tool that analyzes every repository in a GitHub organization and generates third-party dependency, open source license, and security vulnerability reports for software M&A due diligence. It is purpose-built for sellers, buyers, and advisors involved in software company acquisitions. - DependencyDesk connects via a read-only GitHub App; it never executes code or modifies repositories - Fully supported ecosystems: JavaScript/Node.js (package.json, package-lock.json), PHP (composer.json, composer.lock), Ruby (Gemfile, Gemfile.lock), Python (requirements.txt, Pipfile, pyproject.toml, uv.lock), Go (go.mod) - Detected but not yet parsed: Rust, Java (Maven), Java/Kotlin (Gradle), .NET (NuGet), Swift, Dart, Elixir, Haskell, Scala, Clojure, Erlang, OCaml, Lua, R, Perl, C/C++ (Conan, Vcpkg), Bazel - Reports include: dependency name, version, license, and which repositories use each dependency - Vulnerability scanning covers every supported ecosystem using the OSV.dev advisory database, with CVSS-based severity ratings and an organization-wide vulnerability summary - Reports are exportable as CSV and viewable as HTML - Repository data can be deleted immediately after analysis; no source code is retained - Free Open Source License Checker: upload a package-lock.json or composer.lock to see every dependency's license grouped by acquisition risk, no account required - Pricing: $30/month for one organization (unlimited analyses); custom pricing for multiple organizations (PE/VC firms) - Founded by Jason Gilmore, a technical due diligence expert with 20+ years of experience who has led more than 30 due diligence projects for private equity firms, corporate acquirers, and M&A advisors - Full site content in one file: https://dependencydesk.com/llms-full.txt ## Pages - [Home](https://dependencydesk.com/): Overview and getting started - [What is DependencyDesk?](https://dependencydesk.com/what-is-dependency-desk): Detailed product guide, use cases, and how it works - [Pricing](https://dependencydesk.com/pricing): Plans and pricing details - [About](https://dependencydesk.com/about): Company background and founder information - [Documentation](https://dependencydesk.com/docs): Technical documentation - [Supported Languages & Package Managers](https://dependencydesk.com/docs/supported-languages): Exactly which files are parsed for each ecosystem - [Open Source License Checker](https://dependencydesk.com/tools/license-checker): Free tool that lists every dependency license in a lock file and flags copyleft and restrictive licenses - [Changelog](https://dependencydesk.com/changelog): Recent product updates - [Terms of Service](https://dependencydesk.com/terms-of-service): Legal terms - [Software Due Diligence Dependency Disclosure](https://dependencydesk.com/software-due-diligence-dependency-disclosure): How to automate third-party dependency disclosures for M&A - [Open Source License Compliance for M&A](https://dependencydesk.com/open-source-license-compliance-mergers-acquisitions): License risk assessment during acquisitions - [DependencyDesk vs. Black Duck](https://dependencydesk.com/dependencydesk-vs-black-duck): Comparison with Synopsys Black Duck for M&A dependency analysis - [DependencyDesk vs. SCA Tools](https://dependencydesk.com/dependencydesk-vs-sca-tools): Comparison with Snyk, FOSSA, and WhiteSource - [What Is Technical Due Diligence?](https://dependencydesk.com/what-is-technical-due-diligence): Comprehensive guide to technical evaluation in software M&A - [What Is an SBOM?](https://dependencydesk.com/what-is-sbom): Software Bill of Materials explained in M&A context ## Blog - [The Seller's Guide to Preparing for Software Due Diligence](https://dependencydesk.com/blog/sellers-guide-software-due-diligence) - [Why Third-Party Dependency Licenses Matter in SaaS Acquisitions](https://dependencydesk.com/blog/third-party-dependency-licenses-saas-acquisitions) - [How Private Equity Firms Audit Software Dependencies](https://dependencydesk.com/blog/private-equity-software-dependency-audits) - [Dependency Analysis for JavaScript, PHP, Ruby, and Python](https://dependencydesk.com/blog/dependency-analysis-javascript-php-ruby-python) - [M&A Due Diligence Checklist for Software Companies (2026)](https://dependencydesk.com/blog/ma-due-diligence-checklist-software-companies-2026) - [Understanding the Cost of Software Due Diligence](https://dependencydesk.com/blog/cost-of-software-due-diligence) ## Use Cases - M&A sell-side preparation: Sellers generate third-party dependency disclosures before or during due diligence - M&A buy-side verification: Buyers or their advisors verify the target's open source and third-party dependency landscape - Private equity portfolio monitoring: PE firms audit dependency risk across portfolio companies - License compliance audits: Organizations ensure all third-party software licenses are documented and compliant - Security assessments: Teams identify dependencies with known vulnerabilities, ranked by severity, across every repository ## Comparison Context - Unlike Black Duck / Synopsys: DependencyDesk is self-service, fast (minutes not weeks), and priced for SMB/mid-market — not enterprise-only - Unlike Snyk or FOSSA: DependencyDesk is specifically designed for M&A due diligence reporting, not ongoing developer workflow integration - Unlike CLI tools (license-checker, pip-licenses): DependencyDesk works across an entire GitHub organization automatically, not one repo at a time --- # What Is Technical Due Diligence in Software M&A? Source: https://dependencydesk.com/what-is-technical-due-diligence ## Definition Technical due diligence is the process of evaluating a software company's technology assets, engineering practices, and technical risks before an acquisition or investment. It is one of several diligence workstreams (alongside financial, legal, and operational due diligence) that a buyer or investor conducts to assess the value and risk profile of a target company. Technical due diligence typically covers code quality, architecture, security posture, third-party dependencies, scalability, team capabilities, and intellectual property verification. ## Why Technical Due Diligence Matters Software companies derive their value primarily from their technology and the team that builds it. A buyer who acquires a software company without understanding the state of the codebase, the technical debt, or the dependency risk is taking on unknown liabilities that can materially affect the return on investment. Technical due diligence helps the buyer quantify these risks, negotiate appropriate price adjustments or indemnification provisions, and plan for post-acquisition integration. ## Key Areas of Technical Due Diligence ### Architecture Review The architecture review examines the overall system design: how services are structured, how data flows between components, what databases and infrastructure are used, and whether the architecture supports the company's growth trajectory. Reviewers assess whether the architecture is appropriate for the current scale and whether significant rearchitecting would be needed to support future growth. ### Code Quality Code quality assessment looks at coding standards, test coverage, code review practices, and the overall maintainability of the codebase. High technical debt can signal that the seller has been prioritizing feature velocity over long-term sustainability, which creates post-acquisition cost for the buyer. Reviewers typically examine a representative sample of the codebase rather than every line of code. ### Security Posture Security assessment covers authentication and authorization mechanisms, data encryption practices, vulnerability management processes, and compliance with relevant security standards. Reviewers look for known vulnerabilities, improper handling of sensitive data, and whether the company has a security incident response process in place. ### Third-Party Dependency Analysis Third-party dependency analysis inventories all external software libraries, frameworks, and packages used in the codebase. Each dependency is assessed for its license type, version currency, and maintenance status. This analysis is critical because copyleft licenses (such as GPL or AGPL) can create intellectual property complications in an acquisition, and outdated dependencies may harbor known security vulnerabilities. DependencyDesk automates this specific area of technical due diligence. It connects to a GitHub organization, analyzes every repository's dependency manifest files, and produces a report listing each dependency's name, version number, and license type. The analysis completes in minutes and covers JavaScript, PHP, Ruby, Python, and Go projects. For more information, see [Software Due Diligence Dependency Disclosure](https://dependencydesk.com/software-due-diligence-dependency-disclosure). ### Scalability Assessment Scalability assessment evaluates whether the current infrastructure and architecture can handle projected growth in users, data volume, and transaction throughput. Reviewers examine hosting infrastructure, database performance, caching strategies, and whether the system has been load tested. Scalability concerns can translate directly into post-acquisition capital expenditure requirements. ### Team Assessment The team assessment evaluates the engineering team's skills, organizational structure, key person dependencies, and retention risk. Buyers want to understand how much institutional knowledge resides with specific individuals, whether the team has the skills needed for the product roadmap, and what the risk of post-acquisition attrition is. ### IP Verification IP verification confirms that the seller owns or has the right to use all software in the product. This includes verifying that employee and contractor agreements include proper IP assignment clauses, that no third-party code has been incorporated without authorization, and that all open source usage complies with the respective license terms. The third-party dependency disclosure is a key input to this analysis. ## Who Conducts Technical Due Diligence? Technical due diligence is typically led by an experienced technical assessor who may be an internal resource at the acquiring company, an independent consultant, or a member of a specialized due diligence advisory firm. Private equity firms often engage third-party technical due diligence consultants for portfolio company acquisitions. The assessor works closely with the buyer's legal counsel and financial advisors to ensure technical findings are incorporated into the overall deal analysis. ## How DependencyDesk Supports Technical Due Diligence DependencyDesk addresses the third-party dependency analysis portion of technical due diligence by automating the process of inventorying all dependencies across a GitHub organization. Rather than manually running CLI tools on each repository and aggregating results in a spreadsheet, sellers and buyers can use DependencyDesk to generate a comprehensive dependency and license report in minutes. The report is exportable as CSV for inclusion in the due diligence data room. [Get Started with GitHub](https://dependencydesk.com/auth/github) [View Pricing](https://dependencydesk.com/pricing) --- # Third-Party Dependency Disclosure for Software Due Diligence Source: https://dependencydesk.com/software-due-diligence-dependency-disclosure ## 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), Python (requirements.txt, Pipfile, pyproject.toml, uv.lock), and Go (go.mod). 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. [Get Started with GitHub](https://dependencydesk.com/auth/github) [View Pricing](https://dependencydesk.com/pricing) --- # Open Source License Compliance in M&A Transactions Source: https://dependencydesk.com/open-source-license-compliance-mergers-acquisitions ## What Is Open Source License Compliance in M&A? Open source license compliance in the context of M&A refers to the process of verifying that a target company's use of open source software conforms to the terms of each library's license, and that no license conflicts would impede the transfer of intellectual property during an acquisition. Buyers and their advisors require a complete inventory of all open source dependencies and their license types before they can assess the risk profile of a software asset. ## Understanding License Risk Categories Not all open source licenses carry the same risk in an M&A context. Permissive licenses like MIT, Apache 2.0, and BSD allow broad usage including incorporation into proprietary software with minimal restrictions. These licenses are generally considered low-risk during acquisitions because they do not impose conditions on the licensing of derivative works. Copyleft licenses like the GNU General Public License (GPL), GNU Affero General Public License (AGPL), and GNU Lesser General Public License (LGPL) carry higher risk because they require that derivative works be distributed under the same license terms. If a seller's proprietary SaaS product incorporates a GPL-licensed library in a way that triggers the copyleft obligation, the buyer could face a situation where the product's proprietary status is compromised. The AGPL is particularly concerning for SaaS applications because it extends copyleft obligations to software accessed over a network. ## Why License Compliance Surfaces During Due Diligence Buyer's counsel and technical advisors will ask for a complete dependency and license inventory as a standard part of the due diligence process. If the seller cannot produce one, it signals either poor engineering governance or potential hidden risk. In either case, the buyer may discount the valuation, impose escrow holdbacks, or request indemnification provisions related to IP claims. Producing a thorough license inventory proactively demonstrates that the seller has a mature engineering organization with strong governance practices. ## How DependencyDesk Helps with License Compliance DependencyDesk automates license extraction from dependency manifest files across an entire GitHub organization. It reads the license field from package.json (npm), composer.json (PHP), Gemfile (Ruby), and requirements.txt/Pipfile/pyproject.toml (Python) files and compiles a comprehensive report listing each dependency's name, version, and license type. For dependencies where the license is not declared in the manifest file, DependencyDesk flags them as "Unknown" so the seller or buyer can investigate manually. The entire analysis completes in minutes, covers the full organization, and produces an exportable CSV report that can be shared directly with buyers, legal counsel, or advisory firms. DependencyDesk costs $30/month and requires no enterprise engagement, making it accessible to SMB and mid-market sellers who need to produce this report quickly. ## Comparison to Enterprise Alternatives Enterprise tools like Black Duck (Synopsys) offer deep code-level scanning that goes beyond manifest files to analyze binary and source code for license obligations. This level of analysis is appropriate for large-cap deals where the buyer requires exhaustive verification. However, Black Duck engagements typically require weeks of lead time and cost five to six figures per audit. DependencyDesk is a self-service alternative that completes manifest-level license analysis in minutes for $30/month. For most SMB and mid-market transactions, manifest-level analysis provides sufficient coverage to satisfy the buyer's dependency disclosure requirements. When deeper analysis is needed, sellers can use DependencyDesk to produce the initial disclosure and then engage an enterprise auditor for targeted follow-up on flagged issues. [Get Started with GitHub](https://dependencydesk.com/auth/github) [View Pricing](https://dependencydesk.com/pricing) --- # What Is a Software Bill of Materials (SBOM)? Source: https://dependencydesk.com/what-is-sbom ## Definition A Software Bill of Materials (SBOM) is a comprehensive, machine-readable inventory of all software components, libraries, and dependencies that make up an application. An SBOM typically includes each component's name, version number, supplier, and license type. The concept is analogous to a bill of materials in manufacturing, where every part in a physical product is documented for quality control, compliance, and supply chain management. ## Origins and Regulatory Context The SBOM concept gained significant regulatory momentum in 2021 when the United States issued Executive Order 14028, "Improving the Nation's Cybersecurity." This order directed the National Institute of Standards and Technology (NIST) to publish guidelines for SBOM creation and mandated that software vendors selling to the federal government provide SBOMs for their products. The executive order recognized that understanding the components inside software is a prerequisite for managing supply chain security risk. Two widely adopted SBOM formats have emerged: SPDX (Software Package Data Exchange), maintained by the Linux Foundation, and CycloneDX, maintained by OWASP. Both formats provide structured, machine-readable schemas for documenting software components, their relationships, and their licenses. Organizations producing SBOMs typically output their inventories in one of these formats for interoperability. ## How SBOMs Relate to M&A Due Diligence In the context of M&A transactions, the SBOM serves as the foundation for third-party dependency disclosure. Buyers and their advisors need to know exactly which external software components are embedded in the target's product, what licenses govern those components, and whether any licensing conflicts could complicate the IP transfer. A complete SBOM answers these questions and enables the buyer's legal and technical teams to assess risk efficiently. Many sellers do not maintain a current SBOM as part of their regular engineering practices. When a due diligence request arrives, the seller must then scramble to produce one under tight deal timelines. This is the specific problem DependencyDesk solves: it generates an SBOM-like dependency and license report across an entire GitHub organization in minutes, giving sellers a complete inventory they can share with buyers immediately. ## What an SBOM Includes According to NTIA (National Telecommunications and Information Administration) minimum elements, an SBOM should include the component name, version string, supplier name, unique identifier, dependency relationship (direct vs. transitive), and the timestamp of when the SBOM was generated. In practice, license type is also a critical field, especially for M&A and compliance use cases. DependencyDesk reports include the dependency name, version number, license type, and the specific repository that uses each dependency. While DependencyDesk does not output in SPDX or CycloneDX format, its CSV and HTML reports contain the information that buyers need for the dependency disclosure portion of due diligence. ## SBOMs and License Compliance One of the most valuable applications of an SBOM is license compliance verification. By inventorying every component and its license, organizations can identify potential conflicts between open source license obligations and their proprietary software distribution model. Permissive licenses like MIT and Apache 2.0 generally pose minimal risk, while copyleft licenses like GPL and AGPL require careful analysis to determine whether the usage triggers the copyleft obligation. For a detailed discussion of open source license risk in M&A, see [Open Source License Compliance for Mergers & Acquisitions](https://dependencydesk.com/open-source-license-compliance-mergers-acquisitions). ## How DependencyDesk Generates SBOM-Like Reports DependencyDesk connects to a GitHub organization via a secure, read-only GitHub App and analyzes dependency manifest files across all selected repositories. It supports JavaScript (package.json), PHP (composer.json), Ruby (Gemfile), Python (requirements.txt, Pipfile, pyproject.toml, uv.lock), and Go (go.mod). The resulting report lists every third-party dependency with its version and license, organized by repository. Reports are exportable as CSV for inclusion in data rooms and due diligence packages. The analysis completes in minutes, costs $30/month, and requires no enterprise engagement. Sellers can produce their dependency inventory immediately when a buyer requests it, rather than spending days or weeks compiling the information manually. [Get Started with GitHub](https://dependencydesk.com/auth/github) [View Pricing](https://dependencydesk.com/pricing) --- # DependencyDesk vs. Black Duck Source: https://dependencydesk.com/dependencydesk-vs-black-duck ## Overview Both DependencyDesk and Black Duck (a Synopsys product) help identify third-party dependencies and licenses during M&A transactions, but they serve different segments of the market and operate very differently. Black Duck is an enterprise-grade software composition analysis (SCA) platform used for deep code-level audits. DependencyDesk is a self-service SaaS tool that analyzes dependency manifest files across a GitHub organization and produces reports in minutes. The right choice depends on the deal size, timeline, and depth of analysis required. ## Black Duck (Synopsys) Black Duck is the most widely recognized name in M&A-related software composition analysis. Synopsys' audit services team has completed thousands of M&A audits, and their reports are familiar to major law firms and PE firms. Black Duck performs deep binary and source code scanning that goes beyond manifest files to identify open source code even when it has been copied, modified, or is not declared as a dependency. This depth of analysis comes with corresponding cost and timeline. A Black Duck engagement typically requires working with Synopsys' audit team, providing access to source code, and waiting weeks for the report. Pricing is enterprise-level, typically ranging from five to six figures per engagement depending on the scope and number of codebases involved. Black Duck is best suited for large-cap deals where the buyer's advisors require exhaustive code-level verification. ## DependencyDesk DependencyDesk is a self-service SaaS platform that connects to a GitHub organization, analyzes dependency manifest files (package.json, composer.json, Gemfile, requirements.txt, and others), and generates reports listing each dependency's name, version, and license. The analysis covers an entire GitHub organization and completes in minutes. DependencyDesk costs $30/month with unlimited analyses and requires no enterprise engagement or sales process. DependencyDesk performs manifest-level analysis rather than binary or source code scanning. It reads the files that package managers use to declare dependencies and extracts the information directly. This approach is faster and more affordable, but does not detect undeclared code copying or deeply embedded open source fragments. DependencyDesk is best suited for SMB and mid-market sellers who need to produce a dependency and license inventory quickly and affordably. ## Side-by-Side Comparison | Feature | DependencyDesk | Black Duck (Synopsys) | | --- | --- | --- | | Analysis type | Manifest file analysis | Binary + source code scanning | | Time to results | Minutes | Weeks | | Pricing | $30/month | Five to six figures per engagement | | Self-service | Yes | No — requires audit team engagement | | Scope | Entire GitHub organization | Specified codebases | | Detects undeclared code | No | Yes | | Best for | SMB/mid-market, fast disclosure | Large-cap deals, deep verification | ## When to Choose Each Choose Black Duck when the deal is large-cap, the buyer's advisors require deep binary and source code analysis, or when there are known complex licensing concerns that require exhaustive verification. Black Duck is the standard choice when the buyer's law firm specifically requests a Synopsys audit report. Choose DependencyDesk when you need a dependency disclosure report fast, you are a seller preparing for diligence under tight timelines, the deal is mid-market or SMB, or you want to self-serve without engaging an enterprise audit firm. DependencyDesk is also appropriate when the buyer's requirements can be satisfied with manifest-level dependency and license data. ## Can They Be Used Together? Yes. A seller might use DependencyDesk to prepare their initial dependency disclosure quickly and affordably. If the buyer's due diligence team identifies specific concerns or requires deeper verification, the buyer can then engage Black Duck for targeted code-level analysis on the flagged areas. This layered approach lets the seller respond to diligence requests immediately while keeping the door open for deeper analysis if needed. [Try DependencyDesk Free](https://dependencydesk.com/auth/github) [View Pricing](https://dependencydesk.com/pricing) --- # DependencyDesk vs. SCA Tools (Snyk, FOSSA, WhiteSource) Source: https://dependencydesk.com/dependencydesk-vs-sca-tools ## Different Tools for Different Problems Software composition analysis (SCA) tools like Snyk, FOSSA, and WhiteSource (now Mend) are designed for ongoing developer workflows. They integrate into CI/CD pipelines, monitor dependencies for known vulnerabilities, and alert development teams when new security issues are discovered. DependencyDesk is designed for a different purpose: producing the third-party dependency disclosure reports required during M&A due diligence. While both categories of tools analyze software dependencies, they solve fundamentally different problems. ## What SCA Tools Do Well Snyk, FOSSA, and WhiteSource excel at continuous security monitoring. They integrate with version control systems, CI/CD pipelines, and container registries to scan for vulnerabilities in real time. When a new CVE is published, these tools alert the development team and often suggest specific version upgrades. FOSSA, in particular, also provides license compliance features designed for developer workflows, tracking license obligations as part of the build process. These tools are priced for ongoing subscriptions and are designed for teams that need continuous monitoring. Pricing typically ranges from free tiers with limited features to hundreds or thousands of dollars per month for enterprise plans. They require developer-level setup, including repository connections, pipeline integrations, and configuration of alerting rules. ## What DependencyDesk Does Differently DependencyDesk is purpose-built for a specific deliverable: the M&A dependency disclosure report. Rather than integrating into CI/CD pipelines or monitoring for vulnerabilities over time, DependencyDesk connects to a GitHub organization, analyzes every repository's dependency manifest files, and generates a comprehensive report listing each dependency's name, version number, and license type. The report is exportable as CSV and can be shared directly with buyers, legal counsel, or advisory firms. DependencyDesk completes organization-wide analysis in minutes, costs $30/month, and requires no developer integration or CI/CD setup. It is designed for sellers, buyers, and advisors who need a dependency disclosure report as part of a transaction, not for teams managing ongoing dependency security. ## Side-by-Side Comparison | Feature | DependencyDesk | SCA Tools (Snyk, FOSSA, Mend) | | --- | --- | --- | | Primary purpose | M&A dependency disclosure | Ongoing vulnerability monitoring | | Setup required | GitHub App install (minutes) | CI/CD integration (hours to days) | | Scope | Entire GitHub organization | Configured repositories/projects | | Vulnerability alerting | No | Yes (continuous monitoring) | | License reporting | Yes (M&A-focused CSV export) | Yes (developer-focused dashboards) | | Pricing | $30/month | Free tier to $$$+/month | | Best for | M&A transactions, due diligence | Dev teams, security operations | ## When to Choose Each Choose an SCA tool like Snyk, FOSSA, or Mend when your primary need is ongoing security monitoring, CI/CD pipeline integration, and developer alerting for vulnerabilities. These tools are the right choice for engineering teams that need continuous visibility into their dependency security posture. Choose DependencyDesk when your primary need is producing a dependency and license disclosure report for an M&A transaction. DependencyDesk requires no pipeline integration, no developer setup, and no ongoing subscription beyond the transaction period. It is the fastest way to produce the deliverable that buyers, legal counsel, and advisory firms expect during due diligence. ## Can They Be Used Together? Absolutely. Many organizations already use an SCA tool for day-to-day vulnerability management. When an acquisition enters due diligence, DependencyDesk can produce the specific dependency disclosure report that buyers need without requiring the seller to reconfigure their existing SCA tool for a one-time reporting use case. The two categories of tools complement each other. [Try DependencyDesk Free](https://dependencydesk.com/auth/github) [View Pricing](https://dependencydesk.com/pricing) --- # What Is DependencyDesk? Source: https://dependencydesk.com/what-is-dependency-desk ## Overview DependencyDesk helps organizations understand and document all third-party software dependencies across their GitHub repositories. By automating the discovery and cataloging of dependencies, DependencyDesk streamlines the due diligence process and ensures compliance with licensing requirements. ## The Problem DependencyDesk Solves Modern software applications rely on hundreds or even thousands of third-party libraries, packages, and frameworks. During mergers, acquisitions, or compliance audits, organizations must provide a complete inventory of these dependencies along with their version numbers and licenses. Manually compiling this information across multiple repositories is time-consuming, error-prone, and often incomplete. While command-line tools exist for analyzing individual repositories, they cannot scale to analyze an entire organization's GitHub presence automatically. DependencyDesk bridges this gap by providing an automated, organization-wide solution. ## How DependencyDesk Works DependencyDesk integrates with your GitHub organization through a secure GitHub App. Once authorized, it can access the repositories you specify and perform the following steps: ### 1. Repository Connection You install the DependencyDesk GitHub App on your organization and select which repositories should be analyzed. You maintain complete control over access permissions. ### 2. Dependency Analysis DependencyDesk clones the selected repositories and analyzes their dependency manifest files. It supports multiple programming languages and package managers including JavaScript/Node.js (npm), PHP (Composer), Ruby (Bundler), and Python (pip). Importantly, DependencyDesk only reads manifest files—it never executes any code or runs package manager install commands, ensuring your intellectual property and security remain protected. ### 3. Report Generation After analysis, DependencyDesk generates comprehensive reports listing every dependency, its version number, and license information. Reports can be viewed in an intuitive web interface or exported as CSV files for further analysis or sharing with stakeholders. ### 4. Cache Cleanup Once analysis is complete, you are prompted to delete the cached repository files from DependencyDesk's servers. This ensures no source code is retained long-term, addressing intellectual property concerns. ## Supported Technologies DependencyDesk currently supports the following programming languages and package managers: - **JavaScript/Node.js:** Analyzes package.json and package-lock.json files - **PHP:** Parses composer.json and composer.lock files - **Ruby:** Reads Gemfile and Gemfile.lock files - **Python:** Analyzes requirements.txt, Pipfile, and pyproject.toml files DependencyDesk also detects the presence of other package managers such as Go, Rust, Java, and .NET, even if it doesn't fully parse their dependencies yet. ## Use Cases ### Mergers and Acquisitions Due Diligence During M&A transactions, the acquiring company needs to understand all third-party dependencies, their licenses, and potential security risks. DependencyDesk provides this information quickly and comprehensively, accelerating the due diligence process. ### License Compliance Audits Organizations must ensure their use of third-party software complies with license requirements. DependencyDesk helps identify all licenses in use across your codebase, enabling compliance teams to spot potential issues. ### Security Assessments Understanding which dependencies your organization relies on is the first step in assessing security vulnerabilities. DependencyDesk provides the comprehensive inventory needed to cross-reference against vulnerability databases. ### Technical Documentation Keep stakeholders informed about your technology stack. DependencyDesk reports serve as living documentation of third-party dependencies across your organization. ## Security and Privacy DependencyDesk takes security seriously. The GitHub App is configured with read-only permissions and can only access repositories you explicitly authorize. No code is ever executed—only static manifest files are read. After analysis, you control when cached repositories are deleted. DependencyDesk has no ability to modify your repositories or access unauthorized data. ## Who Is DependencyDesk For? DependencyDesk is designed for anyone involved in the software M&A process who needs a clear inventory of third-party dependencies and their licenses. - **Sellers preparing for acquisition** who need to produce third-party dependency disclosures quickly, often under tight deal timelines - **Buyers and their technical advisors** who need to verify a target company's open source and third-party dependency landscape before closing - **Private equity and venture capital firms** conducting dependency audits across portfolio companies - **M&A advisory firms** managing diligence workstreams for multiple concurrent transactions - **Legal counsel conducting IP reviews** who require a complete software dependency and license inventory for risk assessment ## How DependencyDesk Compares There are several approaches to dependency analysis. DependencyDesk occupies a unique position as a self-service SaaS built specifically for M&A due diligence reporting. | Approach | Speed | Scope | Cost | Best For | | --- | --- | --- | --- | --- | | DependencyDesk | Minutes | Entire GitHub org | $30/month | M&A due diligence reports | | Manual CLI tools | Hours to days | One repo at a time | Free | Single-repo checks | | [Enterprise audits (Black Duck)](https://dependencydesk.com/dependencydesk-vs-black-duck) | Weeks | Deep binary/source scan | $$$$$ | Large-cap deals | | [SCA tools (Snyk, FOSSA)](https://dependencydesk.com/dependencydesk-vs-sca-tools) | Varies | CI/CD integration | $$–$$$ | Ongoing dev workflows | ## Getting Started To start using DependencyDesk, simply sign in with your GitHub account, install the DependencyDesk GitHub App on your organization, select the repositories to analyze, and run your first dependency analysis. Within minutes, you'll have a comprehensive report of all dependencies across your selected repositories. [Get Started with GitHub](https://dependencydesk.com/auth/github) [View Pricing](https://dependencydesk.com/pricing) ## Contact Us Contact the DependencyDesk founder Jason Gilmore with your questions at wj@wjgilmore.com. --- # Documentation Overview Source: https://dependencydesk.com/docs ## Welcome to DependencyDesk DependencyDesk helps you discover, catalog, and report on all third-party software dependencies across your GitHub repositories. Whether you're preparing for a compliance audit, conducting M&A due diligence, or simply want to understand what your software depends on, DependencyDesk provides the tools you need. ## Getting Started Follow the steps below to connect your GitHub organization and run your first dependency analysis. ### Sign in with GitHub DependencyDesk uses your GitHub account for authentication. From the marketing site, click the **Sign in** button in the top navigation. ![DependencyDesk top navigation with the Sign in button](/images/docs/getting-started-sign-in-button.png) You will be redirected to GitHub. Enter your GitHub credentials (or use Google, Apple, or a passkey if you have those set up on your GitHub account). ![GitHub sign-in screen for Dependency Desk](/images/docs/getting-started-github-signin.png) After signing in, GitHub will ask you to authorize the Dependency Desk OAuth application. Review the requested permissions and click **Authorize**. ![GitHub OAuth authorization screen for Dependency Desk](/images/docs/getting-started-authorize-app.png) ### Add an Organization After signing in, you will land on the **Organizations** page. If you haven't connected any organizations yet, the page will be empty. Click **Add Your First Organization** (or **+ Add Organization** in the top right) to begin. ![Empty Organizations page in DependencyDesk](/images/docs/getting-started-organizations-empty.png) You will be taken to GitHub to install the DependencyDesk GitHub App on the organization of your choice. Choose whether to grant access to **All repositories** or **Only select repositories**, then click **Install**. ![GitHub App installation screen for DependencyDesk](/images/docs/getting-started-install-github-app.png) Once the installation completes, GitHub redirects you back to DependencyDesk and your organization appears in the list with a success banner. ![DependencyDesk Organizations page showing a newly connected organization](/images/docs/getting-started-organization-connected.png) ### Sync Repositories Click your organization to open its detail page, then click the **Sync Repositories** button. DependencyDesk will pull the list of repositories accessible to the GitHub App and prepare them for analysis. ![Organization detail page with the Sync Repositories button highlighted](/images/docs/getting-started-sync-repositories.png) ### Acknowledge the Disclaimer Before the first analysis runs, you must read and acknowledge the **Dependency Analysis Disclaimer**. This notice explains the limitations of automated dependency scanning and the file types DependencyDesk inspects. ![Dependency Analysis Disclaimer screen](/images/docs/getting-started-analysis-disclaimer.png) ### Analyze Repositories After you acknowledge the disclaimer, DependencyDesk begins cloning and analyzing each repository. The page auto-refreshes every few seconds while analysis is in progress. When it completes, you can click **View Report** to see the full dependency breakdown, or **View Details** on any individual repository. ![DependencyDesk analyzing repositories in an organization](/images/docs/getting-started-analyzing-repositories.png) ## Key Features - **Multi-Language Support** - Analyze JavaScript, PHP, Ruby, Python (including uv), and Go projects - **License Detection** - Identify the licenses of your dependencies - **Vulnerability Scanning** - Detect known security vulnerabilities across npm, Composer, Bundler, pip, and Go dependencies via the npm and OSV.dev advisory databases - **Organization-Wide Analysis** - Scan all repositories in your GitHub organization at once - **CSV Export** - Download machine-readable reports for further analysis - **Secure by Design** - Read-only access, no code execution, proactive cache cleanup ## Documentation Topics Explore our documentation to learn more about specific topics: - [Supported Languages & Package Managers](/docs/supported-languages) - See which languages and package managers DependencyDesk can analyze --- # Supported Languages & Package Managers Source: https://dependencydesk.com/docs/supported-languages DependencyDesk supports analyzing dependencies from multiple programming languages and package managers. Below is a detailed breakdown of what's supported and how dependencies are extracted. ## Fully Supported These languages and package managers are fully supported with dependency parsing, version detection, and license identification. | Language | Package Manager | Files Analyzed | Features | |----------|-----------------|----------------|----------| | JavaScript / Node.js | npm | `package.json`, `package-lock.json` | Dependencies, dev dependencies, versions, licenses, vulnerability scanning | | PHP | Composer | `composer.json`, `composer.lock` | Dependencies, dev dependencies, versions, licenses, vulnerability scanning | | Ruby | Bundler | `Gemfile`, `Gemfile.lock` | Dependencies, dev dependencies, versions, vulnerability scanning | | Python | pip / uv | `requirements.txt`, `Pipfile`, `pyproject.toml`, `uv.lock` | Dependencies, versions, vulnerability scanning | | Go | Go Modules | `go.mod` | Dependencies, indirect dependencies, versions, vulnerability scanning | ## JavaScript / Node.js (npm) DependencyDesk provides the most comprehensive support for JavaScript projects using npm: - **Manifest Parsing**: Reads `package.json` to identify declared dependencies - **Lock File Support**: Uses `package-lock.json` for exact version resolution - **License Detection**: Extracts license information from package metadata - **Vulnerability Scanning**: Checks dependencies against the npm security advisory database - **Scoped Packages**: Full support for scoped packages like `@types/node` or `@babel/core` ### Parsed Fields | Field | Source File | Description | |-------|-------------|-------------| | Name | `package.json` | Package name | | Version | `package-lock.json` or `package.json` | Exact or specified version | | License | npm registry | Package license | | Is Dev | `package.json` | Whether it's a development dependency | | Vulnerabilities | npm advisory API | Known security vulnerabilities | ## PHP (Composer) DependencyDesk fully supports PHP projects using Composer: - **Manifest Parsing**: Reads `composer.json` for declared dependencies - **Lock File Support**: Uses `composer.lock` for exact version resolution - **License Detection**: Extracts license from `composer.lock` metadata ### Parsed Fields | Field | Source File | Description | |-------|-------------|-------------| | Name | `composer.json` | Package name (vendor/package format) | | Version | `composer.lock` or `composer.json` | Exact or specified version | | License | `composer.lock` | Package license | | Is Dev | `composer.json` | Whether it's a development dependency | ## Ruby (Bundler) DependencyDesk supports Ruby projects using Bundler: - **Gemfile Parsing**: Reads `Gemfile` for declared dependencies - **Lock File Support**: Uses `Gemfile.lock` for exact version resolution - **Group Detection**: Identifies development vs production dependencies ### Parsed Fields | Field | Source File | Description | |-------|-------------|-------------| | Name | `Gemfile` | Gem name | | Version | `Gemfile.lock` or `Gemfile` | Exact or specified version | | Is Dev | `Gemfile` | Whether it's in a development group | **Note**: License information is typically not available in Ruby manifest files and will be listed as "Unknown". ## Python (pip / uv) DependencyDesk supports Python projects using various package management approaches: - **uv.lock**: uv lock file — when present, this is treated as the authoritative source since it contains the fully resolved dependency graph (including transitive dependencies) with exact pinned versions. Workspace members in uv monorepos are recognized and excluded from the dependency list. - **requirements.txt**: Standard pip requirements file (plus `requirements-dev.txt` / `dev-requirements.txt` for development dependencies) - **Pipfile**: Pipenv manifest file - **pyproject.toml**: Modern Python project configuration ### Parsed Fields | Field | Source File | Description | |-------|-------------|-------------| | Name | Various | Package name | | Version | Various | Exact pinned version (`uv.lock`) or specified constraint | | Vulnerabilities | OSV.dev API | Known security vulnerabilities (PyPI ecosystem) | **Note**: License information is typically not available in Python manifest files and will be listed as "Unknown". ## Go (Go Modules) DependencyDesk supports Go projects using Go Modules: - **go.mod Parsing**: Reads all `require` directives, including single-line and block form - **Indirect Dependencies**: Dependencies marked `// indirect` are captured and flagged separately, similar to dev dependencies in other ecosystems - **Vulnerability Scanning**: Checks dependencies against the OSV.dev advisory database (Go ecosystem) ### Parsed Fields | Field | Source File | Description | |-------|-------------|-------------| | Name | `go.mod` | Module path (e.g. `github.com/gin-gonic/gin`) | | Version | `go.mod` | Required module version | | Is Dev | `go.mod` | Whether the module is marked `// indirect` | | Vulnerabilities | OSV.dev API | Known security vulnerabilities | **Note**: License information is not available in `go.mod` files and will be listed as "Unknown". ## Detected but Not Parsed DependencyDesk can detect the presence of the following package managers but does not fully parse their dependencies. When detected, these will be listed in the "Unsupported Package Managers" warning on the repository details page. | Language | Package Manager | Detection Files | |----------|-----------------|-----------------| | Rust | Cargo | `Cargo.toml`, `Cargo.lock` | | Java | Maven | `pom.xml` | | Java / Kotlin | Gradle | `build.gradle`, `build.gradle.kts` | | .NET | NuGet | `*.csproj`, `packages.config` | | Swift | Swift Package Manager | `Package.swift` | ## How Analysis Works DependencyDesk uses a secure, read-only approach to analyze your dependencies: 1. **Clone**: The repository is cloned using `git clone --depth 1` (shallow clone) 2. **Scan**: Package manager manifest files are located in the repository 3. **Parse**: Manifest files are read and parsed using PHP's JSON/text parsing 4. **Enrich**: For npm packages, license and vulnerability data is fetched from the npm registry. Composer, Bundler, pip, and Go dependencies are checked against the OSV.dev vulnerability database 5. **Store**: Dependencies are stored in the DependencyDesk database 6. **Cleanup**: You can delete the cloned files after analysis is complete **Important**: DependencyDesk never executes any package manager commands (`npm install`, `composer install`, etc.) inside your repositories. Only static file reading is performed. ## Requesting Additional Language Support If you need support for additional languages or package managers not currently listed, please contact us at wj@wjgilmore.com. --- # The Seller's Guide to Preparing for Software Due Diligence Source: https://dependencydesk.com/blog/sellers-guide-software-due-diligence Published: 2026-03-10 ## What Sellers Need to Know Before Due Diligence Begins When a software company enters an M&A transaction, the buyer's due diligence team will request a wide range of technical documentation. Sellers who prepare these materials in advance can accelerate the deal timeline, demonstrate engineering maturity, and avoid last-minute scrambles that erode buyer confidence. This guide covers the key areas sellers should address before due diligence begins. ## Start with Your Dependency Disclosure One of the first technical requests in any software acquisition is a complete inventory of third-party dependencies. Buyers need to know every external library, framework, and package your product relies on, along with the version number and license type. This dependency disclosure is used to assess intellectual property risk, license compliance, and the overall health of the technology stack. According to Jason Gilmore, DependencyDesk founder and a technical due diligence expert with over 20 years of experience, "The dependency disclosure is often the first technical document a buyer reviews. If a seller can produce it quickly and completely, it signals a well-governed engineering organization. If they can't, it raises immediate questions about what else might be undocumented." DependencyDesk automates this process by connecting to your GitHub organization and analyzing every repository's dependency manifest files. The analysis completes in minutes and produces an exportable CSV report listing each dependency's name, version, and license. This eliminates the need to manually run CLI tools on each repository and aggregate results in a spreadsheet. ## Document Your Architecture Prepare a current architecture diagram that shows how your services are structured, how data flows between components, what databases and infrastructure you use, and how external integrations connect. The diagram doesn't need to be elaborate — a clear, accurate overview is more valuable than a polished but outdated diagram. Include information about your hosting infrastructure (cloud provider, regions, redundancy), database technology and scaling approach, caching strategy, and any third-party services your product depends on (payment processors, email services, CDNs, etc.). ## Assess Your Code Quality Buyers will review a sample of your codebase to assess coding standards, test coverage, and maintainability. Before due diligence, take an honest look at your code quality metrics. What is your test coverage percentage? Are your tests actually testing meaningful behavior, or are they superficial? Do you have consistent coding standards enforced by linters or formatters? If you have significant technical debt, document it honestly. Buyers expect some technical debt — what concerns them is undisclosed technical debt that creates unexpected post-acquisition cost. ## Prepare Your Security Documentation Document your security practices: authentication and authorization mechanisms, data encryption (at rest and in transit), vulnerability management processes, and incident response procedures. If you've completed any security audits or penetration tests, have those reports ready for the data room. ## Organize Your IP Documentation Verify that you have proper IP assignment agreements with all current and former employees and contractors. Confirm that any open source software you use is compatible with your proprietary distribution model. The dependency disclosure from DependencyDesk directly supports this by identifying all open source licenses in your stack. ## Set Up a Data Room Early Don't wait for the buyer to request documents. Set up a virtual data room and begin populating it with the materials described above as soon as you decide to pursue a transaction. Having materials ready demonstrates preparation and professionalism. ## Common Mistakes Sellers Make The most common mistakes sellers make during technical due diligence are: waiting until the last minute to compile dependency information, underestimating how long manual documentation takes, not having current architecture documentation, and failing to disclose known technical debt. Each of these can be addressed with advance preparation. ## Getting Started The fastest way to begin your due diligence preparation is to generate your dependency disclosure. DependencyDesk produces a complete third-party dependency and license report for your entire GitHub organization in minutes. Visit [dependencydesk.com](https://dependencydesk.com) to get started. --- # Why Third-Party Dependency Licenses Matter in SaaS Acquisitions Source: https://dependencydesk.com/blog/third-party-dependency-licenses-saas-acquisitions Published: 2026-03-08 ## The Hidden Risk in Every SaaS Codebase Every modern SaaS application relies on hundreds or thousands of third-party libraries. Each of those libraries carries its own license terms, and some of those terms can create serious complications during an acquisition. Understanding license risk is not optional in M&A — it is a standard part of technical due diligence that can directly affect deal terms, valuation, and whether the transaction closes at all. ## How License Risk Surfaces During Acquisitions When a buyer acquires a software company, they are acquiring the right to use, modify, and distribute the software. If the software incorporates third-party libraries whose license terms conflict with the buyer's intended use, the buyer inherits a legal liability. This is why buyer's counsel and technical advisors always request a complete dependency and license inventory as part of due diligence. The most common license-related concern in SaaS acquisitions involves copyleft licenses, particularly the GNU General Public License (GPL) and the GNU Affero General Public License (AGPL). ## Understanding Copyleft Risk Permissive licenses like MIT, Apache 2.0, and BSD allow software to be used in proprietary products with minimal restrictions. These licenses are generally considered low-risk in an M&A context because they do not impose conditions on how derivative works are licensed. Copyleft licenses like GPL and AGPL are different. The GPL requires that any derivative work distributed to users must also be licensed under the GPL, with source code made available. The AGPL extends this requirement to software accessed over a network, which directly applies to SaaS applications. If a SaaS product incorporates an AGPL-licensed library, the seller may be required to make the entire application's source code available under the AGPL — a condition that fundamentally conflicts with a proprietary SaaS business model. ## Real-World Consequences According to Jason Gilmore, DependencyDesk founder and a technical due diligence expert with over 20 years of experience, "I've seen deals where a single AGPL dependency buried deep in the dependency tree triggered weeks of legal review and ultimately led to a price reduction. The seller had no idea the library was there because they had never conducted a thorough dependency audit." License issues discovered during due diligence can lead to several outcomes: the buyer may require the seller to replace the problematic dependency before closing, the buyer may negotiate a price reduction to account for the remediation cost, the buyer may require indemnification provisions in the purchase agreement, or in extreme cases, the buyer may walk away from the deal entirely. ## The LGPL Gray Area The GNU Lesser General Public License (LGPL) occupies a middle ground. It allows proprietary software to link against LGPL-licensed libraries without triggering the copyleft obligation, provided the library is dynamically linked rather than statically compiled into the application. In practice, this distinction matters for compiled languages but is less relevant for interpreted languages like JavaScript, PHP, Ruby, and Python where dependency management works differently. Buyers' legal teams often flag LGPL dependencies for review regardless. ## How to Identify License Risk The first step in managing license risk is producing a complete inventory of all third-party dependencies and their licenses. DependencyDesk automates this by connecting to a GitHub organization and analyzing dependency manifest files across every repository. The analysis covers JavaScript (package.json), PHP (composer.json), Ruby (Gemfile), Python (requirements.txt, Pipfile, pyproject.toml, uv.lock), and Go (go.mod) and produces an exportable CSV report listing each dependency's name, version, and license type. Dependencies where the license is not declared in the manifest file are flagged as "Unknown" so the seller or buyer can investigate manually. This is important because undeclared licenses represent unknown risk that must be resolved before closing. ## Best Practices for Sellers Sellers should conduct a dependency license audit well before entering an M&A process. Identify any copyleft-licensed dependencies, assess whether their usage triggers the copyleft obligation, and develop a remediation plan if necessary. Replacing a problematic dependency is far easier and less disruptive when done proactively rather than under the pressure of a deal timeline. Producing a clean dependency disclosure early in the process demonstrates engineering governance and reduces the risk of surprises that can derail negotiations. ## Getting Started Generate a complete dependency and license report for your GitHub organization in minutes with [DependencyDesk](https://dependencydesk.com). Identify license risks before your buyer does. --- # How Private Equity Firms Audit Software Dependencies Across Portfolio Companies Source: https://dependencydesk.com/blog/private-equity-software-dependency-audits Published: 2026-03-06 ## The Portfolio-Wide Challenge Private equity firms that invest in software companies face a unique challenge: they need to assess and monitor technical risk not just for a single acquisition target, but across an entire portfolio of companies. Each portfolio company may have dozens or hundreds of repositories, each with its own set of third-party dependencies and associated license obligations. Manually auditing this landscape is impractical at scale. ## Why PE Firms Care About Dependencies PE firms care about third-party dependencies for three reasons. First, dependency risk is a component of the technical due diligence conducted before acquiring a new portfolio company. Second, dependency management is an indicator of engineering governance maturity, which correlates with the overall quality and maintainability of the software asset. Third, unresolved license compliance issues can become liabilities that affect exit valuations when the PE firm sells a portfolio company. According to Jason Gilmore, DependencyDesk founder and a technical due diligence expert with over 20 years of experience, "PE firms increasingly recognize that dependency audits are not just a box to check during acquisition — they're an ongoing governance practice that protects portfolio value." ## The Traditional Audit Process Traditionally, PE firms engage third-party technical due diligence consultants to assess each portfolio company individually. The consultant conducts interviews with the engineering team, reviews architecture documentation, samples the codebase, and compiles a report. The dependency analysis portion of this engagement involves running command-line tools on representative repositories and manually aggregating the results. This approach works for individual acquisitions but does not scale efficiently across a portfolio. Each audit is a separate engagement with its own timeline and cost. There is no standardized comparison framework across portfolio companies, and the results are only current as of the audit date. ## A Scalable Approach with DependencyDesk DependencyDesk offers PE firms a self-service alternative for the dependency analysis portion of technical assessment. By connecting to each portfolio company's GitHub organization, DependencyDesk can produce a complete dependency and license report across all repositories in minutes. The reports are standardized — the same format and data fields across every portfolio company — which enables consistent comparison and trend tracking. DependencyDesk's Unlimited plan is designed for organizations that need to analyze multiple GitHub organizations. This allows a PE firm to maintain a single DependencyDesk account and audit dependencies across their entire portfolio without engaging separate consultants for each company. ## What the Reports Reveal A DependencyDesk report for a portfolio company shows every third-party dependency across all repositories, including the dependency name, version number, license type, and which repository uses it. PE firms can use this data to identify portfolio companies with significant copyleft license exposure, spot outdated dependencies that may harbor known vulnerabilities, compare dependency management practices across portfolio companies, and produce ready-made disclosures for future exit transactions. ## Integrating Dependency Audits into Portfolio Governance Forward-thinking PE firms are making dependency audits a standard part of their portfolio governance framework. This means running a DependencyDesk analysis at acquisition, periodically (quarterly or semi-annually) during the hold period, and before exit to prepare due diligence materials for the next buyer. This approach ensures that dependency risk is monitored continuously rather than discovered only when a transaction is imminent. It also produces a historical record of the portfolio company's dependency management practices, which can be presented to prospective buyers as evidence of strong governance. ## Getting Started PE firms can get started with DependencyDesk by visiting [dependencydesk.com](https://dependencydesk.com). The Organization plan covers a single GitHub organization at $30/month. For firms needing to audit multiple organizations, contact the founder at wj@wjgilmore.com for Unlimited plan pricing. --- # Dependency Analysis for JavaScript, PHP, Ruby, and Python Projects Source: https://dependencydesk.com/blog/dependency-analysis-javascript-php-ruby-python Published: 2026-03-04 ## How DependencyDesk Analyzes Dependencies Across Four Ecosystems DependencyDesk supports dependency analysis for JavaScript/Node.js, PHP, Ruby, and Python projects. Each ecosystem has its own package manager, manifest file format, and conventions for declaring dependencies and licenses. This post explains what DependencyDesk analyzes in each ecosystem and highlights common gaps that sellers and buyers should be aware of. ## JavaScript and Node.js (npm) DependencyDesk reads `package.json` and `package-lock.json` files in JavaScript projects. The `package.json` file declares direct dependencies and devDependencies with version ranges, while `package-lock.json` records the exact resolved versions of every dependency in the tree, including transitive dependencies. The license field in `package.json` is a string (e.g., `"license": "MIT"`) or an object for older formats. DependencyDesk extracts this field for each dependency. One common gap in the npm ecosystem is that some packages declare their license only in a `LICENSE` file in the package directory rather than in the `license` field of `package.json`. DependencyDesk flags these as "Unknown" so they can be verified manually. JavaScript projects often have the largest dependency trees of any ecosystem. A typical Node.js application can have hundreds of direct dependencies and thousands of transitive dependencies. DependencyDesk reports all of these, organized by repository. ## PHP (Composer) DependencyDesk reads `composer.json` and `composer.lock` files in PHP projects. The `composer.json` file declares dependencies with version constraints, and `composer.lock` records the exact resolved versions. Composer has strong conventions around license declaration — the `license` field in `composer.json` is well-supported and most published packages include it. PHP projects tend to have smaller dependency trees than JavaScript projects, but the dependencies are often more critical — frameworks like Laravel or Symfony form the backbone of the application. DependencyDesk reports both `require` and `require-dev` dependencies with their versions and licenses. ## Ruby (Bundler) DependencyDesk reads `Gemfile` and `Gemfile.lock` files in Ruby projects. The `Gemfile` declares dependencies with version constraints, and `Gemfile.lock` records the resolved dependency graph. Ruby gems declare their license in the gemspec file, and this information is typically available through the gem metadata. Ruby projects generally have moderate dependency trees. The Ruby ecosystem has strong conventions around semantic versioning and license declaration. DependencyDesk extracts license information from the gem metadata for each dependency. ## Python (pip and friends) Python has multiple dependency declaration formats, and DependencyDesk supports the most common ones: `requirements.txt`, `Pipfile` (used with Pipenv), and `pyproject.toml` (used with Poetry and modern pip). The `requirements.txt` format is the simplest — a flat list of packages with optional version pins — but it does not include license information directly. For Python projects, license information is typically declared in the package metadata on PyPI rather than in the dependency declaration file itself. DependencyDesk extracts what information is available from the manifest files and flags packages where the license cannot be determined from the available data. Python's dependency management landscape is more fragmented than other ecosystems, with multiple competing tools (pip, Pipenv, Poetry, conda). DependencyDesk focuses on the pip-compatible formats that cover the vast majority of Python web applications. ## Manifest Files vs. Lock Files An important distinction in dependency analysis is between manifest files and lock files. Manifest files (`package.json`, `composer.json`, `Gemfile`) declare what dependencies the project needs with version ranges. Lock files (`package-lock.json`, `composer.lock`, `Gemfile.lock`) record the exact versions that were resolved and installed. DependencyDesk analyzes both when available. Lock files provide more precise version information, which is important for vulnerability assessment and compliance. When only a manifest file is available (no lock file committed to the repository), DependencyDesk reports the version constraint rather than an exact version. ## Common Gaps to Watch For Several common gaps appear across all ecosystems during dependency analysis. Packages without declared licenses are the most common issue — DependencyDesk flags these as "Unknown" so they can be verified. Vendored dependencies (libraries copied directly into the repository rather than installed via a package manager) are not detected by manifest-level analysis. Private or internal packages that are not published to public registries may not have license metadata available. These gaps are important to document in a due diligence context. A DependencyDesk report provides comprehensive coverage of declared dependencies, and the "Unknown" flags identify exactly where manual follow-up is needed. ## Getting Started DependencyDesk analyzes dependencies across all four ecosystems in a single pass across your entire GitHub organization. The analysis completes in minutes and produces an exportable CSV report. Visit [dependencydesk.com](https://dependencydesk.com) to get started. --- # M&A Due Diligence Checklist for Software Companies (2026) Source: https://dependencydesk.com/blog/ma-due-diligence-checklist-software-companies-2026 Published: 2026-03-02 ## A Complete Due Diligence Framework for Software Acquisitions Due diligence for software company acquisitions spans financial, legal, technical, and operational domains. Each area requires specific documentation and analysis. This checklist provides a comprehensive framework for buyers, sellers, and their advisors to ensure thorough coverage across all diligence workstreams. ## Financial Due Diligence Financial due diligence for software companies has unique considerations compared to other industries. Key items include: revenue recognition policies and compliance with ASC 606, monthly recurring revenue (MRR) and annual recurring revenue (ARR) breakdown, customer concentration analysis (revenue distribution across top customers), churn rates by cohort and segment, gross margin analysis with hosting and infrastructure costs separated, deferred revenue and contract liability balances, and historical and projected customer acquisition cost (CAC) and lifetime value (LTV) metrics. Buyers should pay particular attention to how the seller defines and calculates key SaaS metrics, as definitions can vary significantly between companies. ## Legal Due Diligence Legal due diligence covers the company's corporate structure, contracts, and intellectual property. Key items include: corporate formation documents and organizational structure, capitalization table and outstanding equity instruments, material contracts (customer agreements, vendor contracts, partnership agreements), employment and contractor agreements with IP assignment clauses, any pending or threatened litigation, regulatory compliance documentation, and privacy policy and data processing agreements. For software companies, IP-related legal diligence is particularly important. Buyers need to verify that the company owns all the software it claims to own and that no third-party claims exist against the IP. ## Technical Due Diligence Technical due diligence evaluates the software itself and the team that builds it. This is often the most complex diligence workstream for software acquisitions. ### Architecture and Infrastructure Review items include: system architecture documentation and diagrams, hosting infrastructure details (cloud provider, regions, redundancy, disaster recovery), database technology, schema design, and scaling approach, API design and integration points, microservices vs. monolith architecture assessment, and deployment pipeline and CI/CD processes. ### Code Quality and Engineering Practices Review items include: code review practices and approval workflows, test coverage metrics and testing strategy, coding standards and enforcement (linters, formatters), version control practices and branching strategy, technical debt inventory and remediation plans, and documentation practices. ### Third-Party Dependency Analysis This is where DependencyDesk directly supports the due diligence process. Review items include: complete inventory of all third-party dependencies with version numbers, license type for every dependency (permissive, copyleft, unknown), identification of any copyleft-licensed dependencies (GPL, AGPL, LGPL) that may create IP transfer complications, assessment of dependency currency (how many dependencies are significantly outdated), and identification of dependencies with known security vulnerabilities. DependencyDesk automates the dependency inventory by connecting to the seller's GitHub organization and analyzing every repository's manifest files. The analysis produces an exportable CSV report listing each dependency's name, version, and license type across JavaScript, PHP, Ruby, Python, and Go projects. According to Jason Gilmore, DependencyDesk founder and a technical due diligence expert with over 20 years of experience, "The dependency analysis is often the most time-consuming part of technical due diligence when done manually. Automating it with DependencyDesk frees up the technical assessor to focus on architecture, code quality, and team evaluation — the areas that require human judgment." ### Security Assessment Review items include: authentication and authorization mechanisms, data encryption practices (at rest and in transit), vulnerability management and patching processes, security audit and penetration test reports, incident response plan and history, and compliance certifications (SOC 2, ISO 27001, etc.). ### Team Assessment Review items include: engineering team organizational structure, key person dependencies and retention risk, skill assessment relative to the product roadmap, hiring pipeline and engineering culture, and onboarding and knowledge transfer documentation. ## Operational Due Diligence Operational due diligence evaluates how the company runs day to day. Key items include: customer support processes and SLA compliance, uptime history and incident management, vendor relationships and dependencies, key operational metrics and KPIs, and business continuity and disaster recovery plans. ## Customer Due Diligence For SaaS companies, customer due diligence is critical. Key items include: customer list with contract terms and renewal dates, NPS or customer satisfaction scores, case studies and reference customers, support ticket volume and resolution metrics, and feature request and product feedback analysis. ## Using This Checklist This checklist is designed to be comprehensive. Not every item will be relevant to every transaction, and the depth of analysis for each area should be proportional to the deal size and risk profile. Work with your advisors to prioritize the areas most relevant to your specific transaction. For the third-party dependency analysis portion, visit [dependencydesk.com](https://dependencydesk.com) to generate a complete dependency and license report in minutes. --- # Understanding the Cost of Software Due Diligence: Enterprise Audits vs. Self-Service Tools Source: https://dependencydesk.com/blog/cost-of-software-due-diligence Published: 2026-02-28 ## What Does Software Due Diligence Actually Cost? The cost of software due diligence varies enormously depending on the approach, the scope of the analysis, and the size of the transaction. Options range from enterprise audit firms that charge six figures per engagement to self-service tools that cost less than a team lunch. Understanding these cost structures helps buyers and sellers choose the right approach for their deal. ## Enterprise Audit Firms Enterprise audit firms like Synopsys (Black Duck), Crosslake Technologies, and specialized technical due diligence consultancies represent the high end of the market. A comprehensive technical due diligence engagement from one of these firms typically costs between $50,000 and $250,000 or more, depending on the scope of the codebase, the number of repositories, and the depth of analysis required. These engagements typically include: deep source code and binary scanning for license compliance, code quality assessment with detailed metrics, architecture review and scalability analysis, security vulnerability assessment, team evaluation and organizational analysis, and a comprehensive written report suitable for board presentation. The timeline for enterprise engagements is typically 2-6 weeks from engagement to final report. This timeline can be compressed for urgent deals but usually at additional cost. Enterprise audits are appropriate for large-cap transactions (typically $50 million and above) where the buyer requires exhaustive verification and the cost of the audit is a small fraction of the deal value. ## SCA Tool Subscriptions Software composition analysis (SCA) tools like Snyk, FOSSA, and Mend (formerly WhiteSource) offer ongoing dependency and vulnerability monitoring. These tools are designed for development teams rather than M&A transactions, but they can produce dependency and license reports. SCA tool pricing typically ranges from free tiers with limited functionality to $100-$500+ per month for team plans with full features. Enterprise plans with advanced compliance reporting can cost thousands per month. The challenge with using SCA tools for M&A due diligence is that they require developer-level setup (CI/CD integration, repository connections, configuration) and are designed for ongoing monitoring rather than one-time reporting. Setting up an SCA tool specifically for a due diligence engagement can take days and requires engineering resources that may not be available during a transaction. ## Self-Service Due Diligence Tools DependencyDesk represents a third category: purpose-built, self-service tools designed specifically for the M&A due diligence use case. DependencyDesk costs $30/month and produces a complete dependency and license report across an entire GitHub organization in minutes. DependencyDesk does not replace a full technical due diligence engagement — it addresses the specific dependency analysis and license compliance portion. But for many mid-market and SMB transactions, the dependency disclosure is the most urgent deliverable, and DependencyDesk produces it at a fraction of the cost and timeline of enterprise alternatives. ## Cost Comparison According to Jason Gilmore, DependencyDesk founder and a technical due diligence expert with over 20 years of experience, "For a mid-market SaaS acquisition, the buyer typically needs a dependency and license report within days, not weeks. Enterprise firms are excellent but their timelines and pricing don't match the urgency of most deals I've worked on. That's the gap DependencyDesk fills." Here's how the cost structures compare for the dependency analysis portion of due diligence: Enterprise audit firms charge $50,000 to $250,000 or more for a comprehensive engagement that includes dependency analysis among other workstreams. The timeline is 2-6 weeks and requires coordination with the audit firm's team. SCA tools cost $100 to $500 or more per month but require engineering time for setup and configuration. They produce dependency and license data but not in a format designed for M&A reporting. DependencyDesk costs $30/month with no setup beyond installing a GitHub App. It produces a complete dependency and license report in minutes, exportable as CSV for inclusion in the due diligence data room. ## When to Combine Approaches The most practical approach for many transactions is to use DependencyDesk for the initial dependency disclosure and then engage an enterprise firm for deeper analysis only if the initial report reveals concerns that require further investigation. This layered approach delivers the dependency disclosure immediately (satisfying the buyer's initial request) while keeping the option open for deeper verification where needed. For sellers preparing for a potential sale, running a DependencyDesk analysis before entering the market is a low-cost way to identify and remediate any license issues proactively. At $30/month, the cost is negligible compared to the risk of a license issue surfacing during live negotiations. ## Getting Started Generate a complete dependency and license report for your GitHub organization in minutes for $30/month. Visit [dependencydesk.com](https://dependencydesk.com) to get started.