バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。詳細ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合は満たさなくても構いません。すべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮することが望まれます。requestとして提示されれば歓迎します。議論のためのメールリストも用意されています。私たちは多言語で情報を提供していますが、翻訳版に矛盾や意味の不一致がある場合は、英語版を正式な記述とします。これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください!バッジステータスは次のようになります。バッジステータスの埋め込み方法は次のとおりです。レベル基準を表示することもできます。他のプロジェクトが同じ名前を使用していないか注意してください。プロジェクトを簡単に説明してください。implementationプロジェクト全体のURLは?https://www.dulwich.ioバージョン管理リポジトリのURLは何ですか(プロジェクトURLと同じでもかまいません)。複数の言語がある場合は、コンマを区切り(スペースを入れてもよい)としてリストし、使用頻度の高いものから順に並べます。使用言語が多くある場合は、少なくとも最初の3つの最も多く使われるものをリストアップしてください。言語ごとにある大文字・小文字の慣用を踏襲してください(例:「JavaScript」)。Enumeration(CPE)は、情報技術(IT)システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。不適合?プロジェクトのウェブサイトは、ソフトウェアが何をするのか(何の問題を解決するのか)を簡潔に記述しなければなりません。[description_good]詳細これは、潜在的なユーザーが理解できる言語でなければなりません(例えば、それは最小限の専門用語を使用します)。不適合?プロジェクトのウェブサイトは、取得方法、フィードバックの提供方法(バグ報告や拡張機能)、ソフトウェアへの貢献方法に関する情報を提供しなければなりません。リクエストが使用されか、など)を説明する必要があります。別段の記載がない限り、GitHub上のプロジェクトは、(GitHubが提供する)課題管理とプルリクエストを使用することを想定します。この情報は不足しているかもしれません。プロジェクトがプルリクエストと課題追跡ツールを使うことか、メーリングリストへの投稿を言及している。不適合?貢献する方法に関する情報は、貢献を受け入れるための要件(たとえば、必要なコーディング標準への参照)を含むべきです。[contribution_requirements]https://github.com/dulwich/dulwich/blob/master/CONTRIBUTING.rstFLOSSライセンスプロジェクトのライセンスはどのようなものですか?詳細SPDXライセンスの表現形式を使用してください。一重引用符または二重引用符を含めないでください。不適合?プロジェクトによって作成されたソフトウェアは、FLOSSとしてリリースされなければなりません。[floss_license]詳細FLOSSは、オープンソース定義またはフリーソフトウェア定義を満たす方法でリリースされたソフトウェアです。License(GPL)を参照してください。ライセンス、またはFedoraによって「良い」ライセンス.ソフトウェアは他の方法でライセンスされているかもしれません(たとえば、「GPLv2またはプロプライエタリ」は許容されます)。不適合?プロジェクトによって作成されたソフトウェアに必要なライセンスは、オープンソース・イニシアチブ(OSI)によって承認されていることが推奨されています。[floss_license_osi]詳細OSIは、厳格な承認プロセスを使用して、どのライセンスがOSSであるかを判断します。不適合?プロジェクトは、結果のライセンスをソースリポジトリの標準的な場所に投稿しなければなりません。[license_location]詳細たとえば、LICENSEまたはCOPYINGという名前の最上位ファイルです。拡張子を付けることができます。別の規則は、ライセンスファイルを含むLICENSESという名前のディレクトリを持つことです。REUSE仕様で説明されているように、SPDXライセンス識別子とそれに続く適切なファイル拡張子として名前が付けられます。この基準は、ソースリポジトリの要件にすぎないことに注意してください。ソースコード(実行可能ファイル、パッケージ、コンテナなど)から何かを生成するときに、ライセンスファイルを含める必要はありません。Network(CRAN)のRパッケージを生成するときは、標準のCRANプラクティスに従います。ライセンスが標準ライセンスの場合は、標準の短いライセンス仕様を使用して(テキストのコピーをさらにインストールしないようにするため)、リストします。.Rbuildignoreなどの除外ファイル内のLICENSEファイル。可能な場合は、生成された形式で機械可読ライセンス情報を含めることをお勧めします。該当なし?プロジェクトは、プロジェクトによって作成されたソフトウェアに関する基本的なドキュメンテーションを提供しなければなりません。(可能であれば例示したチュートリアル)、および、そのソフトウェアの適切なトピックであれば安全に使用する方法(たとえば何をするべきで、何をすべきでないか)を記述し、メディア(たとえば、テキストやビデオなど)に収められている必要があります。セキュリティの文書は必ずしも長文である必要はありません。プロジェクトは、ドキュメンテーションとしてプロジェクト以外の素材へのハイパーテキストリンクを使用してもよいです。該当なし?プロジェクトは、プロジェクトによって作成されたソフトウェアの外部インタフェース(入力と出力の両方)を記述する参照ドキュメントを提供しなければなりません。外部インターフェイスのドキュメントは、エンドユーザーまたは開発者に、その使用方法を説明します。インターフェイスが含まれます。ライブラリの場合、呼び出すことができる主要なクラス/型とメソッド/関数を文書化します。アプリケーションの場合、URLインタフェース(多くの場合、RESTインタフェース)を定義します。コマンドラインインターフェイスの場合は、サポートするパラメータとオプションを文書化します。多くの場合、ドキュメントのほとんどを自動生成すると、ソフトウェアが変更されたときにドキュメントがソフトウェアと同期したままなので、最も良い方法ですが、これは必須ではありません。プロジェクトは、ドキュメンテーションとしてプロジェクト以外の素材へのハイパーテキストリンクを使用してもよいです。ドキュメンテーションは自動的に生成されるかもしれません(実際的に、しばしばこれを行う最良の方法です)。OpenAPIを使用して生成することができます。(R)、およびDoxygen(多数)のいずれかです。実装コードにコメントがあるだけでは、この基準を満たすには不十分です。すべてのソースコードを読むことなく情報を見るための簡単な方法が必要です。プロジェクトがソフトウェアを作成しない場合は、「該当なし」(N/A)を選択します。不適合?プロジェクトサイト(ウェブサイト、リポジトリ、およびダウンロードURL)は、TLSを使用したHTTPSをサポートしなければなりません。[sites_https]詳細これには、プロジェクトのホームページのURLとバージョン管理リポジトリのURLが「http:」ではなく「https:」で始まる必要があります。Encryptからフリーの証明書を入手できます。GitLabページ、またはSourceForgeプロジェクトページを使ってこの基準を実装してもよいです。HTTPをサポートしている場合は、HTTPトラフィックをHTTPSにリダイレクトすることを強くお勧めします。不適合?プロジェクトは、議論(提案された変更や問題を含む)のための1つ以上の検索可能なメカニズムを持たなければならず、メッセージやトピックがURLでアドレス指定され、新しい人々がディスカッションのいくつかに参加できるようにしなければならず、クライアント側でプロプライエタリなソフトウェアのインストールを必要としないようにします。受け入れ可能なメカニズムの例には、アーカイブされたメーリングリスト、GitHubのイシューとプルリクエストの議論、Bugzilla、Mantis、Tracなどがあります。メカニズム(IRCなど)は、これらの基準を満たしていれば許容されます。URLアドレス可能なアーカイブ機構があることを確認してください。独自のJavaScriptは、推奨されませんが、許可されています。不適合?プロジェクトは英語で文書を提供し、英語でコードに関するバグ報告とコメントを受け入れることができるべきです。英語をサポートすることで、世界中のさまざまな潜在的な開発者とレビュアーの数を増やします。コア開発者の主要言語が英語でなくても、プロジェクトはこの基準を満たすことができます。不適合?プロジェクトはメンテナンスされている必要があります。少なくとも、プロジェクトは重大な問題と脆弱性の報告に対応するように努める必要があります。バッジを積極的に追求しているプロジェクトは、おそらくメンテナンスされているでしょう。すべてのプロジェクトや人のリソースには限りがあり、提案された変更をプロジェクトが拒否しなければならないこともあるため、リソースに限りがあることや、提案が拒否されることが、メンテナンスされていないプロジェクトを示すわけではありません。プロジェクトが今後メンテナンスされなくなることがわかった場合は、この基準を「不適合(Unmet)」に設定し、適切なメカニズムを使用して、メンテナンスされないことを人々に示す必要があります。詳細な説明については、こちらを参照してください。リマインダーを無効にします(このままにしておくことをお勧めします。リマインダーを送信するかどうかを変更するには、プロジェクトエントリーを編集する必要があります。現在:[]詳細ほとんどのプロジェクトはこのフィールドを無視するべきです。プロジェクトのバッジエントリは、バッジエントリのオーナー(作成者)、BadgeApp管理者、GitHubリポジトリにコミットできる人(GitHub上にある場合)によっていつでも編集できます。エントリの編集権限をすでに持っている場合は、編集権限を持つ追加のユーザを追加することができます。"+"と入力し、その後にカンマ区切りの整数ユーザーIDのリストを入力します。エントリを編集できるようになります。エントリのオーナーまたはBadgeApp管理者である場合は、"-"と入力した後にカンマで区切られた整数ユーザーIDのリストを入力すれば、このリストからユーザーを削除できます。通常、特定のバッジエントリを一度に編集するのは1人だけであると予想されます。ロック機能を使用して古いデータを保存しないようにします。データを段階的かつ頻繁に保存することをお勧めします(いずれにしてもこれは賢明な方法です)。リポジトリがなければなりません。[repo_public]詳細URLはプロジェクトのURLと同じであってもよいです。プロジェクトは、変更が公開されていない間に(例えば、公開前に脆弱性を修正するため)、特定のケースでプライベート(非公開)ブランチを使用することができます。リポジトリは、どのような変更が行われたのか、誰が変更を行ったのか、いつ変更が行われたのかを追跡しなければなりません。不適合?共同レビューを可能にするために、プロジェクトのソースリポジトリには、リリース間のレビューのための中間バージョンが含まれなければなりません。最終リリースのみを含めることはできません。リポジトリから特定の暫定版を省略することを選択することができます。リポジトリに共通の分散バージョン管理ソフトウェア(gitなど)を使用することを推奨します。[repo_distributed]詳細Gitが特別に必要とされているわけでなく、プロジェクトでは、集中型バージョン管理ソフトウェア(例:subversion)を正当とする証拠を持って使用できます。不適合?プロジェクトの結果には、ユーザーが使用することを意図されたリリースごとに固有のバージョン識別子が必要です。idなど)やバージョン番号(YYYYMMDDのようなセマンティックバージョニングや日付ベースのスキームを使用するバージョン番号を含む)など、さまざまな方法で対応できます。(CalVer)のバージョン番号形式を使用することが推奨されます。CalVerを使用する場合は、マイクロレベル値を含めることが推奨されます。[version_semver]詳細プロジェクトは一般的に、エコシステムで使用されている通常のフォーマットなど、ユーザーが期待しているフォーマットを優先するべきです。多くのエコシステムではSemVerが好まれており、一般的にSemVerはアプリケーションプログラマインターフェース(API)やソフトウェア開発キット(SDK)に好まれています。CalVerは、規模が大きく、独自に開発した依存関係が異常に多いプロジェクトや、スコープが常に変化するプロジェクト、時間的な制約があるプロジェクトで使用される傾向があります。CalVerを使用する際には、マイクロレベルの値を含めることが推奨されます。マイクロレベルを含めることで、必要になった場合にはいつでも同時にメンテナンスされるブランチをサポートできるからです。バージョンを一意に識別できるものであれば、他のバージョン番号形式をバージョン番号として使用することができます。ような)いくつかの代替形式は、リリースの識別子として問題を引き起こす可能性があります。形式はソフトウェアのリリースを識別する上で重要ではないかもしれません。不適合?プロジェクトがバージョン管理システム内の各リリースを特定することが推奨されています。gitを使用しているユーザーがgitタグを使用して各リリースを特定することが推奨されています。該当なし?プロジェクトは、各リリースにおいて、ユーザーがアップグレードすべきかどうか、また、アップグレードの影響を判断できるよう、そのリリースの主要な変更の要約を説明したリリースノートを提供しなければなりません(MUST)。log"コマンドの結果はリリースノートではない)。プロジェクトの成果物が複数の場所で再利用されることを意図していないプロジェクト(単独のウェブサイトやサービスのためのソフトウェアなど)で、かつ、継続的・断続的な配布を行う場合は、「該当なし」を選択することができます。[release_notes]詳細リリースノートは様々な方法で実装できます(MAY)。".html"などの拡張子を付けることもあります。log"という言葉はすべての変更のログを意味していましたが、本基準を満たすために必要なものは、人間が読める要約です。GitHubリリースのワークフローなどのバージョン管理システムのメカニズムによって提供してもよい(MAY)。該当なし?リリースノートでは、このリリースで修正された、リリースの作成時にすでにCVE割り当てなどがあった、公に知られているランタイムの脆弱性をすべて特定する必要があります。ユーザーが通常、ソフトウェアを実際に更新できない場合(たとえば、カーネルの更新によくあることです)、この基準は該当なし(N/A)としてマークされる場合があります。この基準はプロジェクトの結果にのみ適用され、依存関係には適用されません。リリースノートがない場合、または公に知られている脆弱性がない場合は、[N/A]を選択します。[release_notes_vulns]詳細この基準は、特定の更新によって一般に知られている脆弱性が修正されるかどうかをユーザーが判断するのに役立ち、ユーザーが情報に基づいて更新について決定できるようにします。ユーザーが通常、コンピューター上でソフトウェア自体を実際に更新することはできず、代わりに1つ以上の仲介者に依存して更新を実行する必要がある場合(カーネルお​​よびカーネルと絡み合っている下位レベルのソフトウェアの場合によくあることです)、この追加情報はそれらのユーザーには役立たないため、プロジェクトは「該当なし」(N/A)を選択する場合があります。同様に、すべての受信者が最新バージョンのみを実行している場合(継続的デリバリーによって絶えず更新される単一のWebサイトまたはインターネットサービスのコードなど)、プロジェクトはN/Aを選択できます。この基準はプロジェクトの結果にのみ適用され、依存関係には適用されません。プロジェクトのすべての推移的な依存関係の脆弱性を一覧表示することは、依存関係が増加および変化するにつれて扱いにくくなるため、不要です。依存関係を調べて追跡するツールがよりスケーラブルな方法でこれを実行できます。不適合?プロジェクトは、ユーザーが不具合報告を送信するプロセスを提供しなければなりません(たとえば、課題トラッカーやメーリングリストを使用します)。不適合?プロジェクトは、個々の課題を追跡するための課題トラッカーを使用するべきです。不適合?このプロジェクトは、過去2〜12か月間に提出された多数のバグ報告の受領を認めなければなりません。応答に修正を含める必要はありません。50%)に対応すべきです。応答は、「いいえ」や、そのメリットについての議論であってもよいです。目標は、単にプロジェクトがまだ生きていることを示している、いくつかの要求に対する応答があることです。この基準のために、プロジェクトは偽のリクエスト(スパマーや自動システムなど)をカウントする必要はありません。プロジェクトで機能強化が行われていない場合は、「満足されない」(unmet)を選択し、この状況をユーザーに明確にするURLを含めてください。プロジェクトが強化要求の数によって圧倒される傾向がある場合は、「満足されない」(unmet)を選択して説明してください。不適合?プロジェクトは、後で検索するために、レポートとレスポンスのアーカイブを公開する必要があります。サイトに公開しなければなりません。アドレスで、これはしばしばsecurity@example.orgの形式です。これはバグ報告プロセスと同じかもしれません。脆弱性レポートは常に公開される可能性がありますが、多くのプロジェクトでは、プライベート脆弱性を報告するメカニズムがあります。該当なし?プライベート脆弱性報告がサポートされている場合、プロジェクトは、プライベートに保持された方法で情報を送信する方法を含んでいなくてはなりません。例としては、HTTPS(TLS)を使用してWeb上に提出されたプライベート不具合報告や、OpenPGPを使用して暗号化された電子メールがあります。該当なし?過去6ヶ月間に受け取った脆弱性報告に対するプロジェクトの初期応答時間は、14日以下でなければなりません。過去6か月間に脆弱性が報告されていない場合は、「該当なし」(N/A)を選択します。システムを提供しなければなりません。[build]詳細ビルドシステムは、ソフトウェアをリビルドするのに必要なアクション(およびその順序)を決定し、それらのステップを実行します。ビルドシステムは、ソースコードをコンパイルするためにコンパイラを呼び出すことができます。実行可能ファイルがソースコードから生成される場合、ビルドシステムは、プロジェクトのソースコードを変更でき、その変更を含む更新された実行ファイルを生成できなければなりません。プロジェクトによって生成されたソフトウェアが外部ライブラリに依存する場合、ビルドシステムはそれらの外部ライブラリをビルドする必要はありません。ソースコードが変更されても、ソフトウェアを使用するためにビルドする必要がない場合、「該当なし」(N/A)を選択します。該当なし?ソフトウエアをビルドするために、一般的なツールを使用することをお勧めします。該当なし?プロジェクトは、FLOSSツールだけを使用してビルドができるようにするべきです。不適合?プロジェクトは、FLOSSとして公開されている自動テストスイートを少なくとも1つ使用する必要があります(このテストスイートは、別個のFLOSSプロジェクトとして維持される場合があります)。プロジェクトは、テストスイートの実行方法を明確に示すか文書化する必要があります(たとえば、継続的インテグレーション(CI)スクリプトを介して、またはBUILD.md、README.md、CONTRIBUTING.mdなどのファイルの文書を介して)。[test]詳細プロジェクトでは、複数の自動化されたテストスイートを使用することができます(たとえば、迅速に実行するもの、より完全であるが特別な装置が必要なもの)。多くのテストフレームワークやテスト支援システムが利用可能です。スイートは、その言語の標準的な方法で呼び出すことができるべきです。test」(Ruby)などです。スイートは、コードブランチ、入力フィールド、および機能のほとんど(または理想的にはすべて)をカバーすることが推奨されています。不適合?プロジェクトは、継続的インテグレーション(新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動テストが実行される)を実装することを推奨されています。スイートに追加する必要があるという一般的な方針(正式でも、正式でなくても構いません)を持っていなければなりません。スイートに追加して、新しい機能を追加する必要があるというポリシーが、口頭でも(文書化されていなくても)、存在する限り、「満たしている」を選択してください。守られているという証拠がプロジェクトに存在しなければなりません。主要な機能は、通常、リリースノートに記載されます。スイートに実際にテストが追加されているという証拠となります。不適合?テストを追加するこのポリシー(test_policyを参照)を変更提案に関する手順で文書化することを推奨します。[tests_documented_added]詳細しかし、実際にテストが追加されている限り、非公式の規則でも許容されます。「リンター」ツールを使用してコード品質エラーまたは共通の単純なミスを検索しなければなりません。"-Wall"があります。warnings」があります。分離「リンター」ツールは、ソースコードを調べてコード品質のエラーや一般的な単純なミスを探すツールです。これらは、通常、ソースコードまたはビルド命令内で有効になります。該当なし?プロジェクトは警告を出さなければならない。[warnings_fixed]詳細これらは、警告基準の実装によって識別される警告です。プロジェクトは、警告を修正するか、ソースコード内で警告を誤検出としてマークするべきです。理想的には警告がないことがいいですが、プロジェクトはある程度の警告(通常は100行あたり1警告未満、または全体で10警告未満)を受け入れることができます。該当なし?プロジェクトによって作成されたソフトウェアにある警告に、実際的な場合には、最大限に厳格になることを推奨されています。一部の警告は、あるプロジェクトでは効果的に有効にすることはできません。必要なのは、プロジェクトが可能な限り警告フラグを有効にするように努力しており、エラーが早期に検出されるという証拠です。不適合?プロジェクトには、安全なソフトウェアを設計する方法を知っている少なくとも1人の主要な開発者が必要です。(正確な要件については、「詳細」を参照してください。8つの原則を含む以下の設計原則を理解する必要があります。簡単に保護ができて変更ができる鍵やパスワードのような情報に依存すべきです。特権の分離(理想的には、重要なオブジェクトへのアクセスは複数の条件に依存すべきで、1つの保護システムを破ることで完全なアクセスが可能にならないようにします。トークンを必要とする多因子認証は単因子認証より強いです。最低限の権限(プロセスは最低限の権限で動作する必要がある)最低限の共通メカニズム(設計は、複数のユーザに共通のメカニズムや全てのユーザーに依存するメカニズムを最小限に抑えるべきです。リストで入力を検証します(入力は通常、この検証はブラックリスト(既知の不良値をリストする)ではなく、ホワイトリスト(既知の値のみを受け入れる)を使用する必要があります。プロジェクトの「主要な開発者」とは、プロジェクトのコードベースに精通していて、容易に変更を加えることができ、プロジェクトの他のほとんどの参加者によって認められている人です。主要な開発者は、通常、過去1年間に(コード、文書、または質問に回答して)多数の貢献を行います。ある開発者が、プロジェクトを開始している(3年以上プロジェクトから離れていない)、プライベート脆弱性報告チャネル(存在する場合)に関する情報を受け取る、プロジェクトを代表してコミットを受け入れる、最終リリースする、などを行う時主要な開発者とみなすことができます。開発者が1人だけの場合、その人物が主要開発者です。安全なソフトウェアを開発し、設計について議論する方法を理解するのに役立つ多くの本やコースが利用可能です。コースは、3つのコースの無料セットです。安全なソフトウェアを開発する方法を説明しています。不適合?プロジェクトの主要開発者の少なくとも1人は、この種のソフトウェアの脆弱性につながる一般的な種類のエラーを知っていなければならず、それぞれを対策または緩和する少なくとも1つの方法を知っていなければなりません。例(ソフトウェアの種類によって異なります)には、SQLインジェクション、OSインジェクション、従来のバッファオーバーフロー、クロスサイトスクリプティング、認証の欠落、承認の欠落などがあります。CWE/SANSトップ25またはOWASPトップ10を参照してください。安全なソフトウェアを開発する方法を理解し、脆弱性につながる一般的な実装エラーについて説明するのに役立つ多くの書籍やコースが用意されています。Fundamentalsコースは、より安全なソフトウェアを開発する方法を説明する3つのコースの無料セットです(受講は無料です。追加料金を払うと、学習したことを証明する証明書を入手できます)。優良な暗号手法を使用する一部のソフトウェアは暗号化メカニズムを使用する必要がないことに注意してください。米国(US)から米国外または米国市民以外にリリースされる可能性がある場合は、法的に義務付けられた追加手順の実行を要求される可能性があります。通常、これにはメールの送信が含まれます。Controls(「オープンソース技術と米国の輸出管理について」)の暗号化のセクションを参照してください。該当なし?プロジェクトによって作成されたソフトウェアは、デフォルトで、一般に公開され、専門家によってレビューされている暗号プロトコルとアルゴリズムを使用しなければなりません。[crypto_published]詳細ソフトウェアによっては暗号機能を直接使用する必要がないため、これらの暗号基準は常に適用されるわけではありません。該当なし?プロジェクトによって作成されたソフトウェアがアプリケーションまたはライブラリであり、主な目的が暗号の実装でない場合、暗号機能を実装するために特別に設計されたソフトウェアを呼び出すだけにするべきです。自分用に(暗号機能を)再実装するべきではありません。該当なし?暗号に依存するプロジェクトによって作成されるソフトウェアのすべての機能は、FLOSSを使用して実装可能でなければなりません。スタンダード要件を参照して下さい。メカニズムは、少なくとも、2030年までのNIST最小要件(2012年)を満たすデフォルト鍵長を使用しなければなりません。小さな鍵長を完全に無効になるおうに、ソフトウェアを構成できなければなりません。[crypto_keylength]詳細これらの最小ビット長は、対称鍵112、ファクタリング係数2048、離散対数鍵224、離散対数群2048、楕円曲線224、ハッシュ224(パスワードハッシュはこのビット長でカバーされません。基準にあります)です。さまざまな機関が出している推奨鍵長の比較については、https://www.keylength.comを参照してください。いくつかの構成ではより短い鍵長を許可するかもしれません(これはダウングレード攻撃を許すので、理想的には正しくありません。短い鍵長は、相互運用性のために時に必要となります)。該当なし?プロジェクトによって生成されたソフトウェア内のデフォルトのセキュリティメカニズムは、壊れた暗号化アルゴリズム(MD4、MD5、シングルDES、RC4、Dual_EC_DRBGなど)に依存したり、実装する必要がない限り、コンテキストに不適切な暗号化モードを使用したりしてはなりません。相互運用可能なプロトコル(実装されたプロトコルがネットワークエコシステムによって広くサポートされている標準の最新バージョンであり、そのエコシステムではそのようなアルゴリズムまたはモードの使用が必要であり、そのエコシステムはこれ以上安全な代替手段を提供しません)。これらの壊れたアルゴリズムまたはモードが相互運用可能なプロトコルに必要な場合、ドキュメントには、関連するセキュリティリスクと既知の緩和策を記載する必要があります。ECBペンギンによって示されるように暗号文内の同一のブロックを明らかにするため、ほとんど適切ではありません。CTRモードは、認証を実行せず、入力状態が繰り返されると重複を引き起こすため、不適切なことがよくあります。モードを選択するのが最善です。プロジェクトは、互換性のために必要な場合、ユーザーが壊れたメカニズムを有効にすることを許可する場合があります(構成中など)が、ユーザーはそれを実行していることを認識します。モード)に依存するべきではありません。脆弱性にて議論されています。メカニズムは、鍵合意プロトコルのための完全な順方向秘密を実装するべきなので、もし長期鍵が将来侵害された場合でも、長期鍵のセットから導出されるセッション鍵は侵害されません。該当なし?プロジェクトによって作成されたソフトウェアが外部ユーザーの認証用のパスワードの保存を引き起こす場合、パスワードは、キーストレッチ(反復)アルゴリズム(Argon2id、Bcrypt、Scrypt、PBKDF2など)を使用して、ユーザーごとのソルトで反復ハッシュとして保存される必要があります。Sheetも参照してください)。[crypto_password_storage]詳細この基準は、ソフトウェアがサーバー側Webアプリケーションなどの外部ユーザーのパスワードを使用してユーザーの認証(別名インバウンド認証)を実施している場合にのみ適用されます。ソフトウェアが他のシステムへの認証用のパスワードを保存している場合(別名、アウトバウンド認証、たとえば、ソフトウェアが他のシステムのクライアントを実装している場合)、そのソフトウェアの少なくとも一部がハッシュされていないパスワードにアクセスできる必要があるため、適用されません。メカニズムは、暗号学的にセキュアな乱数発生器を使用して、すべての暗号鍵とナンスを生成しなければなりません。暗号学的にセキュアでない発生器を使用してはいけません。CTR_DRBG、Yarrow、Fortunaなどのアルゴリズムを使用する暗号学的にセキュアな疑似乱数発生器(CSPRNG)でもよいです。セキュアでない乱数発生器には、Javaのjava.util.RandomとJavaScriptのMath.randomがあります。不適合?プロジェクトは、MITM攻撃に対抗する配信メカニズムを使用しなければならない。httpsまたはssh+scpを使用することは許容されます。[delivery_mitm]詳細さらに強力な仕組みは、デジタル署名されたパッケージでソフトウェアをリリースすることです。配布システムへの攻撃を緩和するからです。これは、署名の公開鍵が正当なものであることをユーザーが確信でき、かつユーザーが実際に署名をチェックする場合にのみ有効です。不適合?暗号ハッシュ(たとえばSHA1SUM)は、http経由で運んではならず、暗号署名をチェックすることなしに使用してはいけません。[delivery_unsigned]詳細これらのハッシュは、送信中に変更することができます。不適合?60日を超えて公的に知られている中程度または重大度のパッチが適用されていない脆弱性は存在してはなりません。脆弱性は、プロジェクト自体によってパッチされ、リリースされなければなりません(パッチは他の場所で開発される可能性があります)。)、またはプロジェクトに情報が伝えられ、その情報が(おそらくプロジェクトによって)一般に公開されたとき、脆弱性は一般に知られるようになります。(CVSS)の定性的スコアが中程度以上であれば、脆弱性は中程度以上の深刻度とみなされます。プロジェクトは、広く利用されている脆弱性データベース(国家脆弱性データベースなど)で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを用いて使用することができます。代わりに、プロジェクトは、脆弱性が公表された時点で計算入力内容が公開されている場合には、脆弱性が公表された時点でのCVSSの最新版を用いて深刻度を計算することができます。注意:これは、ユーザーが最大60日間、世界中のすべての攻撃者に対して脆弱なままになる可能性があることを意味します。この基準は、責任ある開示の再起動でGoogleが推奨しているものよりも、はるかに簡単に満たすことができることが多いです。Googleはレポートが公開されていなくても、プロジェクトが通知された時点で60日間の期間が開始されることを推奨しているためです。このバッジの基準は、他の基準と同様に、個々のプロジェクトに適用されることにも注意してください。プロジェクトの中には、より大きな包括組織や大規模プロジェクトの一部であり、複数のレイヤーに分かれている場合もあります。多くのプロジェクトでは、複雑なサプライチェーンの一部として、他の組織やプロジェクトに成果を提供しています。個々のプロジェクトは、多くの場合、残りの部分をコントロールできませんが、個々のプロジェクトは、脆弱性パッチをタイムリーにリリースするための作業を行うことができます。そのため、私たちは個々のプロジェクトの対応時間に焦点を当てています。個々のプロジェクトからパッチが利用可能になると、他のプロジェクトはそのパッチにどのように対処するかを決定することができます(たとえば、新しいバージョンにアップデートすることもできますし、選別されたソリューションのパッチだけを適用することもできます)。不適合?プロジェクトは、すべての重要な脆弱性を、報告された後迅速に修正するべきです。不適合?公開リポジトリは、パブリックアクセスを制限するための有効なプライベートクレデンシャル(たとえば、有効なパスワードやプライベートキー)を漏らしてはなりません。アクセスを制限する意図がない限り、テスト用や重要でないデータベース用の「サンプル」資格情報を漏らす可能性があります。該当なし?選択した言語でこの基準を実装するFLOSSツールが少なくとも1つある場合、少なくとも1つの静的コード分析ツール(コンパイラの警告と「安全な」言語モード以外)を、ソフトウェアの主要な製品リリースの提案に、リリース前に適用する必要があります。静的コード解析ツールは、ソフトウェアコードを実行せずに特定の入力を用いて(ソースコード、中間コード、または実行可能ファイルとして)調べます。この基準のために、コンパイラの警告と「安全な」言語モードは、静的コード解析ツールとしてカウントされません(これらは通常、速度が重要なため深い解析を行いません)。NISTソースコードセキュリティアナライザのリスト、およびウィーラーの静的解析ツール一覧などがあります。使用する実装言語で使用できるFLOSS静的解析ツールがない場合は、「該当なし」(N/A)を選択します。該当なし?static_analysis基準に使用される静的解析ツールの少なくとも1つが、分析された言語または環境における共通の脆弱性を探すためのルールまたはアプローチを含むことが、推奨されています。一般的な脆弱性を探すために特別に設計された静的解析ツールは、それらを見つける可能性が高いです。静的ツールを使用すると、通常は問題を見つけるのに役立ちますので、利用を提案しますが、「合格」レベルのバッジには要求しません。該当なし?静的コード解析で発見された中程度および重大度の悪用可能な脆弱性はすべて、それらが確認された後、適時に修正されなくてはなりません。(CVSS)の基本的な定性的なスコアが中程度以上であれば、脆弱性は中程度以上の深刻度とみなされます。プロジェクトは、広く利用されている脆弱性データベース(国家脆弱性データベースなど)で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを用いて使用することができます。脆弱性が公開された時点で計算入力が公開されている場合には、脆弱性が公開された時点でのCVSSの最新バージョンを用いて深刻度を計算することもできます。日以内にすべての脆弱性を修正することが要求されていることに注意してください。該当なし?静的ソースコード解析は、コミットごと、または少なくとも毎日実行することをお勧めします。不適合?リリース前に、ソフトウェアの主要な製品リリースに少なくとも1つの動的解析ツールを適用することが示唆されています。動的解析ツールは、ソフトウェアを特定の入力で実行して検査します。プロジェクトがプロジェクトにファズテストを適用する可能性があります。スイートである必要があります。ファジングに関するOWASPページで、いくつかの動的解析ツールを特定しています。解析ツールは、セキュリティの脆弱性を探すことに重点を置くことができますが、これは必須ではありません。スキャナ)を、バッファの上書きなどのメモリの安全性の問題を検出するメカニズムと一緒にいつも使用します。プロジェクトがメモリ安全でない言語で書かれたソフトウェアを作成しない場合は、「該当なし」(N/A)を選択します。他に使用される可能性のあるツールには、スレッドサニタイザと定義されていない動作サニタイザを参照してください。広範なアサーションも機能します。不適合?プロジェクトでは、多くのアサーションを可能にする少なくとも一部の動的分析(テストやファジングなど)の構成を使用することをお勧めします。多くの場合、これらのアサーションは本番ビルドでは有効にしないでください。[dynamic_analysis_enable_assertions]詳細この基準は、本番環境でアサーションを有効にすることを示唆するものではありません。それは完全にプロジェクトとそのユーザーが決定することです。この基準の焦点は、展開前の動的分析中の障害検出を改善することです。プロダクション環境でのアサーションの有効化は、動的分析(テストなど)中にアサーションを有効にすることとはまったく異なります。場合によっては、プロダクション環境でアサーションを有効にすることは非常に賢明ではありません(特に高整合性コンポーネントの場合)。プロダクション環境でアサーションを有効にすることには多くの議論があります。ライブラリは呼び出し元をクラッシュさせてはなりません。ライブラリが存在するとアプリストアによる拒否が発生する可能性があります。プロダクション環境でアサーションをアクティブにすると、秘密鍵などの秘密データが公開される可能性があります。NDEBUGを定義することが重要です。該当なし?動的コード分析で発見されたすべての中程度および重大度の悪用可能な脆弱性は、確認された後、適時に修正されなければなりません。動的コード分析を実行しておらず、この方法で脆弱性が見つからない場合は、「該当なし」(N/A)を選択してください。(CVSS)の基本的な定性的スコアが中以上の場合、脆弱性は中程度以上の重大度と見なされます。CVSSバージョン2.0から3.1では、これは4.0以上のCVSSスコアに相当します。Databaseなど)で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを使用して使用できます。代わりに、脆弱性が公表された後に計算入力が公開された場合、プロジェクトは脆弱性の開示時に最新バージョンのCVSSを使用して重大度を自ら計算することができます。+)のもとで利用できます。すべての人がデータを自由に共有および適応できますが、適切にクレジットを入れる必要があります。バッジ貢献者のクレジットを入れてください。こちらから問題を提出してください。利用条件を必ずお読みください。