best-practices-badge

following is NOT a substitute for reading the criteria. I wrote this to give a good idea of why you'd want to take the time to click the above links. >> The following is the criteria to get a _minimally_ passing score. << Website(s) - <Must> succinctly describe the project with a minimum of domain-specific language or siloed knowledge - <Must> explain how to obtain, provide feedback and contribute - <Must> use HTTPS+TLS Project - <Must> use an OSS license (OSI, FSF, or liked by Debian or Fedora); <may> be dual-commercially-licensed - <Must> provide basic documentation in 99% of circumstances - <Must> use a URL-addressable, searchable discussion system for unilateral participation (IRC or mailinglists with URL-accessible logging is acceptable) - <Should> use English Source version control - URL-addressable version control <must> be used - System <must> track who changed what, and when - <Must> list all interim releases, for accountability - Unique version numbers <must> be used for all user-facing releases; commit IDs are listed as acceptable version "numbers", as is use of SemVer, and use of other version representations - Release notes <must> accompany all releases Bug reporting - Project <must> provide bug reporting process; use of an issue tracker is recommended - Project <must> at least respond to (if not fix) issues after 2-12 months, and <should> acknowledge more than half of submitted enhancement requests in the same timeframe Vulnerability reporting - Project <must> provide a vulnerability reporting mechanism; HTTPS or email (possibly with PGP) are suggested - All reports submitted within the last 6 months <must> be responded to within 14 days Building - IF project must be built in order to function, automatic rebuild mechanism must be provided - Automated OSS test suite <must> be used - Tests for new functionality <must> be added to automated test suite Code warnings - Project <must> use compiler warnings, language strict/safe modes, or linting tools Security - Project <must> be built by at least one developer who knows how to design secure software (the 8 principles from Saltzer and Schroeder are noted) - At least one developer <must> have domain knowledge of common vulnerability-introducing errors relevant to the software, and how to mitigate against them - Project <must> use established and reviewed security algorithms/protocols - Project <must> use keylengths that meet minimum NIST requirements through 2030 (certain keylengths are noted) - Project <must not> use known-broken crypto - Security mechanisms <should> use perfect forward secrecy - Stored passwords <must> be iterated/key-stretched hashes with per-$user salt - Keys and nonces must come from a cryptographically secure RNG - Project delivery mechanism <must> be MITM-resilient (HTTPS and SSH+SCP are listed as acceptable) - Checksums <must not> be delivered over HTTP - Medium- to high-severity vulnerabilities <must> be fixed if they are public knowledge for more than 60 days - Project <must not> leak security credentials (sample credentials are exempted) Code analysis - Project <must> use a static code analyser, if one exists for the given project language(s) and is OSS; it is <suggested> that the tool be configured/used to look for vulnerabilities, if possible; it is also <suggested> that code analysis be rerun every commit or at least daily - Project <must> fix medium/high severity (CVSS 2.0 or higher) exploitable issues found by static analysis in a timely manner - The use of a dynamic code analyzer to major production releases is <suggested>, if an OSS tool exists for the project language(s) - If the software is written in C/C++ or another memory-unsafe language, it is <suggested> that a dynamic analyser (fuzzer, web application scanner) be used to look for things like buffer overflows/overwrites - It is <suggested> that the project make heavy use of run-time assertions that are checked by dynamic analysis tools