Open Source Is Not Free: The Supply Chain Risks Your Engineering Team Is Ignoring

Let us be direct about something the software industry has been reluctant to say plainly: open source software is not free. It has never been free. What it is, precisely, is free at the point of acquisition — a distinction that matters enormously when the bill eventually arrives, and it always does.

For startups and growth-stage businesses building on modern software stacks, open source dependencies are not an edge case. They are the foundation. The average Node.js application pulls in hundreds of packages. A typical Python data pipeline may carry thousands of transitive dependencies — libraries that your code depends on indirectly, through the libraries you deliberately chose. Most engineering teams can name perhaps a dozen of them.

This is not a criticism of open source as a model. The collaborative development ecosystem has produced some of the most important software infrastructure in human history, and the productivity gains it delivers to businesses building on top of it are real and substantial. But the risks embedded in that ecosystem have grown faster than most organizations' capacity to manage them — and the consequences of inaction are no longer theoretical.

The Anatomy of a Supply Chain Attack

The 2020 SolarWinds compromise was a watershed moment for software supply chain security. By injecting malicious code into a widely used network monitoring tool during the build process, attackers gained access to networks across the US federal government and Fortune 500 enterprises. The vector was not a zero-day vulnerability in bespoke code. It was a trusted dependency.

More directly relevant to the open source context was the 2021 discovery of the Log4Shell vulnerability in Apache Log4j — a Java logging library so ubiquitous that it was embedded in products from Apple, Amazon, Cisco, and thousands of smaller vendors. The vulnerability allowed unauthenticated remote code execution, and the blast radius was staggering. Organizations scrambled to identify every system that carried the affected library, a task that proved far more difficult than it should have been because most of them had no accurate inventory of their dependencies.

Log4Shell was not an anomaly. It was a preview. The volume of reported vulnerabilities in open source packages has increased year over year, while the average time between vulnerability disclosure and active exploitation has compressed from weeks to hours.

The Maintenance Burden Nobody Budgets For

Security vulnerabilities are the most visible risk, but they are not the only one. Open source libraries require maintenance — updates, patches, and periodic major version migrations — and that maintenance does not happen automatically. Someone has to do it, and in most organizations, that someone is an engineer who was supposed to be shipping product.

The open source maintainer ecosystem is, by many accounts, in crisis. A 2022 report from the Linux Foundation found that the majority of critical open source projects are maintained by fewer than ten individuals, many of whom are volunteers receiving no compensation for their work. When a maintainer burns out or moves on, libraries can go unmaintained for months or years. Downstream consumers — businesses that have built production systems on those libraries — are left holding the risk.

This dynamic creates a compounding maintenance burden that is almost never reflected in engineering team capacity planning. The time spent evaluating dependency updates, testing compatibility, resolving breaking changes, and responding to vulnerability disclosures is real work. It does not appear on a license invoice, but it consumes engineering hours that have a fully loaded cost.

The Compliance Dimension

Beyond security and maintenance, open source carries a licensing compliance obligation that a surprising number of US companies are unprepared to meet.

Not all open source licenses are created equal. MIT and Apache 2.0 licenses are permissive — they impose minimal restrictions on how software can be used and distributed. GPL and AGPL licenses are copyleft — they require that derivative works be distributed under the same license terms, which can create significant complications for commercial software products. LGPL occupies a middle ground that requires careful legal interpretation.

The problem is that engineering teams, understandably focused on technical fit, rarely conduct license reviews before adopting dependencies. Startups have shipped products to enterprise customers only to discover during due diligence — often in the context of an acquisition or funding round — that their codebase contains GPL-licensed components that technically require them to open source proprietary code. Resolving these situations retroactively is expensive, time-consuming, and occasionally deal-breaking.

The Federal Trade Commission and Securities and Exchange Commission have both signaled increasing attention to software supply chain disclosure practices, and enterprise procurement teams are asking harder questions about dependency provenance than they were three years ago. The compliance landscape is tightening.

A Practical Framework for Managing OSS Risk

None of this argues for avoiding open source. That ship has sailed, and the productivity case for leveraging the ecosystem remains compelling. What it argues for is deliberate, systematic risk management.

Establish a Software Bill of Materials (SBOM): An SBOM is a formal inventory of every component in your software stack, including transitive dependencies. Tools like Syft, FOSSA, and Snyk can generate SBOMs automatically and integrate them into CI/CD pipelines. This is the foundation of everything else.

Implement Automated Vulnerability Scanning: Integrate dependency scanning into your build pipeline so that known vulnerabilities are surfaced before code reaches production. GitHub's Dependabot, Snyk, and Mend (formerly WhiteSource) all offer mature solutions in this space. Configure automated pull requests for patch-level updates to reduce the manual overhead of staying current.

Adopt a Dependency Governance Policy: Define criteria for adopting new open source dependencies — minimum maintenance activity thresholds, license approval lists, and security posture requirements. This does not mean bureaucratizing every package install, but it does mean having a documented standard that engineering teams can apply consistently.

Conduct Periodic License Audits: At minimum, run a full license audit before any significant fundraising event, M&A process, or enterprise sales engagement. Quarterly audits are preferable for organizations with active dependency footprints.

Consider Contributing Upstream: Organizations that rely critically on specific open source projects should consider allocating engineering time or financial support to those projects. This is not altruism — it is risk management. A well-maintained dependency is a more secure dependency.

The Honest Reckoning

The open source ecosystem will remain the substrate of modern software development for the foreseeable future. The question is not whether to use it, but whether to use it with the same rigor applied to any other business risk.

The companies that will navigate the next decade of software supply chain complexity successfully are those that treat their dependency graph as a managed asset — inventoried, monitored, and governed with the same discipline applied to their financial ledger. The ones that continue to treat it as a free resource, invisible and unmanaged, are accumulating a liability that will eventually demand collection.

At SolStack, we believe that responsible engineering is inseparable from responsible business strategy. The stack you build on is only as strong as your understanding of what it actually contains.