FLOSSベストプラクティス基準（ゴールド バッジ）
これは、Open Source Security Foundation (OpenSSF) ベストプラクティスのシルバーバッジを達成するための、フリー/リブレおよびオープンソース ソフトウェア（FLOSS）プロジェクトのベストプラクティスのセットです。このリストは、基準のみまたは追加情報とともに表示できます 。 条件の完全なセットも利用できます。
これらの基準の詳細については、 基準の説明を参照してください。
ゴールド
基本的情報
前提要件
プロジェクトの管理・運営
その他
変更管理
公開されたバージョン管理ソースリポジトリ
-
プロジェクトのソースリポジトリは、共通の分散バージョン管理ソフトウェア（gitやmercurialなど）を使用しなければなりません。
{Met justification}
[repo_distributed]
-
プロジェクトは、新規または偶に参加する貢献者によって実行できる小さなタスクを明確に識別しなければなりません。
{Met URL}
[small_tasks]
-
プロジェクトは、中央リポジトリを変更したり、機密データ（プライベート脆弱性レポートなど）にアクセスするために、開発者に対して二要素認証（2FA）を要求する必要があります。推奨されませんが、2FAメカニズムは、SMSのような暗号化メカニズムを持たないメカニズムを使用することができます。
{Met justification}
[require_2FA]
-
プロジェクトの2要素認証（2FA）は、偽装を防ぐために暗号化メカニズムを使用すべきです。ショート メッセージ サービス（SMS）ベースの2FA自体は、暗号化されていないため、この基準を満たしていません。
{Met justification}
[secure_2FA]
品質
コーディング標準
-
プロジェクトは、コードレビューの実施方法、チェックする必要があるもの、受け入れられる必要があるものなど、コードレビュー要件を文書化しなければなりません。
{N/A justification}
{Met URL}
[code_review_standards]
-
プロジェクトは、公開する前に、提案されたすべての変更の少なくとも50％を著作者以外の人がレビューして、それが価値のある変更であり、取り込みに反対する既知の問題がないかどうかを判断しなければなりません。
{Met justification}
[two_person_review]
作業ビルドシステム
-
プロジェクトが再現可能なビルドを持たなければなりません。ビルドが発生しない場合（たとえば、コンパイルされないでソースコードが直接使用されるスクリプト言語）、「該当なし」（N/A）を選択します。
{N/A justification}
{Met URL}
[build_reproducible]
自動テスト スイート
-
テストスイートは、その言語の標準的な方法で呼び出すことができなければなりません。
{Met URL}
[test_invocation]
-
プロジェクトは、新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動化されたテストが実行される、継続的な統合を実装しなければなりません。
{Met URL}
[test_continuous_integration]
-
プロジェクトは、選択された言語でこの基準を測定できる少なくとも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]
その他のセキュリティ上の課題
-
プロジェクトは過去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]