Open Source Friday with OpenSSF - Global Cyber Policy Working Group

Key Concepts:

• Open Source Security Foundation (OpenSSF)
• Global Cyber Policy Working Group
• EU Cyber Resilience Act (CRA)
• Software Bill of Materials (SBOM)
• Upstream vs. Downstream in Software Development
• Open Source Software (OSS) Stewards
• Security Baseline
• Secure by Design
• International Standards (e.g., ISO 27000 series)
• Vulnerability Disclosure
• AI in Software Development

1. Background and Mission of the OpenSSF Global Cyber Policy Working Group:

• The working group was formed due to member interest in international cybersecurity legislation, particularly the EU CRA.
• The mission is to provide resources to members for understanding laws and frameworks and to educate policymakers on how open source works and how legislation impacts upstream development.
• The group aims to bridge the gap between open source projects and global policy requirements, considering frameworks in the US, Europe, India, Japan, South Korea, and other regions.

2. Key Achievements and Initiatives:

• Building a global community of individuals from various countries and organizations.
• Providing training and guidelines for compliance with the CRA and other global frameworks.
• Developing a free course on understanding the CRA and a brief guide for OSS developers.
• Working on guidelines for stewards and bridging open source projects to global policy requirements.
• Mapping multiple initiatives across the globe to create synergies between frameworks and regulations.

3. The EU Cyber Resilience Act (CRA):

• The CRA introduces mandatory cybersecurity requirements for digital products and services in the EU.
• It aims to ensure better protection against cyber threats and secure the entire software chain.
• The final text clarifies that the regulation generally doesn't apply to non-commercial open source software and introduces the category of "stewards."
• The CRA impacts the broader software ecosystem by imposing responsibilities on manufacturers to integrate cybersecurity throughout a product's lifecycle, report exploited vulnerabilities, and support products with security updates for at least 5 years.
• Open source products may opt for self-assessment, but the regulation could indirectly pressure projects to meet commercial-grade standards.
• The CRA is considered one of the most consequential pieces of cybersecurity regulation in recent memory, with far-reaching implications for the open source ecosystem.
• Other governments worldwide are looking at the CRA as a model for their own legislative agendas.

4. Implications of the CRA for Open Source:

• The CRA is focused on commercial software, with several triggers determining whether software is considered commercial (e.g., selling it, using it in a commercial service).
• Some open source software is sold or involves a commercial service, and there is no exception for that.
• The CRA is broad in scope compared to past regulations focused on specific kinds of products.
• Even if an organization is not domiciled in the EU, the CRA applies if they sell products in the EU.

5. Standards and Compliance:

• The European Commission and standardization bodies are looking to identify international standards for implementing controls and practices.
• Standards are technically optional, but manufacturers want confidence in following the law, so they often follow standards to be presumed conformant.
• The European standardization organization (ESO) is working on standards, and Etsy has made its CRA-related work public on Git.
• Paying for standards makes them inaccessible to most developers, hindering compliance.
• The community is advocating for openness in developing standards to make them accessible to developers.

6. Challenges and Opportunities:

• Challenges include closed environments for developing standards, standards that need to be paid for, imprecise guidelines, fragmentation of markets, and lack of consensus.
• Upstream maintainers are often disconnected from lawyers, laws, and security requirements.
• Commercial enterprises selling products globally face a patchwork of laws with different terms for the same idea.
• The OpenSSF is aligning OpenSSF tools to show how projects with a security policy give credit for different regulations and frameworks.

7. Security Baseline:

• The OpenSSF has a project called the Security Baseline, which is a set of 40 different controls broken up over three levels of maturity.
• Level one is designed to be achievable by a single maintainer project with a couple of hours of time.
• The Security Baseline is the lowest common denominator across different control frameworks and laws.
• It works in partnership with David's best practices badge, the security scorecard tool, Salsa, and openchain.

8. Strategies to Increase Awareness and Preparedness:

• Education is a key approach, with developers learning from doing things and from others.
• Tooling is encouraged to augment human brains.
• The OpenSSF uses various methods to get the word out, including sessions, podcasts, webinars, and encouraging members to present at events.
• The OpenSSF directly works with the European Commission, standards groups, and expert groups to provide feedback.

9. Aligning Incentives:

• The CRA mandates that if you develop an improvement to something you use, you have to supply it upstream.
• There are discussions about increasing financial investments in software projects.
• GitHub and the OpenSSF have been doing that for Alpha Omega.
• The OpenSSF is working with Alpha and Omega, GitHub, and the sovereign tech fund tech agency for years.
• Tools are being developed to automate tasks and produce required artifacts.
• Downstream should participate in projects, host infrastructure, or provide tooling and engineering resources.
• Funding expert developers to help uplift the whole community has been an effective tactic.

10. Future Trends:

• The CRA will influence manufacturers, and there will be panicked manufacturers trying to deal with things.
• AI is influencing everything, especially software development, but it should be used as an assistant, not a replacement for humans.
• Governments and authorities are understanding the importance of open source, leading to collaboration between public institutions, private companies, and open source maintainers.
• Open source security is now seen as a matter of national economic security.
• Legislators in China and India are looking at creating their own versions of the CRA.
• There is a need to harmonize requirements across different regions to avoid incompatible or confusing requirements.

11. Call to Action:

• All OpenSSF work is open to the public, and anyone can join.
• Participation can be done through Zoom calls, Git repositories, Slack channels, and mailing lists.
• The GitHub repository and website are good starting points to learn about the group's activities.
• Individuals are encouraged to show up to meetings, ask questions, and have their voices heard.
• The Slack channel is the best way to get immediate answers and responses from the community.
• Share lessons learned and contribute to the community.

Conclusion:

The OpenSSF Global Cyber Policy Working Group plays a crucial role in navigating the complex landscape of international cybersecurity regulations and their impact on open source software. By providing resources, education, and a platform for collaboration, the group aims to bridge the gap between policymakers, developers, and manufacturers, ensuring that open source remains secure and sustainable in an increasingly regulated world. The EU CRA serves as a key focus, but the group's efforts extend globally, addressing the challenges and opportunities presented by emerging regulations and technologies like AI. The call to action emphasizes the importance of community involvement and knowledge sharing to strengthen the open source ecosystem.