EtherealEngine

本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、コアインフラストラクチャイニシアチブ（CII）バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。

ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。また、プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。しかし、ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。たとえば、いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。バッジを獲得するには、すべてのMUSTおよびMUST NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合のみ満たさなくても構いません。すべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮を払うことが望まれます。フィードバックは、 GitHubサイトのissueまたはpull requestとして提示されれば歓迎します。また、議論のためのメールリストも用意されています。

私たちは、いくつかの言語で情報を提供していますが、翻訳版に矛盾や意味の不一致があった場合、英語版を正式な記述とします。
これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください！バッジステータスは次のようになります。 プロジェクト 1453 のバッジ レベルは in_progress です バッジステータスの埋め込み方法は次のとおりです。
バッジステータスを表示するには、あなたのプロジェクトのマークダウンファイルに以下を埋め込みます
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/1453/badge)](https://bestpractices.coreinfrastructure.org/projects/1453)
あるいは、以下をHTMLに埋め込みます
<a href="https://bestpractices.coreinfrastructure.org/projects/1453"><img src="https://bestpractices.coreinfrastructure.org/projects/1453/badge"></a>


これらは合格レベルの基準です。シルバーまたはゴールドレベル基準を表示することもできます。



 基本的情報 6/12 ●

  • 識別情報

    他のプロジェクトが同じ名前を使用していないか注意してください。

    C++ Game Engine and Editor

    どのようなプログラミング言語を使ってプロジェクトを実装していますか？
    複数の言語がある場合は、コンマを区切り（スペースを入れてもよい）としてリストし、使用頻度の高いものから順に並べます。使用言語が多くある場合は、少なくとも最初の3つの最も多く使われるものをリストアップしてください。言語がない場合（例：ドキュメントだけ、またはテスト専用のプロジェクトの場合）、1文字 " - "を使用します。言語ごとにある大文字・小文字の慣用を踏襲してください（例：「JavaScript」）。
    Common Platform Enumeration（CPE）は、情報技術（IT）システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

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


    必須情報が不明、バッジに十分ではありません。

    プロジェクトのウェブサイトは、ソフトウェアが何をするのか（何の問題を解決するのか）を簡潔に記述しなければなりません。 [description_good]
    これは、潜在的なユーザーが理解できる言語でなければなりません（例えば、それは最小限の専門用語を使用します）。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトのウェブサイトは、取得方法、フィードバックの提供方法（バグ報告や拡張機能）、ソフトウェアへの貢献方法に関する情報を提供しなければなりません。 [interact]

    バッジには十分です！

    貢献する方法に関する情報は、貢献プロセス（たとえばプル リクエストが使用されか、など）を説明する必要があります。 (URLが必要です) [contribution]
    別段の記載がない限り、GitHub上のプロジェクトは、（GitHubが提供する）課題管理とプルリクエストを使用することを想定します。この情報は不足しているかもしれません。すなわち、プロジェクトがプルリクエストと課題追跡ツールを使うことか、メーリングリストへの投稿を言及している。（どちら？）

    Projects on GitHub by default use issues and pull requests, as encouraged by documentation such as https://guides.github.com/activities/contributing-to-open-source/.


    必須情報が不明、バッジに十分ではありません。

    貢献する方法に関する情報は、貢献を受け入れるための要件（たとえば、必要なコーディング標準への参照）を含むべきです。 (URLが必要です) [contribution_requirements]

  • FLOSSライセンス

    プロジェクトのライセンスはどのようなものですか？
    SPDXライセンスの表現形式を使用してください。 例：「Apache-2.0」、「BSD-2-Clause」、「BSD-3-Clause」、「GPL-2.0 +」、「LGPL-3.0 +」、「MIT」、「(BSD-2-Clause OR Ruby)」


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアは、FLOSSとしてリリースされなければなりません。 [floss_license]
    FLOSSは、オープンソース定義またはフリーソフトウェア定義を満たす方法でリリースされたソフトウェアです。そのようなライセンスの例としては、CC0、MIT、2項型BSD、 3項型BSD、 Apache 2.0 、Less GNU General Public License（LGPL）、および GNU General Public License（GPL）を参照してください。私たちの目的のためには、これはライセンスが以下のものでなければならないことを意味します： ソフトウェアは他の方法でライセンスされているかもしれません（たとえば、「GPLv2またはプロプライエタリ」は許容されます）。

    The BSD-2-Clause license is approved by the Open Source Initiative (OSI).


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアに必要なライセンスは、オープンソース・イニシアチブ（OSI）によって承認されていることが推奨されています。 [floss_license_osi]
    OSIは、厳格な承認プロセスを使用して、どのライセンスがOSSであるかを判断します。

    The BSD-2-Clause license is approved by the Open Source Initiative (OSI).


    バッジには十分です！

    プロジェクトは、結果のライセンスをソースリポジトリの標準的な場所に投稿しなければなりません。 (URLが必要です) [license_location]
    たとえば、LICENSEまたはCOPYINGという名前の最上位ファイルです。ライセンスファイル名の後に ".txt"や ".md"などの拡張子を付けることができます。

    Non-trivial license location file in repository: https://github.com/volcoma/EtherealEngine/blob/master/LICENSE.txt.


  • ドキュメンテーション


    バッジには不十分です。

    プロジェクトは、プロジェクトによって作成されたソフトウェアに関する基本的なドキュメンテーションを提供しなければなりません。 [documentation_basics]
    このドキュメントは、インストール方法、起動方法、使用方法（可能であれば例示したチュートリアル）、および、そのソフトウェアの適切なトピックであれば安全に使用する方法（たとえば何をするべきで、何をすべきでないか）を記述し、メディア（たとえば、テキストやビデオなど）に収められている必要があります。セキュリティの文書は必ずしも長文である必要はありません。プロジェクトは、ドキュメンテーションとしてプロジェクト以外の素材へのハイパーテキストリンクを使用してもよいです。プロジェクトがソフトウェアを作成しない場合は、「該当なし」（N / A）を選択します。

    // No appropriate folder found for documentation basics.


    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、プロジェクトによって作成されたソフトウェアの外部インタフェース（入力と出力の両方）を記述する参照ドキュメントを提供しなければなりません。 [documentation_interface]
    外部インターフェイスのドキュメントは、エンドユーザーまたは開発者に、その使用方法を説明します。ドキュメントには、ソフトウェアにアプリケーション プログラム インターフェイス（API）が含まれている場合、アプリケーション プログラム インターフェイスが含まれます。ライブラリの場合、呼び出すことができる主要なクラス/型とメソッド/関数を文書化します。ウェブ アプリケーションの場合、URLインタフェース（多くの場合、RESTインタフェース）を定義します。コマンドラインインターフェイスの場合は、サポートするパラメータとオプションを文書化します。多くの場合、ドキュメントのほとんどを自動生成すると、ソフトウェアが変更されたときにドキュメントがソフトウェアと同期したままなので、最も良い方法ですが、これは必須ではありません。プロジェクトは、ドキュメンテーションとしてプロジェクト以外の素材へのハイパーテキストリンクを使用してもよいです。ドキュメンテーションは自動的に生成されるかもしれません（実際的に、しばしばこれを行う最良の方法です）。 RESTインタフェースのドキュメントは、Swagger / OpenAPIを使用して生成することができます。コード インタフェースのドキュメントは、 JSDoc （JavaScript）、 ESDoc （JavaScript）、pydoc（Python）、およびDoxygen（多数）のいずれかです。実装コードにコメントがあるだけでは、この基準を満たすには不十分です。すべてのソースコードを読むことなく情報を見るための簡単な方法が必要です。プロジェクトがソフトウェアを作成しない場合は、「該当なし」（N / A）を選択します。

  • その他


    バッジには十分です！

    プロジェクトサイト（ウェブサイト、リポジトリ、およびダウンロードURL）は、TLSを使用したHTTPSをサポートしなければなりません。 [sites_https]
    暗号化しようからフリーの証明書を入手できます。プロジェクトは、（例えば） GitHubページ、 GitLabページ、またはSourceForgeプロジェクトページを使ってこの基準を実装してもよいです。カスタムドメインでGitHubページを使用している場合は、ブログの投稿「このファイルを安全かつ高速にGitHub Pages with CloudFlare」に記載されているように、HTTPSをサポートするプロキシとしてコンテンツ配信ネットワーク（CDN）を使用することができます。 HTTPをサポートしている場合は、HTTPトラフィックをHTTPSにリダイレクトすることを強くお勧めします。

    Given only https: URLs.


    バッジには十分です！

    プロジェクトは、議論（提案された変更や問題を含む）のための1つ以上の検索可能なメカニズムを持たなければならず、メッセージやトピックがURLでアドレス指定され、新しい人々がディスカッションのいくつかに参加できるようにしなければならず、クライアント側でプロプライエタリなソフトウェアのインストールを必要としないようにします。 [discussion]
    受け入れ可能なメカニズムの例には、アーカイブされたメーリングリスト、GitHubのイシューとプルリクエストの議論、Bugzilla、Mantis、Tracなどがあります。非同期ディスカッション メカニズム（IRCなど）は、これらの基準を満たしていれば許容されます。 URLアドレス可能なアーカイブ機構があることを確認してください。独自のJavaScriptは、推奨されませんが、許可されています。

    GitHub supports discussions on issues and pull requests.


    必須情報が不明、バッジに十分ではありません。

    プロジェクトは英語で文書を提供し、英語でコードに関するバグ報告とコメントを受け入れることができるべきです。 [english]
    現在、英語はコンピュータ技術のリンガ フランカです。英語をサポートすることで、世界中のさまざまな潜在的な開発者とレビュアーの数を増やします。コア開発者の主要言語が英語でなくても、プロジェクトはこの基準を満たすことができます。


（詳細）このバッジエントリを編集する権限を持つユーザーは？現在：[]
ほとんどのプロジェクトはこのフィールドを無視できます。プロジェクトのバッジエントリは、バッジエントリのオーナー（作成者）、BadgeApp管理者、GitHubリポジトリにコミットできる人（GitHub上にある場合）によっていつでも編集できます。他の人がこのバッジエントリを編集できるようにする必要があり、あなたがこのプロジェクトのバッジ エントリの編集権限をすでに持っている場合は、編集権限を持つ追加のユーザを追加することができます。 "+"と入力し、その後にカンマ区切りの整数ユーザーIDのリストを入力します。そうすることで、これらのユーザーも、このプロジェクト エントリを編集できるようになります。あなたがバッジ エントリのオーナーまたはBadgeApp管理者である場合は、 "-"と入力した後にカンマで区切られた整数ユーザーIDのリストを入力すれば、このリストからユーザーを削除できます。複数のユーザーが同時に編集しようとすると、このアプリケーションはオプティミスティック ロック機能を使用して古いデータを保存しないようにします。このフィールドは、このプロジェクト エントリのオーナーとBadgeApp管理者だけが変更できます。



 変更管理 3/9 ●

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


    バッジには十分です！

    プロジェクトには、公開され、URLを持つ、バージョン管理のソース リポジトリがなければなりません。 [repo_public]
    URLはプロジェクトのURLと同じであってもよいです。プロジェクトは、変更が公開されていない間に（例えば、公開前に脆弱性を修正するため）、特定のケースでプライベート（非公開）ブランチを使用することができます。

    Repository on GitHub, which provides public git repositories with URLs.


    バッジには十分です！

    プロジェクトのソース リポジトリは、どのような変更が行われたのか、誰が変更を行ったのか、いつ変更が行われたのかを追跡しなければなりません。 [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.


    必須情報が不明、バッジに十分ではありません。

    共同レビューを可能にするために、プロジェクトのソースリポジトリには、リリース間のレビューのための中間バージョンが含まれなければなりません。最終リリースのみを含めることはできません。 [repo_interim]
    プロジェクトは、公開ソース リポジトリから特定の暫定版を省略することを選択することができます。（たとえば、特定の非公開のセキュリティ脆弱性を修正するものは、公開されないか、または、合法的に投稿できないか、最終リリースに入らないです）

    バッジには十分です！

    プロジェクトのソース リポジトリに共通の分散バージョン管理ソフトウェア（gitなど）を使用することを推奨します。 [repo_distributed]
    Gitが特別に必要とされているわけでなく、プロジェクトでは、集中型バージョン管理ソフトウェア（例：subversion）を正当とする証拠を持って使用できます。

    Repository on GitHub, which uses git. git is distributed.


  • 一意的なバージョン番号


    必須情報が不明、バッジに十分ではありません。

    プロジェクトの結果には、ユーザーが使用することを意図されたリリースごとに固有のバージョン識別子が必要です。 [version_unique]
    これはコミットID（git commit idやmercurial changeset idなど）やバージョン番号（YYYYMMDDのようなセマンティックバージョニングや日付ベースのスキームを使用するバージョン番号を含む）など、さまざまな方法で対応できます。

    必須情報が不明、バッジに十分ではありません。

    リリースには Semantic Versioning（SemVer）形式を使用することを推奨します。 [version_semver]
    コミットID（git commit idやmercurial changeset idなど）やYYYYMMDDなどの日付ベースのスキームなどの他のバージョン番号付けスキームは、一意であるためバージョン番号として使用される場合があります。いくつかの選択肢は問題を引き起こす可能性があります。ユーザーは最新のものかどうかを簡単に判断できない可能性があるからです。 SemVerは、すべての受信者が最新のバージョンのみを実行している場合（たとえば、継続的な配信を介して常に更新されている単一のWebサイトまたはインターネットサービスのコード）ソフトウェアリリースを特定するのにはあまり役立ちません。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトがバージョン管理システム内の各リリースを特定することが推奨されています。たとえば、gitを使用しているユーザーがgitタグを使用して各リリースを特定することが推奨されています。 [version_tags]

  • リリースノート


    バッジには不十分です。

    プロジェクトは、各リリースにおいて、ユーザーがアップグレードすべきかどうか、また、アップグレードの影響を判断できるよう、そのリリースの主要な変更の要約を説明したリリースノートを提供しなければなりません（MUST）。リリースノートは、バージョン管理ログの生の出力であってはなりません（例えば、 "git log"コマンドの結果はリリースノートではない）。プロジェクトの成果物が複数の場所で再利用されることを意図していないプロジェクト（単独のウェブサイトやサービスのためのソフトウェアなど）で、かつ、継続的・断続的な配布を行う場合は、「該当なし」を選択することができます。 (URLが必要です) [release_notes]
    リリースノートは様々な方法で実装できます（MAY）。多くのプロジェクトは、 "NEWS"、 "CHANGELOG"、または "ChangeLog"という名前のファイルでそれらを提供し、 ".txt"、 ".md"、 ".html"などの拡張子を付けることもあります。歴史的には、 "change log"という言葉はすべての変更のログを意味していましたが、本基準を満たすために必要なものは、人間が読める要約です。リリースノートは代わりに、 GitHubリリースのワークフローなどのバージョン管理システムのメカニズムによって提供してもよい（MAY）。

    // No release notes file found.


    必須情報が不明、バッジに十分ではありません。

    リリースノートは、新しいリリースごとに修正された、既知の脆弱性をすべて特定しなければなりません。リリースノートがないか、または既知の脆弱性がない場合、これは 「該当なし」（N/A）です。 [release_notes_vulns]
    ユーザーが一般的にコンピュータ上でソフトウェアを実際に更新することができず、代わりに仲介者に依存してアップグレードを実行する必要がある場合（カーネル、およびカーネルと絡み合う低レベルのソフトウェアではよくあるケース）、プロジェクトは"非該当"（該当なし）。

 報告 0/8 ●

  • バグ報告プロセス


    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、ユーザーが不具合報告を送信するプロセスを提供しなければなりません（たとえば、課題トラッカーやメーリングリストを使用します）。 (URLが必要です) [report_process]

    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、個々の課題を追跡するための課題トラッカーを使用するべきです。 [report_tracker]

    必須情報が不明、バッジに十分ではありません。

    このプロジェクトは、過去2〜12か月間に提出された多数のバグ報告の受領を認めなければなりません。応答に修正を含める必要はありません。 [report_responses]

    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、直近2〜12ヶ月（2ヶ月を含む）に増強要求の多数（> 50％）に対応すべきです。 [enhancement_responses]
    応答は、「いいえ」や、そのメリットについての議論であってもよいです。目標は、単にプロジェクトがまだ生きていることを示している、いくつかの要求に対する応答があることです。この基準のために、プロジェクトは偽のリクエスト（スパマーや自動システムなど）をカウントする必要はありません。プロジェクトで機能強化が行われていない場合は、「満足されない」（unmet）を選択し、この状況をユーザーに明確にするURLを含めてください。プロジェクトが強化要求の数によって圧倒される傾向がある場合は、「満足されない」（unmet）を選択して説明してください。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、後で検索するために、レポートとレスポンスのアーカイブを公開する必要があります。 (URLが必要です) [report_archive]

  • 脆弱性報告プロセス


    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、脆弱性を報告するプロセスをプロジェクト サイトに公開しなければなりません。 (URLが必要です) [vulnerability_report_process]
    たとえば、https：// PROJECTSITE / securityの明示的に指定されたメール アドレスで、これはしばしばsecurity@example.orgの形式です。これはバグ報告プロセスと同じかもしれません。脆弱性レポートは常に公開される可能性がありますが、多くのプロジェクトでは、プライベート脆弱性を報告するメカニズムがあります。

    必須情報が不明、バッジに十分ではありません。

    プライベート脆弱性報告がサポートされている場合、プロジェクトは、プライベートに保持された方法で情報を送信する方法を含んでいなくてはなりません。 (URLが必要です) [vulnerability_report_private]
    例としては、HTTPS（TLS）を使用してWeb上に提出されたプライベート不具合報告や、OpenPGPを使用して暗号化された電子メールがあります。脆弱性報告が常に公開されている場合（プライベート脆弱性報告は存在しないため）、「該当なし」（N / A）を選択します。

    必須情報が不明、バッジに十分ではありません。

    過去6ヶ月間に受け取った脆弱性報告に対するプロジェクトの初期応答時間は、14日以下でなければなりません。 [vulnerability_report_response]
    過去6か月間に脆弱性が報告されていない場合は、「該当なし」（N/A）を選択します。

 品質 2/13 ●

  • 作業ビルドシステム


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアを利用するためにビルドが必要な場合、プロジェクトは、ソース コードからソフトウェアを自動的にリビルドできる作業ビルド システムを提供しなければなりません。 [build]
    ビルドシステムは、ソフトウェアをリビルドするのに必要なアクション（およびその順序）を決定し、それらのステップを実行します。たとえば、ビルドシステムは、ソースコードをコンパイルするためにコンパイラを呼び出すことができます。実行可能ファイルがソースコードから生成される場合、ビルドシステムは、プロジェクトのソースコードを変更でき、その変更を含む更新された実行ファイルを生成できなければなりません。プロジェクトによって生成されたソフトウェアが外部ライブラリに依存する場合、ビルドシステムはそれらの外部ライブラリをビルドする必要はありません。ソースコードが変更されても、ソフトウェアを使用するためにビルドする必要がない場合、「該当なし」（N/A）を選択します。

    Non-trivial build file in repository: https://github.com/volcoma/EtherealEngine/blob/master/CMakeLists.txt.


    バッジには十分です！

    ソフトウエアをビルドするために、一般的なツールを使用することをお勧めします。 [build_common_tools]
    たとえば、Maven、Ant、cmake、autotools、make、rakeなどです。

    Non-trivial build file in repository: https://github.com/volcoma/EtherealEngine/blob/master/CMakeLists.txt.


    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、FLOSSツールだけを使用してビルドができるようにするべきです。 [build_floss_tools]

  • 自動テスト スイート


    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、FLOSSとして公開されている少なくとも1つの自動化されたテスト スイートを使用しなければなりません（このテストスイートは、別のFLOSSプロジェクトとして維持することができます）。 [test]
    プロジェクトでは、複数の自動化されたテストスイートを使用することができます（たとえば、迅速に実行するもの、より完全であるが特別な装置が必要なもの）。

    必須情報が不明、バッジに十分ではありません。

    テスト スイートは、その言語の標準的な方法で呼び出すことができるべきです。 [test_invocation]
    たとえば、「make check」、「mvn test」、「rake test」などです。

    必須情報が不明、バッジに十分ではありません。

    テスト スイートは、コードブランチ、入力フィールド、および機能のほとんど（または理想的にはすべて）をカバーすることが推奨されています。 [test_most]

    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、継続的インテグレーション（新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動テストが実行される）を実装することを推奨されています。 [test_continuous_integration]

  • 新機能テスト


    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、プロジェクトで作成されたソフトウェアに主要な新機能が追加されたときに、その機能のテストを自動化されたテスト スイートに追加する必要があるという一般的な方針（正式でも、正式でなくても構いません）を持っていなければなりません。 [test_policy]
    開発者はテストを自動テスト スイートに追加して、新しい機能を追加する必要があるというポリシーが、口頭でも（文書化されていなくても）、存在する限り、「満たしている」を選択してください。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトによって作成されたソフトウェアの最新の大きな変更で、テストを追加するための test_policy が守られているという証拠がプロジェクトに存在しなければなりません。 [tests_are_added]
    主要な機能は、通常、リリースノートに記載されます。完璧は必要ないですが、プロジェクトによって生成されたソフトウェアに新しい主要機能が追加されたときに、自動テスト スイートに実際にテストが追加されているという証拠となります。

    必須情報が不明、バッジに十分ではありません。

    テストを追加するこのポリシー（test_policyを参照）を変更提案に関する手順で文書化することを推奨します。 [tests_documented_added]
    しかし、実際にテストが追加されている限り、非公式の規則でも許容されます。

  • 警告フラグ


    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、選択した言語でこの基準を実装することができる少なくとも1つのFLOSSツールがあれば、1つまたは複数のコンパイラ警告フラグ、「安全」言語モードを使用可能にするか、分離 「リンター」ツールを使用してコード品質エラーまたは共通の単純なミスを検索しなければなりません。 [warnings]
    コンパイラ警告フラグの例には、gcc / clang "-Wall"があります。 「安全」言語モードの例には、JavaScript「use strict」とperl5の「use warnings」があります。分離「リンター」ツールは、ソースコードを調べてコード品質のエラーや一般的な単純なミスを探すツールです。これらは、通常、ソースコードまたはビルド命令内で有効になります。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトは警告を出さなければならない。 [warnings_fixed]
    これらは、警告基準の実装によって識別される警告です。プロジェクトは、警告を修正するか、ソースコード内で警告を誤検出としてマークするべきです。理想的には警告がないことがいいですが、プロジェクトはある程度の警告（通常100行あたり1警告未満または10警告未満）を受け入れることができます。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトによって作成されたソフトウェアにある警告に、実際的な場合には、最大限に厳格になることを推奨されています。 [warnings_strict]
    一部の警告は、あるプロジェクトでは効果的に有効にすることはできません。必要なのは、プロジェクトが可能な限り警告フラグを有効にするように努力しており、エラーが早期に検出されるという証拠です。

 セキュリティ 0/16 ●

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


    必須情報が不明、バッジに十分ではありません。

    プロジェクトには、セキュアなソフトウェアを設計する方法を知っている少なくとも1人の主要開発者がいなければなりません。 [know_secure_design]
    これには、 Saltzer and Schroeder の8つの原則を含む以下の設計原則を理解する必要があります。
    • メカニズムの経済性（たとえば、スイーピング シンプリフィケーションを採用して、メカニズムを実際的に単純化し小さくする）
    • フェイルセーフのデフォルト（アクセスの決定はデフォルトで拒否されるべきであり、プロジェクトのインストールはデフォルトで安全でなければならない）
    • 完全なメディエーション（制限されたすべてのアクセスは権限がチェックされ、バイパスされない）
    • オープンな設計（セキュリティメカニズムは攻撃者の設計に対する無知に依存するべきではなく、 簡単に保護ができて変更ができる鍵やパスワードのような情報に依存すべきです。
    • 特権の分離（理想的には、重要なオブジェクトへのアクセスは複数の条件に依存すべきで、1つの保護システムを破ることで完全なアクセスが可能にならないようにします。たとえば、パスワードとハードウェア トークンを必要とする多因子認証は単因子認証より強いです。
    • 最低限の権限（プロセスは最低限の権限で動作する必要がある）
    • 最低限の共通メカニズム（設計は、複数のユーザに共通のメカニズムや全てのユーザーに依存するメカニズムを最小限に抑えるべきです。）
    • 心理学的受容性（ヒューマンインタフェースは、使いやすく設計されていなければならない - 「驚きが最小限になる」という設計が助けになる）
    • 限られた攻撃面（攻撃面 - 攻撃者がデータを入力または抽出しようとする部分 - を制限する必要があります）
    • ホワイト リストで入力を検証します（入力は通常、この検証はブラックリスト（既知の不良値をリストする）ではなく、ホワイトリスト（既知の値のみを受け入れる）を使用する必要があります。
    プロジェクトの「主要な開発者」とは、プロジェクトのコードベースに精通していて、容易に変更を加えることができ、プロジェクトの他のほとんどの参加者によって認められている人です。主要な開発者は、通常、過去1年間に（コード、文書、または質問に回答して）多数の貢献を行います。ある開発者が、プロジェクトを開始している（3年以上プロジェクトから離れていない）、プライベート脆弱性報告チャネル（存在する場合）に関する情報を受け取る、プロジェクトを代表してコミットを受け入れる、最終リリースする、などを行う時主要な開発者とみなすことができます。開発者が1人だけの場合、その人物が主要開発者です。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトの主要開発者の少なくとも1人は、この種のソフトウェアの脆弱性につながる一般的な種類のエラーを知っていなければならず、それぞれを対策または緩和する少なくとも1つの方法を知っていなければなりません。 [know_common_errors]
    例としては、（ソフトウェアのタイプに依存しますが）SQLインジェクション、OSインジェクション、古典的なバッファ オーバーフロー、クロスサイト スクリプティング、認証欠落、権限欠落などがあります。 CWE / SANSトップ25 または OWASP Top 10 を参照してください。

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

    一部のソフトウェアでは、暗号化メカニズムを使用する必要はありません。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトによって作成されたソフトウェアは、デフォルトで、一般に公開され、専門家によってレビューされている暗号プロトコルとアルゴリズムを使用しなければなりません。（暗号プロトコルとアルゴリズムが使用される場合） [crypto_published]
    ソフトウェアによっては暗号機能を直接使用する必要がないため、これらの暗号基準は常に適用されるわけではありません。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトによって作成されたソフトウェアがアプリケーションまたはライブラリであり、主な目的が暗号の実装でない場合、暗号機能を実装するために特別に設計されたソフトウェアを呼び出すだけにするべきです。自分用に（暗号機能を）再実装するべきではありません。 [crypto_call]

    必須情報が不明、バッジに十分ではありません。

    暗号に依存するプロジェクトによって作成されるソフトウェアのすべての機能は、FLOSSを使用して実装可能でなければなりません。 [crypto_floss]
    オープン ソース イニシアチブによるオープン スタンダード要件を参照して下さい。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトによって作成されたソフトウェア内にあるセキュリティ メカニズムは、少なくとも、2030年までのNIST最小要件（2012年）を満たすデフォルト鍵長を使用しなければなりません。より小さな鍵長を完全に無効になるおうに、ソフトウェアを構成できなければなりません。 [crypto_keylength]
    これらの最小ビット長は、対称鍵112、ファクタリング係数2018、離散対数鍵224、離散対数群2048、楕円曲線224、ハッシュ224（パスワードハッシュはこのビット長でカバーされません。パスワードハッシュに関する詳しい情報は crypto_password_storage 基準にあります）です。 http://www.keylength.comにさまざまな機関が出している推奨鍵長の比較を参照して下さい。ソフトウェアは、 いくつかの構成ではより短い鍵長を許可するかもしれません。（これはダウングレード攻撃を許すので、理想的には正しくありません。しかし、短い鍵長は、相互運用性のために時に必要となります。）

    必須情報が不明、バッジに十分ではありません。

    プロジェクトで作成したソフトウェア内のデフォルトのセキュリティ メカニズムは、破られた暗号アルゴリズム（たとえば、MD4、MD5、single DES、RC4、Dual_EC_DRBGなど）に依存してはいけませんし、コンテキストに不適切な暗号モード(たとえば、ECBモードは、ECB penguinで明らかにされているように暗号文の中に同じブロックが存在するので、ほとんどの場合不適切です。CTRモードは、入力状態が繰り返されると、認証を実行せず重複が起こすので多くの場合不適切です。)を使用してもいけません。 [crypto_working]
    多くの場合、Galois/Counter Mode (GCM)やEAXなど、秘密と認証を組み合わせて設計されたブロック暗号アルゴリズムを選択するのが最善です。プロジェクトは、互換性の必要から破られたメカニズムを有効にするかもしれませんが、ユーザーはそれをしていることを認識しています。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトによって作成されたソフトウェア内のデフォルトのセキュリティ メカニズムは、既知の重大な脆弱性を持つ暗号アルゴリズムやモード（たとえば、SHA-1暗号ハッシュ アルゴリズムまたはSSHのCBC モード）に依存するべきではありません。 [crypto_weaknesses]
    SSHのCBCモードに関する懸念事項は、 CERT: SSH CBC 脆弱性にて議論されています。.

    必須情報が不明、バッジに十分ではありません。

    プロジェクトによって作成されたソフトウェア内のセキュリティ メカニズムは、鍵合意プロトコルのための完全な順方向秘密を実装するべきなので、もし長期鍵が将来侵害された場合でも、長期鍵のセットから導出されるセッション鍵は侵害されません。 [crypto_pfs]

    必須情報が不明、バッジに十分ではありません。

    プロジェクトによって生成されたソフトウェアが外部ユーザーの認証に使われるパスワードの保存をする場合、パスワードは、鍵ストレッチ（反復）アルゴリズム（PBKDF2、BcryptまたはScryptなど）を使い、ユーザーごとの塩（乱数）を用いて反復ハッシュとして保存しなければなりません。 [crypto_password_storage]
    この基準は、サーバー側ウェブ アプリケーションなどのソフトウェアが、パスワードを使用してユーザー認証を行う場合のみに適用されます。ソフトウェアが他のシステムに認証のためのパスワードを保存するような場合（たとえばソフトウェアが他のシステムのクライアントを実現する場合）、少なくともそのソフトウェアの一部がハッシュされていないパスワードに頻繁にアクセスする必要があるため、この基準は適用されません。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトによって作成されたソフトウェア内のセキュリティ メカニズムは、暗号学的にセキュアな乱数発生器を使用して、すべての暗号鍵とナンスを生成しなければなりません。暗号学的にセキュアでない発生器を使用してはいけません。 [crypto_random]
    暗号学的にセキュアな乱数発生器は、ハードウェアの乱数発生器でも、Hash_DRBG、HMAC_DRBG、 CTR_DRBG、Yarrow、 Fortuna.などのアルゴリズムを使用する暗号学的にセキュアな疑似乱数発生器（CSPRNG）でもよいです。セキュアでない乱数発生器には、Javaのjava.util.RandomとJavaScriptのMath.randomがあります。

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


    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、MITM攻撃に対抗する配信メカニズムを使用しなければならない。httpsまたはssh+scpを使用することは許容されます。 [delivery_mitm]
    さらに強力な仕組みは、デジタル署名されたパッケージでソフトウェアをリリースすることです。配布システムへの攻撃を緩和するからです。しかし、これは、署名の公開鍵が正当なものであることをユーザーが確信でき、かつユーザーが実際に署名をチェックする場合にのみ有効です。

    必須情報が不明、バッジに十分ではありません。

    暗号ハッシュ（たとえばSHA1SUM）は、http経由で運んではならず、暗号署名をチェックすることなしに使用してはいけません。 [delivery_unsigned]
    これらのハッシュは、送信中に変更することができます。

  • 広く知られた脆弱性を修正


    必須情報が不明、バッジに十分ではありません。

    60日を超えて公的に知られている中程度または重大度のパッチされていない脆弱性は存在してはなりません。 [vulnerabilities_fixed_60_days]
    脆弱性は、プロジェクト自体によってパッチされ、リリースされなければなりません（パッチは他の場所で開発される可能性があります）。脆弱性が無料情報と共にCVE（共通脆弱性識別子）を持つとき（例えば、 National Vulnerability Database ）、またはプロジェクトに情報が伝えられ、その情報が（おそらくプロジェクトによって）一般に公開されたとき、脆弱性は一般に知られるようになります。 CVSS 2.0 の基本スコアが4以上の場合、脆弱性は中〜高程度です。 注：これは、世界中のすべての攻撃者にユーザーが60日間まで脆弱である可能性があることを意味します。この基準は、責任のある開示の再開でGoogleが推奨するものよりも、しばしば満たすことが容易です。なぜなら、レポートが公開されていないときでも、プロジェクトに通知されてから60日間の期間が開始されるからです。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、すべての重要な脆弱性を、報告された後迅速に修正するべきです。 [vulnerabilities_critical_fixed]

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


    必須情報が不明、バッジに十分ではありません。

    公開リポジトリは、パブリックアクセスを制限するための有効なプライベートクレデンシャル（たとえば、有効なパスワードやプライベートキー）を漏らしてはなりません。 [no_leaked_credentials]
    プロジェクトは、パブリック アクセスを制限する意図がない限り、テスト用や重要でないデータベース用の「サンプル」資格情報を漏らす可能性があります。

 分析 0/8 ●

  • 静的コード解析


    必須情報が不明、バッジに十分ではありません。

    選択した言語でこの基準を実装している少なくとも1つのFLOSSツールがある場合、少なくとも1つの静的コード解析ツールを、リリース前にソフトウェアの主要な製品リリースに適用する必要があります。 [static_analysis]
    静的コード解析ツールは、ソフトウェアコードを実行せずに特定の入力を用いて（ソースコード、中間コード、または実行可能ファイルとして）調べます。この基準のために、コンパイラの警告と「安全な」言語モードは、静的コード解析ツールとしてカウントされません（これらは通常、速度が重要なため深い解析を行いません）。このような静的コード解析ツールの例には、 cppcheck 、 clang静的解析、 FindBugs （FindSecurityBugsを含む）、 PMD 、 Brakeman 、 Coverity Quality Analyzer 、および HPE Fortify静的コード解析。大きなツールのリストは、静的コード解析のためのWikipediaツール一覧、静的コード解析に関するOWASP情報、 NISTソースコードセキュリティアナライザのリスト、ウィーラーの静的解析ツール一覧。 SWAMPは、さまざまなツールを使用してソフトウェアの脆弱性を評価する無償のプラットフォームです。使用する実装言語で使用できるFLOSS静的解析ツールがない場合は、「該当なし」（N/A）を選択します。

    必須情報が不明、バッジに十分ではありません。

    static_analysis基準に使用される静的解析ツールの少なくとも1つが、分析された言語または環境における共通の脆弱性を探すためのルールまたはアプローチを含むことが、推奨されています。 [static_analysis_common_vulnerabilities]
    一般的な脆弱性を探すために特別に設計された静的解析ツールは、それらを見つける可能性が高いです。つまり、静的ツールを使用すると、通常は問題を見つけるのに役立ちますので、利用を提案しますが、「合格」レベルのバッジには要求しません。

    必須情報が不明、バッジに十分ではありません。

    静的コード解析で発見された中程度および重大度の悪用可能な脆弱性はすべて、それらが確認された後、適時に修正されなくてはなりません。 [static_analysis_fixed]
    CVSS 2.0 が4以上の場合、脆弱性は中〜高程度です。

    必須情報が不明、バッジに十分ではありません。

    静的ソースコード解析は、コミットごと、または少なくとも毎日実行することをお勧めします。 [static_analysis_often]

  • 動的コード分析


    必須情報が不明、バッジに十分ではありません。

    リリース前に、ソフトウェアの主要な製品リリースに少なくとも1つの動的解析ツールを適用することが示唆されています。 [dynamic_analysis]
    動的解析ツールは、ソフトウェアを特定の入力で実行して検査します。たとえば、プロジェクトは、ファジングツール（アメリカンファジーロップなど）やウェブ アプリケーション スキャナ（例： OWASP ZAP または w3af ）です。場合によっては、 OSS-Fuzz プロジェクトがプロジェクトにファズテストを適用する可能性があります。この基準のために、動的分析ツールは、様々な種類の問題を探すために何らかの方法で入力を変更するかまたは少なくとも80％のブランチ カバレッジを持つ自動テスト スイートである必要があります。 動的解析に関するWikipediaのページと ファジングに関するOWASPページで、いくつかの動的解析ツールを特定しています。解析ツールは、セキュリティの脆弱性を探すことに重点を置くことができますが、これは必須ではありません。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトで作成されたソフトウェアにメモリ安全でない言語（CやC ++など）を使用して作成されたソフトウェアが含まれている場合、少なくとも1つの動的ツール（たとえば、ファジーまたはウェブ アプリケーション スキャナ）を、バッファの上書きなどのメモリの安全性の問題を検出するメカニズムと一緒にいつも使用します。プロジェクトがメモリ安全でない言語で書かれたソフトウェアを作成しない場合は、「該当なし」（N/A）を選択します。 [dynamic_analysis_unsafe]
    メモリの安全性の問題を検出するメカニズムの例としては、アドレスサニタイザー（ASAN）（GCCおよびLLVMで利用可能）、 Memory Sanitizer 、および valgrind が含まれます。他に使用される可能性のあるツールには、スレッドサニタイザと定義されていない動作サニタイザを参照してください。広範なアサーションも機能します。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトによって作成されたソフトウェアには、動的解析中にチェックされる多くの実行時アサーションが含まれていることが推奨されます。 [dynamic_analysis_enable_assertions]

    必須情報が不明、バッジに十分ではありません。

    動的コード分析で発見されたすべての中程度および重大度の悪用可能な脆弱性は、確認された後、適時に修正されなければなりません。 [dynamic_analysis_fixed]
    CVSS 2.0 ベース スコアが4の場合、脆弱性は中〜高程度です。動的コード分析を実行していないため、このように脆弱性を発見していない場合は、「該当なし」（N / A）を選択します。


プロジェクトに関するこのデータを送信することにより、少なくとも、クリエイティブ・コモンズ帰属バージョン3.0以降（CC-BY-3.0 +）のライセンス条件によって公開することに同意したことになります。つまり、すべての人が自由にデータを共有し、修正することができますが、適切なクレディットを表示します。あなたが保有する著作権に影響はありません。プロジェクトライセンスにも影響はありません。

プロジェクト バッジ登録の所有者： -.
エントリの作成日時 2017-12-09 08:57:35 UTC、 最終更新日 2017-12-09 08:57:35 UTC

もどる