AWS popularized the shared responsibility model for cloud security: AWS secures the infrastructure, you secure what you put on it. The dividing line is clear, documented, and widely understood.
Software supply chains have no such clarity. When a vulnerability is found in an open-source library, who is responsible? The maintainer who wrote the code? The package registry that distributed it? The organization that included it in their application? The scanner vendor who did or did not detect it?
The answer, in practice, is that nobody feels responsible until something breaks. This ambiguity is a fundamental problem for supply chain security.
The Responsibility Layers
Open-Source Maintainers
Maintainers create and publish software. Their reasonable responsibilities include writing secure code to the best of their ability, responding to reported vulnerabilities, publishing security advisories for known issues, and providing updates that address security problems.
What is unreasonable to expect from maintainers, many of whom are unpaid volunteers: guaranteed response times, formal security audits, long-term support commitments, and liability for vulnerabilities.
The OpenSSF's work on maintainer security practices and the Alpha-Omega project's investment in securing critical projects acknowledge this reality. Maintainer responsibility has natural limits tied to their resources and incentives.
Package Registries
Registries (npm, PyPI, Docker Hub, Maven Central) distribute software. Their responsibilities include protecting the integrity of hosted packages, preventing unauthorized package modifications, implementing authentication and access controls, removing known-malicious packages when reported, and providing package provenance information.
Registries are not responsible for the security quality of every package they host. They are platforms, not auditors. But they are responsible for the security of the platform itself: preventing account takeover, namespace squatting, and metadata manipulation.
Software Vendors
Commercial software vendors who include open-source components in their products take on responsibility for the security of those components. Their responsibilities include maintaining an SBOM of included components, monitoring for vulnerabilities in dependencies, providing patches that address dependency vulnerabilities, and communicating to customers about supply chain risks.
Vendors cannot shift responsibility to open-source maintainers. When you ship a product with a vulnerable library, it is your product and your customers' problem, regardless of who wrote the library.
Consumer Organizations
Organizations that build applications using open-source components are ultimately responsible for the security of their applications. This means choosing dependencies thoughtfully, monitoring for vulnerabilities, remediating vulnerabilities within defined SLAs, maintaining SBOMs for all deployed software, and having incident response plans for supply chain compromises.
"We use open source" is not a risk mitigation statement. It is a responsibility statement.
Where Responsibilities Overlap
Vulnerability Disclosure
The disclosure process spans multiple parties. The researcher discovers the vulnerability. The maintainer develops a fix. The registry may coordinate disclosure timing. Vendors need time to patch their products. Consumer organizations need time to update their applications.
This coordination frequently breaks down. Researchers disclose publicly before maintainers have patches. Maintainers fix silently without advisories. Vendors delay patching. Organizations discover they are affected weeks after everyone else.
SBOM Generation
Who is responsible for generating SBOMs? Ideally, every participant in the supply chain generates SBOMs for their contribution. Maintainers document their package's dependencies. Vendors document the components in their products. Organizations document the components in their applications.
In practice, SBOM generation falls to consumer organizations because they are the ones who need the information and can least afford to be without it.
Security Scanning
Scanning happens at multiple points: registries may scan hosted packages, vendors scan their products, and consumers scan their applications. The ideal is defense in depth where each layer catches issues the others miss. The reality is that organizations often assume someone upstream has already scanned and found nothing, which may not be true.
Building a Clear Model
Document Your Expectations
For each component in your supply chain, document what security assurances you expect from the upstream provider and what you are responsible for verifying yourself.
If you use an open-source library, do not assume the maintainer has conducted a security audit. Assume they have done their best and you are responsible for validating the library meets your security requirements.
Define Internal Responsibilities
Within your organization, clarify who is responsible for dependency selection and evaluation, vulnerability monitoring and notification, remediation within SLA, SBOM generation and maintenance, and incident response for supply chain events.
Assign these responsibilities to specific teams or roles. Shared responsibility without clear ownership is no responsibility at all.
Establish Vendor Requirements
When purchasing commercial software, include supply chain security requirements in your vendor assessment: SBOM availability, vulnerability notification timelines, patch response commitments, and transparency about open-source component usage.
Contribute Upstream
If your organization depends heavily on specific open-source projects, consider contributing to their security. This can take the form of code contributions, security audits, financial support, or simply reporting vulnerabilities through responsible disclosure.
This is not altruism. It is supply chain risk management. Improving the security of your dependencies directly reduces your own risk.
How Safeguard.sh Helps
Safeguard.sh helps organizations fulfill their side of the shared responsibility model by providing comprehensive SBOM management, continuous vulnerability monitoring, and supply chain risk assessment. It ensures you know exactly what components your software depends on, which of those components have known vulnerabilities, and what actions you need to take to maintain your security posture. Safeguard.sh turns the abstract concept of supply chain responsibility into concrete, actionable visibility.