BadgeApp

Normally only a single version of the product is in production use. That said, it's important to handle upgrades, especially so that various developers can upgrade. How to upgrade is documented in CONTRIBUTING.md.

Here is a summary of common cases: * Upgrading often involves a database migration, which is handled by running "rake db:migration" (if the user forgets to do this, it is detected, running stops, and this information is presented). * Other upgrades generally involve installing updated gems (libraries), which are handled with "bundle update". * In rare cases an update to the Ruby language is needed; the steps to do this are also in CONTRIBUTING.md.

Yes, GitHub issue tracker.

We've never had an external bug reporter.

CONTRIBUTING.md notes that:

We will gladly give credit to anyone who reports a vulnerability so that we can fix it. If you want to remain anonymous or pseudonymous instead, please let us know that; we will gladly respect your wishes.

This is emphasized in the vulnerability report handling process docs/security.md, where the last step is giving credit.

The vulnerability report handling process is documented in docs/security.md.

CONTRIBUTING.md documents our coding style guides.

As documented there: * For Ruby on Rails, we generally follow the community Ruby style guide and the complementary community Rails style guide. * For JavaScript, our coding style is based on the Node.js style guide.

CONTRIBUTING.md documents our coding style enforcement mechanisms.

As documented there: * For Ruby on Rails, we use rubocop and rails_best_practices for style enforcement (as well as Brakeman to find vulnerabilities) * For JavaScript, we ESLint.

The application does not create native binaries. (Some of the libraries it depends on do, but those are external.)

The application does not create native binaries. (Some of the libraries it depends on do, but those are external.)

The application does not create native binaries. (Some of the libraries it depends on do, but those are external.)

The application does not create native binaries. (Some of the libraries it depends on do, but those are external.) It is written in scripting languages where the source code is used directly.

We include an install script, install_badge_dev_env which allows devs to quickly install the software for development. This script uses calls to various package managers to install all necessary dependencies quickly and easily. The uninstall process is documented in docs/INSTALL.md.

There is no installation system for build artifacts, as it's written using scripts.

It could be said that Rails builds web application assets (e.g., minified and concatenated JavaScript, and combined CSS); under that interpretation, they are written by the Rails framework as part of the execution of the Rails asset pipeline, and this is controlled in the usual way by controlling the framework.

The software is installed using standard conventions for this kind of software. The underlying Ruby libraries are installed using bundler (the usual Ruby package manager). Lower-level system components are normally installed using the system package manager.

It's possible to install these quickly, using a provided installation shell script that determines which system package manager to use & tries to automatically install whatever is needed, including the tests and test environment. The instructions for quickly installing everything is in INSTALL.md.

External dependencies are stored in a Gemfile.

External dependency checking is performed in two ways:

• bundle_audit. This checks all gems for known vulnerabilities. This is run on every execution of the "rake" local check task and on every run of the continuous integration task on CircleCI.
• Gemnasium. This also checks gems for known vulnerabilities, and puts the current status on a badge that is displayed on the front page of the project home page.

For the few external dependencies that aren't managed as gems (e.g., PostgreSQL) the system package managers and/or the deployment system's managers are used to maintain them & periodically check them.

The project uses bundler, the standard package management solution for Ruby, for most externally-maintained components. For the rest (e.g., PostgreSQL) it uses the system package manager.

We avoid depending on deprecated/obsolete functions.

We use CircleCI to automatically test every check in to any branch in our repository. I some circumstances experimental branches which do not yet run even in a development environment may be ignored via a custom entry in our circle.yml file. The master, staging, and production branches are always tested.

When regressions occur, we add tests for them.

As of this writing, we have 100% statement coverage, see Codecov.io.

Yes, this is a documented policy in CONTRIBUTING.md which says:

When adding or changing functionality, please include new tests for them as part of your contribution.

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 settings for the warning tools are generally fairly strict.

They are implemented, as described in docs/security.md.

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.

This implements a web application, and the (external) web server determines what cryptographic algorithms are in use by the user. If the web server supports multiple cryptographic algorithms (and it usually would), then the application does. The functionality that calls out to other systems (e.g., OAUTH for GitHub, and data access for the detectives) are also external (and they support multiple algorithms anyway).

All authentication credentials can be provided via environment variables when run in production, so no useful key is stored in the source code.

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

Github uses TLS 1.2, see https://github.com/linuxfoundation/cii-best-practices-badge.

The software does not directly implement TLS, instead, it depends on the webserver and Ruby libraries to implement TLS - including certificate checking. That said, there is a case where TLS certificate verification is necessary.

The only case where TLS certificate verification matters is that this application uses OAuth for access delegation (in this case, we contact GitHub to determine if someone is the claimed GitHub user). In this case it does need to verify the TLS certificate, because if anyone could pretend to be the access delagatee (e.g., GitHub) then they could claim anything. The application does not do this directly, instead this is done by the gems (Ruby libraries) we call for this purpose, which perform this checking.

Other than that, this application does not use TLS certificate verification. That's because it implements a server-side application, not a client-side application, and uses name/password or GitHub authentication for user authentication (not TLS certificates).

The software does not directly implement TLS, instead, it depends on the webserver and Ruby libraries to implement TLS - including certificate checking. That said, there is a case where TLS certificate verification is necessary, and this is supported (indirectly) by the systems it depends on.

The only case where TLS certificate verification matters is that this application uses OAuth for access delegation (in this case, we contact GitHub to determine if someone is the claimed GitHub user). In this case it does need to verify the TLS certificate, because if anyone could pretend to be the access delagatee (e.g., GitHub) then they could claim anything. The application does not do this directly, instead this is done by the gems (Ruby libraries) we call for this purpose, which perform this checking.

Other than that, this application does not use TLS certificate verification. That's because it implements a server-side application, not a client-side application, and uses name/password or GitHub authentication for user authentication (not TLS certificates).

Releases are not intended for widespread use in many different sites, so this is N/A.

All inputs from potentially untrusted sources are checked & rejected if they are invalid. Some, such as justifications, only have a few limitations (must be UTF-8 and have a limited length). For more information, see security.md.

We use various HTTP headers for hardening, including a rigorous Content Security Policy (CSP) setting. For more information, see security.md which discusses the hardening mechanisms.

The security requirements and assurance case are documented in docs/security.md.

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

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