Become CII-compliant

Currently runC doesn't meet all of the requirements from the Linux Foundation's Core Infrastructure Initiative badging program. runC is used in many different projects, and will soon be used in even more (like cri-o). So we should handle these problems now.

The following is the collection of requirements (with checkmarks). Most of the problems are because https://runc.io is quite old, and we need to update the damn thing.

Basics

• The project MUST have a public website with a stable URL.

• The project website MUST succinctly describe what the software does (what problem does it solve?).

• The project website MUST provide information on how to: opencontainers/runc.io#3

  • obtain,
  • provide feedback (as bug reports or enhancements), opencontainers/runc.io#3
  • and contribute to the software. opencontainers/runc.io#3

• The information on how to contribute MUST explain the contribution process. opencontainers/runc.io#3

• The information on how to contribute SHOULD include the requirements for acceptable contributions. opencontainers/runc.io#3

• The software MUST be licensed as FLOSS.

• It is SUGGESTED that any required license(s) be approved by the Open Source Initiative (OSI).

• The project MUST post license(s) in a standard location (e.g., as a top-level file named LICENSE or COPYING).

• The project MUST provide basic documentation for the software in some media (such as text or video) that includes: opencontainers/runc.io#3

  • how to install it,
  • how to start it, opencontainers/runc.io#3
  • how to use it (possibly with a tutorial using examples), and opencontainers/runc.io#3
  • how to use it securely (e.g., what to do and what not to do). opencontainers/runc.io#3

• The project MUST include reference documentation that describes its interface.

• The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.

• The project MUST have one or more mechanisms
  for discussion (including proposed changes and issues) that are:

  • searchable,
  • allow messages and topics to be addressed by URL,
  • enable new people to participate in some of the discussions, and
  • do not require client-side installation of proprietary software.

• The project SHOULD include documentation in English and be able to accept bug reports and comments about code in English.

• The project MUST have a version-controlled source repository that is publicly readable and has a URL.

• The source repository MUST track what changes were made, who made the changes, and when the changes were made.

• To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases.

• It is SUGGESTED that common distributed version control software be used (e.g., git).

• The project MUST have a unique version number for each release intended to be used by users.

• It is SUGGESTED that the Semantic Versioning (SemVer) format be used for releases.

• It is SUGGESTED that projects identify each release within their version control system.

• The project MUST provide, in each release, release notes that are a human-readable summary of major changes in that release. The release notes MUST NOT be the output of a version control log (e.g., the "git log" command results are not release notes).

• The release notes MUST identify every publicly known vulnerability that is fixed in each new release.

• The project MUST provide a process for users to submit bug reports (e.g., using an issue tracker or a mailing list).

• The project SHOULD use an issue tracker for tracking individual issues.

• The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix.

• The project SHOULD respond to most enhancement requests in the last 2-12 months (inclusive).

• The project MUST have a publicly available archive for reports and responses for later searching.

• The project MUST publish the process for reporting vulnerabilities on the project site. opencontainers/runc.io#3

• If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private.

• The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days.

• If the software requires building for use, the project MUST provide a working build system that can automatically rebuild the software from source code.

• The project SHOULD be buildable using only FLOSS tools.

• The project MUST have at least one automated test suite that is publicly released as FLOSS
  (this test suite may be maintained as a separate FLOSS project).

• A test suite SHOULD be invocable in a standard way for that language.

• It is SUGGESTED that the test suite cover most (or ideally all) the code branches, input fields, and functionality.

• It is SUGGESTED that the project implement continuous integration.

• The project MUST have a general policy (formal or not) that as major new functionality is added, tests of that functionality SHOULD be added to an automated test suite.

• The project MUST have evidence that such tests are being added in the most recent major changes to the project. Major functionality would typically be mentioned in the ChangeLog.

• It is SUGGESTED that this policy on adding tests be documented in the instructions for change proposals. However, even an informal rule is acceptable as long as the tests are being added in practice.

• The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language.

• The project MUST address warnings. The project should fix warnings or mark them in the source code as false positives.

• The project MUST have at least one primary developer who knows how to design secure software. This requires understanding the following design principles, including the 8 principles from Saltzer and Schroeder.

• At least one of the primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them.

• There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days. The vulnerability must be patched and released by the project itself (patches may be developed elsewhere).

• Projects SHOULD fix all critical vulnerabilities rapidly after they are reported.

• The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access.

• At least one static code analysis tool MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language.

• It is SUGGESTED that at least one of the static analysis tools used for the static_analysis criterion include rules or approaches to look for common vulnerabilities in the analyzed language or environment.

• All medium and high severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed.

• It is SUGGESTED that static source code analysis occur on every commit or at least daily.

• It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release.

• It is SUGGESTED that the software include many run-time assertions that are checked during dynamic analysis.

• All medium and high severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed.

Start by reviewing the unchecked CII Best Practices criteria in this issue and the referenced opencontainers/runc.io#3 work. Identify which requirements concern documentation, release notes, vulnerability reporting, testing, and security practices before selecting a focused change. Done means the applicable criteria are addressed and the project’s CII compliance status can be updated.