The vendor that scans everyone else's code rarely scans its own
Picture the diligence call. The founder of a 60-person threat-detection vendor is walking you through the platform — the proprietary correlation engine, the patented anomaly model, the moat. You ask one question: "Can you send over the SBOM and the most recent software composition scan?" There's a pause. Then: "We can generate that for you."
That sentence is the whole deal. A cybersecurity company that has to generate a Software Bill of Materials on request does not continuously track what is inside its own product. Which means the company whose entire pitch is "we see the risk before you do" cannot see its own dependency tree. That is not a footnote. In a security acquisition, the code is the product, the brand is "we are safe to trust," and the gap between those two things is exactly what you are buying.
The numbers say the gap is the norm, not the exception. Nearly all modern software — 96% of commercial codebases — pulls in open source, and that's fine; nobody hand-writes a TLS library anymore. The problem is what comes with it. Synopsys found that 74% of codebases contain high-risk vulnerabilities, and worse for a security target, 53% carry open source license conflicts. When you acquire this firm you are not just buying ARR and a roadmap — you are signing for every unpatched CVE and every license obligation buried under the word "proprietary."
Three places a security deal quietly breaks
Quality of Earnings won't catch any of these. Neither will a polished architecture deck. You have to look at the dependency graph, the commit log, and the contractor invoices — in that order.
1. The "proprietary" engine that's three open source projects in a trench coat
The detection or encryption engine the seller calls proprietary is, in most security startups, a thin layer of original logic wrapped around well-known open source crypto, parsing, and ML libraries. That's normal engineering. The danger is licensing. If a copyleft component — GPL, AGPL — sits inside the distributed product, the obligation can attach to the surrounding code, and the "proprietary" core you paid a premium for may be legally compelled toward disclosure. For a SaaS security product, AGPL is the one to hunt: it triggers on network use, not just distribution, so the usual "we host it, we don't ship it" defense evaporates. Run a real composition analysis scan (SCA), not a manual spreadsheet, and read the license column before the vulnerability column.
2. The encryption code a contractor still legally owns
Ask who wrote the cryptographic core, then ask whether they were an employee when they wrote it. In early security startups the founding team frequently ships an MVP built by offshore contractors, then forgets the paperwork. If the IP assignment was never signed — or was signed after the commits landed, with no "prior inventions" clause — the company does not own the one piece of code that defines its product. I have watched a deal freeze over exactly this: a freelancer who had moved on years earlier held the legal authorship of the platform's key-management library, and no closing could happen until that was unwound. In a security company, this isn't a generic IP gap. It's the difference between owning a product and renting one from someone who has no idea they're the landlord.
3. The remediation backlog that quietly caps your EBITDA
Every security vendor has a vulnerability backlog. The question is whether the team is spending its week building the roadmap you underwrote or re-patching the same fragile subsystem. McKinsey's work on the topic is blunt: tech debt acts as a direct tax on engineering capacity and on the value those teams can create. If a third of engineering hours go to keeping the existing platform from collapsing, your value-creation plan is not "ambitious" — it's overstated by that same third, and you priced the deal on the wrong velocity. Translate it into dollars of delayed roadmap, not a "code quality: C+" grade nobody can act on. For the mechanics of putting a number on it, see Technical Debt is Financial Debt: The M&A Due Diligence Playbook.
What to pull from the data room this week
You don't need a month. You need the right four artifacts and one uncomfortable question.
- An automated SCA report from a real scanner. Black Duck, Snyk, or equivalent — generated against the current main branch, not a curated PDF. A security company that can't produce one in days is telling you it doesn't run its own product internally. That refusal is your finding.
- The git contribution history for the core engine. Map the top five contributors to the cryptographic and detection code. For each one not currently on payroll, put their signed IP assignment on the table before you read anything else.
- The license column of the SBOM. Flag every GPL, AGPL, and weak-copyleft entry inside the distributed or network-served product. One AGPL dependency in the wrong place can outweigh every CVE on the list.
- The open vulnerability ledger with ages. Not the count — the dwell time. A security vendor sitting on its own 200-day-old high-severity findings has a culture problem that no remediation budget fixes overnight.
Then ask the CTO one thing: "If I gave you six months and no roadmap pressure, which subsystem would you rewrite from scratch?" If the answer is the core engine, price in the rewrite — and use the finding. As Zartis notes, rigorous technical diligence is leverage, not just a checkbox; quantified debt and IP gaps routinely support a 10–15% adjustment to enterprise value, which conveniently doubles as your day-one remediation budget. For the full document request list, work from The 'Dirty Dozen': 12 IT Due Diligence Documents That Reveal the Truth, and pressure-test the seller's safety claims against The Security Posture Assessment checklist. In cybersecurity, you are buying trust as inventory. Verify it the way the company's own product claims to.
