This project identifies best practices for open source software (OSS) and implements a badging system for those best practices. The "BadgeApp" badging system is a simple web application that lets OSS projects self-certify that they meet the criteria and show a badge. The real goal of this project is to encourage OSS projects to apply best practices, and to help users determine which OSS projects do so. We believe that OSS projects that implement best practices are more likely to produce better software, including more secure software.

This is an early version of this material; we are releasing it so we can get feedback. Feedback is welcome via the GitHub site as issues or pull requests. There is also a mailing list for general discussion.

• Draft Badging Criteria
• Information on how to contribute
• Draft Background on Badging
• ChangeLog
• Current implementation - notes about the BadgeApp implementation
• security - notes about BadgeApp security
• Current Burndown and Kanban Board of this project.

This is a summary of the criteria, with requirements in bold (for details, see the full list of criteria):

• Have a stable website, accessible over HTTPS, which says:
  • what it does
  • how to get it
  • how to give feedback
  • how to contribute and preferred styles
• Explicitly specify an OSS license
• Document how to install and run (securely), and any API
• Have a distributed public version control system, including changes between releases:
  • Give each release a unique version, using semantic versioning format
  • Give a summarizy of changes for each release, identifying any fixed vulnerabilities
• Allow bug reports to be submitted, archived and tracked:
  • Acknowledge/respond to bugs & enhancement requests, rather than ignoring them
  • Have a secure, documented process for reporting vulnerabilities
  • Respond within 7 days (on average), and fix vulnerabilities, within 60 days if they're public
• Have a build that works, using standard open-source tools
  • Enable (and fix) compiler warnings and lint-like checks
  • Run other static analysis tools and fix exploitable problems
• Have an automated test suite that covers most of the code/functionality, and officially require new tests for new code
• Automate running the tests on all changes, and apply dynamic checks:
  • Run memory/behaviour analysis tools (sanitizers/Valgrind etc.)
  • Run a fuzzer or web-scanner over the code
• Have a developer who understands secure software and common vulnerability errors
• If cryptography is used:
  • Use public protocols/algorithm
  • Don't re-implement standard functionality
  • Use open-source cryptography
  • Use key lengths that will stay secure
  • Don't use known-broken or known-weak algorithms
  • Use algorithms with forward secrecy
  • Support multiple algorithms, and allow switching between them
  • Store any passwords with iterated, salted, hashes using a key-stretching algorithm
  • Use cryptographic random number sources

All material is released under the MIT license. All material that is not executable, including all text when not executed, is also released under the Creative Commons Attribution 3.0 International (CC BY 3.0) license or later. In SPDX terms, everything here is licensed under MIT; if it's not executable, including the text when extracted from code, it's "(MIT OR CC-BY-3.0+)".