BadgeApp

It uses git, URL is https://github.com/linuxfoundation/cii-best-practices-badge

Uses git to track this. Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Interim versions are put on git, not just final versions.

Uses git. Repository on GitHub, which uses git. git is distributed.

The primary single user uses git commit records to identify releases.

Full releases are tagged using 'git tag'.

CHANGELOG file is in top directory, see: https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/CHANGELOG.md

We intend to do that, though we don't know of any for-certain publicly known vulnerabilities.

Our release notes do document that commit fdb83380 on 2015-11-26 updated gem nokogiri from 1.6.6.2 to 1.6.6.4 due to CVE-2015-1819. It's not clear if our application was actually vulnerable; it was easier to simply upgrade. In any case, we upgraded immediately, and this is documented in our release notes.

Yes, either GitHub issue tracker or mailing list. See: https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/README.md

Yes, GitHub issue tracker.

Yes. Not many have been submitted so far, but we've responded.

The project has been responding to most enhancement requests.

Yes, via GitHub isue tracker: https://github.com/linuxfoundation/cii-best-practices-badge/issues

https://github.com/linuxfoundation/cii-best-practices-badge/issues

https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/CONTRIBUTING.md

No external reports so far, so this is vacuously true.

The software is written using Ruby and Javascript, and their implementations run directly on the source code.

Note that a Gemfile.lock file and Rake tasks are provided to enable others to quickly recreate a development environment.

Yes, it includes a test suite based on minitest (the test framework that comes with Rails).

Yes. "rake test" invokes the automated test suite. The default "rake" command includes "rake test". This is documented in CONTRIBUTING.md.

Met. Currently coverage of the ruby code is over 90%, and most of the code is in Ruby.

Code is frequently integrated back into GitHub; CircleCI and several other tools are then run on the result to determine if there's a problem. If a problem is found, the tools provide feedback via GitHub. For more information, see the BadgeApp's status on CircleCI.

Yes. The CONTRIBUTING file at https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/CONTRIBUTING.md says, "When adding or changing functionality, please include new tests for them as part of your contribution". Also, the project home page shows the test coverage, which encourages adding tests as new functionality is added.

Tests are added as new functionality is added.

Yes. The CONTRIBUTING file at https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/CONTRIBUTING.md says, "When adding or changing functionality, please include new tests for them as part of your contribution".

The set of tools used for examining code quality are listed in CONTRIBUTING.md.

The project uses rubocop and rails_best_practices to check for code quality errors in Ruby code; eslint is used to look for problems in Javascript. The markdown documentation is scanned with markdownlink.

In general warnings are addressed. In some cases warnings are disabled for specific cases.

The settings for the warning tools are generally fairly strict.

David A. Wheeler, lead developer, literally wrote the code on how to design secure software: http://www.dwheeler.com/secure-programs

For a discussion of security requirements, common types of security vulnerabilities, and how this application counters those common kinds of vulnerabilities, see: https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/security.md

The software uses bcrypt to store salted hashed iterated passwords, and https+standard crypto protocols to communicate with users.

Uses 'bcrypt' gem for bcrypt, and https implementation built into its web server.

All required functionality is implemented using FLOSS, including cryptography.

Note: This application uses bcrypt, which uses 128-bit salt and produces 184 bits as a salted encrypted iterated hash. This is less than 224 bits, but that's not really what the 224 bits of hash are for. This probably needs clarification in the criteria; see https://github.com/linuxfoundation/cii-best-practices-badge/issues/153

The only cryptographic algorithm directly used by the program is bcrypt, which is not broken.

The only cryptography used directly by this application is bcrypt (used for storing passwords as salted iterated hashes). At the time of this writing, no serious breaks are known in bcrypt. The application also depends on the web server's https configuration, but that is out of scope for this code.

Nothing in the code inhibits or prevents the use of PFS; that is a property of the website's web server.

Bcrypt used for storing local passwords.

The nonce for the salt is created by the bcrypt gem; its engine.rb file shows that it uses OpenSSL to get cryptographically random data for the salt (on Java it would use SecureRandom, which is still fine, but that is not the default configuration). Other nonces are part of the https implementation, which are implemented by the web server (not this application).

Uses https.

Does not make this mistake.

No such vulnerabilities at this time.

No such vulnerabilities at this time.

No valid private credentials are leaked. There is a .env file, but it only includes stub data for testing, not the live credentials.

As noted in https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/CONTRIBUTING.md, Brakeman, Rubocop, and rails_best_practices are used to analyze the Ruby code. Brakeman is specifically designed to analyze Ruby on Rails code. The Javascript client-side code is analyzed with ESLint, using over 100 rules.

These analysis tools are used as part of the default 'rake' process used in local development, as well as the "pronto" process run on the continuous integration server running on CircleCI.

Brakeman specifically looks for common vulnerabilities in Ruby on Rails applications.

This is vacuously true, since we've had no reports of vulnerabilities that apply to a deployed system.

All commits to GitHub are run through CircleCI, which performs a number of static analysis checks (Brakeman, Rubocop, etc.).

Analyzed with OWASP ZAP by Emily Ratliff

Application written using Ruby and Javascript, not C/C++

A few minor issues were found by OWASP ZAP during development; these have already been fixed.