Table of contents
- Beyond the myth: “closed source = secure”
- Closed SDKs: the most common blind spot
- “Certified” plugins that are no longer maintained
- Forgotten JavaScript dependencies
- The supply chain in proprietary software
- An organizational problem, not just a technical one
- Why this topic is more relevant than ever
When people talk about dependency security, the conversation almost automatically turns to open source. Log4j, npm, PyPI, Maven: in recent years, both media and technical attention have focused mainly on open libraries, public repositories, and vulnerabilities inherited from third-party code. But as grounded as this narrative may be, it is incomplete.
The software supply chain is not an open-source-only problem. In many enterprise environments, the greatest risk comes precisely from what is perceived as “secure by definition”: proprietary SDKs, certified plugins, commercial components, and closed dependencies that no one really inspects.
This article starts from that premise: challenging a common assumption and explaining why dependency security concerns all software, not just open source. We’ll do this through concrete examples, real-world scenarios, and a deliberately non-trivial perspective aimed at people who actually work with complex systems.
Beyond the myth: “closed source = secure”
In many organizations there is still an implicit assumption: if a component is proprietary, it must also be more secure. The reasoning is simple and reassuring: the code is not public, the vendor is responsible, there is a contract, maybe even a certification. Problem solved.
In reality, this approach confuses control with trust. The fact that code is not visible does not mean it was written well, maintained properly, or updated promptly. On the contrary, opacity makes it harder to identify vulnerabilities, understand their impact, and assess real risk.
In the open-source world, at least in theory, anyone can analyze the code, report bugs, and propose fixes. With closed software, everything depends on:
- the vendor’s timelines and priorities
- transparency in vulnerability disclosure
- the quality of internal development processes
- the actual willingness to fix issues that don’t directly impact revenue
Supply chain security thus becomes a problem of information asymmetry: you use the component, but you don’t really know what’s happening inside it.
Closed SDKs: the most common blind spot
Examples
Proprietary SDKs. They are everywhere: analytics, advertising, payments, authentication, cloud services, IoT, mobile apps. They are often integrated with just a few lines of code, following official documentation and without further questions.
The problem is that an SDK:
- runs inside your application
- has access to the same permissions
- communicates externally
- can update dynamically
If an SDK contains a critical vulnerability, it immediately becomes part of your risk perimeter.
In several real incidents, closed SDKs introduced:
- undocumented remote code execution paths
- outdated internal libraries (openssl, curl, zlib)
- calls to deprecated or unmaintained endpoints
- silent update logic outside the team’s control
The paradox is that these SDKs are often not even considered “dependencies” in security processes. They don’t appear in SBOMs, aren’t scanned, and fall outside patch-management policies. They are trusted black boxes until the day an incident occurs.
“Certified” plugins that are no longer maintained
Another critical area is certified plugins. CMS platforms, e-commerce systems, ERPs, CRMs, collaboration tools—all of them expose official marketplaces with extensions labeled “verified,” “approved,” or “certified.”
These labels send a clear message: you can trust this. But in most cases, certification means:
- an initial review
- functional validation
- rarely a continuous security audit
The result is that many plugins:
- remain technically compatible
- stop receiving meaningful security updates
- accumulate technical debt
- continue to be distributed because they are “official”
In multiple compromise cases, the entry point wasn’t the platform core, but a certified plugin installed years earlier, never reviewed again, and forgotten even by administrators.
Here, dependency security fails not because of missing tools, but because of institutionalized trust.
Forgotten JavaScript dependencies
The JavaScript ecosystem deserves its own discussion. Modern frontends, Node.js backends, build tools, CI/CD pipelines everything revolves around deep and transitive dependencies.
The issue isn’t just quantity, but persistence. Many dependencies:
- are added to solve a specific problem
- remain in the project even when no longer needed
- aren’t updated because “everything works”
Over time, this creates layers of libraries that are:
- no longer directly used
- still present in bundles
- affected by known vulnerabilities
- often flagged, but ignored
In enterprise environments it’s common to find projects with:
- dozens of unreferenced dependencies
- versions pinned for years
- packages maintained by developers who no longer exist
The risk is not theoretical. A forgotten JavaScript dependency can become a supply chain attack entry point, especially if the maintainer or publishing account is compromised.
The supply chain in proprietary software
When people think about proprietary software, they often imagine a monolithic product developed entirely in-house by the vendor. In reality, modern commercial software is also a chain of dependencies.
A closed product may include:
- embedded open-source libraries
- licensed third-party components
- SDKs from other vendors
- external cloud services
- legacy modules never rewritten
The end customer sees a single interface, but underneath lies a complex and often invisible supply chain. When a vulnerability emerges, the problem becomes twofold:
- technical dependency
- contractual dependency
You can’t patch it yourself. You have to wait. And in the meantime, you’re exposed.
This is one reason why dependency security in proprietary software is, paradoxically, harder to manage than in open source.
An organizational problem, not just a technical one
A common mistake is treating dependency security as a purely technical issue. In reality, it’s largely organizational and cultural.
Typical warning signs include:
- no clear ownership of dependencies
- no up-to-date inventory
- audits performed sporadically
- “legacy” dependencies considered untouchable
- vendors trusted by default
In this context, even the best scanning tool has limited impact. Software supply chain security requires clear processes:
- dependency ownership
- adoption and decommissioning criteria
- vendor risk assessment
- continuous monitoring
Without these foundations, security remains reactive and fragmented.
Why this topic is more relevant than ever
Supply chain attacks have increased in recent years because they are efficient. Compromising a dependency allows attackers to reach hundreds or thousands of targets with a single effort.
And while attention remains focused on open source, many organizations stay vulnerable precisely where they feel safest: commercial software, official plugins, “trusted” SDKs.
The real paradigm shift is this:
Dependency security is not about licensing, but about visibility, control, and accountability.
Conclusion
Believing that supply chain risk concerns only open source is a dangerous oversimplification. Closed SDKs, certified plugins, and forgotten dependencies prove every day that the problem cuts across all software.
The right question is not “is it open source or proprietary?”
But rather:
- who maintains it?
- how is it updated?
- what happens if a vulnerability is discovered tomorrow?
Only by addressing dependency security systemically rather than ideologically can organizations truly reduce risk. Everything else is just a false sense of control.
Frequently asked questions
- Does dependency security concern only open source?
No, it also affects proprietary software, closed SDKs, and certified plugins. - Why are proprietary SDKs risky?
Because they are black boxes with high privileges and often outside security controls. - Are certified plugins always secure?
No, initial certification does not guarantee ongoing maintenance. - What are forgotten dependencies?
Libraries no longer used directly but still present in the project. - Does proprietary software have a supply chain?
Yes, it often includes many third-party components. - Why is it hard to manage vulnerabilities in closed products?
Because you depend on the vendor’s timelines and decisions. - Do SBOMs include proprietary components?
They should, but often they don’t do so completely. - Are automated tools enough?
No, without clear processes and ownership they remain ineffective. - What is the most common company mistake?
Trusting the vendor without verification. - What is the first concrete step?
Mapping all dependencies, regardless of license.
