By Ana JimĂ©nez SantamarĂa (TODO Group) and David A. Wheeler (Linux Foundation)
A well-designed Open Source Program Office (OSPO), when present, is the center of competency for an organization’s open source operations and structure. As described in the recent deep dive research report by TODO Group and the Linux Foundation AI & Data, OSPOs benefit organizations worldwide by:
- Implementing unique and flexible sets of tools that support OSS development models while meeting corporate Information Technology guidelines
- Overseeing the establishment or adaptation of internal policies to better manage open source software (OSS) compliance in fast-moving, dynamic environments
- Helping to bridge the cultural gap between traditional software development practices and the requirements of open source development
- Improving technical mentorship, and compliance-related education and training programming for team members across all levels of the organization
Enabling continuity in executive support, funding, software development practices, and OSS project prioritization
An OSPO’s role can include setting code use, distribution, selection, auditing, and other policies, as well as training developers, ensuring legal compliance, or promoting and building community engagement. This is important since modern software applications are either open source software (OSS) or mostly OSS. One of the first tasks OSPO leaders need to do to take care of a correct function for an organization’s open source efforts is to assist in securing open source technology and best practices.
OSPOs play an important role in establishing open source sustainability and security. The TODO Group has developed a list of ways we recommend OSPOs can begin to improve open source sustainability & security in your organizations.
Ways OSPOs Can Be a Key Lever for Open Source Sustainability & Security
- Focus on Education – have every developer from your firm using or contributing to OSS learn how to develop secure software, e.g., by taking the free Developing Secure Software education module.
- Use Multi-factor Authentication (MFA) on developer accounts– MFA makes it harder for attackers to take over developers’ accounts to make malicious changes (e.g., on GitHub).
- Use a combination of tools in your CI pipeline to detect vulnerabilities. See the OpenSSF guide to security tools. Tools shouldn’t be the only mechanism, but they scale. For example, Security Code Scanners (Static Application Security Testing (SAST) Tools) analyze source code and can report areas with likely vulnerabilities, while Software Component Analysis (SCA)/Dependency Analysis tools can warn you about known vulnerabilities in your dependencies.
- Adopt OpenSSF Best Practices Badge criteria when evaluating, contributing, and releasing projects as OSS.
- Measure OSS projects using the OpenSSF Scorecards.
- Sign contribution agreements – Require contributors from your organization to sign off on commits using DCO to increase confidence that code can be legally licensed and used in the open source project.
- Adopt sigstore – the new standard for signing, verifying and protecting software.
- Publish and consume a software bill of materials (SBOM). One such format is SPDX.
- Monitor and track the overall health of open source projects with project health tracking tools such as the Linux Foundation’s LFX and CHAOSS toolkit.
- Identify relevant guidance and share with developers – e.g., the OpenSSF concise guides for developing secure software and evaluating open source software.
- Create bi-directional communication between communities – Create and nurture bi-directional communication between communities. You can now leave your requests on OSPO Forum under the new OSPO wishlist category.
- Participate in community discussions – get involved in OpenSSF Working Groups and join us at our new OSPOlogy.live events.
Not only do we recommend taking this advice to heart, we also recommend OSPOs can leverage their strategic position in organizations to be the driving factor for turning these recommendations into policies that employees /stakeholders /teams should, or even must, follow. That can be a useful lever especially to “bring up the floor” in how an organization’s stakeholders engage in OSS which is especially important when an organization wants to make sure it’s not their employee whose mistake leads to the next log4shell incident.
Get Involved in New OSPOlogy.live Events
We are seeking content ideas and presenters for TODO Group’s new OSPOlogy.live in person workshops in Europe, along with the OpenChain, CHAOSS, SPDX, and OpenSSF communities. OPSOlogy.live initiative aims to bring together the various communities involved in OSPO-specific topics to help organizations effectively implement OSPO Programs based on specific region needs.
Topics will include:
- safely using open source to license compliance
- open source sustainability
- contributing back to the community
- securing OSS
Efforts are already on the way to organizing the OSPOlogy workshops in different European countries focused on the various OSPO responsibilities per quarter and we invite you to collaborate.
OSPOlogy.live Workshop Sweden
The first in-person Ospology.live workshop designed to help organizations effectively implement OSPOs based on specific region needs will be held in Stockholm on October 19 -20, hosted by OSPO at Ericsson and co-organized with TODO, OpenChain, SPDX, CHAOSS and OpenSSF projects. Registration for OSPOlogy.live Workshop Sweden is open now.