33.5: Recommendations for Different Stakeholders¶

The challenges of software supply chain security touch everyone involved in creating, securing, governing, and using software—but they touch each group differently. A developer choosing dependencies faces different decisions than an executive allocating security budget. A maintainer managing a popular project has different concerns than a policy maker drafting regulation. Effective guidance must be tailored to the specific context, authority, and constraints of each role.

Throughout this book, we've explored supply chain security from multiple angles: technical mechanisms, organizational practices, economic incentives, regulatory frameworks, and community dynamics. This section synthesizes that guidance into targeted recommendations for each major stakeholder group. While your primary role may place you in one category, many readers occupy multiple roles—the developer who also maintains open source projects, the security professional who advises executives, the researcher who influences policy. Read beyond your primary category to understand how your work connects with others in the ecosystem.

For Software Developers and Engineers¶

You build the software that relies on supply chains. Your daily decisions—which dependencies to use, how to configure tools, what to review and what to trust—shape the security of systems that may serve millions of users.

Dependency management:

Treat dependencies as commitments, not conveniences. Each dependency you add becomes part of your security surface. Before adding a package, ask: Do I really need this? What's its security track record? Who maintains it? How will I know about vulnerabilities?
Evaluate before adopting. Check OpenSSF Scorecard ratings. Review the project's security policy (SECURITY.md). Look at maintenance activity, response to security issues, and governance structure. Five minutes of evaluation can prevent months of problems.
Pin versions and verify integrity. Use lock files. Enable checksum verification. Consider signature verification where available. Don't let your build pull arbitrary versions from the internet.
Keep dependencies updated. Enable automated dependency updates through Dependabot, Renovate, or similar tools. Review and merge updates promptly. Stale dependencies accumulate vulnerabilities.
Minimize dependency count. Resist the temptation to add packages for trivial functionality. Each dependency is a risk. Sometimes writing a few lines of code is better than importing a library.

Secure development practices:

Use memory-safe languages for new projects. Rust, Go, Swift, and other memory-safe languages eliminate entire vulnerability classes. The transition takes effort, but the security benefits compound over time.
Enable security tooling. Configure static analysis, secret scanning, and dependency scanning in your development environment. Address findings promptly. Tools catch what humans miss.
Review AI-generated code with security in mind. AI assistants generate code quickly but may suggest vulnerable patterns. Treat AI output as untrusted input requiring review, especially for security-relevant code.
Protect your credentials. Your package registry credentials, signing keys, and CI/CD tokens are supply chain attack vectors. Use strong authentication. Enable two-factor authentication (2FA) everywhere. Rotate secrets regularly.
Understand what you're building on. Know your critical dependencies. Read their security documentation. Understand their threat models. Your security depends on theirs.

For Security Professionals¶

You protect organizations from threats while enabling business operations. Supply chain security adds complexity to an already challenging mission—but also provides opportunities to reduce risk systematically.

Program development:

Build supply chain security into your program. Don't treat supply chain as separate from application security. Integrate dependency scanning, SBOM generation, and supply chain risk assessment into existing workflows.
Implement defense in depth. No single control prevents all supply chain attacks. Layer protections: secure development practices, dependency scanning, build verification, runtime monitoring, incident response. Assume some attacks will succeed and limit their impact.
Prioritize based on risk. Not all dependencies warrant equal attention. Focus intensive review on critical dependencies with high privilege, broad exposure, or weak security indicators. Use automation for routine checking.
Know your inventory. You can't protect what you don't know about. Generate and maintain SBOMs for your software. Understand your dependency graph. Correlate vulnerabilities to your actual exposure.
Prepare for incidents. Supply chain incidents happen despite prevention. Develop playbooks for responding to compromised dependencies, vulnerable components, and malicious packages. Practice these playbooks.

Tool and process recommendations:

Deploy comprehensive scanning. Use tools like Snyk, Grype, Trivy, or similar for vulnerability scanning. Integrate scanning into CI/CD pipelines. Fail builds on critical vulnerabilities.
Implement SBOM processes. Generate SBOMs using tools like Syft or cdxgen. Store and manage SBOMs with platforms like Dependency-Track. Use SBOMs for vulnerability correlation and incident response.
Enable provenance verification. Verify package signatures where available. Use Sigstore for signing your own releases. Check SLSA provenance attestations when provided.
Monitor for threats. Subscribe to security advisories for critical dependencies. Monitor threat intelligence for supply chain attack patterns. Participate in information sharing with peers.
Measure and report progress. Track metrics like mean time to remediate vulnerabilities, dependency update currency, and SBOM coverage. Report to leadership on supply chain security posture.

For Technology Executives and CISOs¶

You set priorities, allocate resources, and bear accountability for security outcomes. Supply chain security requires sustained investment that may compete with other priorities.

Strategic priorities:

Recognize supply chain security as strategic risk. Supply chain attacks can cause significant financial, operational, and reputational damage. SolarWinds (§7.2), Log4Shell (§5.1), and similar incidents affected major organizations. Treat supply chain security with commensurate priority.
Invest proportionate to risk. Assess your supply chain exposure—how many dependencies, how critical, what's the blast radius of compromise? Invest security resources proportionate to this exposure, not just to traditional application security.
Set clear expectations. Establish organizational standards for dependency management, security scanning, and supply chain practices. Make these expectations clear and enforceable, not just aspirational.
Fund the ecosystem you depend on. Your organization relies on open source infrastructure maintained by others. Consider contributing to OpenSSF, sponsoring critical projects, or funding security audits. Ecosystem investment is enlightened self-interest.
Plan for long-term improvement. Supply chain security matures over years, not quarters. Set multi-year objectives. Accept incremental progress. Avoid expecting transformation overnight.

Governance and risk management:

Include supply chain in risk assessments. Ensure enterprise risk assessments consider supply chain exposure. Quantify potential impact of major supply chain incidents. Include supply chain in board-level risk reporting.
Establish supply chain governance. Define roles and responsibilities for supply chain security. Establish policies for dependency adoption, update requirements, and incident response. Integrate with existing governance frameworks.
Prepare for regulatory requirements. EU CRA, federal SBOM mandates, and sector-specific regulations are expanding. Assess your exposure to emerging requirements. Begin compliance preparation before deadlines.
Evaluate insurance coverage. Review cyber insurance policies for supply chain coverage. Understand exclusions, sublimits, and requirements. Work with insurers to optimize coverage for your risk profile.
Build relationships with key suppliers. Identify critical software suppliers and open source dependencies. Establish communication channels. Understand their security practices. Include supply chain security in vendor management.

For Open Source Maintainers¶

You create and maintain the software that powers the world. Your work provides enormous value, often without adequate compensation or support. Supply chain security adds responsibility to already demanding roles.

Project security practices:

Publish a security policy. Create a SECURITY.md file explaining how to report vulnerabilities. Provide secure communication channels. Set expectations for response. This simple step helps researchers help you.
Protect your credentials. Your package registry accounts, commit signing keys, and CI/CD access are high-value targets. Enable strong authentication. Use hardware security keys where possible. Limit who has publish access.
Implement basic security controls. Enable branch protection. Require code review for changes. Use CI/CD for builds rather than local builds. These practices provide assurance your project isn't a soft target.
Keep dependencies updated. Your dependencies' vulnerabilities become your users' vulnerabilities. Enable automated updates. Review and merge promptly. Model the practices you want your users to follow.
Pursue Best Practices Badge. The OpenSSF Best Practices Badge provides a roadmap for security practices appropriate to your project's stage. Even if you don't complete it, the assessment identifies improvements.

Sustainability and support:

Communicate your support model. Be clear about what users can expect—whether this is a passion project with best-effort support or an actively maintained critical component. Help users make informed decisions.
Seek support for security work. Security improvements require time and expertise. Explore GitHub Sponsors, Open Collective, Tidelift, or foundation affiliation. Apply for audit funding through OSTIF or similar. Security work deserves compensation.
Build contributor community. Single-maintainer projects are fragile. Cultivate contributors who can share security response burden. Document processes so others can help.
Know when to step back. If you can't maintain a project securely, communicate that clearly. Archive inactive projects. Help transition to new maintainers if possible. An honestly abandoned project is better than one silently decaying.
Connect with community. Join OpenSSF working groups, security researcher networks, and peer maintainer communities. Learn from others' experiences. Share your own. Collective knowledge improves everyone's security.

For Policy Makers and Regulators¶

You shape the rules that influence how organizations approach security. Well-designed policy can accelerate improvement; poorly designed policy can create burden without benefit.

Policy design principles:

Focus on outcomes, not technologies. Mandate security objectives (verified provenance, vulnerability management, incident response) rather than specific technologies. Allow flexibility for implementation while ensuring results.
Align with existing frameworks. Build on NIST SSDF, OpenSSF guidance, and established standards rather than creating parallel requirements. Consistency reduces compliance burden while increasing actual security.
Allow realistic timelines. Compliance requires tool development, process change, and skill building. Provide phased implementation timelines. Learn from EU CRA's multi-year transition approach.
Avoid unintended consequences. Consider how requirements affect open source volunteers, small businesses, and innovation. Requirements appropriate for large enterprises may be impossible for individual maintainers. Design thoughtfully.
Support, don't just mandate. Complement requirements with resources—guidance, tools, funding for compliance support. Requirements without support burden those least able to comply.

Specific policy recommendations:

Require SBOMs for critical software. SBOM requirements for government procurement and critical infrastructure software improve transparency without excessive burden. Build on existing NTIA minimum elements.
Establish safe harbors for good practices. Create incentives for security investment by providing liability protection for organizations following recognized secure development frameworks.
Fund ecosystem security. Invest in open source security as public infrastructure through sovereign tech funds, research programs, and coordination support. Public benefit justifies public investment.
Support international coordination. Supply chains are global. Coordinate with international partners on standards, requirements, and enforcement. Avoid creating fragmented, conflicting requirements.
Engage with technical community. Effective policy requires technical understanding. Include practitioners, researchers, and maintainers in policy development. Test requirements against real-world constraints.

For Researchers and Educators¶

You advance knowledge and prepare the next generation of practitioners. Your work shapes both the state of the art and the skills of future professionals.

Research priorities:

Address practical challenges. The most impactful research solves real problems practitioners face—scalable provenance verification, automated dependency risk assessment, detection of malicious packages. Connect with industry to understand needs.
Evaluate effectiveness. Many security practices are adopted without evidence of effectiveness. Research what actually works—which tools detect what threats, which practices improve outcomes, what's security theater versus genuine improvement.
Study ecosystem dynamics. Supply chain security involves economic, social, and organizational factors beyond technology. Research maintainer sustainability, incentive structures, cultural factors, and coordination challenges.
Advance formal methods accessibility. Formal verification provides high assurance but remains difficult to apply. Research that makes verification more accessible—better tools, clearer methods, reduced expertise requirements—multiplies impact.
Share findings openly. Publish in venues practitioners can access. Create practical guidance alongside academic papers. Tools and datasets enable follow-on work. Open research accelerates progress.

Educational priorities:

Include supply chain security in curricula. Software engineering and security courses should cover dependency management, SBOM, provenance, and supply chain threats. Graduates should understand ecosystem security, not just individual program security.
Provide hands-on experience. Students learn supply chain security by practicing it—managing dependencies in real projects, using security tools, contributing to open source. Theoretical knowledge alone is insufficient.
Teach security mindset. Beyond specific techniques, teach students to think about trust, verification, and defense in depth. These principles apply regardless of how technology evolves.
Connect with industry. Bring practitioners into classrooms. Send students to open source projects. Build connections that help students understand real-world context and help industry access emerging talent.
Develop accessible resources. Create tutorials, exercises, and educational materials others can use. Share curriculum. Build community around supply chain security education.

For Open Source Consumers¶

You use open source software in your products, services, and internal systems. Your choices as a consumer shape ecosystem incentives and your own security.

Responsible consumption:

Acknowledge your dependence. Inventory the open source software you rely on. Understand how critical each component is. Recognize that you've built on others' work and have responsibilities in return.
Contribute back. If you benefit from open source, contribute proportionately—financial support for projects and foundations, engineering time for maintenance and security, bug reports and documentation improvements. Consumption without contribution degrades the commons.
Maintain your dependencies. Don't adopt open source and ignore it. Keep components updated. Monitor for vulnerabilities. Respond to security issues. You accepted responsibility when you adopted the software.
Support maintainers. Maintainers are often overwhelmed. Be respectful in issue reports and feature requests. Acknowledge their volunteer work. Understand that your urgent problem may not be their priority.
Make informed choices. When selecting open source components, consider security alongside functionality. Use available assessments—Scorecard, Best Practices Badge, security history. Choose components that demonstrate security commitment.

Organizational practices:

Implement governance. Establish policies for open source adoption, update requirements, and security expectations. Don't let adoption be ad hoc decisions without oversight.
Build response capability. When vulnerabilities emerge in your open source dependencies, you need to respond quickly. Know your exposure. Have processes for rapid assessment and remediation.
Engage with supply chain security initiatives. Join OpenSSF. Participate in industry coordination. Share your experiences. Collective action improves security for everyone.
Prepare for regulation. SBOM requirements, vulnerability disclosure mandates, and security attestations are expanding. Build capabilities before they're required. Compliance prepared-for is cheaper than compliance-forced.
Plan for sustainability. What happens if a critical dependency loses its maintainer? Have contingency plans—alternative components, capability to fork and maintain, commercial support relationships.

Cross-Cutting Themes¶

Several themes apply across all stakeholder groups:

Shared responsibility:

Supply chain security is everyone's responsibility. Developers choose dependencies. Security professionals monitor them. Executives fund improvement. Maintainers secure their projects. Policy makers create incentives. Researchers advance knowledge. Consumers use responsibly. No single group can solve the problem alone. Success requires coordinated effort across all roles.

Long-term commitment:

Supply chain security improves through sustained investment over years and decades, not through quick fixes. Each stakeholder should plan for long-term engagement, measuring progress incrementally rather than expecting immediate transformation.

Balance and pragmatism:

Perfect security is impossible. The goal is meaningful risk reduction at acceptable cost. Each stakeholder should focus on highest-impact improvements within their constraints rather than pursuing unachievable perfection.

Community engagement:

Supply chain security benefits from community collaboration—sharing knowledge, coordinating on standards, collective investment in infrastructure. Each stakeholder should engage with relevant communities, contributing to and learning from collective efforts.

Continuous learning:

The threat landscape, technology options, and best practices continue evolving. Each stakeholder should commit to continuous learning, updating practices as the field advances.

By fulfilling their respective roles effectively and coordinating with others in the ecosystem, stakeholders can collectively build the trustworthy software supply chains that modern society requires.