本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、コアインフラストラクチャイニシアチブ(CII)バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。詳細ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合のみ満たさなくても構いません。すべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮を払うことが望まれます。requestとして提示されれば歓迎します。議論のためのメールリストも用意されています。私たちは、いくつかの言語で情報を提供していますが、翻訳版に矛盾や意味の不一致があった場合、英語版を正式な記述とします。これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください!バッジステータスは次のようになります。バッジステータスの埋め込み方法は次のとおりです。レベル基準を表示することもできます。他のプロジェクトが同じ名前を使用していないか注意してください。プロジェクトを簡単に説明してください。HMI.プロジェクト全体のURLは?https://github.com/ross-newman/vivoe-liteバージョン管理リポジトリのURLは何ですか(プロジェクトURLと同じでもかまいません)。複数の言語がある場合は、コンマを区切り(スペースを入れてもよい)としてリストし、使用頻度の高いものから順に並べます。使用言語が多くある場合は、少なくとも最初の3つの最も多く使われるものをリストアップしてください。言語ごとにある大文字・小文字の慣用を踏襲してください(例:「JavaScript」)。Enumeration(CPE)は、情報技術(IT)システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。満足しない?プロジェクトのウェブサイトは、ソフトウェアが何をするのか(何の問題を解決するのか)を簡潔に記述しなければなりません。[description_good]詳細これは、潜在的なユーザーが理解できる言語でなければなりません(例えば、それは最小限の専門用語を使用します)。満足しない?プロジェクトのウェブサイトは、取得方法、フィードバックの提供方法(バグ報告や拡張機能)、ソフトウェアへの貢献方法に関する情報を提供しなければなりません。リクエストが使用されか、など)を説明する必要があります。別段の記載がない限り、GitHub上のプロジェクトは、(GitHubが提供する)課題管理とプルリクエストを使用することを想定します。この情報は不足しているかもしれません。プロジェクトがプルリクエストと課題追跡ツールを使うことか、メーリングリストへの投稿を言及している。満足しない?貢献する方法に関する情報は、貢献を受け入れるための要件(たとえば、必要なコーディング標準への参照)を含むべきです。[contribution_requirements]https://github.com/ross-newman/vivoe-lite/blob/master/docs/DEVELOPER.mdFLOSSライセンスプロジェクトのライセンスはどのようなものですか?詳細SPDXライセンスの表現形式を使用してください。満足しない?プロジェクトによって作成されたソフトウェアは、FLOSSとしてリリースされなければなりません。[floss_license]詳細FLOSSは、オープンソース定義またはフリーソフトウェア定義を満たす方法でリリースされたソフトウェアです。License(GPL)を参照してください。ライセンス、またはFedoraによって「良い」ライセンス.ソフトウェアは他の方法でライセンスされているかもしれません(たとえば、「GPLv2またはプロプライエタリ」は許容されます)。満足しない?プロジェクトによって作成されたソフトウェアに必要なライセンスは、オープンソース・イニシアチブ(OSI)によって承認されていることが推奨されています。[floss_license_osi]詳細OSIは、厳格な承認プロセスを使用して、どのライセンスがOSSであるかを判断します。満足しない?プロジェクトは、結果のライセンスをソースリポジトリの標準的な場所に投稿しなければなりません。[license_location]詳細たとえば、LICENSEまたはCOPYINGという名前の最上位ファイルです。".md"などの拡張子を付けることができます。満足しない該当なし?プロジェクトは、プロジェクトによって作成されたソフトウェアに関する基本的なドキュメンテーションを提供しなければなりません。(可能であれば例示したチュートリアル)、および、そのソフトウェアの適切なトピックであれば安全に使用する方法(たとえば何をするべきで、何をすべきでないか)を記述し、メディア(たとえば、テキストやビデオなど)に収められている必要があります。セキュリティの文書は必ずしも長文である必要はありません。プロジェクトは、ドキュメンテーションとしてプロジェクト以外の素材へのハイパーテキストリンクを使用してもよいです。満足しない該当なし?プロジェクトは、プロジェクトによって作成されたソフトウェアの外部インタフェース(入力と出力の両方)を記述する参照ドキュメントを提供しなければなりません。外部インターフェイスのドキュメントは、エンドユーザーまたは開発者に、その使用方法を説明します。インターフェイスが含まれます。ライブラリの場合、呼び出すことができる主要なクラス/型とメソッド/関数を文書化します。アプリケーションの場合、URLインタフェース(多くの場合、RESTインタフェース)を定義します。コマンドラインインターフェイスの場合は、サポートするパラメータとオプションを文書化します。多くの場合、ドキュメントのほとんどを自動生成すると、ソフトウェアが変更されたときにドキュメントがソフトウェアと同期したままなので、最も良い方法ですが、これは必須ではありません。プロジェクトは、ドキュメンテーションとしてプロジェクト以外の素材へのハイパーテキストリンクを使用してもよいです。ドキュメンテーションは自動的に生成されるかもしれません(実際的に、しばしばこれを行う最良の方法です)。OpenAPIを使用して生成することができます。(JavaScript)、pydoc(Python)、およびDoxygen(多数)のいずれかです。実装コードにコメントがあるだけでは、この基準を満たすには不十分です。すべてのソースコードを読むことなく情報を見るための簡単な方法が必要です。満足しない?プロジェクトサイト(ウェブサイト、リポジトリ、およびダウンロードURL)は、TLSを使用したHTTPSをサポートしなければなりません。暗号化しようからフリーの証明書を入手できます。GitLabページ、またはSourceForgeプロジェクトページを使ってこの基準を実装してもよいです。CloudFlare」に記載されているように、HTTPSをサポートするプロキシとしてコンテンツ配信ネットワーク(CDN)を使用することができます。HTTPをサポートしている場合は、HTTPトラフィックをHTTPSにリダイレクトすることを強くお勧めします。満足しない?プロジェクトは、議論(提案された変更や問題を含む)のための1つ以上の検索可能なメカニズムを持たなければならず、メッセージやトピックがURLでアドレス指定され、新しい人々がディスカッションのいくつかに参加できるようにしなければならず、クライアント側でプロプライエタリなソフトウェアのインストールを必要としないようにします。受け入れ可能なメカニズムの例には、アーカイブされたメーリングリスト、GitHubのイシューとプルリクエストの議論、Bugzilla、Mantis、Tracなどがあります。メカニズム(IRCなど)は、これらの基準を満たしていれば許容されます。URLアドレス可能なアーカイブ機構があることを確認してください。独自のJavaScriptは、推奨されませんが、許可されています。満足しない?プロジェクトは英語で文書を提供し、英語でコードに関するバグ報告とコメントを受け入れることができるべきです。英語をサポートすることで、世界中のさまざまな潜在的な開発者とレビュアーの数を増やします。コア開発者の主要言語が英語でなくても、プロジェクトはこの基準を満たすことができます。https://github.com/ross-newman/vivoe-lite/issues(詳細)非アクティブリマインダを無効にします(このままにしておくことをお勧めします)(詳細)このバッジエントリを編集する権限を持つユーザーは?現在:[]詳細ほとんどのプロジェクトはこのフィールドを無視できます。プロジェクトのバッジエントリは、バッジエントリのオーナー(作成者)、BadgeApp管理者、GitHubリポジトリにコミットできる人(GitHub上にある場合)によっていつでも編集できます。エントリの編集権限をすでに持っている場合は、編集権限を持つ追加のユーザを追加することができます。"+"と入力し、その後にカンマ区切りの整数ユーザーIDのリストを入力します。エントリを編集できるようになります。"-"と入力した後にカンマで区切られた整数ユーザーIDのリストを入力すれば、このリストからユーザーを削除できます。ロック機能を使用して古いデータを保存しないようにします。エントリのオーナーとBadgeApp管理者だけが変更できます。リポジトリがなければなりません。[repo_public]詳細URLはプロジェクトのURLと同じであってもよいです。プロジェクトは、変更が公開されていない間に(例えば、公開前に脆弱性を修正するため)、特定のケースでプライベート(非公開)ブランチを使用することができます。リポジトリは、どのような変更が行われたのか、誰が変更を行ったのか、いつ変更が行われたのかを追跡しなければなりません。満足しない?共同レビューを可能にするために、プロジェクトのソースリポジトリには、リリース間のレビューのための中間バージョンが含まれなければなりません。最終リリースのみを含めることはできません。リポジトリから特定の暫定版を省略することを選択することができます。リポジトリに共通の分散バージョン管理ソフトウェア(gitなど)を使用することを推奨します。[repo_distributed]詳細Gitが特別に必要とされているわけでなく、プロジェクトでは、集中型バージョン管理ソフトウェア(例:subversion)を正当とする証拠を持って使用できます。満足しない?プロジェクトの結果には、ユーザーが使用することを意図されたリリースごとに固有のバージョン識別子が必要です。idなど)やバージョン番号(YYYYMMDDのようなセマンティックバージョニングや日付ベースのスキームを使用するバージョン番号を含む)など、さまざまな方法で対応できます。Versioning(SemVer)形式を使用することを推奨します。idなど)やYYYYMMDDなどの日付ベースのスキームなどの他のバージョン番号付けスキームは、一意であるためバージョン番号として使用される場合があります。いくつかの選択肢は問題を引き起こす可能性があります。ユーザーは最新のものかどうかを簡単に判断できない可能性があるからです。SemVerは、すべての受信者が最新のバージョンのみを実行している場合(たとえば、継続的な配信を介して常に更新されている単一のWebサイトまたはインターネットサービスのコード)ソフトウェアリリースを特定するのにはあまり役立ちません。満足しない?プロジェクトがバージョン管理システム内の各リリースを特定することが推奨されています。gitを使用しているユーザーがgitタグを使用して各リリースを特定することが推奨されています。満足しない該当なし?プロジェクトは、各リリースにおいて、ユーザーがアップグレードすべきかどうか、また、アップグレードの影響を判断できるよう、そのリリースの主要な変更の要約を説明したリリースノートを提供しなければなりません(MUST)。log"コマンドの結果はリリースノートではない)。プロジェクトの成果物が複数の場所で再利用されることを意図していないプロジェクト(単独のウェブサイトやサービスのためのソフトウェアなど)で、かつ、継続的・断続的な配布を行う場合は、「該当なし」を選択することができます。[release_notes]詳細リリースノートは様々な方法で実装できます(MAY)。".html"などの拡張子を付けることもあります。log"という言葉はすべての変更のログを意味していましたが、本基準を満たすために必要なものは、人間が読める要約です。GitHubリリースのワークフローなどのバージョン管理システムのメカニズムによって提供してもよい(MAY)。満足しない該当なし?リリースノートは、新しいリリースごとに修正された、既知の脆弱性をすべて特定しなければなりません。「該当なし」(N/A)です。[release_notes_vulns]詳細ユーザーが一般的にコンピュータ上でソフトウェアを実際に更新することができず、代わりに仲介者に依存してアップグレードを実行する必要がある場合(カーネル、およびカーネルと絡み合う低レベルのソフトウェアではよくあるケース)、プロジェクトは"非該当"(該当なし)。満足しない?プロジェクトは、ユーザーが不具合報告を送信するプロセスを提供しなければなりません(たとえば、課題トラッカーやメーリングリストを使用します)。満足しない?プロジェクトは、個々の課題を追跡するための課題トラッカーを使用するべきです。満足しない?このプロジェクトは、過去2〜12か月間に提出された多数のバグ報告の受領を認めなければなりません。応答に修正を含める必要はありません。50%)に対応すべきです。応答は、「いいえ」や、そのメリットについての議論であってもよいです。目標は、単にプロジェクトがまだ生きていることを示している、いくつかの要求に対する応答があることです。この基準のために、プロジェクトは偽のリクエスト(スパマーや自動システムなど)をカウントする必要はありません。プロジェクトで機能強化が行われていない場合は、「満足されない」(unmet)を選択し、この状況をユーザーに明確にするURLを含めてください。プロジェクトが強化要求の数によって圧倒される傾向がある場合は、「満足されない」(unmet)を選択して説明してください。満足しない?プロジェクトは、後で検索するために、レポートとレスポンスのアーカイブを公開する必要があります。サイトに公開しなければなりません。アドレスで、これはしばしばsecurity@example.orgの形式です。これはバグ報告プロセスと同じかもしれません。脆弱性レポートは常に公開される可能性がありますが、多くのプロジェクトでは、プライベート脆弱性を報告するメカニズムがあります。満足しない該当なし?プライベート脆弱性報告がサポートされている場合、プロジェクトは、プライベートに保持された方法で情報を送信する方法を含んでいなくてはなりません。例としては、HTTPS(TLS)を使用してWeb上に提出されたプライベート不具合報告や、OpenPGPを使用して暗号化された電子メールがあります。満足しない該当なし?過去6ヶ月間に受け取った脆弱性報告に対するプロジェクトの初期応答時間は、14日以下でなければなりません。過去6か月間に脆弱性が報告されていない場合は、「該当なし」(N/A)を選択します。システムを提供しなければなりません。[build]詳細ビルドシステムは、ソフトウェアをリビルドするのに必要なアクション(およびその順序)を決定し、それらのステップを実行します。ビルドシステムは、ソースコードをコンパイルするためにコンパイラを呼び出すことができます。実行可能ファイルがソースコードから生成される場合、ビルドシステムは、プロジェクトのソースコードを変更でき、その変更を含む更新された実行ファイルを生成できなければなりません。プロジェクトによって生成されたソフトウェアが外部ライブラリに依存する場合、ビルドシステムはそれらの外部ライブラリをビルドする必要はありません。ソースコードが変更されても、ソフトウェアを使用するためにビルドする必要がない場合、「該当なし」(N/A)を選択します。満足しない該当なし?ソフトウエアをビルドするために、一般的なツールを使用することをお勧めします。[build_common_tools]詳細たとえば、Maven、Ant、cmake、autotools、make、rakeなどです。満足しない該当なし?プロジェクトは、FLOSSツールだけを使用してビルドができるようにするべきです。スイートを使用しなければなりません(このテストスイートは、別のFLOSSプロジェクトとして維持することができます)。[test]詳細プロジェクトでは、複数の自動化されたテストスイートを使用することができます(たとえば、迅速に実行するもの、より完全であるが特別な装置が必要なもの)。スイートは、その言語の標準的な方法で呼び出すことができるべきです。スイートは、コードブランチ、入力フィールド、および機能のほとんど(または理想的にはすべて)をカバーすることが推奨されています。満足しない?プロジェクトは、継続的インテグレーション(新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動テストが実行される)を実装することを推奨されています。スイートに追加する必要があるという一般的な方針(正式でも、正式でなくても構いません)を持っていなければなりません。スイートに追加して、新しい機能を追加する必要があるというポリシーが、口頭でも(文書化されていなくても)、存在する限り、「満たしている」を選択してください。守られているという証拠がプロジェクトに存在しなければなりません。主要な機能は、通常、リリースノートに記載されます。スイートに実際にテストが追加されているという証拠となります。満足しない?テストを追加するこのポリシー(test_policyを参照)を変更提案に関する手順で文書化することを推奨します。[tests_documented_added]詳細しかし、実際にテストが追加されている限り、非公式の規則でも許容されます。「リンター」ツールを使用してコード品質エラーまたは共通の単純なミスを検索しなければなりません。"-Wall"があります。warnings」があります。分離「リンター」ツールは、ソースコードを調べてコード品質のエラーや一般的な単純なミスを探すツールです。これらは、通常、ソースコードまたはビルド命令内で有効になります。満足しない該当なし?プロジェクトは警告を出さなければならない。[warnings_fixed]詳細これらは、警告基準の実装によって識別される警告です。プロジェクトは、警告を修正するか、ソースコード内で警告を誤検出としてマークするべきです。理想的には警告がないことがいいですが、プロジェクトはある程度の警告(通常100行あたり1警告未満または10警告未満)を受け入れることができます。満足しない該当なし?プロジェクトによって作成されたソフトウェアにある警告に、実際的な場合には、最大限に厳格になることを推奨されています。一部の警告は、あるプロジェクトでは効果的に有効にすることはできません。必要なのは、プロジェクトが可能な限り警告フラグを有効にするように努力しており、エラーが早期に検出されるという証拠です。満足しない?プロジェクトには、セキュアなソフトウェアを設計する方法を知っている少なくとも1人の主要開発者がいなければなりません。8つの原則を含む以下の設計原則を理解する必要があります。簡単に保護ができて変更ができる鍵やパスワードのような情報に依存すべきです。特権の分離(理想的には、重要なオブジェクトへのアクセスは複数の条件に依存すべきで、1つの保護システムを破ることで完全なアクセスが可能にならないようにします。トークンを必要とする多因子認証は単因子認証より強いです。最低限の権限(プロセスは最低限の権限で動作する必要がある)最低限の共通メカニズム(設計は、複数のユーザに共通のメカニズムや全てのユーザーに依存するメカニズムを最小限に抑えるべきです。リストで入力を検証します(入力は通常、この検証はブラックリスト(既知の不良値をリストする)ではなく、ホワイトリスト(既知の値のみを受け入れる)を使用する必要があります。プロジェクトの「主要な開発者」とは、プロジェクトのコードベースに精通していて、容易に変更を加えることができ、プロジェクトの他のほとんどの参加者によって認められている人です。主要な開発者は、通常、過去1年間に(コード、文書、または質問に回答して)多数の貢献を行います。ある開発者が、プロジェクトを開始している(3年以上プロジェクトから離れていない)、プライベート脆弱性報告チャネル(存在する場合)に関する情報を受け取る、プロジェクトを代表してコミットを受け入れる、最終リリースする、などを行う時主要な開発者とみなすことができます。開発者が1人だけの場合、その人物が主要開発者です。満足しない?プロジェクトの主要開発者の少なくとも1人は、この種のソフトウェアの脆弱性につながる一般的な種類のエラーを知っていなければならず、それぞれを対策または緩和する少なくとも1つの方法を知っていなければなりません。