Why Open Source Software (OSS) Matters

Modern software relies on libraries that provide specialized functions, such as reading and writing PDF files, encrypting data, or creating polished user interfaces. In essence, a modern application is like a Lego set, combining dozens of pre-built libraries to deliver a specific set of features.

Where do these libraries come from? They generally fall into two categories: commercial libraries, which require a paid license, and open-source libraries, which are publicly shared on platforms like GitHub.

Who creates open-source libraries? Some are developed by tech giants, while others are maintained by passionate independent developers. Before using one, a smart developer considers the code quality, the community support, and the licensing requirements.

Quality and reliability are easy to understand, but what's the deal with license requirements?

The Two Paths of Open Source

When it comes to Open Source, there are essentially two paths you can walk:

The Intellectual Property (IP) Trap

This "pay-it-forward" rule is why Copyleft introduced massive Intellectual Property (IP) risk. Imagine spending a year writing a proprietary desktop app or game, only to discover you used one small, insignificant copyleft library. Because you are distributing that app to users, you are now legally obligated to hand over your entire proprietary codebase to anyone who buys or downloads your software.

Why would anyone design a system like this?

Picture the early 1980s. A legendary programmer named Richard Stallman got so frustrated by a jammed office printer he couldn't fix, solely because the manufacturer locked down the software and refused to share the source code, that he launched the GNU free software movement. He believed software should be open and collaborative. To protect that dream, he helped design Copyleft as a legal forcefield, ensuring that open software stays open when it's shared, preventing companies from locking it up.

The Dependency Nightmare

Can't you just manually review the licenses of the dozen or so packages your application uses?

In a perfect world, yes. But in reality, software has a dependency problem. Each of those dozen packages you pull in relies on a dozen packages of its own, which rely on a dozen more. This dependency tree can go down ten layers deep. If a single copyleft library is buried deep down in that chain, it drags your entire application into the copyleft trap.

Does that mean a package can claim to be "MIT licensed" on its homepage, yet secretly pull in a GPL Copyleft package deep in its dependencies?

Unfortunately, yes. It happens often and you simply cannot trust the parent package's stated license to represent the messy reality of its deep dependencies. This is why modern development requires automated scanning tools to map out and verify every single branch of your software's family tree.

The Other Thing Hiding in the Tree

Everything so far has been about licensing: who owns the code, and what you owe them for using it. But look again at what the Dependency Nightmare actually described. It described a tree, ten layers deep, packed with code you did not write, did not choose, and have never read, running inside your product all the same.

Licensing is only one of the two things riding in on that tree.

The other is vulnerabilities: publicly catalogued security holes in specific versions of specific packages, each one given an identifier like CVE-2021-44228 and a severity score. And they arrive by exactly the same mechanism as the copyleft trap. You inherit them from packages you never chose, and from the dependencies of those packages, all the way down.

That particular CVE number is worth remembering. In December 2021 a flaw nicknamed Log4Shell was disclosed in Log4j, a Java library that does something as unglamorous as writing log messages to a file. The flaw scored a perfect 10.0 severity, and it was triggered by something horrifyingly ordinary: if an attacker could get a string of their choosing written to your logs, they could run their own code on your server. A username. A web browser's User-Agent header. A chat message typed into a Minecraft server, which is how a great many people first learned about it.

Ask the companies who spent that December in a war room how many of them had sat down and chosen to use Log4j, and most would tell you they never had. It arrived as a dependency of a dependency of something they did choose. The tree gave it to them, and the tree never sent a memo.

So the same unreadable dependency tree that can quietly drag your proprietary code into a copyleft obligation can also quietly hand an attacker a way in. One tree, two very different bad days.

The "Critical" That Isn't

Fine, you say: scan for vulnerabilities too, patch anything marked Critical or High, and go home.

Here is where vulnerability scanning gets genuinely harder than license scanning. A license is a fact. Package X is under the GPL, full stop, and it stays that way whether you use the package or not. A vulnerability is not a fact about your application; it is a hypothesis about it. The scanner matches a package name and a version number against a public advisory database and raises a flag. What it cannot tell you is the only thing you actually want to know: is the broken code reachable from your application at all?

That gap is not a detail. Consider a real finding from an OSSScan run, and notice how much the headline leaves out:

None of that makes the flaw fake. The flaw is entirely real, and for an application that genuinely calls the vulnerable function it may well be a fire drill. But severity describes the flaw in the abstract. It says nothing whatsoever about whether your code ever touches it. A traditional scanner cannot close that gap, because it knows package names and version strings, not your application. So it does the only responsible thing available to it and shows you everything, which is why "we have three hundred Criticals and Highs" is a sentence that sounds alarming and means almost nothing.

Answering the question properly means opening the code, finding whether the vulnerable function is called, tracing whether attacker-controlled input can reach it, and working out whether the package runs in production or only in your test suite. That is reachability analysis, and until very recently the only thing capable of doing it was a person reading the code, one finding at a time. Across hundreds of findings that is not an afternoon's work; it is weeks of it, and those weeks come out of your most experienced engineers, who spend them reading other people's libraries instead of innovating on your own product. Every hour spent proving that a package nobody chose cannot hurt you is an hour that did not go into the thing your customers are actually paying for.

And unlike licenses, vulnerabilities do not wait for you to change anything. You can freeze your dependency tree completely and still wake up to a new Critical, because the advisory was published this morning against code you shipped last year. Licensing is a question you answer once per package. Security is a question the world keeps re-asking you, forever.

The Cost of Finding Out

So you buy a scanning tool, point it at your code, and the problem is solved?

Not quite. Traditional scanning tools are excellent at exactly one thing: producing findings. Point one at a real codebase and it will cheerfully hand you hundreds of them, a wall of packages, licenses, advisories, and "possible" matches. What it will not tell you is which of those findings actually matter for your situation. That judgment is left entirely to you, and that is where the real bill comes from.

In practice, the costs land in five places:

1. The triage tax: Someone has to work through the findings by hand. For licenses, that means reading license texts and checking how each package is really used. For vulnerabilities, it means the reachability work above, repeated once per advisory: is this called, is it reachable, is it production or just build tooling, is there an upgrade path. On a codebase of any size that is weeks of expensive engineering time, and often legal time on top of it.

2. Groundhog Day: Scan again next month and most tools hand you the same wall back, including every finding you already investigated and cleared. The judgment you paid for last time does not carry forward, so you pay for it again. And because new advisories land continuously, you cannot simply choose to scan less often. You are re-buying yesterday's answers just to see today's question.

3. The "All-or-Nothing" Access Trap: Many security tools expect you to upload your source code to their cloud, create global accounts, and install intrusive agents on your local machines. For teams whose source code is the entire business, that is an incredibly difficult conversation to have with a security team, and it is often an impossible one.

4. Priced for a different problem: Per-seat annual subscriptions mean the bill scales with the size of your development team rather than the amount of scanning you actually do. Hire five developers who will never once run a scan, and your license cost still goes up.

5. Commit first, learn later: You generally have to sign the contract before you discover how well the tool understands your particular language, package manager, or build system. Coverage varies enormously between ecosystems, and you find out after the money is spent.

None of this is anyone acting in bad faith. It is simply what the tooling looked like when the only thing available to do the triage was a human being.

Why We Thought There Was a Better Way

Then the ground shifted. Almost every developer now works alongside an AI coding agent, whether that is Claude Code, GitHub Copilot, or something else. That agent already has the context of the codebase, it already reads and reasons about code all day, and you are already paying for it.

Which raises an obvious question: why is a human still doing the triage?

Look at what the triage actually consists of. Reading a license and deciding whether it binds you. Opening the code to see whether a vulnerable function is ever called, and whether anything an attacker controls can reach it. Telling the difference between a package that ships to production and one that only runs in your tests. This is tedious, context-heavy reading of exactly the kind an AI agent is genuinely good at, and it is precisely the work that made scanning slow and expensive in the first place. The costly part of OSS scanning had quietly become the part a machine could help with, and the tools had not caught up.

So we built OSSScan around that idea. We designed it against six goals, and each one is a direct answer to something that made the old way painful.

The Six Goals Behind OSSScan

1. Your AI agent does the triage. OSSScan coordinates with the AI coding agent you already use, Claude Code, GitHub Copilot, or any other, to review every finding for you. It hands the agent a structured investigation request per finding, with the dependency chain, where the package is actually imported, the severity and real-world exploitation probability, and the version that fixes it. The agent goes and reads your code, then answers the question that matters: exploitable, not exploitable, or needs further investigation, with its confidence and its reasoning, and with facts kept carefully separate from inferences. You spend your engineering bandwidth on what actually matters instead of sifting through minutiae.

2. Baselines mean you never investigate the same thing twice. Save your manual evaluations and load them as a baseline on your next scan. OSSScan carries forward every investigation you have already completed, so future scans pick up where you left off and show you the delta: what is genuinely new, and what has already been answered. That cuts both your time and your AI token costs, and it is what makes the endless drip of new advisories survivable rather than exhausting.

3. You decide how much access to give it. OSSScan never needs your source code at all: bring your own SBOM instead, and you still get full editing, AI agent coordination, and delta investigations against your baseline. Nothing you scan is written to the cloud, and OSSScan does not track who you are or what you scanned. No login, no tracking of your scan results, it all stays local. Given that a vulnerability report is a precise map of where your software is weakest, that is not a small thing to hand to a third party.

4. A real CLI, not just a GUI. Every capability is available from the command line, so you can run scans by hand or wire OSSScan directly into an automated pipeline. Since new advisories arrive whether or not anyone remembers to open a dashboard, scanning belongs in your build, not only in someone's browser tab.

5. A simple machine license, not a subscription. OSSScan is licensed short-term and per machine, not per seat. There is no yearly subscription to manage and no pricing that scales with the size of your dev team. You pay for the scanning you do, not for the headcount you have.

6. Try before you buy. Run Check Project Coverage on your source folder or an SBOM, with no license required, and compare the results. OSSScan tells you whether it expects Strong, Partial, or Limited coverage for your project before you spend a dollar. You find out first, not after.

Where That Leaves You

The dependency tree is not going away. Modern applications will keep being Lego sets assembled from other people's bricks, those bricks will keep arriving with licenses attached and flaws inside them, and the tree will keep going ten layers deep. Copyleft is not a bug in the system; it is a deliberate design by people who wanted open software to stay open, and it deserves to be respected rather than tripped over. Vulnerabilities are not a betrayal by the open-source world either; they are simply what happens when software gets written. That was true when every line was typed by a human being, and it is no less true now that so much of it is written by AI agents. The code your own team shipped this week is not exempt, whoever or whatever wrote it.

What has changed is the cost of dealing with both. Mapping your dependency tree, understanding what its licenses require of you, and working out which of its advisories can actually hurt you used to mean a large tool, a large invoice, and a great many human hours spent reading. It does not have to anymore. That is the whole reason OSSScan exists.

← Back to the OSSScan Blog