FLOSSベストプラクティス基準（ゴールドバッジ）

これは、Open Source Security Foundation (OpenSSF) ベストプラクティスのシルバーバッジを達成するための、フリー/リブレおよびオープンソースソフトウェア（FLOSS）プロジェクトのベストプラクティスのセットです。このリストは、基準のみまたは追加情報とともに表示できます。条件の完全なセットも利用できます。

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

ゴールド

基本的情報

前提要件

プロジェクトは、シルバーレベルバッジを達成しなければなりません。 ^{[achieve_silver]}

プロジェクトの管理・運営

プロジェクトは2以上の "バスファクタ"を持つ必要があります。 {Met URL} ^[bus_factor]
プロジェクトには少なくとも2人の関係を持たない重要な貢献者がいなければなりません。 {Met URL} ^{[contributors_unassociated]}

詳細:

同じ組織によって作業に対しに支払われ（従業員または請負業者）、組織がプロジェクトの成果の恩恵を受ける場合、貢献者は関連します。財務補助金が他の組織を通過する場合、同じ組織のものであると見なされません（例えば、共通の政府やNGOのソースから異なる組織に支払われた科学補助金は、貢献者を関連させません）。過去1年間にプロジェクトに些細でない貢献をしていれば、その人は大きな貢献をしています。重要な貢献者の良い指標の例としては、少なくとも1,000行のコード、50個のコミット、または少なくとも20ページの文書化が挙げられます。

その他

プロジェクトは、少なくとも1つの関連する年と著作権者を特定する著作権記述書を各ソースファイルに含まなければなりません（"[プロジェクト名] 貢献者" のように）。 {Met justification} ^{[copyright_per_file]}

詳細:

これは、各ファイルの先頭近くに以下のコメントを含めることによって行うことができます： "Copyright the [project name] contributors."。"Copyright Notices in Open Source Software Projects" by Steve Winslowを参照してください。
プロジェクトは、各ソースファイルにライセンスステートメントを含まなければなりません。これは、各ファイルの先頭近くに次のコメントを含めることによって行うことができます： SPDXライセンス識別子：[プロジェクトに対するSPDXライセンス表現] {Met justification} ^{[license_per_file]}

詳細:

これは、ライセンスを特定する自然言語での記述を含めることによっても行うことができます。プロジェクトには、ライセンステキストまたは完全なライセンステキストを指し示す安定したURLを含めることもできます。 license_location基準は、プロジェクトライセンスが標準の場所にあることを要求します。 SPDXライセンスの詳細については、このSPDXチュートリアルを参照してください。 copyright_per_file との関係に注意してください。その内容は通常、ライセンス情報に先行します。

変更管理

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

プロジェクトのソースリポジトリは、共通の分散バージョン管理ソフトウェア（gitやmercurialなど）を使用しなければなりません。 {Met justification} ^{[repo_distributed]}
プロジェクトは、新規または偶に参加する貢献者によって実行できる小さなタスクを明確に識別しなければなりません。 {Met URL} ^{[small_tasks]}

詳細:

この特定は、通常、課題トラッカーの選択された課題に対して、プロジェクトがそのために使用する1つまたは複数のタグ、たとえば、 up-for-grabs（誰でも使用可能）、first-timers-only（初心者専用）、Small fix（小修正）、microtask（小タスク）、またはIdealFirstBug（理想的な最初のバグ）のいずれかをマークすることによって行われます。これらの新しいタスクには機能を追加する必要はありません。ドキュメントを改善したり、テストケースを追加したり、プロジェクトを支援したり、プロジェクトの詳細を貢献者が理解できるようにすることができます。
プロジェクトは、中央リポジトリを変更したり、機密データ（プライベート脆弱性レポートなど）にアクセスするために、開発者に対して二要素認証（2FA）を要求する必要があります。推奨されませんが、2FAメカニズムは、SMSのような暗号化メカニズムを持たないメカニズムを使用することができます。 {Met justification} ^{[require_2FA]}
プロジェクトの2要素認証（2FA）は、偽装を防ぐために暗号化メカニズムを使用すべきです。ショートメッセージサービス（SMS）ベースの2FA自体は、暗号化されていないため、この基準を満たしていません。 {Met justification} ^[secure_2FA]

詳細:

この基準を満たす2FAメカニズムは、一定時間後に変更される認証コードを自動的に生成するタイムベースのワンタイムパスワード（TOTP）アプリケーションです。 GitHubはTOTPをサポートしています。

品質

コーディング標準

プロジェクトは、コードレビューの実施方法、チェックする必要があるもの、受け入れられる必要があるものなど、コードレビュー要件を文書化しなければなりません。 {N/A justification} {Met URL} ^{[code_review_standards]}

詳細:

two_person_review とcontribution_requirementsも参照してください。
プロジェクトは、公開する前に、提案されたすべての変更の少なくとも50％を著作者以外の人がレビューして、それが価値のある変更であり、取り込みに反対する既知の問題がないかどうかを判断しなければなりません。 {Met justification} ^{[two_person_review]}

作業ビルドシステム

プロジェクトが再現可能なビルドを持たなければなりません。ビルドが発生しない場合（たとえば、コンパイルされないでソースコードが直接使用されるスクリプト言語）、「該当なし」（N/A）を選択します。 {N/A justification} {Met URL} ^{[build_reproducible]}

詳細:

再現可能なビルドは、複数の当事者がソースファイルから情報を生成するプロセスを独立にやり直し、ビット単位でまったく同じ結果を得られることを意味します。ある場合には、これ（再現可能なビルド）は、あるソート順を強いることで解決されます。Javaスクリプトの開発者は、npm shrinkwrapとwebpack OccurenceOrderPluginの使用を検討するかもしれません。GCCとclangのユーザーは、-frandom-seedオプションが有用であることを見つけるかもしれません。ビルド環境（ツールセットを含む）は、リビルドに使用できる特定のコンテナや仮想マシンの暗号化ハッシュを指定することによって、外部パーティのために、しばしば定義可能です。再現可能なビルドプロジェクトは、これを行う方法を記載したドキュメントを有します。

自動テストスイート

テストスイートは、その言語の標準的な方法で呼び出すことができなければなりません。 {Met URL} ^{[test_invocation]}
プロジェクトは、新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動化されたテストが実行される、継続的な統合を実装しなければなりません。 {Met URL} ^{[test_continuous_integration]}

詳細:

ほとんどの場合、これは、プロジェクトでフルタイムで働く各開発者が少なくとも1日に1回統合作業をすることを意味します。
プロジェクトは、選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがある場合、少なくとも80％のステートメントカバレッジを提供するFLOSS自動テストスイートを備えていなければなりません。 {N/A justification} {Met justification} ^{[test_statement_coverage90]}
選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがあれば、少なくとも80％のブランチカバレッジを提供するFLOSS自動テストスイートがプロジェクトに存在しなければなりません。 {N/A justification} {Met justification} ^{[test_branch_coverage80]}

セキュリティ

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

プロジェクトで作成されたソフトウェアは、ネットワーク通信すべてに対して、SSHv2以降、TLS1.2以降 (HTTPS)、IPsec、SFTP、SNMPv3などのセキュアプロトコルをサポートしなければなりません。FTP、HTTP、telnet、SSLv3以前、SSHv1などのセキュアでないプロトコルは、デフォルトで無効にしておき、ユーザーが特別に設定した亜場合のみ有効にしなければなりません。プロジェクトによって作成されたソフトウェアがネットワーク通信をサポートしない場合は、「該当なし」（N/A）を選択します。 {N/A allowed} {Met justification} ^{[crypto_used_network]}
プロジェクトによって作成されたソフトウェアは、TLSをサポートあるいは使用する場合、少なくともTLSバージョン1.2をサポートしなければなりません。TLSの前身は、SSLと呼ばれていたことに注意して下さい。ソフトウェアがTLSを使用ない場合、「該当なし」（N/A）を選択します。 {N/A allowed} {Met justification} ^{[crypto_tls12]}

MITM（man-in-the-middle：中間者）攻撃に対応できる安全な配信

プロジェクトウェブサイト、リポジトリ（ウェブからアクセス可能な場合）、およびダウンロードサイト（別々の場合）には、許容できない値を持つキー強化ヘッダーが含まれていなければなりません。 {Met URL} ^{[hardened_site]}

詳細:

GitHubやGitLabはこれを満たしていることが知られているので注意してください。https://securityheaders.com/ のようなサイトは、これをすぐに確認することができます。重要なセキュリティ強化ヘッダーは以下の通りです。Content Security Policy (CSP)、HTTP Strict Transport Security (HSTS)、X-Content-Type-Options (「nosniff」として)、および X-Frame-Options 。Web ページからログインする機能のない完全に静的な Web サイトでは、いくつかの強化ヘッダーを省略してもリスクは少なくて済みますが、そのようなサイトを検出する信頼できる方法がないため、完全に静的なサイトであってもこれらのヘッダーが必要です。

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

プロジェクトは過去5年間にセキュリティレビューを実施していなければなりません。このレビューは、セキュリティ要件とセキュリティ境界を考慮しなければならりません。 {Met justification} ^{[security_review]}

詳細:

これは、プロジェクトメンバーおよび/または独立した評価によって行うことができます。この評価は、静的および動的解析ツールによってサポートされることができますが、ツールが検出できない問題（特に設計上）を特定するためには、人間によるレビューが必要です。
プロジェクトによって作成されたソフトウェアで強化メカニズムを使用しなければならないので、ソフトウェア欠陥がセキュリティ上の脆弱性を引き起こす可能性が低くなります。 {N/A justification} {Met URL} ^[hardening]

分析

動的コード分析

プロジェクトは、リリース前にプロジェクトによって作成されたソフトウェアの主要な製品リリースに対して、少なくとも1つの動的解析ツールを適用しなければなりません。 {N/A justification} {Met justification} ^{[dynamic_analysis]}
プロジェクトは、生成するソフトウェアに多くの実行時アサーションを含めるべきであり、動的分析中にそれらのアサーションをチェックするべきです。 {N/A justification} {Met justification} ^{[dynamic_analysis_enable_assertions]}

FLOSSベストプラクティス基準（ゴールド バッジ）