Open Source Software Risk and Startup Insurance Gaps

Open source components appear in 98% of commercial codebases, and the vulnerability count inside those codebases more than doubled in a single year: from 280 to 581, according to the Open Source Security and Risk Analysis report from Black Duck. Startups are building faster than ever on code they don't own and often can't fully see, and the insurance they carry was priced for a version of software development that no longer exists.

What 98% open source penetration means for a startup's codebase

Black Duck's 2026 OSSRA report audited 947 codebases between November 2024 and October 2025, and found that only 2% contained zero open source components. For practical purposes, every startup shipping software today is shipping someone else's code, wrapped around a thin layer of its own. The average M&A audit turned up 3,550 open source components inside a single target company; customer audits, run on live products rather than acquisition targets, still found north of 1,000 components in a typical codebase.

Most of that gets caught. Automated scanning, the kind that reads package manifests and lock files, picks up 84% of components without a human ever looking. Most of that gets caught by automated scanning, the kind that reads package manifests and lock files, which picks up 84% of components without a human ever looking, but the other 16% is where the trouble lives: code copied straight from a vendor's repo, snippets lifted from Stack Overflow, and chunks generated by an AI assistant and pasted into a file with no manifest entry. A scanner reading package.json misses code copied straight from a vendor's repo, snippets lifted from Stack Overflow, and chunks generated by an AI assistant and pasted into a file with no manifest entry at all, because none of it appears in the manifest a scanner checks. A startup can run a clean-looking dependency audit and still be carrying components nobody logged.

SaaS companies face a sharper version of this problem with code released under a strong copyleft license. Certain copyleft licenses can trigger source-disclosure obligations that extend beyond traditional binary distribution scenarios. A company can build a product entirely in-house, never sell or ship a single copy of the underlying code, and still owe source disclosure because a user hit the product over the web. AI-generated code adds to this, so a startup may have open-source material baked into its "proprietary" stack without a single person on the team knowing it happened.

None of this is a side issue anymore, either. The EU's Cyber Resilience Act took effect in December 2024, with its first major compliance deadline landing in September 2026, and it expects companies to produce a Software Bill of Materials, an SBOM, on demand. Most startups can't do that today. That's a gap in the paperwork a regulator will ask for, not merely a nice-to-have compliance checklist item. It's a gap in the paperwork a regulator will ask for.

Three distinct risk categories inside every OSS-heavy codebase that startups conflate

Founders tend to talk about "our vulnerabilities" as if it's one bucket. It's three, and they behave nothing alike.

Security vulnerabilities are the most familiar. The 2026 OSSRA found a mean of 581 total vulnerabilities per codebase, but only 237 unique ones, which tells you something on its own: a single flawed library, reused across a dozen services, generates a dozen findings from one root cause. Nearly every codebase carries at least one high-risk vulnerability, and close to half carry a critical one. Sixty-five percent of organizations Black Duck surveyed in 2025 said they'd been hit by a software supply chain attack in the prior year, spanning a range of attack shapes that target different points in the open source supply chain. Different attack vectors require different defensive approaches.

License conflicts are a separate animal entirely, and in 2025 they were everywhere: 94% of M&A transactions audited that year included components with license conflicts. The single most common offender was Creative Commons Attribution ShareAlike 3.0, showing up in 54% of transactions, usually smuggled in through a Stack Overflow snippet, which is exactly the kind of source an AI coding assistant draws from and reproduces. Copyleft licenses like GPL and AGPL go further: they condition use on passing the same obligations downstream, so an acquirer who closes a deal without checking copyleft scope can end up owning an undisclosed obligation to release source code. That is no longer a theoretical risk. In 2024, a federal judge denied a smart-TV maker's motion for summary judgment in a lawsuit brought by an open-source advocacy group. Vizio*, letting the question of whether consumers can enforce the GPL as third-party beneficiaries proceed to trial. That case has put the question of copyleft enforcement into sharper focus for companies relying on open source.

Then there's obsolescence: components nobody's touched in years, still running in production. The 2026 OSSRA found 93% of codebases contain at least one component with no development activity in over two years, what the industry calls zombie components, and that's a direct compliance gap under the CRA on its own. Black Duck's DevSecOps survey found that sixty percent of organizations push code to production daily or more often, while the components underneath that code often get patched far less frequently. Fast feature velocity paired with slow security maintenance is the exact definition of security debt, and fast-moving startups are particularly exposed to accumulating it.

These three categories sit in the same dependency tree, which makes them feel like one problem. They trigger different legal theories, sit under different regulatory regimes, and, as it turns out, land differently against an insurance policy, so treating the three categories as one problem is a mistake. They trigger different legal theories, sit under different regulatory regimes, and, as it turns out, land differently against an insurance policy.

Standard cyber and tech E&O policies written for a different software world

A typical startup carries some combination of general liability (usually required by a lease or an enterprise contract before anyone even asks about security), a business owner's policy, tech E&O for the service the software delivers, and a cyber policy to cover customer data. General liability and BOP policies are broadly understood to exclude cyber losses and professional errors, with such carve-outs commonly appearing in policy exclusions.

Some BOPs include a limited cyber endorsement, typically sized for a modest incident rather than a serious one. A serious incident can quickly dwarf a BOP's cyber sublimit once forensics, notification, and downtime are totaled up. Founders also tend to treat tech E&O and cyber coverage as the same thing, and they're not. If a flaw in how a product performs, rather than an external breach, causes a client's data loss, the extent of cyber-only policy coverage can be uncertain. Tech E&O exists for exactly that gap, and any company selling a software product needs it sitting next to cyber, not instead of it.

Underwriters have also gotten stricter about what they'll even quote. Basic security controls have shifted from good practice to baseline requirements that underwriters scrutinize before returning a quote.

The shape of the problem is clear: these policies were built for a software development environment that carried far fewer vulnerabilities and got written at a very different pace. None of those three conditions hold anymore.

The specific clauses where OSS risk falls through the coverage floor

Take a vulnerability in an open source dependency that leads to a breach. Whether a cyber policy pays out often comes down to one distinction that the wording buries: was this a security incident, or a product defect? Some policies exclude claims that arise from a flaw in the technology product itself, which puts the exact question an OSS vulnerability raises right at the edge of the exclusion. The dollar figures at stake, ranging into the millions, make the security-incident-versus-product-defect line one insurers and policyholders fight over. Industry estimates put the average cost of a data breach in the millions globally, and substantially higher in the U.S. market. Small businesses face a narrower but still brutal range, from roughly $120,000 to $1.24 million per incident, and research has found that a large share of small businesses close within six months of a serious cyberattack. At startup scale, that's not a line item, a serious cyberattack can close the company itself.

License conflicts fall through a separate hole. A copyleft obligation, a misapplied CC-SA license, an undisclosed AGPL component: these generate intellectual property liability, sometimes with an injunction attached, and standard cyber policies simply don't cover IP disputes. General liability usually excludes them too. That matters most at the exact moment a company gets acquired: 97% of 2025 M&A transactions carried unpatched vulnerabilities, and 94% carried license conflicts. An acquirer's reps-and-warranties insurance is frequently being priced against a codebase nobody actually understood at signing. A small minority of organizations have a dedicated process for assessing OSS liability exposure before a deal closes. Most are buying, or being bought, without one.

A newer problem is stacking on top of both of these. Standard policy language in one large national insurance market gained endorsements in 2026 that let insurers explicitly carve generative AI outputs out of general liability coverage, and several major carriers adopted similar language fast. The same logic is spreading into directors and officers policies and into professional liability. This is the same sequence the industry went through with "silent cyber" years back: ambiguous coverage gets replaced first by an explicit exclusion, and only later does an affirmative market show up to fill the space. Startups are sitting in that gap right now. An AI assistant that quietly drops an unlicensed open source snippet into production code is precisely the claim that falls into both holes at once, the silent AI exclusion and the IP gap, and no standard policy on the market today was built with that claim in mind.

A dedicated market for open source maintainer liability does exist, and it's growing, valued in the hundreds of millions in 2025 with projections pointing toward significant growth through the early 2030s. But it's early. Coverage at that layer isn't standardized or widely available at the size and price point a typical startup needs.

What investors and acquirers are now finding under the hood

Open source turned up in 98% of codebases and 100% of M&A transactions audited in 2025. Open source turned up in 98% of codebases and 100% of M&A transactions audited in 2025, making the risk universal. Open source turned up in 98% of codebases and 100% of M&A transactions audited in 2025, but the preparedness to manage it lags behind, and due diligence keeps surfacing exactly that gap.

Investors have started treating cyber and OSS governance as a pre-funding question rather than a post-close cleanup item, because a single breach, at a company that size, can stall a product launch, break customer trust, and sink the next fundraise before it starts. Carriers have made the same shift from the other direction: MFA, EDR, and backup discipline are now baseline requirements to get a quote at all, which means a startup without those controls can find itself effectively uninsurable right when it needs coverage most. Pricing in the broader 2026 cyber market is falling, but not evenly. Companies that can show real, documented security controls are capturing most of that decline; companies that can't are facing tighter underwriting and smaller discounts. The market hasn't written OSS governance into policy language yet, but it's already pricing the discipline behind it.

Acquirers are running into the sharpest version of the problem. With 94% of 2025 M&A transactions carrying license conflicts and 97% carrying unpatched vulnerabilities, a lot of reps-and-warranties insurance is being underwritten against an SBOM that was never actually complete. And the EU's Cyber Resilience Act adds a forcing function no insurance policy can substitute for: its September 2026 deadline for vulnerability and incident reporting means access to the European market now depends on a company being able to demonstrate component governance directly, not on having a policy that pays out after the fact.

OSS governance has quietly become a valuation question and an insurability question that reaches well beyond the security team's standup.

Steps startups can take now to reduce exposure and make their risk legible to underwriters

Build the SBOM before anyone asks for it. Being able to produce a compliant Software Bill of Materials on demand is both a CRA requirement and the starting point for any serious insurance application, and right now most startups simply can't do it.

Stop treating vulnerabilities, license conflicts, and zombie components as one list. They need different remediation work, they map to different insurance clauses, and folding them together leaves holes in both the security program and the coverage built around it.

Check what an AI coding assistant actually produces before it reaches production. The 16% of components that enter a codebase outside normal package management, including AI-generated snippets, are invisible to a scanner that only reads manifests, and that's the most likely place a silent copyleft violation is hiding right now.

Line the policies up against the real risk. Cyber coverage alone isn't enough for a company that sells software; tech E&O needs to sit alongside it. AI-related exclusions are moving fast enough that a policy renewed without a careful read may already cover less than it did a year ago. A BOP's cyber sublimit almost certainly won't survive a real ransomware event, so a standalone cyber policy is worth the separate line item. And any company heading toward an acquisition should bring in third-party audit tools built to catch components that entered outside a package manager well before due diligence starts, not during it.

Underwriters want to see the controls, not just hear about them: MFA, EDR, and backup routines are the baseline now, and a documented SBOM process is becoming the thing that actually moves pricing. The insurance market caught up to cyber risk eventually, and it will catch up to open source risk the same way. The startups that build the governance now, the audit trail, the SBOM, the separated remediation workflows, are the ones that land in the affirmative-coverage tier when that market matures. Everyone else is still going to be sitting in the exclusion period, hoping the gap doesn't find them first.