On March 5th, the SBOMit community hosted the Beyond the SBOM: Ensuring Integrity with Attestations event at The National Press Club in Washington, D.C. This event, co-located with OpenSSF Policy…
Read More
The OpenSSF Policy Summit DC 2025 brought together open source, government, and industry leaders to tackle pressing security challenges. The event fostered open dialogue under the Chatham House Rule, emphasizing shared responsibility and commitment to strengthening the open source ecosystem.
A Message from Steve Fernandez, OpenSSF General Manager,
“The OpenSSF is committed to tackling the most pressing security challenges facing the consumption of open source software in critical infrastructure and beyond. Our recent Policy Summit highlighted the shared responsibility, common goals, and commitment to strengthening the resilience of the open source ecosystem by bringing together the open source community, government, and industry leaders.” – Steve Fernandez, General Manager, OpenSSF
Keynotes & Panels
The summit opened with remarks from OpenSSF General Manager Steve Fernandez emphasizing the importance of collaboration between industry, government, and the broader open source community to tackle security challenges. Jim Zemlin, Executive Director of The Linux Foundation, delivered a keynote on the importance of securing open source in modern infrastructure, followed by Robin Bender Ginn of the OpenJS Foundation, who provided insights into systemic security challenges. Panels covered key topics such as integrating security into the software lifecycle, regulatory harmonization, AI security risks, and the adoption of open source in government.
Breakout Sessions
The policy summit included various breakout sessions; below are some key takeaways from each.
AI & Open Source Security
AI security is at a crossroads, with many of the same supply chain risks seen in traditional software. Unlike past security crises, AI has not yet had its “Heartbleed moment”, making this the time to proactively address risks.
Discussion Highlights
AI presents both new challenges and an urgent need to reinforce existing security efforts led by OpenSSF and The Linux Foundation. If the origins of AI models are unclear, how can we truly trust them? Understanding and measuring the risks associated with AI is critical, especially as AI frameworks and libraries integrate with other tools, potentially introducing new vulnerabilities. Yet, security in this space is often left as an afterthought—an exercise for the user rather than a built-in safeguard. As AI intersects with open source software, traditional cybersecurity risks remain relevant, raising key questions: What are the existing guardrails, and how can we strengthen them to ensure a more secure AI ecosystem?
Key Takeaways
- AI is software, and software security principles still apply – a fact that many AI practitioners may not yet fully understand.
- There is a need for new OpenSSF personas: AI Scientist and Data Engineer.
- There is a need for basic software security education tailored to AI practitioners.
Open Source Best Practices
The conversation centered on improving how open source components are updated, ensuring clear maintenance statuses, and reducing dependencies on U.S.centric platforms.
Discussion Highlights
Improving component updates is a critical challenge, especially when backward-incompatible changes prevent seamless upgrades. The industry needs clear guidance on enabling and streamlining updates, ensuring that software remains secure without unnecessary friction. Best practices for downstream consumers should be more widely established—such as evaluating whether a project is actively maintained before adopting it and identifying major backward-incompatible API changes as potential risks.
A structured approach to declaring an open source project’s maintenance or production status is also essential. There should be a formal, machine-ready way to indicate when a project is no longer maintained, making it easy to see and act upon. Additionally, as organizations strive to avoid being U.S.centric, requirements should be designed to be platform-agnostic rather than tied to specific tools.
Transparency is another key consideration. There needs to be a way to self-attest disagreements in security scans—allowing individuals to provide justification with supporting URLs when a requirement is met or missed. While knowing who maintainers are can be useful, it should not be the sole security measure.
Finally, ensuring that executables match their claimed source code is fundamental to software integrity. Protecting the build process through frameworks like SLSA and enabling verified reproducible builds can help mitigate risks, preventing attacks like those seen with xz utils.
Key Takeaways
- There’s still a lot to do (and opportunities) for identifying & encouraging best practices in OSS to improve security.
- This list is being shared with the OpenSSF Best Practices Working Group to determine which of these would be a fruitful item to work on this year.
Regulatory Harmonization
As open source software faces increasing regulatory scrutiny, the need for cross-compliance agreements and clear policies has become a priority.
Discussion Highlights
There are many open questions surrounding the EU’s Cyber Resilience Act (CRA)s definition of an open source steward. Clarity on what qualifies as stewardship is essential, as it impacts compliance responsibilities and obligations under the regulation.
A key concern for organizations navigating the CRA is the lack of a Mutual Recognition Agreement (MRA)—a framework that would allow compliance with one regulation to satisfy the requirements of another. Without this reciprocity, manufacturers must meet CRA standards separately to sell in Europe, adding complexity for global companies. Many U.S.based organizations are now grappling with whether and how to align these requirements domestically to avoid maintaining multiple sets of policies.
One proposal to strengthen open source sustainability is requiring government contracts to include provisions mandating that any changes to open source software made as part of the contract be contributed upstream. This would ensure that improvements benefit the broader ecosystem rather than remaining siloed.
Another growing concern is the financial sustainability of open source projects. Large organizations often look to cut costs, and open source funding is frequently among the first areas to be reduced. Regulation could help prevent this by recognizing the critical role open source plays in security and innovation.
Finally, organizations need better ways to quantify the impact of their open source contributions across distributed teams and departments. Some efforts are underway to address this challenge, but it remains difficult to track how contributions tie back to business value. While The Linux Foundation’s LFX provides some insight, similar visibility is lacking across other foundations, leaving a gap in industry-wide solutions.
Key Takeaways
- The group wants to educate policymakers on how their regulations impact open source communities and industry.
- The group suggested crafting a one-pager which describes, at a policy-maker (high) level, how open source fits into security and its importance. It should also explain how regulations impact open source and how regulation and policy can be designed to help support open source while still accomplishing security goals.
- There was a lot of positive sentiment around encouraging policy makers to require contribution of changes and ongoing support for open source that is modified as part of software delivered in government contracts.
Repository & Package Supply Chain Security
Discussions focused on improving how package repositories handle security and lifecycle management.
Discussion Highlights
The group explored how to effectively track when open source projects reach end-of-life or end-of-support, recognizing the need for clearer visibility into project status. One proposal discussed was the Global Cyber Policy Working Group’s idea to introduce a “steward.md” file, which would explicitly indicate whether a project is maintained by an OSS Steward. A key question raised was how package repositories should track and surface Steward information. Ensuring that repositories can reliably display this data would help users make informed decisions about software adoption and maintenance. Security was another focus of discussion, particularly the importance of isolating components of the build pipeline to minimize attack surfaces. One suggestion was to remove pre-install scripts, which can introduce vulnerabilities if not properly managed. Finally, the group considered next steps for the Principles of Package Repository Security document. Identifying priority areas for improvement will be crucial in strengthening repository security and ensuring alignment with broader security best practices.
Key Takeaways
- How can we better communicate to consumers the lifecycle risk associated with a package?
- PyPI supports archiving projects for when the whole project is no longer active; should we publish guidance to make this more common across ecosystems?
- Specifying a per-package-version lifecycle isn’t really supported (e.g. “the last N releases will get security fixes backported”), although the Securing Repos Working Group is working on package yanking guidance.
- Should package repositories actively stop people from using known-vulnerable, very out-of-date packages? This could be a slippery slope; today repositories stay away from “curation.”
- Package repositories could serve vulnerability information alongside packages (some already do).
Looking Ahead
The Policy Summit reinforced OpenSSF’s commitment to improving open source security through collaboration and actionable insights. We encourage the community to stay engaged and contribute to ongoing efforts in these key areas.
