本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、コアインフラストラクチャイニシアチブ(CII)バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。詳細ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合のみ満たさなくても構いません。すべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮を払うことが望まれます。requestとして提示されれば歓迎します。議論のためのメールリストも用意されています。私たちは、いくつかの言語で情報を提供していますが、翻訳版に矛盾や意味の不一致があった場合、英語版を正式な記述とします。これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください!バッジステータスは次のようになります。バッジステータスの埋め込み方法は次のとおりです。レベル基準を表示することもできます。他のプロジェクトが同じ名前を使用していないか注意してください。プロジェクトを簡単に説明してください。Securityプロジェクト全体のURLは?https://falco.orgバージョン管理リポジトリのURLは何ですか(プロジェクトURLと同じでもかまいません)。バッジを達成しなければなりません。ファクタ"を持つ必要があります。ファクタ」)は、知見があり有能な人材が離脱して、プロジェクトが停止に至る時に、プロジェクトから突然消失する(「バスに当たった」)プロジェクトメンバーの最小人数です。ファクタツールは、GitHub上のプロジェクトに対してこれを見積もることができます。ファクタの評価を参照してください。満足しない?プロジェクトには少なくとも2人の関係を持たない重要な貢献者がいなければなりません。同じ組織によって作業に対しに支払われ(従業員または請負業者)、組織がプロジェクトの成果の恩恵を受ける場合、貢献者は関連します。財務補助金が他の組織を通過する場合、同じ組織のものであると見なされません(例えば、共通の政府やNGOのソースから異なる組織に支払われた科学補助金は、貢献者を関連させません)。過去1年間にプロジェクトに些細でない貢献をしていれば、その人は大きな貢献をしています。重要な貢献者の良い指標の例としては、少なくとも1,000行のコード、50個のコミット、または少なくとも20ページの文書化が挙げられます。満足しない?プロジェクトは、少なくとも1つの関連する年と著作権者を特定する著作権記述書を各ソースファイルに含まなければなりません。満足しない?プロジェクトは、各ソースファイルにライセンスステートメントを含まなければなりません。[license_per_file]詳細これは、ライセンスを特定する自然言語での記述を含めることによっても行うことができます。テキストまたは完全なライセンステキストを指し示す安定したURLを含めることもできます。license_location基準は、プロジェクトライセンスが標準の場所にあることを要求します。SPDXライセンスの詳細については、このSPDXチュートリアルを参照してください。関係に注意してください。その内容は通常、ライセンス情報に先行します。満足しない?プロジェクトのソースリポジトリは、共通の分散バージョン管理ソフトウェア(gitやmercurialなど)を使用しなければなりません。[repo_distributed]詳細Gitが特別に必要とされているわけでなく、プロジェクトでは、集中型バージョン管理ソフトウェア(例:subversion)を正当とする証拠を持って使用できます。満足しない?プロジェクトは、新規または偶に参加する貢献者によって実行できる小さなタスクを明確に識別しなければなりません。fix(小修正)、microtask(小タスク)、またはIdealFirstBug(理想的に最初のバグ)のいずれかをマークすることによって行われます。これらの新しいタスクには機能を追加する必要はありません。ドキュメントを改善したり、テストケースを追加したり、プロジェクトを支援したり、プロジェクトの詳細を寄稿者が理解できるようにすることができます。満足しない?プロジェクトは、中央リポジトリを変更したり、機密データ(プライベート脆弱性レポートなど)にアクセスするために、開発者に対して二要素認証(2FA)を要求する必要があります。推奨されませんが、2FAメカニズムは、SMSのような暗号化メカニズムを持たないメカニズムを使用することができます。満足しない?プロジェクトの2要素認証(2FA)は、偽装を防ぐために暗号化メカニズムを使用すべきです。サービス(SMS)ベースの2FA自体は、暗号化されていないため、この基準を満たしていません。パスワード(TOTP)アプリケーションです。GitHubはTOTPをサポートしています。満足しない該当なし?プロジェクトは、コードレビューの実施方法、チェックする必要があるもの、受け入れられる必要があるものなど、コードレビュー要件を文書化しなければなりません。contribution_requirementsも参照してください。満足しない?プロジェクトは、公開する前に、提案されたすべての変更の少なくとも50%を著作者以外の人がレビューして、それが価値のある変更であり、取り込みに反対する既知の問題がないかどうかを判断しなければなりません。満足しない該当なし?プロジェクトが再現可能なビルドを持たなければなりません。ビルドが発生しない場合(たとえば、コンパイルされないでソースコードが直接使用されるスクリプト言語)、「該当なし」(N/A)を選択します。ファイルから情報を生成するプロセスを独立にやり直し、ビット単位でまったく同じ結果を得られることを意味します。ある場合には、これ(再現可能なビルド)は、あるソート順を強いることで解決されます。OccurenceOrderPluginの使用を検討するかもしれません。GCCとclangのユーザーは、-frandom-seedオプションが有用であることを見つけるかもしれません。ビルド環境(ツールセットを含む)は、リビルドに使用できる特定のコンテナや仮想マシンの暗号化ハッシュを指定することによって、外部パーティのために、しばしば定義可能です。プロジェクトは、これを行う方法を記載したドキュメントを有します。満足しない?テストスイートは、その言語の標準的な方法で呼び出すことができなければなりません。警告:URLが必要ですが、URLは見つかりません。満足しない?プロジェクトは、新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動化されたテストが実行される、継続的な統合を実装しなければなりません。[test_continuous_integration]詳細ほとんどの場合、これは、プロジェクトでフルタイムで働く各開発者が少なくとも1日に1回統合作業をすることを意味します。警告:URLが必要ですが、URLは見つかりません。カバレッジを提供するFLOSS自動テストスイートを備えていなければなりません。満足しない該当なし?選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがあれば、少なくとも80%のブランチカバレッジを提供するFLOSS自動テストスイートがプロジェクトに存在しなければなりません。優良な暗号手法を使用する一部のソフトウェアでは、暗号化メカニズムを使用する必要はありません。プロトコルをサポートしなければなりません。FTP、HTTP、telnet、SSLv3以前、SSHv1などのセキュアでないプロトコルは、デフォルトで無効にするべきで、ユーザーが特別に設定した亜場合のみ有効にします。プロジェクトによって作成されたソフトウェアがネットワーク通信をサポートしない場合、「該当なし」(N/A)を選択します。満足しない該当なし?プロジェクトによって作成されたソフトウェアは、TLSをサポートあるいは使用する場合、少なくともTLSバージョン1.2をサポートしなければなりません。TLSの前身は、SSLと呼ばれていたことに注意して下さい。ソフトウェアがTLSを使用ない場合、「該当なし」(N/A)を選択します。満足しない?プロジェクトウェブサイト、リポジトリ(ウェブからアクセス可能な場合)、およびダウンロードサイト(別々の場合)には、許容できない値を持つキー強化ヘッダーが含まれていなければなりません。[hardened_site]詳細GitHubはこれを満たしています。https://securityheaders.io/などのサイトでこれをすばやく確認できます。セキュリティ(HSTS)、X-Content-Type-Options(「nosniff」)、X-Frame-Options、X-XSS-Protectionです。満足しない?プロジェクトは過去5年間にセキュリティレビューを実施していなければなりません。このレビューは、セキュリティ要件とセキュリティ境界を考慮しなければならりません。[security_review]詳細これは、プロジェクトメンバーおよび/または独立した評価によって行うことができます。この評価は、静的および動的解析ツールによってサポートされることができますが、ツールが検出できない問題(特に設計上)を特定するためには、人間によるレビューが必要です。満足しない該当なし?プロジェクトによって作成されたソフトウェアで強化メカニズムを使用しなければならないので、ソフトウェア欠陥がセキュリティ上の脆弱性を引き起こす可能性が低くなります。私たちの目的のために、最低限の特権は強化メカニズムとはみなされません(最低の特権は重要ですが、別の話です)。満足しない該当なし?プロジェクトは、リリース前にプロジェクトによって作成されたソフトウェアの主要な製品リリースに対して、少なくとも1つの動的解析ツールを適用しなければなりません。動的解析ツールは、ソフトウェアを特定の入力で実行して検査します。プロジェクトがプロジェクトにファズテストを適用する可能性があります。スイートである必要があります。ファジングに関するOWASPページで、いくつかの動的解析ツールを特定しています。解析ツールは、セキュリティの脆弱性を探すことに重点を置くことができますが、これは必須ではありません。満足しない該当なし?プロジェクトは、生成するソフトウェアに多くの実行時アサーションを含めるべきであり、動的分析中にそれらのアサーションをチェックするべきです。+)のライセンス条件によって公開することに同意したことになります。すべての人が自由にデータを共有し、修正することができますが、適切なクレディットを表示します。あなたが保有する著作権に影響はありません。プロジェクトライセンスにも影響はありません。こちらから問題を提出してください。利用条件を必ずお読みください。