I just found and read through the criteria list. It's mind-bogglingly exhaustive, but in a very good way, and an excellent catalyst for maintainable, secure software.

I'd regard it as universally applicable to any and all code.

This list gets you in the door: https://github.com/coreinfrastructure/best-practices-badge/b...

And this is the list that gets you a gold star rating: https://github.com/coreinfrastructure/best-practices-badge/b...

Prepare to have your eyes glaze over.

---

I had a go at summarizing the criteria. This is not an accurate reduction of the essence of the two lists; it comes close (I have no reason to misrepresent the criteria), but I've paraphrased here and there where I think it was editorially safe to do so (including slightly rearranging/renaming the major headings a little and swapping the ordering of points).

The 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