本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、コアインフラストラクチャイニシアチブ(CII)バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。詳細ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合のみ満たさなくても構いません。すべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮を払うことが望まれます。requestとして提示されれば歓迎します。議論のためのメールリストも用意されています。私たちは、いくつかの言語で情報を提供していますが、翻訳版に矛盾や意味の不一致があった場合、英語版を正式な記述とします。これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください!バッジステータスは次のようになります。バッジステータスの埋め込み方法は次のとおりです。レベル基準を表示することもできます。他のプロジェクトが同じ名前を使用していないか注意してください。プロジェクトを簡単に説明してください。Securityプロジェクト全体のURLは?https://falco.orgバージョン管理リポジトリのURLは何ですか(プロジェクトURLと同じでもかまいません)。満足しないプロジェクトは合格レベルバッジに達成しなければなりません。満足しない?貢献する方法に関する情報には、受け入れ可能な貢献の要件(例えば、必要なコーディング標準への言及)が含まれなければなりません。ソフトウェアのそれなりの量を開発しているすべての開発者が、これらの貢献を行うことが法的に認められていると主張すりょうな法的な仕組みを持っていなければなりません。これを行うための最も一般的で簡単に実装されたアプローチは、開発者証明書(DCO)を使用することです。DCOのウェブサイトへのプロジェクトのリンクが表示されます。ライセンス契約(CLA)またはその他の法的な仕組みとして実装することができます。"サインオフ"機能を直接サポートするため、推奨されるメカニズムです。効果的であるためには、プロジェクト文書が、そのプロジェクトに対して「サインオフ」とは何を意味するのかを説明するのが最善です。CLAは、知的著作物が組織またはプロジェクトにライセンスされている条件を定義する法的合意です。アグリーメント(CAA)は、知的著作物の権利を他の当事者に移転する法的合意です。プロジェクトはCAAを必ずしも持つ必要はありません。CAAは、特に受領者が営利目的の組織である場合には、潜在的な貢献者が貢献しないリスクを高めます。ライセンスと法人CLA)は、この種のCLAのリスクを判断するプロジェクトにとって、リスクが便益よりも小さいのCLAの例です。モデル(主要な役割を含む意思決定方法)を明確に定義し、文書化しなければなりません。決定を下し、論争を解決するための十分に確立された文書化された方法が必要です。小規模なプロジェクトでは、これは「プロジェクトオーナーとリーダーがすべての最終決定を下す」という単純なものです。慈愛の強い独裁者や正式な能力主義を含む様々な統治モデルが存在します。詳細については、統治モデルを参照してください。メインテナー)アプローチの両方が、プロジェクトにおいて成功のうちに使用されています。統治情報は、プロジェクトフォークを作成する可能性について文書化する必要はありません。これはFLOSSプロジェクトでは常に可能であるからです。満足しない?プロジェクトは、行動規範を採択し、標準的な場所に掲示しなければなりません。[code_of_conduct]詳細プロジェクトは、地域社会の礼儀正しさを向上させることと、行動規範を採択することで受け入れられる行動についての期待を設定すること、ができるかもしれません。これにより、問題が発生する前に問題を回避し、プロジェクトをより貢献を促す場所にすることができます。これは、プロジェクトのコミュニティ/職場内の行動にのみ焦点を当てるべきです。行動規範の例としては、貢献者行動規範およびLinuxカーネル競争規範を参照してください。満足しない?プロジェクトは、プロジェクトでの重要な役割と役割が実行しなければならないタスクを含む責任を明確に定義し、公的に文書化しなければなりません。誰がどの役割を持っているかは明確でなければなりませんが、これは同じ方法で文書化されていない可能性があります。統治と役割と責任に関する文章は1か所にあるのが良いでしょう。満足しない?いずれかの人が仕事を継続できなくなるまたは死亡した場合、プロジェクトは最小限の中断で継続することができなければなりません。プロジェクトは、課題の作成と終了、提案された変更の受け入れ、およびバージョンのソフトウェアのリリース、1週間内に個人が仕事を継続できくなったことまたは死亡したことの確認、行うことができなければならない。これは、他の誰かがプロジェクトを継続するのに必要な鍵、パスワード、法的権利を持っていることを保証することによって行うことができます。FLOSSプロジェクトを実行する個人は、ロックボックスにキーを提供し、必要な法的権利を提供する意志(例えば、DNS名のために)を提供することによって、これを行うことができます。ファクタ"を持っているべきです。ファクタ」)は、知見があり有能な人材が離脱して、プロジェクトが停止に至る時に、プロジェクトから突然消失する(「バスに当たった」)プロジェクトメンバーの最小人数です。ファクタツールは、GitHub上のプロジェクトに対してこれを見積もることができます。ファクタの評価を参照してください。満足しない?プロジェクトは、少なくとも翌年に、プロジェクトが何をしたいか、やるつもりはないかを記述した文書化されたロードマップを持っていなければなりません。[documentation_roadmap]詳細このプロジェクトはロードマップを達成できないかもしれません。それは問題ありません。ロードマップの目的は、潜在的なユーザーや貢献者がプロジェクトの意図された方向を理解するのを助けることです。詳細にする必要はありません。満足しない該当なし?プロジェクトは、プロジェクトによって作成されたソフトウェアのアーキテクチャー(いわゆる高水準設計)の文書を含まなければなりません。アーキテクチャは、プログラムの基本的な構造、すなわちプログラムの主な構成要素、それらの間の関係、およびこれらの構成要素および関係の主要な特性を説明します。満足しない?プロジェクトは、ユーザーが、プロジェクトによって作成されたソフトウェアからセキュリティの観点から期待できるものと期待できないものを文書化しなければなりません。[documentation_security]詳細これらは、ソフトウェアが満たすことが意図されているセキュリティ要件です。満足しない該当なし?プロジェクトでは、新規ユーザーがソフトウェアで何かをすばやく実行できるようにするための「クイックスタート」ガイドを提供する必要があります。[documentation_quick_start]詳細このアイデアは、ユーザーにソフトウェアを始動させる方法と何かをさせる方法を示すことです。これは潜在的なユーザーが開始するために非常に重要です。満足しない該当なし?プロジェクトは、現行バージョンのプロジェクト結果(プロジェクトによって作成されたソフトウェアを含む)とドキュメントの整合性を保つために努力しなければならない。不一致を招く既知のドキュメントの欠陥は、修正しなければなりません。ドキュメントが一般的に最新のものですが、古い情報が誤って含まれて、もはや正しくない場合は、それを欠陥として扱い、通常どおりに追跡して修正してください。[documentation_current]詳細ドキュメントには、ソフトウェアのバージョン間の相違点や変更点、および/またはドキュメントの古いバージョンへのリンクに関する情報が含まれていてもよいです。この基準の意図は、ドキュメントが完璧である必要があることではなく、ドキュメントの一貫性を保つための努力がなされていることです。満足しない?プロジェクトのリポジトリのフロントページおよび/またはウェブサイトは、このベストプラクティスのバッジを含め、成果が達成されたことを一般に認められてから48時間以内に特定し、ハイパーリンクする必要があります。達成とは、いくつかのバッジを含めて、プロジェクトが具体的に満たしている外部基準のセットです。この情報は、プロジェクトのウェブサイトのフロントページにある必要はありません。GitHubを使用するプロジェクトは、READMEファイルに追加することで、リポジトリのフロントページに成果を置くことができます。サイトとプロジェクト結果の両方)は、アクセシビリティのベストプラクティスに従い、障害のある人が引き続きプロジェクトに参加し、プロジェクトの結果を合理的な範囲で使用することができるようにするべきです。W3Cアクセシビリティ情報を参照してください。「force-arrow-cursor」設定のような、よりアクセスしやすくするためにいくつかのことを行うことができます。アプリケーションは、そのままの状態でかなりアクセス可能です。ライブラリの場合、「該当なし」(N/A)であることが多いです。取り上げるべき行動や考慮すべき課題の例を以下に示します。人々が必要とする他の形式に変更することができます。大きな印刷物、点字、スピーチ、記号またはより単純な言語などです。)アクションを示したり、応答を促したり、または視覚的要素を区別するために、色が唯一の視覚的な伝達手段として使用されるわけではありません。BSDのOrca;AndroidのTalkBack)。TUIプログラムは、スクリーンリーダーによる冗長な読み取りを防止するために、オーバードローを減らせるかもしれません。オーディエンスの文化、地域、または言語へのローカリゼーションを容易にするために国際化されるべきです。国際化(i18n)が適用されない場合(たとえば、ソフトウェアがエンドユーザー向けのテキストを生成せず、人間が読めるテキストを扱わない場合)、「該当なし」(N/A)を選択します。[internationalization]詳細ローカリゼーションとは、「特定のターゲット市場(ロケール)の言語、文化、およびその他の要件を満たす、製品、アプリケーションまたはドキュメントのコンテンツの適合を指します」。よって異なるターゲットオーディエンスに対してローカライズを容易にする製品、アプリケーション、またはドキュメントコンテンツの設計と開発」のことです。W3Cの「ローカリゼーションと国際化」を参照してください。)ソフトウェアは国際化されるだけでこの基準を満たします。ソフトウェアが国際化されると、他の人がローカライゼーションに取り組むことができるので、別の特定の言語のローカリゼーションは必要ありません。サイト(ウェブサイト、リポジトリ、およびダウンロードURL)が外部ユーザーの認証用のパスワードを格納する場合、パスワードは、キーストレッチ(反復)アルゴリズム(PBKDF2、BcryptまたはScryptなど)を使用してユーザーごとの塩で反復ハッシュとして保存する必要があります。使用はこの基準を満たすことに注意してください。サイトへの認証に使用されるパスワードにのみ適用されます。サイトが他のサイトにログインする必要がある場合、Bcryptなどのアルゴリズムを使用するとパスワードが役に立たないため、その目的のためにパスワードを別々に保存する必要があります。これにより、crypto_password_storageの基準がsites_httpsと同様にプロジェクトサイトに適用されます。グレードを提供しなければなりません。グレード方法が困難な場合は、プロジェクトは、アップグレード方法(変更されたインターフェイスや、アップグレードに役立つ詳細な手順など)を記載しなければなりません。満足しない該当なし?プロジェクトは、個々の課題を追跡するための課題トラッカーを使用する必要があります。満足しない該当なし?プロジェクトは、匿名の報告者を除いて、過去12ヶ月間に解決されたすべての脆弱性の報告者に信用していることを伝えなければなりません。満足しない?プロジェクトには、脆弱性レポートに対応するための文書化されたプロセスがなければなりません。[vulnerability_response_process]詳細これはvulnerability_report_processに強く関連しており、脆弱性を報告するための文書化された方法が必要です。これは、特定の時間枠内の脆弱性レポートへの応答を必要とする、vulnerability_report_responseにも関連しています。ガイドを指定しなければなりませんし、貢献が一般にそれに準拠することを要求しなければなりません。ガイドを参照し、おそらく差異をリストすることによって行われます。ガイドには、可読性を向上させる方法や、欠陥(脆弱性を含む)の可能性を減らす方法が含まれています。ガイドが1つ以上あります。CERTコーディング標準を参照してください。満足しない該当なし?選択した言語において行うことができるFLOSSツールが少なくとも1つあれば、プロジェクトは自動的に選択したコーディングスタイルを適用しなければなりません。[coding_standards_enforced]詳細これは、静的解析ツールを使用して、および/またはコード再フォーマットを介してコードを強制することによって実装することができます。多くの場合、ツールの設定は、プロジェクトのリポジトリに含まれます(プロジェクトによって異なる設定が選択される可能性があるため)。プロジェクトはスタイルの例外を許可するかもしれません(通常はそうなります)。例外が発生した場合は、それらの場所のコードでまれで、文書化されていなければなりませんので、それらの例外が再検討され、ツールが将来自動的にそれらを処理できるようにできます。このようなツールの例には、ESLint(JavaScript)とRubocop(Ruby)があります。バイナリのビルドシステムは、それらに渡される関連するコンパイラおよびリンカ(環境)変数(CC、CFLAGS、CXX、CXXFLAGS、LDFLAGSなど)を受け入れ、コンパイラおよびリンカ呼び出しに渡す必要があります。システムは追加のフラグでそれらを拡張するかもしれません。提供された値を単にそれ自身のものに置き換えてはいけません。ネイティブバイナリが生成されていない場合は、「該当なし」(N/A)を選択します。プラクティス(コンパイラフラグを簡単にオンにするなど)を遵守するのが、簡単であるべきです。-s"が使用されていない)で要求されたデバッグ情報を保存しておくべきです。システムがない場合(例:一般的なJavaScriptライブラリ)は、「該当なし」(N/A)を選択します。++)を設定すると、それらの言語が使用されている場合に、関連デバッグ情報が作成されるべきですし、インストール時には削除するべきではありません。デバッグ情報は、サポートと分析のために必要であり、コンパイルされたバイナリのハードニング機能の存在を測定するのにも役立ちます。システムは、サブディレクトリに相互依存関係がある場合、再帰的にサブディレクトリをビルドしてはなりません。システムがない場合(例:一般的なJavaScriptライブラリ)は、「該当なし」(N/A)を選択します。システムの内部依存情報は、正確でなければなりません。ないと、プロジェクトへの変更が正しくビルドされないことがあります。ビルドが正しくないと、欠陥(脆弱性を含む)が発生する可能性があります。大規模ビルドシステムでよく見られる間違いは、ソースファイルを含むサブディレクトリの階層で、各サブディレクトリが独立してビルドされるとき、「再帰的ビルド」か「再帰的Make」を使用することです。各サブディレクトリが完全に独立していない限り、依存関係の情報が正しくないため、これらを使用することは間違いです。満足しない該当なし?プロジェクトは、ソースファイルから情報を生成するプロセスを繰り返すことができなければならず、ビット単位でまったく同じ結果を得ることができなければなりません。ビルドが発生しない場合(例えば、ソースコードをコンパイルする代わりに直接使用するスクリプト言語)は、「該当なし」(N/A)を選択します。[build_repeatable]詳細GCCとclangのユーザーには、-frandom-seedオプションが有用であるかもしれません。場合によっては、ソート順を強制することで解決できます。再現可能なビルドサイトで、より多くの提案を見つけることができます。満足しない該当なし?プロジェクトは、プロジェクトで作成されたソフトウェアを一般的に使用されているやり方で簡単にインストールおよびアンインストールする方法を提供する必要があります。uninstall」(DESTDIRをサポート)、標準形式のコンテナー、または標準形式の仮想マシンイメージを使用することが挙げられます。インストールとアンインストールのプロセス(たとえば、パッケージング)は、FLOSSである限り、サードパーティによって実装されてもよいです。システムは、インストール時にビルドされる生成物が書き込まれる場所を選択するための標準的な規則を守らなければなりません。POSIXシステムにファイルをインストールする場合は、DESTDIR環境変数を守らなければなりません。満足しない該当なし?プロジェクトは、潜在的な開発者がすべてのプロジェクト結果を迅速にインストールし、テストやテスト環境を含む変更を行うために必要な環境を迅速にインストールする方法を提供しなければなりません。これは、一般に使用されている手法で実行する必要があります。スクリプトを使用して実装できます。外部依存部分は、典型的には、external_dependenciesごとにシステムおよび/または言語パッケージマネージャを呼び出すことによってインストールされます。満足しない該当なし?プロジェクトは、外部依存関係をコンピュータ処理可能な方法でリストしなければなりません。マネージャーやビルドシステムのやり方を使用して行われます。コピーを含む)を監視または定期的にチェックしなければなりません。オリジンアナライザー/依存性検査ツールを使用して行うことができます。パッケージマネージャには、これを行うためのメカニズムが含まれています。コンポーネントの脆弱性を悪用することはできない場合、分析が難しいが、単に更新または修正する方が簡単なであれば、それは許容できます。システムまたはプログラミング言語によって提供される標準コンポーネントを使用しているのどちらかでなければなりません。すれば、再利用されたコンポーネントに脆弱性が見つかった場合に、そのコンポーネントを簡単に更新することができます。[updateable_reused_components]詳細この基準を満たす典型的な方法は、システムおよびプログラミング言語のパッケージ管理システムを使用することです。ライブラリー"と一緒に頒布されます(フォークされている可能性があります)。それ自体は、それでいいです。アップデートとして"標準"ライブラリをアップデートすると、これらの追加のコピーは依然として脆弱のままです。"標準"ライブラリを更新してもプログラムがそれらを使用しない場合、更新プログラムは実際には役に立ちません。Callaway著を参照してください。スタック")において、プロジェクトがサポートするユーザの超大多数がFLOSSの代替案を利用可能な(ユーザが代替手段にアクセスしている)場合には、評価の低いまたは時代遅れの機能とAPIの使用を避けるべきです。スイートが適用される必要があります。スイートは、テストの成功または失敗に関するレポートを生成しなければなりません。[automated_integration_testing]詳細この要件は、test_continuous_integrationのサブセットと見ることができますが、継続的な統合を範囲外として、テストだけに焦点を当てています。スイートに回帰テストを追加しなければなりません。満足しない該当なし?プロジェクトは、選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがある場合、少なくとも80%のステートメントカバレッジを提供するFLOSS自動テストスイートを備えていなければなりません。lcov、Blanket.js、Istanbul、JCovなど、多くのFLOSSツールが、テストカバレッジを測定できます。スイートであることを示す強い指標であることに注意してください。スイートに追加されなければならないという正式な文書化されたポリシーがなければなりません。満足しない該当なし?プロジェクトは、変更提案のための文書化された手順に、重要な新機能用にテストを追加するという方針を含まなければなりません。[tests_documented_added]詳細しかし、実際にテストが追加されている限り、非公式の規則でも許容されます。満足しない該当なし?プロジェクトによって作成されたソフトウェアにある警告に、実際的な場合には、最大限に厳格にならなければなりません。一部の警告は、あるプロジェクトでは効果的に有効にすることはできません。必要なのは、プロジェクトが可能な限り警告フラグを有効にするように努力しており、エラーが早期に検出されるという証拠です。満足しない該当なし?適用できる場合、プロジェクトはセキュア設計原則(「know_secure_design」から)を実装しなければなりません。セーフのデフォルト値を持つべきです(デフォルトではアクセスの決定は拒否されるべきで、プロジェクトのインストールはデフォルトでセキュリティ保護されているべきです)。完全なメディエーションであるべきです(制限されているすべてのアクセスは、権限がチェックされバイパス不可能でなければなりません)。原則が矛盾する場合があります。その場合、選択が必要です(たとえば、多くの仕組みは、「機構の節約」に反して複雑にすることも、単純にすることもできます)。優良な暗号手法を使用する一部のソフトウェアでは、暗号化メカニズムを使用する必要はありません。モード)に依存してはいけません。脆弱性にて議論されています。満足しない該当なし?プロジェクトは複数の暗号アルゴリズムをサポートするべきですので、ユーザーは破られた場合に素早く切り替えることができます。一般的な対称鍵アルゴリズムには、AES、Twofish、およびSerpentがあります。アルゴリズムには、SHA-2(SHA-224、SHA-256、SHA-384およびSHA-512を含む)およびSHA-3があります。満足しない該当なし?プロジェクトは、他の情報(構成ファイル、データベース、ログなど)とは別にしたファイルに、認証資格情報(パスワードやダイナミックトークンなど)やプライベート暗号鍵を格納することをサポートしなければなりませんし、ユーザーがコードの再コンパイルなしにそれらを更新や置き換えできるように許可しなければなりません。プロジェクトが認証資格情報とプライベート暗号化鍵を決して処理しない場合は、「該当なし」(N/A)を選択します。プロトコルをサポートするべきです。FTP、HTTP、telnet、SSLv3以前、SSHv1などのセキュアでないプロトコルは、デフォルトで無効にするべきで、ユーザーが特別に設定した亜場合のみ有効にします。プロジェクトによって作成されたソフトウェアがネットワーク通信をサポートしない場合、「該当なし」(N/A)を選択します。満足しない該当なし?プロジェクトによって作成されたソフトウェアは、TLSをサポートあるいは使用する場合、少なくともTLSバージョン1.2をサポートするべきです。TLSの前身は、SSLと呼ばれていたことに注意して下さい。ソフトウェアがTLSを使用ない場合、「該当なし」(N/A)を選択します。満足しない該当なし?TLSをサポートしている場合、プロジェクトで作成されたソフトウェアは、TLSを使う時には、サブリソースを含めて、デフォルトでTLS認証を受けなければなりません。ソフトウェアがTLSを使用しない場合、「該当なし」(N/A)を選択します。誤ったTLS認証の検証は、よくある間違いであることに注意して下さい。Catanzaro著.を参照して下さい。満足しない該当なし?TLSをサポートしている場合、プロジェクトによって作成されたソフトウェアは、(たとえばセキュアクッキーなど)プライベートな情報をHTTPヘッダと共に送信する前に、証明書の検証をしなければなりません。ソフトウェアがTLSを使用しない場合は、「該当なし」(N/A)を選択します。満足しない該当なし?プロジェクトは、広く普及することを意図しているプロジェクト結果のリリースには暗号で署名しなければなりませんし、パブリック署名鍵を入手して署名を検証する方法をユーザに説明するプロセスがなければなりません。これらの署名の秘密鍵は、ソフトウェアを一般に直接配布するために使用されるサイトにあってはなりません。リリースが広く普及することを意図していない場合は、「該当なし」(N/A)を選択します。[signed_releases]詳細プロジェクトの結果には、ソースコードと生成された成果物(実行可能ファイル、パッケージ、コンテナなど)が含まれます。生成された成果物は、ソースコードとは別に署名することができます。これらは、(暗号デジタル署名を使用して)署名付きgitタグとして実装できます。プロジェクトはgitのようなツールとは別に生成された結果を提供するかもしれませんが、そのような場合、別々の結果を別々に署名しなければなりません。説明されているように、重要なバージョンタグ(メジャーリリース、マイナーリリース、または公開されている脆弱性の一部であるタグ)を暗号署名して検証することが推奨されています。満足しない該当なし?プロジェクトの結果は、潜在的に信頼できないソースからのすべての入力をチェックして有効であることを確認し(*ホワイトリスト*)、データに何らかの制限がある場合は無効な入力を拒否しなければなりません。"不正な形式"(別名*ブラックリスト*)のリストと比較するのは、通常十分ではないことに注意してください。数値は内部形式に変換され、最小値と最大値の間であるかがチェックされますし、文字列は、有効なテキストパターン(有効なUTF-8、長さ、構文など)であることを確認するためにチェックされます。一部のデータは「何でもよい」(たとえばファイルアップローダ)ことがありますが、通常はまれです。満足しない該当なし?プロジェクトによって作成されたソフトウェアで強化メカニズムを使用するべきですので、ソフトウェア欠陥がセキュリティ上の脆弱性を引き起こす可能性が低くなります。私たちの目的のために、最低限の特権は強化メカニズムとはみなされません(最低の特権は重要ですが、別の話です)。満足しない?プロジェクトは、そのセキュリティ要件が満たされていることを証明する保証ケースを提供しなければならない。保証ケースには、脅威モデルの説明、信頼境界の明確な識別、セキュアな設計原則が適用されていることの議論、共通の実装セキュリティの弱点が対処されたことの議論が含まれなければならない。信頼境界は、データまたは実行がその信頼レベル、例えば、典型的なウェブアプリケーションにおけるサーバの境界、を変更する境界である。SANSトップ25など)をリストし、それぞれがどのように対抗しているかを示すのは一般的です。BadgeAppの保証ケースは良い参考例になるかもしれません。これは、documentation_security、documentation_architecture、およびimplement_secure_designに関連しています。満足しない該当なし?プロジェクトは、選択された言語でこの基準を実装できる少なくとも1つのFLOSSツールがある場合、解析された言語または環境で共通の脆弱性を探すためのルールまたはアプローチを備えた少なくとも1つの静的解析ツールを使用しなければならなりません。一般的な脆弱性を探すために特別に設計された静的解析ツールは、それらを見つける可能性が高いです。静的ツールを使用すると、通常は問題を見つけるのに役立ちますので、利用を提案しますが、「合格」レベルのバッジには要求しません。スキャナ)を、バッファの上書きなどのメモリの安全性の問題を検出するメカニズムと一緒にいつも使用します。プロジェクトがメモリ安全でない言語で書かれたソフトウェアを作成しない場合は、「該当なし」(N/A)を選択します。他に使用される可能性のあるツールには、スレッドサニタイザと定義されていない動作サニタイザを参照してください。広範なアサーションも機能します。+)のライセンス条件によって公開することに同意したことになります。すべての人が自由にデータを共有し、修正することができますが、適切なクレディットを表示します。あなたが保有する著作権に影響はありません。プロジェクトライセンスにも影響はありません。こちらから問題を提出してください。利用条件を必ずお読みください。