The open source blind spot in our supply chains

A recent report highlighted that nearly a third of business leaders have seen an increase in cyber attacks targeting their supply chains. The focus, understandably, has been on supplier concentration, third parties and the domino effect when one partner falls. This concern is valid, but it’s incomplete.

There is another supply chain risk that rarely makes it to the agenda of board. It doesn’t arrive through a vendor contract and is not listed in a procurement register. It’s also not captured in a due diligence questionnaire. The risk is open source software.

Today, open source components underpin almost every modern digital service.

From customer portals to payment platforms, from cloud workloads to internal tooling, development teams rely on libraries, frameworks and container images pulled from public repositories. In many environments, more than 80 percent of the code base can be traced back to open source components.

Yet when executives discuss supply chain exposure, the conversation typically focuses on managed service providers, outsourced IT and hardware dependencies. The open-source layer remains largely invisible.

Underneath the surface

Most organizations still frame cyber risk around familiar narratives: phishing emails, ransomware gangs, credential theft and social engineering. These are tangible threats. They are easy to explain and measure, and these are the ones that generate headlines.

Open source risk, by contrast, is quiet and systemic. There is no malicious email to point at. There is no obvious adversary knocking at the door. Instead, risk enters through a routine developer action: importing a library to accelerate delivery.

The challenge is not that open source is inherently insecure. The challenge is that it’s decentralized and largely unregulated. Anyone can publish a package. Anyone can update it. Maintainers can change. Dependencies can shift. A component that was stable and secure yesterday can introduce a critical flaw today.

In effect, organizations are continuously importing code from an external ecosystem that they do not govern and cannot control. This is supply chain risk in its purest form.

A landscape that moves by the minute

Traditional risk management models struggle to cope with this reality. Many enterprises still rely on point-in-time assessments, e.g.an ISO certification, or annual vendor reviews or regular audits.

These approaches assume relative stability and that what was assessed remains materially the same until the next review.

However, open-source software doesn’t operate on that timetable.

Libraries are updated daily, sometimes hourly. New dependencies are introduced automatically through build processes. Container images are rebuilt and republished.

A previously trusted component can become vulnerable within minutes of a new disclosure or a malicious update. The notion that an annual certification reflects the real-time security posture of a software stack is completely outdated.

We’ve seen incidents where a single compromised package in a public repository cascaded across thousands of downstream projects. Not because organizations were careless, but because they had no visibility into the deeper layers of their dependency tree.

The result is systemic exposure that sits below the surface of standard governance frameworks.

The ingestion problem

One of the most overlooked moments in software risk is the point of ingestion. When a developer pulls a new library or container image into an environment, that is a supply chain decision. It is the equivalent of onboarding a new vendor.

Yet in many organizations, this decision is made without guardrails. There is no verification of provenance or reputation scoring. By the time security teams review the code base, the component is already embedded, deployed and in production.

Mature organizations are starting to rethink this. They are scanning libraries and container images as they enter the environment, not weeks later.

They are verifying digital signatures, tracking the origin of packages and enforcing policies that restrict untrusted sources. They are continuously monitoring for drift, recognizing that a once trusted component can degrade over time as new vulnerabilities emerge.

This is not about slowing innovation, but it’s about bringing the same discipline to code dependencies that we already apply to financial suppliers and critical infrastructure partners.

The case for independent risk ratings

One structural weakness in the open-source ecosystem is the absence of an independent, widely adopted risk rating system. In financial markets, we rely on credit ratings to assess counterparty risk. In hardware, we have safety standards and regulatory oversight.

In open source, we largely rely on community trust and reactive vulnerability disclosures.

A more mature model would introduce transparent risk indicators for widely used components. Factors such as maintainer activity, update frequency, known vulnerabilities, dependency complexity and source integrity could be quantified.

Organizations could then make informed decisions based not just on functionality, but on systemic risk.

This doesn’t require heavy-handed regulation. It requires collaboration between industry, repository operators and security researchers to provide clearer signals to the market.

Without that visibility, enterprises are flying blind.

Balancing innovation with exposure

Open source has transformed innovation. It has often accelerated development, reduced costs and enabled speedy experimentation. Walking away from it is neither realistic nor desirable.

The goal is balance.

Security leaders need to expand their definition of supply chain risk to include code. Boards need to understand that systemic exposure can be imported silently through development pipelines. Governance frameworks need to evolve from static audits to continuous oversight.

Attack surface management in 2026 cannot stop at internet-facing assets and third-party contracts. It must reach into the software bill of materials, into dependency trees and into the real-time health of open source components.

The uncomfortable truth is that many organizations are secure one moment and insecure the next, not because an attacker breached their perimeter, but because a library they depend on changed.

If nearly a third of leaders are already seeing increased supply chain attacks, the question is not whether open source risk will become a focal point. It is when.

The sooner we treat open source ingestion as a board-level supply chain issue rather than a developer convenience, the stronger our digital foundations will be.

We've featured the best online cybersecurity course.

This article was produced as part of TechRadarPro's Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro