FLOSSベストプラクティス基準（合格バッジ）
これは、Open Source Security Foundation (OpenSSF) ベストプラクティスのシルバーバッジを達成するための、フリー/リブレおよびオープンソースソフトウェア（FLOSS）プロジェクトのベストプラクティスのセットです。このリストは、基準のみまたは追加情報とともに表示できます 。 条件の完全なセットも利用できます。
これらの基準の詳細については、 基準の説明を参照してください。
合格
基本的情報
基本的なプロジェクト ウェブサイトのコンテンツ
-
プロジェクトのウェブサイトは、ソフトウェアが何をするのか（何の問題を解決するのか）を簡潔に記述しなければなりません。
[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]
-
プロジェクトはメンテナンスされている必要があります。
[maintained]
変更管理
公開されたバージョン管理ソースリポジトリ
-
プロジェクトには、公開され、URLを持つ、バージョン管理のソース リポジトリがなければなりません。
[repo_public]
-
プロジェクトのソース リポジトリは、どのような変更が行われたのか、誰が変更を行ったのか、いつ変更が行われたのかを追跡しなければなりません。
[repo_track]
-
共同レビューを可能にするために、プロジェクトのソースリポジトリには、リリース間のレビューのための中間バージョンが含まれなければなりません。最終リリースのみを含めることはできません。
[repo_interim]
-
プロジェクトのソース リポジトリに共通の分散バージョン管理ソフトウェア（gitなど）を使用することを推奨します。
[repo_distributed]
一意的なバージョン番号
リリースノート
-
プロジェクトは、各リリースにおいて、ユーザーがアップグレードすべきかどうか、また、アップグレードの影響を判断できるよう、そのリリースの主要な変更の要約を説明したリリースノートを提供しなければなりません（MUST）。リリースノートは、バージョン管理ログの生の出力であってはなりません（例えば、 "git log"コマンドの結果はリリースノートではない）。プロジェクトの成果物が複数の場所で再利用されることを意図していないプロジェクト（単独のウェブサイトやサービスのためのソフトウェアなど）で、かつ、継続的・断続的な配布を行う場合は、「該当なし」を選択することができます。
{N/A justification}
{Met URL}
[release_notes]
-
リリースノートでは、このリリースで修正された、リリースの作成時にすでにCVE割り当てなどがあった、公に知られているランタイムの脆弱性をすべて特定する必要があります。 ユーザーが通常、ソフトウェアを実際に更新できない場合（たとえば、カーネルの更新によくあることです）、この基準は該当なし（N/A）としてマークされる場合があります。 この基準はプロジェクトの結果にのみ適用され、依存関係には適用されません。 リリースノートがない場合、または公に知られている脆弱性がない場合は、[N/A]を選択します。
{N/A justification}
[release_notes_vulns]
報告
バグ報告プロセス
脆弱性報告プロセス
品質
作業ビルドシステム
-
プロジェクトによって作成されたソフトウェアを利用するためにビルドが必要な場合、プロジェクトは、ソース コードからソフトウェアを自動的にリビルドできる作業ビルド システムを提供しなければなりません。
{N/A allowed}
[build]
-
ソフトウエアをビルドするために、一般的なツールを使用することをお勧めします。
{N/A allowed}
[build_common_tools]
-
プロジェクトは、FLOSSツールだけを使用してビルドができるようにするべきです。
{N/A allowed}
[build_floss_tools]
自動テスト スイート
-
プロジェクトは、FLOSSとして公開されている自動テストスイートを少なくとも1つ使用する必要があります（このテストスイートは、別個のFLOSSプロジェクトとして維持される場合があります）。 プロジェクトは、テストスイートの実行方法を明確に示すか文書化する必要があります（たとえば、継続的インテグレーション（CI）スクリプトを介して、またはBUILD.md、README.md、CONTRIBUTING.mdなどのファイルの文書を介して）。
[test]
-
テスト スイートは、その言語の標準的な方法で呼び出すことができるべきです。
[test_invocation]
-
テスト スイートは、コードブランチ、入力フィールド、および機能のほとんど（または理想的にはすべて）をカバーすることが推奨されています。
[test_most]
-
プロジェクトは、継続的インテグレーション（新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動テストが実行される）を実装することを推奨されています。
[test_continuous_integration]
新機能テスト
警告フラグ
-
プロジェクトは、選択した言語でこの基準を実装することができる少なくとも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、シングルDES、RC4、Dual_EC_DRBGなど）に依存したり、実装する必要がない限り、コンテキストに不適切な暗号化モードを使用したりしてはなりません。相互運用可能なプロトコル（実装されたプロトコルがネットワークエコシステムによって広くサポートされている標準の最新バージョンであり、そのエコシステムではそのようなアルゴリズムまたはモードの使用が必要であり、そのエコシステムはこれ以上安全な代替手段を提供しません）。これらの壊れたアルゴリズムまたはモードが相互運用可能なプロトコルに必要な場合、ドキュメントには、関連するセキュリティリスクと既知の緩和策を記載する必要があります。
{N/A allowed}
[crypto_working]
-
プロジェクトによって作成されたソフトウェア内のデフォルトのセキュリティ メカニズムは、既知の重大な脆弱性を持つ暗号アルゴリズムやモード（たとえば、SHA-1暗号ハッシュ アルゴリズムまたはSSHのCBC モード）に依存するべきではありません。
{N/A allowed}
[crypto_weaknesses]
-
プロジェクトによって作成されたソフトウェア内のセキュリティ メカニズムは、鍵合意プロトコルのための完全な順方向秘密を実装するべきなので、もし長期鍵が将来侵害された場合でも、長期鍵のセットから導出されるセッション鍵は侵害されません。
{N/A allowed}
[crypto_pfs]
-
プロジェクトによって作成されたソフトウェアが外部ユーザーの認証用のパスワードの保存を引き起こす場合、パスワードは、キーストレッチ（反復）アルゴリズム（Argon2id、Bcrypt、Scrypt、PBKDF2など）を使用して、ユーザーごとのソルトで反復ハッシュとして保存される必要があります。OWASP Password Storage Cheat Sheetも参照してください）。
{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]
広く知られた脆弱性を修正
その他のセキュリティ上の課題
分析
静的コード解析
-
選択した言語でこの基準を実装するFLOSSツールが少なくとも1つある場合、少なくとも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]