FLOSSベストプラクティス基準(合格バッジ)

This is the set of best practices for Free/Libre and Open Source Software (FLOSS) projects to achieve the Core Infrastructure Initiative (CII) Best Practices passing badge. You can show this list with just the criteria or with additional information. The full set of criteria for all badge levels are also available.

これらの基準の詳細については、 基準の説明を参照してください。

合格

基本的情報

基本的なプロジェクト ウェブサイトのコンテンツ

  • プロジェクトのウェブサイトは、ソフトウェアが何をするのか(何の問題を解決するのか)を簡潔に記述しなければなりません。 [description_good]
  • プロジェクトのウェブサイトは、取得方法、フィードバックの提供方法(バグ報告や拡張機能)、ソフトウェアへの貢献方法に関する情報を提供しなければなりません。 [interact]
  • 貢献する方法に関する情報は、貢献プロセス(たとえばプル リクエストが使用されか、など)を説明する必要があります。 {Met URL} [contribution]
  • 貢献する方法に関する情報は、貢献を受け入れるための要件(たとえば、必要なコーディング標準への参照)を含むべきです。 {Met URL} [contribution_requirements]

FLOSSライセンス

ドキュメンテーション

  • プロジェクトは、プロジェクトによって作成されたソフトウェアに関する基本的なドキュメンテーションを提供しなければなりません。 {N/A justification} [documentation_basics]
  • プロジェクトは、プロジェクトによって作成されたソフトウェアの外部インタフェース(入力と出力の両方)を記述する参照ドキュメントを提供しなければなりません。 {N/A justification} [documentation_interface]

その他

  • プロジェクトサイト(ウェブサイト、リポジトリ、およびダウンロードURL)は、TLSを使用したHTTPSをサポートしなければなりません。 [sites_https]
  • プロジェクトは、議論(提案された変更や問題を含む)のための1つ以上の検索可能なメカニズムを持たなければならず、メッセージやトピックがURLでアドレス指定され、新しい人々がディスカッションのいくつかに参加できるようにしなければならず、クライアント側でプロプライエタリなソフトウェアのインストールを必要としないようにします。 [discussion]
  • プロジェクトは英語で文書を提供し、英語でコードに関するバグ報告とコメントを受け入れることができるべきです。 [english]

変更管理

公開されたバージョン管理ソースリポジトリ

  • プロジェクトには、公開され、URLを持つ、バージョン管理のソース リポジトリがなければなりません。 [repo_public]
  • プロジェクトのソース リポジトリは、どのような変更が行われたのか、誰が変更を行ったのか、いつ変更が行われたのかを追跡しなければなりません。 [repo_track]
  • 共同レビューを可能にするために、プロジェクトのソースリポジトリには、リリース間のレビューのための中間バージョンが含まれなければなりません。最終リリースのみを含めることはできません。 [repo_interim]
  • プロジェクトのソース リポジトリに共通の分散バージョン管理ソフトウェア(gitなど)を使用することを推奨します。 [repo_distributed]

一意的なバージョン番号

  • プロジェクトの結果には、ユーザーが使用することを意図されたリリースごとに固有のバージョン識別子が必要です。 [version_unique]
  • リリースには Semantic Versioning(SemVer)形式を使用することを推奨します。 [version_semver]
  • プロジェクトがバージョン管理システム内の各リリースを特定することが推奨されています。たとえば、gitを使用しているユーザーがgitタグを使用して各リリースを特定することが推奨されています。 [version_tags]

リリースノート

  • プロジェクトは、各リリースにおいて、ユーザーがアップグレードすべきかどうか、また、アップグレードの影響を判断できるよう、そのリリースの主要な変更の要約を説明したリリースノートを提供しなければなりません(MUST)。リリースノートは、バージョン管理ログの生の出力であってはなりません(例えば、 "git log"コマンドの結果はリリースノートではない)。プロジェクトの成果物が複数の場所で再利用されることを意図していないプロジェクト(単独のウェブサイトやサービスのためのソフトウェアなど)で、かつ、継続的・断続的な配布を行う場合は、「該当なし」を選択することができます。 {N/A justification} {Met URL} [release_notes]
  • リリースノートは、新しいリリースごとに修正された、既知の脆弱性をすべて特定しなければなりません。リリースノートがないか、または既知の脆弱性がない場合、これは 「該当なし」(N/A)です。 {N/A justification} [release_notes_vulns]

報告

バグ報告プロセス

  • プロジェクトは、ユーザーが不具合報告を送信するプロセスを提供しなければなりません(たとえば、課題トラッカーやメーリングリストを使用します)。 {Met URL} [report_process]
  • プロジェクトは、個々の課題を追跡するための課題トラッカーを使用するべきです。 [report_tracker]
  • このプロジェクトは、過去2〜12か月間に提出された多数のバグ報告の受領を認めなければなりません。応答に修正を含める必要はありません。 [report_responses]
  • プロジェクトは、直近2〜12ヶ月(2ヶ月を含む)に増強要求の多数(> 50%)に対応すべきです。 [enhancement_responses]
  • プロジェクトは、後で検索するために、レポートとレスポンスのアーカイブを公開する必要があります。 {Met URL} [report_archive]

脆弱性報告プロセス

  • プロジェクトは、脆弱性を報告するプロセスをプロジェクト サイトに公開しなければなりません。 {Met URL} [vulnerability_report_process]
  • プライベート脆弱性報告がサポートされている場合、プロジェクトは、プライベートに保持された方法で情報を送信する方法を含んでいなくてはなりません。 {N/A allowed} {Met URL} [vulnerability_report_private]
  • 過去6ヶ月間に受け取った脆弱性報告に対するプロジェクトの初期応答時間は、14日以下でなければなりません。 {N/A allowed} [vulnerability_report_response]

品質

作業ビルドシステム

  • プロジェクトによって作成されたソフトウェアを利用するためにビルドが必要な場合、プロジェクトは、ソース コードからソフトウェアを自動的にリビルドできる作業ビルド システムを提供しなければなりません。 {N/A allowed} [build]
  • ソフトウエアをビルドするために、一般的なツールを使用することをお勧めします。 {N/A allowed} [build_common_tools]
  • プロジェクトは、FLOSSツールだけを使用してビルドができるようにするべきです。 {N/A allowed} [build_floss_tools]

自動テスト スイート

  • プロジェクトは、FLOSSとして公開されている少なくとも1つの自動化されたテスト スイートを使用しなければなりません(このテストスイートは、別のFLOSSプロジェクトとして維持することができます)。 [test]
  • テスト スイートは、その言語の標準的な方法で呼び出すことができるべきです。 [test_invocation]
  • テスト スイートは、コードブランチ、入力フィールド、および機能のほとんど(または理想的にはすべて)をカバーすることが推奨されています。 [test_most]
  • プロジェクトは、継続的インテグレーション(新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動テストが実行される)を実装することを推奨されています。 [test_continuous_integration]

新機能テスト

  • プロジェクトは、プロジェクトで作成されたソフトウェアに主要な新機能が追加されたときに、その機能のテストを自動化されたテスト スイートに追加する必要があるという一般的な方針(正式でも、正式でなくても構いません)を持っていなければなりません。 [test_policy]
  • プロジェクトによって作成されたソフトウェアの最新の大きな変更で、テストを追加するための test_policy が守られているという証拠がプロジェクトに存在しなければなりません。 [tests_are_added]
  • テストを追加するこのポリシー(test_policyを参照)を変更提案に関する手順で文書化することを推奨します。 [tests_documented_added]

警告フラグ

  • プロジェクトは、選択した言語でこの基準を実装することができる少なくとも1つのFLOSSツールがあれば、1つまたは複数のコンパイラ警告フラグ、「安全」言語モードを使用可能にするか、分離 「リンター」ツールを使用してコード品質エラーまたは共通の単純なミスを検索しなければなりません。 {N/A allowed} [warnings]
  • プロジェクトは警告を出さなければならない。 {N/A allowed} [warnings_fixed]
  • プロジェクトによって作成されたソフトウェアにある警告に、実際的な場合には、最大限に厳格になることを推奨されています。 {N/A allowed} [warnings_strict]

セキュリティ

セキュリティに関する開発知識

  • プロジェクトには、セキュアなソフトウェアを設計する方法を知っている少なくとも1人の主要開発者がいなければなりません。 [know_secure_design]
  • プロジェクトの主要開発者の少なくとも1人は、この種のソフトウェアの脆弱性につながる一般的な種類のエラーを知っていなければならず、それぞれを対策または緩和する少なくとも1つの方法を知っていなければなりません。 [know_common_errors]

優良な暗号手法を使用する

  • プロジェクトによって作成されたソフトウェアは、デフォルトで、一般に公開され、専門家によってレビューされている暗号プロトコルとアルゴリズムを使用しなければなりません。(暗号プロトコルとアルゴリズムが使用される場合) {N/A allowed} [crypto_published]
  • プロジェクトによって作成されたソフトウェアがアプリケーションまたはライブラリであり、主な目的が暗号の実装でない場合、暗号機能を実装するために特別に設計されたソフトウェアを呼び出すだけにするべきです。自分用に(暗号機能を)再実装するべきではありません。 {N/A allowed} [crypto_call]
  • 暗号に依存するプロジェクトによって作成されるソフトウェアのすべての機能は、FLOSSを使用して実装可能でなければなりません。 {N/A allowed} [crypto_floss]
  • プロジェクトによって作成されたソフトウェア内にあるセキュリティ メカニズムは、少なくとも、2030年までのNIST最小要件(2012年)を満たすデフォルト鍵長を使用しなければなりません。より小さな鍵長を完全に無効になるおうに、ソフトウェアを構成できなければなりません。 {N/A allowed} [crypto_keylength]
  • プロジェクトで作成したソフトウェア内のデフォルトのセキュリティ メカニズムは、破られた暗号アルゴリズム(たとえば、MD4、MD5、single DES、RC4、Dual_EC_DRBGなど)に依存してはいけませんし、コンテキストに不適切な暗号モード(たとえば、ECBモードは、ECB penguinで明らかにされているように暗号文の中に同じブロックが存在するので、ほとんどの場合不適切です。CTRモードは、入力状態が繰り返されると、認証を実行せず重複が起こすので多くの場合不適切です。)を使用してもいけません。 {N/A allowed} [crypto_working]
  • プロジェクトによって作成されたソフトウェア内のデフォルトのセキュリティ メカニズムは、既知の重大な脆弱性を持つ暗号アルゴリズムやモード(たとえば、SHA-1暗号ハッシュ アルゴリズムまたはSSHのCBC モード)に依存するべきではありません。 {N/A allowed} [crypto_weaknesses]
  • プロジェクトによって作成されたソフトウェア内のセキュリティ メカニズムは、鍵合意プロトコルのための完全な順方向秘密を実装するべきなので、もし長期鍵が将来侵害された場合でも、長期鍵のセットから導出されるセッション鍵は侵害されません。 {N/A allowed} [crypto_pfs]
  • プロジェクトによって生成されたソフトウェアが外部ユーザーの認証に使われるパスワードの保存をする場合、パスワードは、鍵ストレッチ(反復)アルゴリズム(PBKDF2、BcryptまたはScryptなど)を使い、ユーザーごとの塩(乱数)を用いて反復ハッシュとして保存しなければなりません。 {N/A allowed} [crypto_password_storage]
  • プロジェクトによって作成されたソフトウェア内のセキュリティ メカニズムは、暗号学的にセキュアな乱数発生器を使用して、すべての暗号鍵とナンスを生成しなければなりません。暗号学的にセキュアでない発生器を使用してはいけません。 {N/A allowed} [crypto_random]

MITM(man-in-the-middle:中間者)攻撃に対応できる安全な配信

  • プロジェクトは、MITM攻撃に対抗する配信メカニズムを使用しなければならない。httpsまたはssh+scpを使用することは許容されます。 [delivery_mitm]
  • 暗号ハッシュ(たとえばSHA1SUM)は、http経由で運んではならず、暗号署名をチェックすることなしに使用してはいけません。 [delivery_unsigned]

広く知られた脆弱性を修正

  • 60日を超えて公的に知られている中程度または重大度のパッチされていない脆弱性は存在してはなりません。 [vulnerabilities_fixed_60_days]
  • プロジェクトは、すべての重要な脆弱性を、報告された後迅速に修正するべきです。 [vulnerabilities_critical_fixed]

その他のセキュリティ上の課題

  • 公開リポジトリは、パブリックアクセスを制限するための有効なプライベートクレデンシャル(たとえば、有効なパスワードやプライベートキー)を漏らしてはなりません。 [no_leaked_credentials]

分析

静的コード解析

  • 選択した言語でこの基準を実装している少なくとも1つのFLOSSツールがある場合、少なくとも1つの静的コード解析ツールを、リリース前にソフトウェアの主要な製品リリースに適用する必要があります。 {N/A justification} {Met justification} [static_analysis]
  • static_analysis基準に使用される静的解析ツールの少なくとも1つが、分析された言語または環境における共通の脆弱性を探すためのルールまたはアプローチを含むことが、推奨されています。 {N/A allowed} [static_analysis_common_vulnerabilities]
  • 静的コード解析で発見された中程度および重大度の悪用可能な脆弱性はすべて、それらが確認された後、適時に修正されなくてはなりません。 {N/A allowed} [static_analysis_fixed]
  • 静的ソースコード解析は、コミットごと、または少なくとも毎日実行することをお勧めします。 {N/A allowed} [static_analysis_often]

動的コード分析

  • リリース前に、ソフトウェアの主要な製品リリースに少なくとも1つの動的解析ツールを適用することが示唆されています。 [dynamic_analysis]
  • プロジェクトで作成されたソフトウェアにメモリ安全でない言語(CやC ++など)を使用して作成されたソフトウェアが含まれている場合、少なくとも1つの動的ツール(たとえば、ファジーまたはウェブ アプリケーション スキャナ)を、バッファの上書きなどのメモリの安全性の問題を検出するメカニズムと一緒にいつも使用します。プロジェクトがメモリ安全でない言語で書かれたソフトウェアを作成しない場合は、「該当なし」(N/A)を選択します。 {N/A allowed} [dynamic_analysis_unsafe]
  • プロジェクトによって作成されたソフトウェアには、動的解析中にチェックされる多くの実行時アサーションが含まれていることが推奨されます。 [dynamic_analysis_enable_assertions]
  • 動的コード分析で発見されたすべての中程度および重大度の悪用可能な脆弱性は、確認された後、適時に修正されなければなりません。 {N/A allowed} [dynamic_analysis_fixed]