Best Practices for Open Source Developers

Anyone is welcome to join our open discussions related to the group's mission and charter. The BEST Working group is officially a Graduated-level working group within the OpenSSF

Mission

Our Mission is to provide open source developers with security best practices recommendations and easy ways to learn and apply them.

We seek to fortify the open-source ecosystem by championing and embedding best security practices, thereby creating a digital environment where both developers and users can trust and rely on open-source solutions without hesitation.

Vision

• We envision a world where software developers can easily IDENTIFY good practices, requirements and tools that help them create and maintain secure world-class software, helping foster a community where security knowledge is shared and amplified.
• We seek to provide means to LEARN techniques of writing and identifying secure software using methods best suited to learners of all types.
• We desire to provide tools to help developers ADOPT these good practices seamlessly into their daily work.

Scope

The Developer Best Practices group wants to help identify and curate an accessible inventory of best practices

• Prioritized according to ROI for open source developers
• Categorized per technology, language, framework
• Community-curated

Strategy

To achieve our Mission and Vision, the BEST Working group will execute on the following strategy:

• Collaborate with security experts to draft a comprehensive set of best practices tailored for open-source projects.
• Identify gaps in tools and resources that provide opportunities to promote and implement secure development practices.
• Evangelize and drive adoption of our artifacts (ex: guides, trainings, tools) through community outreach and targeted maintainer engagement.
• Collaborate with other OpenSSF and open source efforts to provide comprehensive guidance, advice, and tooling for software developers and open source software consumers to use, implement, and evaluate the security qualities of software.

Roadmap

To deliver on our Strategy, the BEST Working Group will do the following:

• Evangelize OpenSSF “best practices” and tooling through blogs, podcasts, conference presentations, and the like.
• Create express learning classes for our body of work: working group explainer, SCM BP Guide, C/C++ Guide, Scorecard/Badges, Concise Guides
• Create a “Best Practices Member Badge” for member organizations
• Support and promote our sub-projects with contributions and feedback - Scorecard, BP Badges, OpenSSF - SkillFoundry, Classes, and Guides, Secure Software Guiding Principles (SSGP)
• Create a Memory Safety W3C-style workshop to assemble development leaders to talk about how to integrate memory safe languages and techniques more deeply into the oss ecosystem.
• Expand BEAR (Belonging, Empowerment, Allyship, and Representation) WG Office Hours to more broadly engage new-to-oss individuals and provide a forum for mentorship and guidance as they launch into and grow within their careers.
• Identify, curate, produce, and deliver new secure development education such as Developer Manager Training, Implementing/Integrating OSSF tools (such as Scorecard, Badges, OSV, OpenVEX, etc), advanced secure development techniques, and more.
• Evangelize and embed all of our guides across OpenSSF Technical Initiatives and understand what makes sense to integrate into Scorecard

Current Work

Active SIGs and Initiatives

The table below lists the active initiatives and efforts of the Best Practices Working Group. The meeting times may change, so please check the public OpenSSF calendar for up-to-date information about all community meetings.

Work Items, Outputs, Deliverables

We develop our material on GitHub and publish a rendered version of our guides on https://best.openssf.org.

We currently use the Simplest Possible Process (SPP) for publishing. Please see the SPP documentation if you have questions about it.

Best Practices Guides

Longer reference documents on implementing specific secure techniques

• Compiler Annotations for C and C++ (incubating)
• Compiler Options Hardening Guide for C and C++
• Correctly Using Regular Expressions for Secure Input Validation
• Cyber Resilience Act (CRA) Brief Guide for Open Source Software (OSS) Developers
• Existing Guidelines for Developing and Distributing Secure Software
• npm Best Practices Guide
• Package Manager Best Practices (archived)
• Secure Coding Guide for Python
• Security Focused Guide for AI Code Assistant Instructions
• Simplifying Software Component Updates
• Source Code Management Platform Configuration Best Practices
• The Memory Safety Continuum

Concise Guides

Quick Guidance around Open Source Software Development Good Practices

• Concise Guide for Developing More Secure Software
• Concise Guide for Evaluating Open Source Software

Education Material and Training Courses

The Education SIG provides industry standard secure software development training materials that will educate learners of all levels and backgrounds on how to create, compose, deploy, and maintain software securely using best practices in cyber and application security.

• Developing Secure Software (LFD121)
  • The presentation "A Brief Introduction to Developing Secure Software" summarizes its content
• Security for Software Development Managers (LFD125). We thank Intel for contributing the starting material for this course.
  • The presentation from LFD125 is available if you want to propose changes or reuse it for special purposes (CC-BY-4.0)
• Understanding the EU Cyber Resilience Act (CRA) (LFEL1001). Developed with the OpenSSF Global Cyber Policy WG.
  • The presentation from LFEL1001 is available if you want to propose changes or reuse it for special purposes (CC-BY-4.0)
• Secure AI/ML-Driven Software Development (LFEL1012), to be released 2025-10-16. Developed with the OpenSSF AI/ML WG.
  • The presentation from LFEL1012 is available if you want to propose changes or reuse it for special purposes (CC-BY-4.0)

Related resources

• A Brief Introduction to Developing Secure Software (short presentation)

Past Work

• OpenSSF Security Baseline - spun out
  • Baseline is now a part of the ORBIT Working Group
• Interactive artwork - archived
  • A place where we want to guide developers in what stage they can use what type of tooling or approach. We have tons of great tools and materials but hard to find for devs, using this page and interactive loop we want to guide them to find the right stuff.
• Great MFA Distribution Project - completed
  • Distribute MFA tokens to OSS developers and best practices on how to easily use them
• Recommended compiler option flags for C/C++ programs - spun out
  • This early draft inspired the group's work on the C/C++ Compiler Hardening Guide.
• The Security Toolbelt - currently on hold
  • Assemble a “sterling” collection of capabilities (software frameworks, specifications, and human and automated processes) that work together to automatically list, scan, remediate, and secure the components flowing through the software supply chain that come together as software is written, built, deployed, consumed, and maintained. Each piece of the collection will represent an interoperable link in that supply chain, enabling adaptation and integration into the major upstream language toolchains, developer environments, and CI/CD systems.

Contributing

Contributions to all initiatives of the Working Group are highly welcome. Please see our Contribution Guide for more details.

Translations

We are delighted that some are willing to help us translate materials to other languages. Please ensure all pull requests that add or modify translations are labeled with its language. Such pull requests (PRs) must be first reviewed and approved by a trusted translator.

See translations for specific details.

Meeting Notes

We take notes for each meeting. Please see Meeting Notes for links to the documents.

Governance

Charter

The CHARTER.md outlines the scope and governance of our group activities. Like all OpenSSF working groups, this working group reports to the OpenSSF Technical Advisory Council (TAC). For more organizational information, see the OpenSSF Charter.

Project Leads

• Co-chair - Avishay Balter, Microsoft
• Co-chair - Georg Kunz, Ericsson
• "*" denotes a project/SIG lead

Project Maintainers

• Christopher "CRob" Robinson*, OpenSSF
• David A Wheeler, LF/OSSF
• Dave Russo*, Red Hat
• Georg Kunz, Ericsson
• Avishay Balter, Microsoft

Project Collaborators

• Christine Abernathy*, F5
• Daniel Applequist*, Snyk
• Marta Rybczynska, Syslinbit
• Thomas Nyman*, Ericsson
• Yotam Perkal, Rezilion
• Chris de Almeida, IBM

Project Contributors

• Arnaud J Le Hors, IBM
• Jeffrey Borek, IBM
• Ixchel Ruiz, jfrog
• Laurent Simon*, Google/Scorecard
• Matt Rutkowski, IBM
• Riccardo ten Cate, SKF
• Spyros Gasteratos*, OWASP/CRE
• Glenn ten Cate*, OWASP/SKF
• Jay White, Microsoft
• Jonathan Leitschuh*, Dan Kaminsky Fellowship @ Human Security
• Judy Kelly, Red Hat
• Roberth Strand, Amesto Fortytwo / Cloud Native Norway
• Sal Kimmich, EscherCloud
• Helge Wehder, Ericsson
• Noam Dotan, Legit Security
• Eddie Knight, Sonatype
• Randall T. Vasquez*, The Linux Foundation

A listing of our current and past group members.

Licenses

Unless otherwise specifically noted, software released by this working group is released under the Apache 2.0 license, and documentation is released under the CC-BY-4.0 license. Formal specifications would be licensed under the Community Specification License (though at this time we don't have any examples of that).

Antitrust Policy Notice

Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.