When Does Enterprise Responsibility for Shared Technology Begin?

All enterprises depend on technology they do not own. Some of this comes from commercial vendors, but much of it is embedded in the open source software, development tools and shared infrastructure that companies use daily. These foundations make modern enterprise technology possible, while the organisations that profit from them may not really be active in keeping them functioning. 

From a security perspective, that is an interesting problem. A company might spend a lot safeguarding its own systems, yet rely on shared technology maintained by a tiny team with significantly fewer resources. If that technology is compromised, it might affect every organisation that uses it. 

So where does enterprise responsibility start? Benefiting from shared technology does not necessarily mean an organisation is responsible for maintaining it. But if a business relies on that technology for key operations and its security has ripple effects on others, there can be good reasons to help sustain it. 

The question therefore is how to decide when such reasons are strong enough to warrant participation, what form that participation should take and where the responsibility of the enterprise reasonably ends.

Why Shared Technology Security Raises Questions of Responsibility

Most business security strategies focus on securing the systems, applications and data within the organisation’s environment. Even if a company employs technology from external sources, there’s typically a contract or service agreement that helps specify who is responsible for what. But shared tech doesn't always work that way. 

For example, think about public package registries. These are services that developers use to search for, download and publish reusable software components. Thousands of organisations can use the same registry without having any direct interaction with the people running it. 

And whilst these organisations are benefiting from the service, they don’t necessarily pay for its security or maintenance. The Open Source Security Foundation (OpenSSF) released an enterprise commitment to sustainable package registries in September 2026. 

The pledge, supported by organisations including Microsoft, Google, IBM and Red Hat, recognises that public registries face increasing security and operational challenges that current funding models may not be able to support. The worry goes beyond just keeping these services available. 

Package registries also need the tools to find malicious software, to keep the published components trustworthy, and to fix things when they go wrong. An organisation can protect its own development environment, but it can’t solve all the security issues affecting the shared infrastructure its developers use in isolation. 

This creates a divide between the organisations reaping the benefits and those doing the job of keeping the technology secure. And it presents a challenge that standard security approaches based on ownership don’t quite address: when should the enterprises that rely on these foundations step up and play a more active role in securing them?

When Does Reliance Become a Reason to Contribute?

An organisation may routinely employ shared technology in the course of its operations. If every dependency created a responsibility to contribute, then businesses would soon be saddled with more projects than they could properly maintain. The strength of that responsibility will depend on the relationship between the business and the technology. 

Take two organisations using the same open source component. One uses it in a small internal application that might easily be replaced. The other uses it in a variety of customer-facing services, where a major security failure might disrupt operations and affect thousands of users. 

The component is a benefit for both businesses, but their reliance on it is considerably different. The more vital a shared foundation is to an enterprise’s operations, the more reason there is to consider helping sustain its security. 

This is especially true where the technology is hard to replace, its maintenance resources are restricted or a security failure can impact companies beyond the enterprise itself. Commercial gain is also a consideration. 

A firm that’s making a lot of money from services built on shared infrastructure has a different relationship with that infrastructure than an individual developer using it for a personal project. But there’s more to the story than dependence and commercial worth. 

An enterprise can be strongly reliant on a project that already has good backing, while another critical component is receiving insufficient security attention. The opportunity to make a useful contribution is also part of the decision. This is where the concept of stewardship materiality is helpful. 

It’s a way of thinking about when an organisation’s relationship with shared technology is significant enough to deserve active assistance, rather than just managing the risks of using it. It’s not an established industry framework or a fixed threshold. 

Instead, it helps security leaders think through the practical questions involved: how dependent is the business on the technology, what could go wrong if it fails, who else is impacted, and can the organisation really do anything to help?

What Makes a Security Contribution Proportionate?

Once a company has established a reason to contribute, it still has to decide what useful participation looks like. One possibility is financial support, especially if a project depends on consistent funding for security infrastructure or technical expertise. But money is not always the best contribution. 

A project might need engineers to identify vulnerabilities, better testing tools or help assessing security findings. Another might benefit more from infrastructure resources or help improving the process for reporting and correcting security issues. 

In March 2026, the Linux Foundation announced $12.5 million in total funding for open source security. Contributions came from Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft and OpenAI, with funding administered through Alpha-Omega and OpenSSF. The effort is meant to help maintainers deal with increased security needs, like the growing number of vulnerabilities that automated tools are finding. 

It’s a good illustration of how organisations can come together to support shared security work rather than relying on individual maintainers or a single corporation to handle the load. However, the contribution of an enterprise should reflect the real needs of the project. Sending engineers to a project that can’t review their work could put extra strain on its maintainers. 

If no one has time to operate yet another security tool, funding it won’t necessarily help. The contribution should be proportional to the project’s circumstances and the enterprise’s resources and experience. Sometimes the most helpful thing to do will be straightforward technical work. In other circumstances, supporting an existing effort can do more. 

And helping secure shared technology doesn’t mean a business gets to control how that technology is run.

Why Responsibility Does Not Mean Control

Companies are used to having a degree of control over the technology that they buy. They can negotiate contracts, set service expectations and hold suppliers to account for agreed outcomes. When the technology is maintained by an independent open source community, the relationship becomes more complicated. 

A corporation might pay for security enhancements because it relies on a project, but maintainers still have responsibilities to the wider community. They need to think about other users, the ongoing health of the project and the resources available to support changes. 

A contribution that is good for one organisation may be bad for others if it skews development priorities away from the broader needs of the project. An illustration of how commercial needs can be handled without losing the public role of a shared foundation is the Open VSX Managed Registry announcement from the Eclipse Foundation in April 2026. 

Open VSX is a registry for extensions used by compatible development tools. Commercial adopters get defined support arrangements and a 99.95% uptime service-level agreement with the managed service, while the public registry continues to be free to use. The approach recognises that businesses using shared infrastructure at a commercial scale may require different levels of support and reliability. 

It also demonstrates how such requirements can be met using a service model, as opposed to giving individual customers authority over the underlying ecosystem. Responsible participation means companies working with the people who are already maintaining the technology. 

Security concerns can be a reason to ask for improvements or offer resources, but they do not automatically give a contributor authority over the direction of the project.

Where Should Enterprise Responsibility End?

Even where an organisation relies on shared technology, there are limits to what it may reasonably offer. Security teams already have challenging choices about how to spend their time and resources. Another set of expectations comes from supporting external projects, and these need to be balanced against the organisation’s existing obligations. 

There are solid reasons why a corporation might want to support a crucial piece of software, but that doesn't mean it needs to be responsible for every library, tool or service it's linked to. The calculation also varies depending on the existing support around a project. Where there are already several organisations contributing to its security efforts, another firm may be able to join through an existing programme. 

Where a project has minimal backing, direct involvement could be more valuable, provided the organisation has the right expertise. And then there is the matter of influence. An organisation can provide funding, technical assistance or specialist knowledge, but it cannot ensure that all security concerns will be addressed. 

Some issues may require collaboration across numerous projects or organisations, while others may be outside the scope of available resources. That does not remove the organisation's responsibility for its own systems' security. Even if it has committed to supporting the people maintaining shared technology, it still has to manage the risks of using it. 

The boundary can also change. A component that was formerly a small part of an organisation’s infrastructure may become important for a new service. Similarly, a company might lessen its reliance on a project or switch to an alternative. 

An enterprise’s stewardship responsibility should be tied to its relationship with shared technology, not to a permanent commitment based on past reliance.

How Can Enterprises Recognise Where Stewardship Matters Most?

The difficulty for security leaders is to identify when a shared technology dependency warrants more than the typical internal risk controls. It starts with asking what the organisation would lose if the technology was unavailable or insecure. 

A vulnerability in a widely used component could expose a number of vital services, while a failure of a shared registry could impair the software development and delivery process itself. Then you evaluate how far those repercussions might reach. 

If a company provides products or services for other organisations, its customers could be indirectly dependent on the same foundation. This means that its security decisions can affect people and businesses who are not directly involved with the original technology project. From there, leaders need to know what help already exists and whether their organisation has something useful to give. 

For instance, a business with experienced security engineers may be able to help a project improve its vulnerability testing. Another organisation may be better suited to sponsor maintenance work through a foundation. For a business that is using shared infrastructure at a substantial scale, a commercial support contract may be the most appropriate answer. 

These judgements should be made alongside enterprise security strategy, but they are not just another way to rank software vulnerabilities. A vulnerability assessment helps an organisation determine which flaws to remediate in its own environment. The stewardship question is whether the organisation should also contribute to strengthening the shared foundation on which that environment is based. 

This distinction is important since the two decisions can result in different actions. A company may need to replace a vulnerable component immediately while still recognising that the wider project would benefit from continued security support. Security leaders don’t need a one-size-fits-all approach for making these choices. 

They require enough knowledge about the organisation's dependence, the circumstances of the project and their potential contributions to make a justified judgement. Because all three can change, those decisions need to be reassessed as the organisation’s technology and security requirements change.

Final Thoughts: Shared Security Requires Proportionate Responsibility

Traditionally, enterprise security has been about securing what an organisation owns, operates or directly controls. However, modern enterprises rely on technological foundations that extend far beyond these limits, and the security of such foundations can affect anyone who uses them. Simply benefiting from shared technology is not enough to create a responsibility to maintain it. 

A stronger justification for participation arises if a firm depends on a foundation for critical activities, its security has wider effects and the organisation has a realistic opportunity to help. That responsibility needs limits too. Supporting shared technology does not mean taking it over, taking on every maintenance burden or replacing the work of existing communities. 

It means understanding where the organisation’s relationship with a shared foundation justifies a proportionate contribution to its ongoing security. As enterprise systems become more interconnected through shared software and infrastructure, security leaders will need to think beyond defending the technologies they use. 

They’ll also have to consider when helping to sustain that technology is part of defending the business itself. As EM360Tech continues to cover the responsibilities that come with shared technology, the question for enterprise security leaders is becoming harder to ignore: are they doing enough to protect the foundations their businesses depend on?