Apache Syncope

Projects that follow the best practices below will be able to voluntarily self-certify and show that they've achieved a Core Infrastructure Initiative (CII) badge.

There is no set of practices that can guarantee that software will never have defects or vulnerabilities; even formal methods can fail if the specifications or assumptions are wrong. Nor is there any set of practices that can guarantee that a project will sustain a healthy and well-functioning development community. However, following best practices can help improve the results of projects. For example, some practices enable multi-person review before release, which can both help find otherwise hard-to-find technical vulnerabilities and help build trust and a desire for repeated interaction among developers from different companies. To earn a badge, all MUST and MUST NOT criteria must be met, all SHOULD criteria must be met OR be unmet with justification, and all SUGGESTED criteria must be met OR unmet (we want them considered at least). Feedback is welcome via the GitHub site as issues or pull requests There is also a mailing list for general discussion.

We gladly provide the information in several locales, however, if there is any conflict or inconsistency between the translations, the English version is the authoritative version.
If this is your project, please show your badge status on your project page! The badge status looks like this: プロジェクト 154 のバッジ レベルは passing です Here is how to embed it:
You can show your badge status by embedding this in your markdown file:
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/154/badge)](https://bestpractices.coreinfrastructure.org/projects/154)
or by embedding this in your HTML:
<a href="https://bestpractices.coreinfrastructure.org/projects/154"><img src="https://bestpractices.coreinfrastructure.org/projects/154/badge"></a>


These are the 合格 level criteria. You can also view the シルバー or ゴールド level criteria.



 基本的情報 12/12

  • 識別情報

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

    Apache Syncope is an Open Source system for managing digital identities in enterprise environments, implemented in Java EE technology and released under Apache 2.0 license.

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


    Enough for a badge!

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

    General description in home page (https://syncope.apache.org/). Reference scenario for Identity and Access Manager in https://syncope.apache.org/iam-scenario.html



    Enough for a badge!

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

    Enough for a badge!

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


    Enough for a badge!

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

    Build instructions (http://syncope.apache.org/building.html) and contributor guidelines (https://syncope.apache.org/contributing.html) describe how to contribute alongside with acceptance criteria. Those checks are also automatically checked by our CI system.


  • FLOSS License

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



    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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

  • ドキュメンテーション


    Enough for a badge!

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


    Enough for a badge!

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

  • その他


    Enough for a badge!

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

    All website URLs are available as HTTP and HTTPS: http://syncope.apache.org/ -> https://syncope.apache.org/



    Enough for a badge!

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

    User and developers mailing lists, IRC channel: https://syncope.apache.org/mailing-lists.html



    Enough for a badge!

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





 変更管理 9/9

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


    Enough for a badge!

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

    https://git-wip-us.apache.org/repos/asf/syncope.git

    This GIT repo is mirrored at GitHub under https://github.com/apache/syncope and we are able to manage PR from there.



    Enough for a badge!

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

    We use git.



    Enough for a badge!

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


    Enough for a badge!

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

    We use git.


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


    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

    リリースノートは、新しいリリースごとに修正された、既知の脆弱性をすべて特定しなければなりません。リリースノートがないか、または既知の脆弱性がない場合、これは 「該当なし」(N/A)です。 [release_notes_vulns]

 報告 8/8

  • バグ報告プロセス


    Enough for a badge!

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

    Enough for a badge!

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

    Enough for a badge!

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

    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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

 品質 13/13

  • 実動ビルドシステム


    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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

    The build process only requires Apache Maven.


  • Automated test suite


    Enough for a badge!

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

    Unit and integration tests are part of the codebase and run at every build.



    Enough for a badge!

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

    The Apache Maven Surefire and Failsafe plugin are used.



    Enough for a badge!

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

    Enough for a badge!

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

    Travis CI builds are triggered by commits and PRs.


  • 新機能テスト


    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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

  • 警告フラグ


    Enough for a badge!

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

    The build process enforces code quality checks via Checkstyle and Apache RAT plugins.



    Enough for a badge!

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


    Enough for a badge!

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

 セキュリティ 16/16

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


    Enough for a badge!

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


    Enough for a badge!

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

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

    Note that some software does not need to use cryptographic mechanisms.

    Enough for a badge!

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


    Enough for a badge!

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

    Enough for a badge!

    暗号に依存するプロジェクトによって作成されるソフトウェアのすべての機能は、FLOSSを使用して実装可能でなければなりません。 [crypto_floss]

    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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

    Enough for a badge!

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


    Enough for a badge!

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

  • MITM(man-in-the-middle:中間者)攻撃に対応できる安全な配信


    Enough for a badge!

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


    Enough for a badge!

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

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


    Enough for a badge!

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


    Enough for a badge!

    プロジェクトは、すべての重要な脆弱性を、報告された後迅速に修正するべきです。 [vulnerabilities_critical_fixed]
  • その他のセキュリティ上の課題


    Enough for a badge!

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

 Analysis 7/8

  • 静的コード解析


    Enough for a badge!

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

    Warning: Requires lengthier justification.



    Enough for a badge!

    static_analysis基準に使用される静的解析ツールの少なくとも1つが、分析された言語または環境における共通の脆弱性を探すためのルールまたはアプローチを含むことが、推奨されています。 [static_analysis_common_vulnerabilities]

    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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


    Enough for a badge!

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

    Enough for a badge!

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

 今後予定される基準 8/8


These are criteria we intend to add in the near future, but are not currently required for a badge. This grace period allows projects to update to changed criteria and retain their badge as best practices improve.

Enough for a badge!

(Future criterion) プロジェクトは、プロジェクトで作成されたソフトウェアを一般的に使用されているやり方で簡単にインストールおよびアンインストールする方法を提供するべきです。 [installation_common]
たとえば、パッケージマネージャー(システムまたは言語レベル)、「make install / uninstall」(DESTDIRをサポート)、標準形式のコンテナー、または標準形式の仮想マシンイメージを使用することが挙げられます。インストールとアンインストールのプロセス(たとえば、パッケージング)は、FLOSSである限り、サードパーティによって実装されてもよいです。

Besides Apache Maven-based project generation via archetype, we also provide a GUI installer and a standalone distribution ZIP archive.



Enough for a badge!

(Future criterion) プロジェクトが再現可能なビルドを持つことが、推奨されています。ビルドが発生しない場合(たとえば、コンパイルされないでソースコードが直接使用されるスクリプト言語)、「該当なし」(N/A)を選択します。 [build_reproducible]
再現可能なビルドは、複数の当事者がソース ファイルから情報を生成するプロセスを独立にやり直し、ビット単位でまったく同じ結果を得られることを意味します。ビルドが発生しない場合(たとえば、コンパイルされる代わりに、ソースコードが直接使用されるスクリプト言語)、「該当なし」(N/A)を選択します。ある場合には、これ(再現可能なビルド)は、あるソート順を強いることで解決されます。Javaスクリプトの開発者は、npm shrinkwrapとwebpack OccurenceOrderPluginの使用を検討するかもしれません。GCCとclangのユーザーは、-frandom-seedオプションが有用であることを見つけるかもしれません。ビルド環境(ツールセットを含む)は、リビルドに使用できる特定のコンテナや仮想マシンの暗号化ハッシュを指定することによって、外部パーティのために、しばしば定義可能です。再現可能なビルド プロジェクトは、これを行う方法を記載したドキュメントを有します


Enough for a badge!

(Future criterion) プロジェクトで作成されたソフトウェアは、ネットワーク通信すべてに対して、SSHv2以降、TLS1.2以降 (HTTPS)、IPsec、SFTP、SNMPv3などのセキュア プロトコルをサポートするべきです。FTP、HTTP、telnet、SSLv3以前、SSHv1などのセキュアでないプロトコルは、デフォルトで無効にするべきで、ユーザーが特別に設定した亜場合のみ有効にします。プロジェクトによって作成されたソフトウェアがネットワーク通信をサポートしない場合、「該当なし」(N/A)を選択します。 [crypto_used_network]

Enough for a badge!

(Future criterion) プロジェクトによって作成されたソフトウェアは、TLSをサポートあるいは使用する場合、少なくともTLSバージョン1.2をサポートするべきです。TLSの前身は、SSLと呼ばれていたことに注意して下さい。ソフトウェアがTLSを使用ない場合、「該当なし」(N/A)を選択します。 [crypto_tls12]

Enough for a badge!

(Future criterion) TLSをサポートしている場合、プロジェクトで作成されたソフトウェアは、TLSを使う時には、サブリソースを含めて、デフォルトでTLS認証を受けなければなりません。ソフトウェアがTLSを使用しない場合、「該当なし」(N/A)を選択します。 [crypto_certificate_verification]
誤ったTLS認証の検証は、よくある間違いであることに注意して下さい。詳細については、「世界でもっとも危険なコード:非ブラウザー ソフトウェアでのSSL認証の検証」Martin Georgiev et al著「このアプリケーションを信頼しますか?」Michael Catanzaro著.を参照して下さい。


Enough for a badge!

(Future criterion) TLSをサポートしている場合、プロジェクトによって作成されたソフトウェアは、(たとえばセキュアクッキーなど)プライベートな情報をHTTPヘッダと共に送信する前に、証明書の検証をするべきです。ソフトウェアがTLSを使用しない場合は、「該当なし」(N/A)を選択します。 [crypto_verification_private]

Enough for a badge!

(Future criterion) プロジェクトウェブサイト、リポジトリ(ウェブからアクセス可能な場合)、およびダウンロードサイト(別々の場合)には、許容できない値を持つキー強化ヘッダーが含まれていることが推奨されます。 [hardened_site]
GitHubはこれを満たしています。 https://securityheaders.io/などのサイトでこれをすばやく確認できます。キーセキュリティ強化ヘッダーは、コンテンツ セキュリティ ポリシー(CSP)、HTTP厳密トランスポート セキュリティ(HSTS)、X-Content-Type-Options(「nosniff」)、X-Frame-Options、X-XSS-Protectionです。


Enough for a badge!

(Future criterion) プロジェクトによって作成されたソフトウェアで強化メカニズムを使用することが推奨されていますので、ソフトウェア欠陥がセキュリティ上の脆弱性を引き起こす可能性が低くなります。 [hardening]
強化メカニズムは、Content Security Policy(CSP)などのHTTPヘッダー、攻撃を緩和するコンパイラ フラグ(-fstack-protectorなど)、または未定義の動作を排除するためのコンパイラ フラグを含みます。私たちの目的のために、最低限の特権は強化メカニズムとはみなされません(最低の特権は重要ですが、別の話です)。


This data is available under the Creative Commons Attribution version 3.0 license (CC-BY-3.0) per the Core Infrastructure Initiative terms of use. All are free to share and adapt the data, but must give appropriate credit. Please credit Francesco Chicchiriccò and the CII Best Practices badge contributors.

Project badge entry owned by: Francesco Chicchiriccò.
Entry created on 2016-05-26 06:45:40 UTC, last updated on 2016-05-26 07:13:09 UTC. Last achieved passing badge on 2016-05-26 07:13:00 UTC.

もどる