Skip to content

Latest commit

 

History

History
246 lines (179 loc) · 20.8 KB

README.md

File metadata and controls

246 lines (179 loc) · 20.8 KB
Raw

Best Practices for Open Source Developers

GitHub Super-Linter

Anyone is welcome to join our open discussions related to the group's mission and charter.

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 a “Secure from the (open) source” expert podcast to showcase the work across the foundation. -- As new guides/best practices are launched, we will create blogs and a conference presentation to raise awareness about it. -- Amplify talks and artifacts created by other groups within the foundation -- Create 3 EvilTux artifacts each quarter
  • 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 DEI AMA 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.
  • Evangelisze and embed all of our guides across OpenSSF Technical Inititatives and understand what makes sense to integrate into Scorecard

Help build a community

  • Program to attract open source contributors and incentivize them to use and contribute to the inventory

Supply a Learning platform -Any free course can be integrated into the platform

  • The learner can follow a track, track their progress and get badges
  • A suite of exercises are available for each best practice of the inventory

Current Work

We welcome contributions, suggestions and updates to our projects. To contribute please fill in an issue or create a pull request.

We typically use the Simplest Possible Process (SPP) to publish and maintain the documents we publish; see the SPP documentation if you have questions about it.

Our work is organized into several discrete-yet-related projects that help us achieve our goals:

Effort Description Git Repo Slack Channel Mailing List
Best Practices Guides Longer reference documents on implementing specific secure techniques - Compiler Options Hardening Guide for C and C++ (incubating),

- Existing Guidelines for Developing and Distributing Secure Software,

- Package Manager Best Practices (incubating),

- npm Best Practices Guide,

- Source Code Management Platform Configuration Best Practices		 SCM Slack
Concise Guides SIGs Quick Guidance around Open Source Software Develpment Good Practices - Concise Guide for Developing More Secure Software,

- Concise Guide for Evaluating Open Source Software		 Mailing List
Education SIG - (incubating) To provide 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. EDU.SIG stream-01-security-education Mailing List
OpenSSF Best Practices Badge - formerly CII Best Practices badge Identifies FLOSS best practices & implements a badging system for those practices,
OpenSSF Scorecard Project Automate analysis and trust decisions on the security posture of open source projects Scorecard Repo security_scorecards
Secure Software Development Fundamentals - online course Teach software developers fundamentals of developing secure software GitHub
Memory Safety SIG The Memory Safety SIG is a group working within the OpenSSF's Best Practices Working Group formed to advance and deliver upon The OpenSSF's Mobilization Plan - Stream 4. Git Repo Slack Mailing List
The Security Toolbelt 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. Security Toolbelt security-toolbelt Mailing List
SKF - Security Knowledge Framework Learn to integrate security by design in your web application

Past Work/Greatest Hits

Related Activities

There are many great projects both within and outside the Foundation that compliment and intersect our work here. Some other great projects/resources to explore:

  • SLSA Supply-chain Levels for Software Artifacts - https://github.com/slsa-framework/slsa
    • Purpose - A security framework from source to service, giving anyone working with software a common language for increasing levels of software security and supply chain integrity

Quick Start

Areas that need contributions

  • Any topics related to helping developers more easily make more secure software or consumers to better understand the security qualities of the software they wish to ingest

Where to file issues

  • Issues can be reviewed and filed here

Get Involved

Anyone is welcome to join our open discussions related to the group's mission and charter.

Meeting Times

Every 2 weeks, Tuesday 10am EST. The meeting invite is available on the public OSSF calendar

Effort Meeting Times Meeting Notes/Agenda Git Repo Slack Channel Mailing List
Full WG Every 2nd Tuesday 7:00a PT/10:00a ET/1400 UTC Meeting Notes Git Repo Slack Mailing List
Concise Guides - C/C++ Compiler Hardening Options Occurs every 2nd Wednesday 6:00a PT/9:00a ET/1400 UTC Meeting Notes Git Repo Slack Mailing List
Concise Guides - Source Code Management Best Practices Occurs every 2nd Thursday 7:00a PT/10:00a ET/1400 UTC Meeting Notes Git Repo Slack Mailing List
EDU.SIG Occurs every 2nd Wednesday 6:00a PT/9:00a ET/1400 UTC Meeting Notes Git Repo Slack Mailing List
EDU.SIG - DEI Subcommittee Occurs every 2nd Tuesday 8:00a PT/11:00a ET/1600 UTC Meeting Notes Git Repo Slack Mailing List
Memory Safety SIG Every 2nd Thursday 10:00a PT/1:00p ET/1500 UTC Meeting Notes Git Repo Slack Mailing List
Scorecard Occurs every 2nd Thursday 1:00p PT/4:00p ET/1800 UTC Meeting Notes Git Repo Slack Mailing List
Security Knowledge Framework - SKF TBD Meeting Notes Git Repo Slack Mailing List
The Security Toolbelt Every Tuesday Noon/12pm ET Meeting Notes Git Repo Slack Mailing List

Meeting Notes

Meeting notes are maintained in a Google Doc found in the above table. If attending please add your name, and if a returning attendee, please change the color of your name from gray to black.

Governance

The CHARTER.md outlines the scope and governance of our group activities.

Project Maintainers

Project Collaborators

Project Contributors

Toolbelt Collaborators

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).

Charter

Like all OpenSSF working groups, this working group reports to the OpenSSF Technical Advisory Council (TAC). For more organizational information, see the OpenSSF Charter.

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.