What Your Software Supply Chain Diligence Is Missing (and How to Get It Fast)
If you work in private equity or corporate development, you already know the shape of the problem. A deal has a timeline measured in weeks, sometimes days, and somewhere in the middle of it someone asks a question nobody on the deal team can answer with confidence: what is actually running inside the target's software, and what is it going to cost us after close?
Traditional technical due diligence leans on questionnaires, a data room full of architecture diagrams, and maybe a few hours with the target's engineering leads. That approach was built for a world where "software risk" meant a handful of licensed vendor products. It was never built for the modern reality: hundreds of open source dependencies nested three and four layers deep, AI models quietly wired into production features, and license terms that nobody on either side has actually read closely. By the time these issues surface, they surface as post-close surprises: a GPL-licensed component baked into a proprietary product, a dependency with a known, actively exploited vulnerability, or an AI model whose training data or usage terms create liability nobody priced into the deal.
The four things you actually need before signature
Cut through the noise and diligence on a software asset comes down to four concrete questions, each answerable from evidence rather than assurance.
Is the SBOM complete? A software bill of materials that only lists top-level dependencies is close to useless. What matters is full transitive dependency inventory, the packages your target's packages depend on, several layers deep, because that is where unmanaged risk actually lives. Safeguard's SBOM generation and analysis produces this in SPDX and CycloneDX formats with more than 30 export options [GA], giving you a document you can hand to counsel, to your own security team, or to the seller's engineers without translation.
What is the license exposure? License compliance checking against SPDX data and policy [GA] flags copyleft and attribution obligations that can quietly constrain how the acquired asset is used or resold after close. This is often the single fastest way to find a deal-changing issue, because license terms do not show up in a financial model, they show up in a dependency tree.
How exposed are the known vulnerabilities, really? A raw CVE count is not a risk figure, it is a noise figure. Vulnerability management enriched with EPSS and KEV data [GA], paired with reachability analysis that determines whether a vulnerable function is actually reachable from the application's code paths [GA], cuts that noise by roughly 60 to 80 percent. That difference matters in a deal context: it separates "this target has 400 open CVEs" from "this target has 12 vulnerabilities in code paths that actually execute," which is a very different conversation with the deal committee.
Is there AI in here, and what is it? AI-BOM discovery [EA] inventories the models, agents, and AI-related assets embedded in a target's software, which increasingly matters as acquirers discover, after close, that a "traditional" software product has an LLM dependency, a fine-tuned model, or an agent framework nobody disclosed in the data room.
The access problem, and the local runner answer
Here is the part that makes technical diligence genuinely hard in an M&A context: you often cannot get the access you would need to answer these questions properly. Mid-negotiation, a target company is understandably reluctant to grant a prospective acquirer deep, standing access to its source repositories. Trust has not been established yet, the deal might not close, and handing over repo credentials feels like a one-way door.
This is precisely the scenario Safeguard's local runner CLI was built to unlock [GA]. Instead of granting an outside party access to your infrastructure, the target (or a neutral technical advisor on either side) runs the CLI locally. It pulls the repository on that machine, performs the scan there, and pushes only encrypted results out. No standing repo access, no code leaving the target's environment, no new integration to stand up and tear down. It answers the acquirer's diligence questions without requiring the seller to answer the harder question of "how much access are we comfortable granting a company we haven't decided to sell to yet."
What this looks like in practice
A corporate development team evaluating an acquisition can have the target's technical lead run the local scanner against the codebase, generate a full SBOM, and share the resulting report, license findings, reachability-prioritized vulnerability list, and AI-BOM, all without the acquirer ever touching the target's repositories directly. That report becomes part of the deal file: a defensible, evidence-based answer to "what is the real software risk here," delivered in the timeframe a deal actually allows.
Software risk that surfaces after close is a cost with no negotiating leverage left to offset it. Software risk that surfaces during diligence is a term in the deal. If your team is running technical diligence on a target's software supply chain and needs answers that hold up in the deal room, visit safeguard.sh to see how the local runner and SBOM analysis fit into your process without slowing the timeline down.
