# OpenSSF BEST working group: a curated inventory of secure development practices > The Best Practices for OSS Developers working group is an OpenSSF Technical Advisory Committee group dedicated to raising awareness and education of secure code best practices for open source developers. What it actually produces is a prioritised, community-curated inventory of practices, plus a set of guides, trainings and sub-projects, and the repository itself is a governance record rather than a tool. **ossf/wg-best-practices-os-developers** — The Best Practices for OSS Developers working group is dedicated to raising awareness and education of secure code best practices for open source developers. - Repository: https://github.com/ossf/wg-best-practices-os-developers - Website: https://openssf.org - Stars: 1,087 · Forks: 211 - Language: JavaScript - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/ossf-wg-best-practices-os-developers ## A working group, not a tool you install The repository describes itself as the OpenSSF repository for the Best Practices for OSS Developers working group, and the primary language is recorded as JavaScript, which is misleading until you look at what is actually in the tree. The top level is documents. There is CHARTER.md, CONTRIBUTING.md, code-of-conduct.md, SECURITY.md, meeting-minutes.md, members.md, a minutes/ directory, a presentations/ directory, docs/, img/, and a LICENSES/ directory. The package.json exists to run a formatter over Markdown, and nothing more. That tells you the deliverable. This is a governance and content project, not a code project. The artefact is a body of written guidance, a community that maintains it, and a set of sub-projects that turn some of that guidance into tooling. The group is officially a Graduated-level working group within the OpenSSF Technical Advisory Committee, and anyone is welcome to join the open discussions related to the group's mission and charter. The audience is stated in the mission: to provide open source developers with security best practices recommendations and easy ways to learn and apply them. The stated aim is to fortify the open-source ecosystem by championing and embedding best security practices, so that both developers and users can trust open-source solutions without hesitation. The primary language field in the repository metadata is worth flagging, because a reader scanning a list of JavaScript projects would not expect to find a working group charter here. ## The inventory: prioritised by ROI, categorised by technology The concrete deliverable is an inventory, and the scope section says exactly what kind of inventory it is. The 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, and community-curated. Those four qualifiers are the design. Prioritisation by return on investment is what separates this from a checklist dump, because a maintainer with a weekend to spare needs to know which three changes matter most, not the full hundred. Categorisation per technology, language and framework is what makes it usable, since the right practice for a C project with memory safety concerns is not the same as the right practice for a JavaScript package. And community-curated is what makes it honest about being incomplete, since nobody can enumerate every practice for every stack. The inventory lives at docs/inventory.md in the repository, and the README links it directly. That link is the most useful single entry point for someone who wants the substance rather than the organisational context. The vision section adds a second dimension to the mission. The group wants a world where developers can easily identify good practices, requirements and tools that help them create and maintain secure software. It wants to provide means to learn techniques of writing and identifying secure software using methods best suited to learners of all types. And it wants to provide tools to help developers adopt these good practices into their daily work. Identify, learn, adopt. Those three verbs map onto the three things a practice recommendation can fail at, and they are a useful way to judge any security guidance you come across, including this. ## Working with a community of maintainers The repository shows a real working group at work rather than a set of finished documents, and the mechanics of that are visible. There is meeting-minutes.md at the root plus a minutes/ directory, and the README's table of active SIGs links each effort to its meeting notes, its Git repository, its Slack channel and its mailing list. The full working group meets every two weeks on Tuesday at 7:00a PT, and the Academic Connections SIG meets every two weeks on Wednesday, with Allstar on Thursday. The README includes a warning that matters for anyone planning to attend: the meeting times may change, so please check the public OpenSSF calendar for up-to-date information about all community meetings. The active initiatives table is the best view of the work in progress. The Full WG effort is described as Secure Software Development Best Practices. The Academic Connections SIG collaborates with the academic community to support education, in concert with the EDU.SIG. Allstar monitors GitHub repositories for adherence to security best practices. And the C/C++ Compiler Guides effort is a C/C++ compiler hardening best practices guide. That list is a map of where the group's attention is, and it is also a directory of the artifacts you would actually use. Allstar and the compiler hardening guides are concrete enough to act on, whereas the full working group line is a placeholder for the group as a whole. The repository is public, the charter is public, the meeting notes are public, and the membership is recorded in members.md. There is no membership process described in the README beyond the invitation to join the discussions, which is itself worth knowing before you plan to participate. ## The sub-projects are where the guidance becomes a tool The roadmap is long, and the second half of it names the things that would actually change a maintainer's workflow. The group intends to support and promote its sub-projects with contributions and feedback, and the list is specific: Scorecard, BP Badges, OpenSSF SkillFoundry, Classes, and Guides, plus the Secure Software Guiding Principles, known as SSGP. The relationship between these and the inventory is worth spelling out, because a newcomer often confuses them. The inventory says what a secure project should do. Scorecard is an automated way to check whether a project does those things, Badges is the signalling mechanism that lets a project show the result, and Allstar is the piece that watches repositories continuously. The Working Group is not a scanner; it is the group that decides what the scanners should check. That is why the roadmap includes identifying gaps in tools and resources that provide opportunities to promote and implement secure development practices. A gap in tooling is a gap in the guidance, and closing it means either writing the practice or building the tool. The roadmap also plans to embed all of the guides across OpenSSF Technical Initiatives and understand what makes sense to integrate into Scorecard, which is the reverse direction: taking the guidance and making the existing tooling aware of it. Two education-oriented items are worth calling out. The group plans express learning classes for its body of work, listing a working group explainer, an SCM Best Practices Guide, a C/C++ Guide, Scorecard and Badges material, and concise guides. And it plans a memory safety W3C-style workshop to assemble development leaders to talk about integrating memory safe languages and techniques more deeply into the ecosystem, which is a specific, dated-sounding kind of effort rather than a vague aspiration. ## Formatting the documentation is the only build step The package.json is the one piece of machinery in the repository, and it is worth reading because it tells you what the project considers a contribution to require. ```json { "name": "wg-best-practices-os-developers", "version": "1.0.0", "description": "OpenSSF Repository for the Best Practices for OSS Developers WG", "scripts": { "format": "npx prettier --write . && npx markdownlint --fix '**/*.md' --ignore node_modules" } } ``` There is exactly one script, and it runs Prettier over the tree and then markdownlint with the --fix flag over every Markdown file. The devDependencies are markdownlint-cli at 0.49.1 and prettier at 2.7.1. So the bar for a pull request is that the Markdown lints and the formatting matches Prettier's output, and the tooling does both automatically once the dependencies are installed. There is a .markdownlint.yml at the root configuring the rules, and a .prettierrc-style setup is not present, which means Prettier runs on its defaults for Markdown. The continuous integration badge is the GitHub Super-Linter, running on the Code Base workflow. Super-Linter is the OpenSSF's own GitHub Action that bundles a large set of linters into one job, and using it here rather than a bespoke workflow means the same linting applies across the whole OpenSSF organisation's repositories. There is also a .devcontainer/ directory, so the repository can be opened in a containerised development environment, which for a documentation project is mostly about having the right linter versions without polluting a local machine. For a contributor, the practical sequence is: install the two dev dependencies, run the format script, and open a pull request against main. The Super-Linter badge tells you whether it passed. ## A working group with a published charter A few structural details make this repository different from a documentation site, and they are the reason it is worth reading as a governance record rather than as a manual. CHARTER.md at the root is the group's formal mandate. The README links the OpenSSF working group lifecycle document, which is where the Graduated-level designation comes from, and graduation is a status that has to be earned and can be lost. That is the opposite of a side project that a single maintainer runs until they get bored. SECURITY.md exists alongside code-of-conduct.md, which is unusual for a repository that contains no running code. It means the reporting path for a security problem with the guidance itself, such as an inventory entry that would lead a maintainer to a bad decision, is defined before anyone needs it. The LICENSES/ directory is present, which is the REUSE-style convention for tracking licence information per file in a document collection where different artifacts may carry different terms. The repository's own licence is Apache-2.0, declared in package.json as well, and the LICENSES directory suggests the per-file exceptions are tracked properly rather than assumed uniform. The last push was on 2026-10-05, and the repository has no GitHub releases, which is consistent with a governance repository whose history is in commits and meeting minutes rather than in tagged artefacts. The version field in package.json reads 1.0.0 and is not tied to any release process. For someone deciding whether to invest time in this kind of group, that combination of a published charter, a public meeting cadence and a licence file per artefact is the signal that the output is meant to outlive any single maintainer's attention span. ## Conclusion The BEST working group suits an open source maintainer who wants a defensible answer to what secure development practice means for their project, since the inventory is prioritised by return on investment and categorised per technology rather than being a generic checklist, and the group is a graduated-level OpenSSF body with a published charter and public meetings. It is the wrong starting point if you want a tool that checks your repository, because that is what the Scorecard, Badges and Allstar sub-projects are for, and it is the wrong place to look for a single authoritative list, because the inventory is community-curated and by design incomplete. Before joining in, read CHARTER.md and CONTRIBUTING.md, and pick the SIG that matches your work, since the active initiatives and their meeting times are listed in the README and the meeting times may change. ## FAQ ### What is the OpenSSF Best Practices for OSS Developers working group? It is a Graduated-level working group within the OpenSSF Technical Advisory Committee, dedicated to raising awareness and education of secure code best practices for open source developers. Its mission is to provide security best practices recommendations and easy ways to learn and apply them. ### How is the best practices inventory organized? The inventory at docs/inventory.md is prioritized according to ROI for open source developers, categorized per technology, language and framework, and community-curated. ### How do I contribute documentation to the OpenSSF BEST working group? The repository expects Markdown that passes the GitHub Super-Linter. Install the dev dependencies, run the format script which applies Prettier and markdownlint --fix over all Markdown files, and open a pull request. CONTRIBUTING.md and CHARTER.md at the repository root describe the process. ### Which active initiatives does the OpenSSF BEST working group run? The README lists the Full WG, the Academic Connections SIG which works with the academic community on education, Allstar which monitors GitHub repositories for adherence to security best practices, and the C/C++ Compiler Guides effort for compiler hardening guidance. ### How do I join the OpenSSF BEST working group? Anyone is welcome to join the open discussions related to the group's mission and charter, and the README's table of active initiatives links the meeting notes, Git repository, Slack channel and mailing list for each effort. The README notes that meeting times may change, so check the public OpenSSF calendar. ## Sources - [Issues](https://github.com/ossf/wg-best-practices-os-developers/issues) - [License: Apache-2.0](https://github.com/ossf/wg-best-practices-os-developers/blob/main/LICENSE) - [ossf/wg-best-practices-os-developers on GitHub](https://github.com/ossf/wg-best-practices-os-developers) - [Project website](https://openssf.org) - [README](https://github.com/ossf/wg-best-practices-os-developers/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ossf-wg-best-practices-os-developers