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

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

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

シルバー

基本的情報

前提要件

プロジェクトは合格レベルバッジに達成しなければなりません。 ^{[achieve_passing]}

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

貢献する方法に関する情報には、受け入れ可能な貢献の要件（例えば、必要なコーディング標準への言及）が含まれなければなりません。 {Met URL} ^{[contribution_requirements]}

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

プロジェクトは、プロジェクトソフトウェアのそれなりの量を開発しているすべての開発者が、これらの貢献を行うことが法的に認められていると主張すりょうな法的な仕組みを持っていなければなりません。これを行うための最も一般的で簡単に実装されたアプローチは、開発者証明書（DCO）を使用することです。ユーザーは、 DCOのウェブサイトへのプロジェクトのリンクが表示されます。ただし、これはコントリビュータライセンス契約（CLA）またはその他の法的な仕組みとして実装することができます。 {Met URL} ^[dco]

詳細:

DCOは、実装が容易で、ソースコードで追跡され、gitが "commit -s"を使用して "サインオフ"機能を直接サポートするため、推奨されるメカニズムです。最も効果的であるためには、プロジェクト文書が、そのプロジェクトに対して「サインオフ」とは何を意味するのかを説明するのが最善です。 CLAは、知的著作物が組織またはプロジェクトにライセンスされている条件を定義する法的合意です。コントリビュータアサインアグリーメント（CAA）は、知的著作物の権利を他の当事者に移転する法的合意です。プロジェクトはCAAを必ずしも持つ必要はありません。なぜなら、CAAは、特に受領者が営利目的の組織である場合には、潜在的な貢献者が貢献しないリスクを高めます。 Apache Software Foundation CLA（個々のコントリビュータライセンスと法人CLA）は、この種のCLAのリスクを判断するプロジェクトにとって、リスクが便益よりも小さいのCLAの例です。
プロジェクトは、プロジェクトガバナンスモデル（主要な役割を含む意思決定方法）を明確に定義し、文書化しなければなりません。 {Met URL} ^[governance]

詳細:

決定を下し、論争を解決するための十分に確立された文書化された方法が必要です。小規模なプロジェクトでは、これは「プロジェクトオーナーとリーダーがすべての最終決定を下す」という単純なものです。慈愛の強い独裁者や正式な能力主義を含む様々な統治モデルが存在します。詳細については、統治モデルを参照してください。集中化された（例えば、単一メインテナー）および分散された（例えば、グループメインテナー）アプローチの両方が、プロジェクトにおいて成功のうちに使用されています。統治情報は、プロジェクトフォークを作成する可能性について文書化する必要はありません。なぜなら、これはFLOSSプロジェクトでは常に可能であるからです。
プロジェクトは、行動規範を採択し、標準的な場所に掲示しなければなりません。 {Met URL} ^{[code_of_conduct]}

詳細:

プロジェクトは、地域社会の礼儀正しさを向上させることと、行動規範を採択することで受け入れられる行動についての期待を設定すること、ができるかもしれません。これにより、問題が発生する前に問題を回避し、プロジェクトをより貢献を促す場所にすることができます。これは、プロジェクトのコミュニティ内や職場内の行動にのみ焦点を当てるべきです。行動規範の例としては、以下のようなものがあります。Linuxカーネル行動規範、コントリビューター規約行動規範、Debian行動規範、Ubuntu行動規範、Fedora行動規範、GNOME行動規範、KDEコミュニティ行動規範、Pythonコミュニティ行動規範、Rubyコミュニティ行動指針、およびRust 行動規範。
プロジェクトは、プロジェクトでの重要な役割と役割が実行しなければならないタスクを含む責任を明確に定義し、公的に文書化しなければなりません。誰がどの役割を持っているかは明確でなければなりませんが、これは同じ方法で文書化されていない可能性があります。 {Met URL} ^{[roles_responsibilities]}

詳細:

統治と役割と責任に関する文章は1か所にあるのが良いでしょう。
いずれかの人が仕事を継続できなくなるまたは死亡した場合、プロジェクトは最小限の中断で継続することができなければなりません。特に、プロジェクトは、課題の作成と終了、提案された変更の受け入れ、およびバージョンのソフトウェアのリリース、1週間内に個人が仕事を継続できくなったことまたは死亡したことの確認、行うことができなければならない。これは、他の誰かがプロジェクトを継続するのに必要な鍵、パスワード、法的権利を持っていることを保証することによって行うことができます。 FLOSSプロジェクトを実行する個人は、ロックボックスにキーを提供し、必要な法的権利を提供する意志（例えば、DNS名のために）を提供することによって、これを行うことができます。 {Met URL} ^{[access_continuity]}
プロジェクトは2以上の "バスファクタ"を持っているべきです。 {Met URL} ^[bus_factor]

詳細:

「バスファクタ」（別名「トラックファクタ」）は、知見があり有能な人材が離脱して、プロジェクトが停止に至る時に、プロジェクトから突然消失する（「バスに当たった」）プロジェクトメンバーの最小人数です。トラックファクタツールは、GitHub上のプロジェクトに対してこれを見積もることができます。詳細については、Cosentino et al。の Gitリポジトリのバスファクタの評価を参照してください。

ドキュメンテーション

プロジェクトは、少なくとも翌年に、プロジェクトが何をしたいか、やるつもりはないかを記述した文書化されたロードマップを持っていなければなりません。 {Met URL} ^{[documentation_roadmap]}

詳細:

このプロジェクトはロードマップを達成できないかもしれません。それは問題ありません。ロードマップの目的は、潜在的なユーザーや貢献者がプロジェクトの意図された方向を理解するのを助けることです。詳細にする必要はありません。
プロジェクトは、プロジェクトによって作成されたソフトウェアのアーキテクチャー（いわゆる高水準設計）の文書を含まなければなりません。プロジェクトでソフトウェアが作成されない場合は、「該当なし」（N/A）を選択します。 {N/A justification} {Met URL} ^{[documentation_architecture]}

詳細:

ソフトウェアアーキテクチャは、プログラムの基本的な構造、すなわちプログラムの主な構成要素、それらの間の関係、およびこれらの構成要素および関係の主要な特性を説明します。
プロジェクトは、ユーザーが、プロジェクトによって作成されたソフトウェアからセキュリティの観点から期待できるものと期待できないものを文書化しなければなりません。（セキュリティ要件） {N/A allowed} {Met URL} ^{[documentation_security]}

詳細:

これらは、ソフトウェアが満たすことが意図されているセキュリティ要件です。
プロジェクトでは、新規ユーザーがソフトウェアで何かをすばやく実行できるようにするための「クイックスタート」ガイドを提供する必要があります。 {N/A justification} {Met URL} ^{[documentation_quick_start]}

詳細:

このアイデアは、ユーザーにソフトウェアを始動させる方法と何かをさせる方法を示すことです。これは潜在的なユーザーが開始するために非常に重要です。
プロジェクトは、現行バージョンのプロジェクト結果（プロジェクトによって作成されたソフトウェアを含む）とドキュメントの整合性を保つために努力しなければならない。不一致を招く既知のドキュメントの欠陥は、修正しなければなりません。ドキュメントが一般的に最新のものですが、古い情報が誤って含まれて、もはや正しくない場合は、それを欠陥として扱い、通常どおりに追跡して修正してください。 {N/A justification} {Met justification} ^{[documentation_current]}

詳細:

ドキュメントには、ソフトウェアのバージョン間の相違点や変更点、および/またはドキュメントの古いバージョンへのリンクに関する情報が含まれていてもよいです。この基準の意図は、ドキュメントが完璧である必要があることではなく、ドキュメントの一貫性を保つための努力がなされていることです。
プロジェクトのリポジトリのフロントページおよび/またはウェブサイトは、このベストプラクティスのバッジを含め、成果が達成されたことを一般に認められてから48時間以内に特定し、ハイパーリンクする必要があります。 {Met URL} ^{[documentation_achievements]}

詳細:

達成とは、いくつかのバッジを含めて、プロジェクトが具体的に満たしている外部基準のセットです。この情報は、プロジェクトのウェブサイトのフロントページにある必要はありません。 GitHubを使用するプロジェクトは、READMEファイルに追加することで、リポジトリのフロントページに成果を置くことができます。

アクセシビリティと国際化

プロジェクト（プロジェクトサイトとプロジェクト結果の両方）は、アクセシビリティのベストプラクティスに従い、障害のある人が引き続きプロジェクトに参加し、プロジェクトの結果を合理的な範囲で使用することができるようにするべきです。 {N/A justification} {Met justification} ^{[accessibility_best_practices]}
詳細:
ウェブアプリケーションについては、ウェブコンテンツアクセシビリティガイドライン（WCAG 2.0）とそのサポートドキュメント WCAG 2.0の理解; W3Cアクセシビリティ情報を参照してください。 GUIアプリケーションの場合は、環境固有のアクセシビリティガイドラインの使用を検討して下さい（Gnome、KDE、XFCE、 Android 、bility/ios/" > iOS 、 Mac 、Windows ）。いくつかのTUIアプリケーション（例えば、「ncurses」プログラム）は、「alpine」の「force-arrow-cursor」設定のような、よりアクセスしやすくするためにいくつかのことを行うことができます。ほとんどのコマンドラインアプリケーションは、そのままの状態でかなりアクセス可能です。この基準は、例えば、プログラムライブラリの場合、「該当なし」（N/A）であることが多いです。取り上げるべき行動や考慮すべき課題の例を以下に示します。
- テキスト以外のコンテンツの代替テキストを提供するkotode, 人々が必要とする他の形式に変更することができます。大きな印刷物、点字、スピーチ、記号またはより単純な言語などです。（ WCAG 2.0ガイドライン1.1 ）
- アクションを示したり、応答を促したり、または視覚的要素を区別するために、色が唯一の視覚的な伝達手段として使用されるわけではありません。（ WCAG 2.0ガイドライン1.4.1 ）
- 大文字、付随的なテキストとロゴタイプを除いて、テキストの視覚的提示とテキストのイメージには、少なくとも4.5：1の比率のコントラストがあります（ WCAG 2.0ガイドライン1.4.3 ）
- キーボードからすべての機能を利用できるようにする（WCAGガイドライン2.1）
- GUIまたはウェブベースのプロジェクトは少なくとも1つターゲットプラットフォーム上のスクリーンリーダーでテストするべきです（例えば、NVDA、Jaws、またはWindows上のWindowEyes; MacとiOSのVoiceOver Linux / BSDのOrca;AndroidのTalkBack）。 TUIプログラムは、スクリーンリーダーによる冗長な読み取りを防止するために、オーバードローを減らせるかもしれません。
プロジェクトによって作成されたソフトウェアは、ターゲットオーディエンスの文化、地域、または言語へのローカリゼーションを容易にするために国際化されるべきです。国際化（i18n）が適用されない場合（たとえば、ソフトウェアがエンドユーザー向けのテキストを生成せず、人間が読めるテキストを扱わない場合）、「該当なし」（N/A）を選択します。 {N/A justification} {Met justification} ^{[internationalization]}

詳細:

ローカリゼーションとは、「特定のターゲット市場（ロケール）の言語、文化、およびその他の要件を満たす、製品、アプリケーションまたはドキュメントのコンテンツの適合を指します」。国際化とは、「文化、地域、言語によって異なるターゲットオーディエンスに対してローカライズを容易にする製品、アプリケーション、またはドキュメントコンテンツの設計と開発」のことです。（ W3Cの「ローカリゼーションと国際化」を参照してください。）ソフトウェアは国際化されるだけでこの基準を満たします。いったんソフトウェアが国際化されると、他の人がローカライゼーションに取り組むことができるので、別の特定の言語のローカリゼーションは必要ありません。

その他

プロジェクトサイト（ウェブサイト、リポジトリ、およびダウンロードURL）が外部ユーザーの認証用のパスワードを格納する場合、パスワードは、キーストレッチ（反復）アルゴリズム（PBKDF2、Bcrypt、Scrypt、PBKDF2など）を使用してユーザーごとのソルトで反復ハッシュとして保存する必要があります。プロジェクトサイトがこの目的のためにパスワードを保存しない場合は、「該当なし」（N/A）を選択します。 {N/A justification} {Met justification} ^{[sites_password_security]}

詳細:

GitHub の使用はこの基準を満たしていることに注意してください。この基準は、プロジェクトサイトへの外部ユーザーの認証に使用されるパスワードにのみ適用されます（別名インバウンド認証）。プロジェクトサイトが他のサイトにログインしなければならない場合（別名：アウトバウンド認証）、その目的のために別の方法で認証トークンを保存する必要があるかもしれません（ハッシュを保存しても意味がないため）。これは、crypto_password_storage の基準を sites_httpsと同様にプロジェクトサイトに適用します。

変更管理

以前のバージョン

プロジェクトは、最も頻繁に使用される古いバージョンの製品を維持するか、または新しいバージョンへのアップグレードを提供しなければなりません。アップグレード方法が困難な場合は、プロジェクトは、アップグレード方法（変更されたインターフェイスや、アップグレードに役立つ詳細な手順など）を記載しなければなりません。 {N/A justification} {Met justification} ^{[maintenance_or_update]}

報告

バグ報告プロセス

プロジェクトは、個々の課題を追跡するための課題トラッカーを使用する必要があります。 {N/A justification} {Met justification} ^{[report_tracker]}

脆弱性報告プロセス

プロジェクトは、匿名の報告者を除いて、過去12ヶ月間に解決されたすべての脆弱性の報告者に信用していることを伝えなければなりません。過去12ヶ月間に解決された脆弱性がない場合は、「該当なし」（N / A）を選択します。 {N/A justification} {Met URL} ^{[vulnerability_report_credit]}
プロジェクトには、脆弱性レポートに対応するための文書化されたプロセスがなければなりません。 {Met URL} ^{[vulnerability_response_process]}

詳細:

これはvulnerability_report_processに強く関連しており、脆弱性を報告するための文書化された方法が必要です。これは、特定の時間枠内の脆弱性レポートへの応答を必要とする、vulnerability_report_responseにも関連しています。

品質

コーディング標準

プロジェクトは、使用する主要な言語のための特定のコーディングスタイルガイドを指定しなければなりませんし、貢献が一般にそれに準拠することを要求しなければなりません。 {N/A justification} {Met URL} ^{[coding_standards]}

詳細:

ほとんどの場合、これはいくつかの既存のスタイルガイドを参照し、おそらく差異をリストすることによって行われます。これらのスタイルガイドには、可読性を向上させる方法や、欠陥（脆弱性を含む）の可能性を減らす方法が含まれています。多くのプログラミング言語には、広く使用されているスタイルガイドが1つ以上あります。スタイルガイドの例には、 Googleスタイルガイドと SEI CERTコーディング標準を参照してください。
選択した言語において行うことができるFLOSSツールが少なくとも1つあれば、プロジェクトは自動的に選択したコーディングスタイルを適用しなければなりません。 {N/A justification} {Met justification} ^{[coding_standards_enforced]}

詳細:

これは、静的解析ツールを使用して、および/またはコード再フォーマットを介してコードを強制することによって実装することができます。多くの場合、ツールの設定は、プロジェクトのリポジトリに含まれます（プロジェクトによって異なる設定が選択される可能性があるため）。プロジェクトはスタイルの例外を許可するかもしれません（通常はそうなります）。例外が発生した場合は、それらの場所のコードでまれで、文書化されていなければなりませんので、それらの例外が再検討され、ツールが将来自動的にそれらを処理できるようにできます。このようなツールの例には、ESLint（JavaScript）、Rubocop（Ruby）、および devtools check (R)があります。

作業ビルドシステム

ネイティブバイナリのビルドシステムは、それらに渡される関連するコンパイラおよびリンカ（環境）変数（CC、CFLAGS、CXX、CXXFLAGS、LDFLAGSなど）を受け入れ、コンパイラおよびリンカ呼び出しに渡す必要があります。ビルドシステムは追加のフラグでそれらを拡張するかもしれません。提供された値を単にそれ自身のものに置き換えてはいけません。ネイティブバイナリが生成されていない場合は、「該当なし」（N/A）を選択します。 {N/A justification} {Met justification} ^{[build_standard_variables]}

詳細:

Address Sanitizer（ASAN）などの特別なビルド機能を有効にしたり、ディストリビューション強化のベストプラクティスに準拠したりするのは簡単です（コンパイラフラグを簡単にオンにするなどして）。
ビルドとインストールシステムは、関連するフラグ（例えば、 "install -s"が使用されていない）で要求されたデバッグ情報を保存しておくべきです。ビルドやインストールシステムがない場合（例：一般的なJavaScriptライブラリ）は、「該当なし」（N/A）を選択します。 {N/A justification} {Met justification} ^{[build_preserve_debug]}

詳細:

すなわち、CFLAGS（C）またはCXXFLAGS（C ++）を設定すると、それらの言語が使用されている場合に、関連デバッグ情報が作成されるべきですし、インストール時には削除するべきではありません。デバッグ情報は、サポートと分析のために必要であり、コンパイルされたバイナリのハードニング機能の存在を測定するのにも役立ちます。
プロジェクトによって作成されたソフトウェアのビルドシステムは、サブディレクトリに相互依存関係がある場合、再帰的にサブディレクトリをビルドしてはなりません。ビルドやインストールシステムがない場合（例：一般的なJavaScriptライブラリ）は、「該当なし」（N/A）を選択します。 {N/A justification} {Met justification} ^{[build_non_recursive]}

詳細:

プロジェクトのビルドシステムの内部依存情報は、正確でなければなりません。そうでないと、プロジェクトへの変更が正しくビルドされないことがあります。ビルドが正しくないと、欠陥（脆弱性を含む）が発生する可能性があります。大規模ビルドシステムでよく見られる間違いは、ソースファイルを含むサブディレクトリの階層で、各サブディレクトリが独立してビルドされるとき、「再帰的ビルド」か「再帰的Make」を使用することです。各サブディレクトリが完全に独立していない限り、依存関係の情報が正しくないため、これらを使用することは間違いです。
プロジェクトは、ソースファイルから情報を生成するプロセスを繰り返すことができなければならず、ビット単位でまったく同じ結果を得ることができなければなりません。ビルドが発生しない場合（例えば、ソースコードをコンパイルする代わりに直接使用するスクリプト言語）は、「該当なし」（N/A）を選択します。 {N/A justification} {Met justification} ^{[build_repeatable]}

詳細:

GCCとclangのユーザーには、-frandom-seedオプションが有用であるかもしれません。場合によっては、ソート順を強制することで解決できます。再現可能なビルドサイトで、より多くの提案を見つけることができます。

インストールシステム

プロジェクトは、プロジェクトで作成されたソフトウェアを一般的に使用されているやり方で簡単にインストールおよびアンインストールする方法を提供する必要があります。 {N/A justification} {Met justification} ^{[installation_common]}

詳細:

たとえば、パッケージマネージャー（システムまたは言語レベル）、「make install / uninstall」（DESTDIRをサポート）、標準形式のコンテナー、または標準形式の仮想マシンイメージを使用することが挙げられます。インストールとアンインストールのプロセス（たとえば、パッケージング）は、FLOSSである限り、サードパーティによって実装されてもよいです。
エンドユーザ用のインストールシステムは、インストール時にビルドされる生成物が書き込まれる場所を選択するための標準的な規則を守らなければなりません。たとえば、POSIXシステムにファイルをインストールする場合は、DESTDIR環境変数を守らなければなりません。インストールシステムがない場合や標準的な規約がない場合は、「該当なし」（N / A）を選択します。 {N/A justification} {Met justification} ^{[installation_standard_variables]}
プロジェクトは、潜在的な開発者がすべてのプロジェクト結果を迅速にインストールし、テストやテスト環境を含む変更を行うために必要な環境を迅速にインストールする方法を提供しなければなりません。これは、一般に使用されている手法で実行する必要があります。 {N/A justification} {Met justification} ^{[installation_development_quick]}

詳細:

これは生成されたコンテナおよび/またはインストールスクリプトを使用して実装できます。外部依存部分は、典型的には、external_dependenciesごとにシステムおよび/または言語パッケージマネージャを呼び出すことによってインストールされます。

外部で維持管理されるコンポーネント

プロジェクトは、外部依存関係をコンピュータ処理可能な方法でリストしなければなりません。 {N/A justification} {Met URL} ^{[external_dependencies]}

詳細:

通常、これはパッケージマネージャーやビルドシステムのやり方を使用して行われます。これは installation_development_quick の実装に役立ちます。
プロジェクトは、既知の脆弱性を検出し、悪用可能な脆弱性を修正したり、悪用できない脆弱性として確認するために、外部の依存先（コンビニエンスコピーを含む）を監視または定期的にチェックしなければなりません。 {N/A justification} {Met justification} ^{[dependency_monitoring]}

詳細:

これは、 OWASPのDependency-Check 、 SinatypeのNexus Auditor 、SynopsysのBlack Duck Software Composition Analysis、 Bundler-audit （Rubyの場合）などのオリジンアナライザー/依存性検査ツールを使用して行うことができます。パッケージマネージャーには、これを行うためのメカニズムが含まれています。コンポーネントの脆弱性を悪用することはできない場合、分析が難しいが、単に更新または修正する方が簡単なであれば、それは許容できます。
プロジェクトは
1. 再使用された外部管理コンポーネントの識別と更新を容易にできるようにしている、 または
2. システムまたはプログラミング言語によって提供される標準コンポーネントを使用している
のどちらかでなければなりません。そうすれば、再利用されたコンポーネントに脆弱性が見つかった場合に、そのコンポーネントを簡単に更新することができます。 {N/A justification} {Met justification} ^{[updateable_reused_components]}

詳細:

この基準を満たす典型的な方法は、システムおよびプログラミング言語のパッケージ管理システムを使用することです。多くのFLOSSプログラムは、標準ライブラリーのローカルコピーである "コンビニエンスライブラリー"と一緒に頒布されます（フォークされている可能性があります）。それ自体は、それでいいです。しかし、プログラムがこれらのローカルな（フォークされた）コピーを使用しなければならない場合、セキュリティアップデートとして"標準"ライブラリをアップデートすると、これらの追加のコピーは依然として脆弱のままです。これは、特にクラウドベースシステムの問題です。クラウドプロバイダが "標準"ライブラリを更新してもプログラムがそれらを使用しない場合、更新プログラムは実際には役に立ちません。たとえば、「Chromium：適切なパッケージとしてFedoraにまだない理由は何ですか？」Tom Callaway著を参照してください。
プロジェクトは、使用するテクノロジセット（その "テクノロジスタック"）において、プロジェクトがサポートするユーザの超大多数がFLOSSの代替案を利用可能な（ユーザが代替手段にアクセスしている）場合には、評価の低いまたは時代遅れの機能とAPIの使用を避けるべきです。 {N/A justification} {Met justification} ^{[interfaces_current]}

自動テストスイート

少なくとも1つのブランチの共有リポジトリへの各チェックインに対して、自動テストスイートが適用される必要があります。このテストスイートは、テストの成功または失敗に関するレポートを生成しなければなりません。 {Met justification} ^{[automated_integration_testing]}

詳細:

この要件は、test_continuous_integrationのサブセットと見ることができますが、継続的な統合を範囲外として、テストだけに焦点を当てています。
プロジェクトは、過去6ヶ月以内に修正されたバグの少なくとも50％について、自動テストスイートに回帰テストを追加しなければなりません。 {N/A justification} {Met justification} ^{[regression_tests_added50]}
プロジェクトは、選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがある場合、少なくとも80％のステートメントカバレッジを提供するFLOSS自動テストスイートを備えていなければなりません。 {N/A justification} {Met justification} ^{[test_statement_coverage80]}

詳細:

gcov/lcov、Blanket.js、Istanbul、JCov、covr (R) など、多くのFLOSSツールが、テストカバレッジを測定できます。この基準を満たすことは、テストスイートが徹底していることを保証するものではないですが、それよりも、この基準を満たさないことは、貧弱なテストスイートであることを示す強い指標であることに注意してください。

新機能テスト

プロジェクトには、主要な新機能が追加されると、新しい機能のテストが自動化されたテストスイートに追加されなければならないという正式な文書化されたポリシーがなければなりません。 {N/A justification} {Met justification} ^{[test_policy_mandated]}
プロジェクトは、変更提案のための文書化された手順に、重要な新機能用にテストを追加するという方針を含まなければなりません。 {N/A justification} {Met justification} ^{[tests_documented_added]}

警告フラグ

プロジェクトによって作成されたソフトウェアにある警告に、実際的な場合には、最大限に厳格にならなければなりません。 {N/A justification} {Met justification} ^{[warnings_strict]}

セキュリティ

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

適用できる場合、プロジェクトはセキュア設計原則（「know_secure_design」から）を実装しなければなりません。プロジェクトでソフトウェアが作成されていない場合は、「該当なし」（N / A）を選択します。 {N/A justification} {Met justification} ^{[implement_secure_design]}

詳細:

たとえば、プロジェクトの結果は、フェールセーフのデフォルト値を持つべきです（デフォルトではアクセスの決定は拒否されるべきで、プロジェクトのインストールはデフォルトでセキュリティ保護されているべきです）。また、完全なメディエーションであるべきです（制限されているすべてのアクセスは、権限がチェックされバイパス不可能でなければなりません）。原則が矛盾する場合があります。その場合、選択が必要です（たとえば、多くの仕組みは、「機構の節約」に反して複雑にすることも、単純にすることもできます）。

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

プロジェクトによって作成されたソフトウェア内のデフォルトのセキュリティメカニズムは、既知の重大な脆弱性を持つ暗号アルゴリズムやモード（たとえば、SHA-1暗号ハッシュアルゴリズムまたはSSHのCBC モード）に依存してはいけません。 {N/A allowed} {Met justification} ^{[crypto_weaknesses]}
プロジェクトは複数の暗号アルゴリズムをサポートするべきですので、ユーザーは破られた場合に素早く切り替えることができます。一般的な対称鍵アルゴリズムには、AES、Twofish、およびSerpentがあります。一般的な暗号化ハッシュアルゴリズムには、SHA-2（SHA-224、SHA-256、SHA-384およびSHA-512を含む）およびSHA-3があります。 {N/A allowed} {Met justification} ^{[crypto_algorithm_agility]}
プロジェクトは、他の情報（構成ファイル、データベース、ログなど）とは別にしたファイルに、認証資格情報（パスワードやダイナミックトークンなど）やプライベート暗号鍵を格納することをサポートしなければなりませんし、ユーザーがコードの再コンパイルなしにそれらを更新や置き換えできるように許可しなければなりません。プロジェクトが認証資格情報とプライベート暗号化鍵を決して処理しない場合は、「該当なし」（N/A）を選択します。 {N/A allowed} {Met justification} ^{[crypto_credential_agility]}
プロジェクトで作成されたソフトウェアは、ネットワーク通信すべてに対して、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]}
TLSをサポートしている場合、プロジェクトで作成されたソフトウェアは、TLSを使う時には、サブリソースを含めて、デフォルトでTLS認証を受けなければなりません。ソフトウェアがTLSを使用しない場合、「該当なし」（N/A）を選択します。 {N/A allowed} {Met justification} ^{[crypto_certificate_verification]}

詳細:

誤ったTLS認証の検証は、よくある間違いであることに注意して下さい。詳細については、「世界でもっとも危険なコード：非ブラウザーソフトウェアでのSSL認証の検証」Martin Georgiev et al著と「このアプリケーションを信頼しますか？」Michael Catanzaro著.を参照して下さい。
TLSをサポートしている場合、プロジェクトによって作成されたソフトウェアは、（たとえばセキュアクッキーなど）プライベートな情報をHTTPヘッダと共に送信する前に、証明書の検証をしなければなりません。ソフトウェアがTLSを使用しない場合は、「該当なし」（N/A）を選択します。 {N/A allowed} {Met justification} ^{[crypto_verification_private]}

公開物の安全性

プロジェクトは、広く普及することを意図しているプロジェクト結果のリリースには暗号で署名しなければなりませんし、パブリック署名鍵を入手して署名を検証する方法をユーザに説明するプロセスがなければなりません。これらの署名の秘密鍵は、ソフトウェアを一般に直接配布するために使用されるサイトにあってはなりません。リリースが広く普及することを意図していない場合は、「該当なし」（N/A）を選択します。 {N/A justification} {Met justification} ^{[signed_releases]}

詳細:

プロジェクトの結果には、ソースコードと生成された成果物（実行可能ファイル、パッケージ、コンテナなど）が含まれます。生成された成果物は、ソースコードとは別に署名することができます。これらは、（暗号デジタル署名を使用して）署名付きgitタグとして実装できます。プロジェクトはgitのようなツールとは別に生成された結果を提供するかもしれませんが、そのような場合、別々の結果を別々に署名しなければなりません。
バージョン管理システムでは、 signed_releases で説明されているように、重要なバージョンタグ（メジャーリリース、マイナーリリース、または公開されている脆弱性の一部であるタグ）を暗号署名して検証することが推奨されています。 {Met justification} ^{[version_tags_signed]}

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

プロジェクトの結果は、潜在的に信頼できないソースからのすべての入力をチェックして有効であること（*allowlist*）を確認し、データに何らかの制限がある場合は無効な入力を拒否しなければなりません。 {N/A justification} {Met justification} ^{[input_validation]}

詳細:

攻撃者はしばしばブラックリストを回避することができるので、入力を "不正な形式" のリスト（別名*denylist*）と比較するのは、通常十分ではないことに注意してください。特に、数値は内部形式に変換され、最小値と最大値の間であるかがチェックされますし、文字列は、有効なテキストパターン（有効なUTF-8、長さ、構文など）であることを確認するためにチェックされます。一部のデータは「何でもよい」（たとえばファイルアップローダー）ことがありますが、通常はまれです。
プロジェクトによって作成されたソフトウェアで強化メカニズムを使用するべきですので、ソフトウェア欠陥がセキュリティ上の脆弱性を引き起こす可能性が低くなります。 {N/A justification} {Met justification} ^[hardening]

詳細:

強化メカニズムは、Content Security Policy（CSP）などのHTTPヘッダー、攻撃を緩和するコンパイラフラグ（-fstack-protectorなど）、または未定義の動作を排除するためのコンパイラフラグを含みます。私たちの目的のために、最低限の特権は強化メカニズムとはみなされません（最低の特権は重要ですが、別の話です）。
プロジェクトは、そのセキュリティ要件が満たされていることを証明する保証ケースを提供しなければならない。保証ケースには、脅威モデルの説明、信頼境界の明確な識別、セキュアな設計原則が適用されていることの議論、共通の実装セキュリティの弱点が対処されたことの議論が含まれなければならない。 {Met URL} ^{[assurance_case]}

詳細:

保証ケースは、「システムのプロパティに関する特定の一連の重大なクレームが、特定の環境とアプリケーションに対して適切に正当化されていることを説得力のある正当な議論で示す証拠」である（「構造化された保証ケースモデルを使用したソフトウェア保証」、Thomas Rhodes他、NIST Interagency Report 7608 ）。信頼境界は、データまたは実行がその信頼レベル、例えば、典型的なウェブアプリケーションにおけるサーバの境界、を変更する境界である。安全な設計原則（SaltzerやSchroeerなど）と一般的な実装セキュリティの弱点（OWASPトップ10やCWE / SANSトップ25など）をリストし、それぞれがどのように対抗しているかを示すのは一般的です。 BadgeAppの保証ケースは良い参考例になるかもしれません。これは、documentation_security、documentation_architecture、およびimplement_secure_designに関連しています。

分析

静的コード解析

プロジェクトは、選択された言語でこの基準を実装できる少なくとも1つのFLOSSツールがある場合、解析された言語または環境で共通の脆弱性を探すためのルールまたはアプローチを備えた少なくとも1つの静的解析ツールを使用しなければならなりません。 {N/A justification} {Met justification} ^{[static_analysis_common_vulnerabilities]}

動的コード分析

もしプロジェクトで作成されたソフトウェアにメモリ安全でない言語（CやC ++など）を使用して作成されたソフトウェアが含まれているならば、そのときには 少なくとも1つの動的ツール（たとえば、ファジーまたはウェブアプリケーションスキャナ）を、バッファの上書きなどのメモリの安全性の問題を検出するメカニズムと一緒にいつも使用します。プロジェクトがメモリ安全でない言語で書かれたソフトウェアを作成しない場合は、「該当なし」（N/A）を選択します。 {N/A justification} {Met justification} ^{[dynamic_analysis_unsafe]}

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