Blog

3 Key Takeaways on Open Source Security and Compliance from All Things Open

All Things Open is an annual technology conference focusing on the tools, processes, technology, and people making open source software. At this year’s conference, I had the opportunity to join an amazing technology panel on open source compliance and security.

Author: Brian Dussault
/
5 mins read
/
Oct 23, 2023

All Things Open is an annual technology conference focusing on the tools, processes, technology, and people making open source software. At this year’s conference in Raleigh, North Carolina, I had the opportunity to join an amazing technology panel on open source compliance and security. My fellow panelists included: 

  • Aeva Black, Open Source Security Lead at Cybersecurity and Infrastructure Security Agency (CISA) and an Open Source Initiative board member

  • Madison Oliver, Senior Manager, Advisory Database Curation at GitHub

  • Alex Beaver, InfoSec Engineer at Paramount, studying computing security at RIT 

Since the 2021 Executive Order, supply chain security has been a hot topic—and that was true at All Things Open as well. This panel focused on three key areas: the open source ecosystem's roles and responsibilities for supply chain security, Software Bill of Material (SBOM) adoption, and international regulations. Below, I’m sharing my key takeaways from the panel discussion. 

1. Open source communities have important roles to play—and increasingly, more tools at hand—to keep software safe.

There was general consensus that everyone involved in open source software (for-profit and non-profit)  has an important role to play in securing the software supply chain. Open source project maintainers need to ensure package integrity and authenticity for consumers so they can ensure the package hasn’t been tampered with. This process involves mechanisms such as the cryptographic signing of packages and providing a means for consumers to verify signatures. 

OpenSSF Foundation’s Sigstore project provides the critical infrastructure to ensure that developers can trust open source software. The adoption of Sigstore by language and package ecosystems such as npm, Python, and Java is accelerating; while there is more work to do around tooling, the future looks bright (and more secure).

In addition, open source project maintainers should continue to provide responsible disclosure and rapid response to security vulnerabilities. Vigilance around keeping third-party dependencies up-to-date and ensuring those projects are healthy will also improve a project’s security posture. The panel called out some good work that the CHAOSS organization is doing to establish OSS project health metrics; this is a good resource for folks trying to reason about a project’s vitality.

2. SBOMs are helpful—if you know what to do with them. 

The panel acknowledged that the need for an “ingredients label” for software packages will improve transparency, which is always a good thing. The bigger question the panel wrestled with was what to do with a Software Bill of Materials (SBOM) once you have it. For example, how do you exchange SBOMs across a myriad of different groups and organizations (e.g. procurement, security teams, government, etc.). Other challenges include how to handle SBOMs when software is packaged and repackaged as it moves across the supply chain. CISA has established a number of working groups that are collaborating to answer these questions and provide guidance. 

3. We need more dialogue and engagement on recent international supply chain regulations, to better support open source communities. 

The panel spent time discussing recent regulations and executive orders related to securing the software supply chain. Top of mind for many open source practitioners was the draft of European Union's Cyber Resilience Act (CRA). At the heart of the CRA controversy is that while the intention of the act is to enhance cybersecurity, the current draft lacks clear liability exemptions for many open source developers and project maintainers. In addition, it has the potential to put a significant burden on smaller OSS projects that aren’t backed by foundations or for-profit companies. 

In the extreme case, the act could fragment the OSS ecosystem, where some project maintainers might be forced to prevent their software from being used in areas governed by the CRA. A number of software foundations such as Linux, Eclipse, and Apache Foundation (just to name a few) have published open letters to help reshape the CRA so that it can achieve its security goals while helping open source communities grow. 

The imposition of regulations might discourage open source developers from releasing new software or updating existing ones, given the heightened compliance burden. Consequently, such constraints could potentially impede the pace of innovation within the open-source communities. It’s critical that regulators, corporations, foundations, and open source developers continue to drive a shared understanding of these trade-offs and risks. We need to keep the dialogue open and encourage active participation!

Summary 

The conference showcased an impressive lineup of over 200 sessions, 200 speakers, and welcomed a staggering 4,300 registered attendees from 41 states and 32 countries. Although this marked my inaugural participation at All Things Open's 11th conference, I am already excited about next year's event! The longevity and size of this event is a testament to the excitement around open source software and the critical role that it plays in the software supply chain.

Photo source: All Things Open