e3-core

本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、Open Source Security Foundation (OpenSSF) バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。

これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください！バッジステータスは次のようになります。 プロジェクト 979 のバッジ レベルは passing です バッジステータスの埋め込み方法は次のとおりです。

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

        

 基本的情報 11/17 ●

  • 識別情報

    Core framework for developing portable automated build systems

  • 前提要件


    バッジには十分です！

    プロジェクトは合格レベルバッジに達成しなければなりません。 [achieve_passing]

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


    バッジには十分です！

    貢献する方法に関する情報には、受け入れ可能な貢献の要件（例えば、必要なコーディング標準への言及）が含まれなければなりません。 (URLが必要です) [contribution_requirements]

    https://github.com/AdaCore/e3-core/blob/master/CONTRIBUTING.md

    We document that we're PEP8 compliant and are asking for verifying it with our checker.


  • プロジェクトの管理・運営


    バッジには十分です！

    プロジェクトは、プロジェクト ソフトウェアのそれなりの量を開発しているすべての開発者が、これらの貢献を行うことが法的に認められていると主張すりょうな法的な仕組みを持っていなければなりません。これを行うための最も一般的で簡単に実装されたアプローチは、開発者証明書（DCO）を使用することです。ユーザーは、 DCOのウェブサイトへのプロジェクトのリンクが表示されます。ただし、これはコントリビュータ ライセンス契約（CLA）またはその他の法的な仕組みとして実装することができます。 (URLが必要です) [dco]

    Use of a CLA automated through cla-asistant as visible for every pull-request, e.g. https://github.com/AdaCore/e3-core/pull/332


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

    プロジェクトは、プロジェクト ガバナンス モデル（主要な役割を含む意思決定方法）を明確に定義し、文書化しなければなりません。 (URLが必要です) [governance]

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

    プロジェクトは、行動規範を採択し、標準的な場所に掲示しなければなりません。 (URLが必要です) [code_of_conduct]

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

    プロジェクトは、プロジェクトでの重要な役割と役割が実行しなければならないタスクを含む責任を明確に定義し、公的に文書化しなければなりません。誰がどの役割を持っているかは明確でなければなりませんが、これは同じ方法で文書化されていない可能性があります。 (URLが必要です) [roles_responsibilities]

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

    いずれかの人が仕事を継続できなくなるまたは死亡した場合、プロジェクトは最小限の中断で継続することができなければなりません。特に、プロジェクトは、課題の作成と終了、提案された変更の受け入れ、およびバージョンのソフトウェアのリリース、1週間内に個人が仕事を継続できくなったことまたは死亡したことの確認、行うことができなければならない。これは、他の誰かがプロジェクトを継続するのに必要な鍵、パスワード、法的権利を持っていることを保証することによって行うことができます。 FLOSSプロジェクトを実行する個人は、ロックボックスにキーを提供し、必要な法的権利を提供する意志（例えば、DNS名のために）を提供することによって、これを行うことができます。 (URLが必要です) [access_continuity]

    バッジには十分です！

    プロジェクトは2以上の "バス ファクタ"を持っているべきです。 (URLが必要です) [bus_factor]

    AdaCore, as a commercial entity, ensures the project will continue with minimal interruption. e3-core is a key component of AdaCore internal infrastructure. See https://github.com/AdaCore/e3-core/network/dependents See https://snyk.io/advisor/python/e3-core for an analysis of maintainers and contributors.


  • ドキュメンテーション


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

    プロジェクトは、少なくとも翌年に、プロジェクトが何をしたいか、やるつもりはないかを記述した文書化されたロードマップを持っていなければなりません。 (URLが必要です) [documentation_roadmap]

    バッジには十分です！

    プロジェクトは、プロジェクトによって作成されたソフトウェアのアーキテクチャー（いわゆる高水準設計）の文書を含まなければなりません。プロジェクトでソフトウェアが作成されない場合は、「該当なし」（N/A）を選択します。 (URLが必要です) [documentation_architecture]

    The project provides a simple API that is documented in https://e3-core.readthedocs.io/en/latest/index.html This API is extensible using plugins: https://e3-core.readthedocs.io/en/latest/plugins.html


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

    プロジェクトは、ユーザーが、プロジェクトによって作成されたソフトウェアからセキュリティの観点から期待できるものと期待できないものを文書化しなければなりません。（セキュリティ要件） (URLが必要です) [documentation_security]

    バッジには十分です！

    プロジェクトでは、新規ユーザーがソフトウェアで何かをすばやく実行できるようにするための「クイックスタート」ガイドを提供する必要があります。 (URLが必要です) [documentation_quick_start]

    An highlight of main API functions is provided: https://e3-core.readthedocs.io/en/latest/quickstart.html


    バッジには十分です！

    プロジェクトは、現行バージョンのプロジェクト結果（プロジェクトによって作成されたソフトウェアを含む）とドキュメントの整合性を保つために努力しなければならない。 不一致を招く既知のドキュメントの欠陥は、修正しなければなりません。ドキュメントが一般的に最新のものですが、古い情報が誤って含まれて、もはや正しくない場合は、それを欠陥として扱い、通常どおりに追跡して修正してください。 [documentation_current]

    The main documentation is the API documentation that is maintained using Python docstrings and type annotations. The documentation is maintained up-to-date with changes to the code.


    バッジには十分です！

    プロジェクトのリポジトリのフロントページおよび/またはウェブサイトは、このベストプラクティスのバッジを含め、成果が達成されたことを一般に認められてから48時間以内に特定し、ハイパーリンクする必要があります。 (URLが必要です) [documentation_achievements]

    e3-core uses CII best practices badge https://github.com/AdaCore/e3-core


  • アクセシビリティと国際化


    バッジには十分です！

    プロジェクト（プロジェクト サイトとプロジェクト結果の両方）は、アクセシビリティのベストプラクティスに従い、障害のある人が引き続きプロジェクトに参加し、プロジェクトの結果を合理的な範囲で使用することができるようにするべきです。 [accessibility_best_practices]

    Project site is on GitHub, the Python library is integrated with the Python ecosystem.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアは、ターゲット オーディエンスの文化、地域、または言語へのローカリゼーションを容易にするために国際化されるべきです。国際化（i18n）が適用されない場合（たとえば、ソフトウェアがエンドユーザー向けのテキストを生成せず、人間が読めるテキストを扱わない場合）、「該当なし」（N/A）を選択します。 [internationalization]

    The project is meant to be used by developers and not end-users.


  • その他


    バッジには十分です！

    プロジェクト サイト（ウェブサイト、リポジトリ、およびダウンロードURL）が外部ユーザーの認証用のパスワードを格納する場合、パスワードは、キーストレッチ（反復）アルゴリズム（PBKDF2、Bcrypt、Scrypt、PBKDF2など）を使用してユーザーごとのソルトで反復ハッシュとして保存する必要があります。プロジェクトサイトがこの目的のためにパスワードを保存しない場合は、「該当なし」（N/A）を選択します。 [sites_password_security]

    Use of GitHub


  • 以前のバージョン


    バッジには十分です！

    プロジェクトは、最も頻繁に使用される古いバージョンの製品を維持するか、または新しいバージョンへのアップ グレードを提供しなければなりません。アップ グレード方法が困難な場合は、プロジェクトは、アップグレード方法（変更されたインターフェイスや、アップグレードに役立つ詳細な手順など）を記載しなければなりません。 [maintenance_or_update]

    All backward incompatible changes are documented in https://github.com/AdaCore/e3-core/blob/master/NEWS.md


  • バグ報告プロセス


    バッジには十分です！

    プロジェクトは、個々の課題を追跡するための課題トラッカーを使用する必要があります。 [report_tracker]

    GitHub issues: https://github.com/AdaCore/e3-core/issues


  • 脆弱性報告プロセス


    バッジには十分です！

    プロジェクトは、匿名の報告者を除いて、過去12ヶ月間に解決されたすべての脆弱性の報告者に信用していることを伝えなければなりません。過去12ヶ月間に解決された脆弱性がない場合は、「該当なし」（N / A）を選択します。 (URLが必要です) [vulnerability_report_credit]

    No vulnerabilities reported


    バッジには十分です！

    プロジェクトには、脆弱性レポートに対応するための文書化されたプロセスがなければなりません。 (URLが必要です) [vulnerability_response_process]

    We ask for GitHub issues in https://github.com/AdaCore/e3-core/blob/master/CONTRIBUTING.md


  • コーディング標準


    バッジには十分です！

    プロジェクトは、使用する主要な言語のための特定のコーディング スタイル ガイドを指定しなければなりませんし、貢献が一般にそれに準拠することを要求しなければなりません。 (URLが必要です) [coding_standards]

    https://github.com/AdaCore/e3-core/blob/master/CONTRIBUTING.md we document our coding standard


    バッジには十分です！

    選択した言語において行うことができるFLOSSツールが少なくとも1つあれば、プロジェクトは自動的に選択したコーディングスタイルを適用しなければなりません。 [coding_standards_enforced]

    Enforce at each pull request via tox


  • 作業ビルドシステム


    バッジには十分です！

    ネイティブ バイナリのビルドシステムは、それらに渡される関連するコンパイラおよびリンカ（環境）変数（CC、CFLAGS、CXX、CXXFLAGS、LDFLAGSなど）を受け入れ、コンパイラおよびリンカ呼び出しに渡す必要があります。ビルド システムは追加のフラグでそれらを拡張するかもしれません。提供された値を単にそれ自身のものに置き換えてはいけません。ネイティブバイナリが生成されていない場合は、「該当なし」（N/A）を選択します。 [build_standard_variables]

    Pure Python


    バッジには十分です！

    ビルドとインストール システムは、関連するフラグ（例えば、 "install -s"が使用されていない）で要求されたデバッグ情報を保存しておくべきです。ビルドやインストール システムがない場合（例：一般的なJavaScriptライブラリ）は、「該当なし」（N/A）を選択します。 [build_preserve_debug]

    We have a Python lib, are are using standard tools


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアのビルド システムは、サブディレクトリに相互依存関係がある場合、再帰的にサブディレクトリをビルドしてはなりません。ビルドやインストール システムがない場合（例：一般的なJavaScriptライブラリ）は、「該当なし」（N/A）を選択します。 [build_non_recursive]

    Standard Python project (script language)


    バッジには十分です！

    プロジェクトは、ソースファイルから情報を生成するプロセスを繰り返すことができなければならず、ビット単位でまったく同じ結果を得ることができなければなりません。ビルドが発生しない場合（例えば、ソースコードをコンパイルする代わりに直接使用するスクリプト言語）は、「該当なし」（N/A）を選択します。 [build_repeatable]

    Standard Python project (script language)


  • インストールシステム


    バッジには十分です！

    プロジェクトは、プロジェクトで作成されたソフトウェアを一般的に使用されているやり方で簡単にインストールおよびアンインストールする方法を提供する必要があります。 [installation_common]

    python setup.py install

    pip install / uninstall


    バッジには十分です！

    エンドユーザ用のインストール システムは、インストール時にビルドされる生成物が書き込まれる場所を選択するための標準的な規則を守らなければなりません。たとえば、POSIXシステムにファイルをインストールする場合は、DESTDIR環境変数を守らなければなりません。インストール システムがない場合や標準的な規約がない場合は、「該当なし」（N / A）を選択します。 [installation_standard_variables]

    Standard Python project (script language)


    バッジには十分です！

    プロジェクトは、潜在的な開発者がすべてのプロジェクト結果を迅速にインストールし、テストやテスト環境を含む変更を行うために必要な環境を迅速にインストールする方法を提供しなければなりません。これは、一般に使用されている手法で実行する必要があります。 [installation_development_quick]

    Easy to build and run the testsuite, all documented in CONTRIBUTING.md


  • 外部で維持管理されるコンポーネント


    バッジには十分です！

    プロジェクトは、外部依存関係をコンピュータ処理可能な方法でリストしなければなりません。 (URLが必要です) [external_dependencies]

    In setup.py: https://github.com/AdaCore/e3-core/blob/master/setup.py


    バッジには十分です！

    プロジェクトは、既知の脆弱性を検出し、悪用可能な脆弱性を修正したり、悪用できない脆弱性として確認するために、外部の依存先（コンビニエンス コピーを含む）を監視または定期的にチェックしなければなりません。 [dependency_monitoring]

    We run safety check --full-report automatically


    バッジには十分です！

    プロジェクトは
    1. 再使用された外部管理コンポーネントの識別と更新を容易にできるようにしている、 または
    2. システムまたはプログラミング言語によって提供される標準コンポーネントを使用している
    のどちらかでなければなりません。そうすれば、再利用されたコンポーネントに脆弱性が見つかった場合に、そのコンポーネントを簡単に更新することができます。 [updateable_reused_components]

    Use of python package manager.


    バッジには十分です！

    プロジェクトは、使用するテクノロジ セット（その "テクノロジ スタック"）において、プロジェクトがサポートするユーザの超大多数がFLOSSの代替案を利用可能な（ユーザが代替手段にアクセスしている）場合には、評価の低いまたは時代遅れの機能とAPIの使用を避けるべきです。 [interfaces_current]

    This is met to the best of our knowledge. FLOSS alternatives are regularly reviewed and used when it makes sense.


  • 自動テスト スイート


    バッジには十分です！

    少なくとも1つのブランチの共有リポジトリへの各チェックインに対して、自動テスト スイートが適用される必要があります。このテスト スイートは、テストの成功または失敗に関するレポートを生成しなければなりません。 [automated_integration_testing]

    Automated via TravisCI and AppVeyor for pull-request. Pushing directly to master without pull-request is disabled.


    バッジには十分です！

    プロジェクトは、過去6ヶ月以内に修正されたバグの少なくとも50％について、自動テスト スイートに回帰テストを追加しなければなりません。 [regression_tests_added50]

    A test is added after each bug detected.


    バッジには十分です！

    プロジェクトは、選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがある場合、少なくとも80％のステートメントカバレッジを提供するFLOSS自動テストスイートを備えていなければなりません。 [test_statement_coverage80]

    Coverage is displayed on the project main page and computed for each pull-request. As documented in CONTRIBUTING.md we're want to be near 100% statement coverage (currently 96%)


  • 新機能テスト


    バッジには十分です！

    プロジェクトには、主要な新機能が追加されると、新しい機能のテストが自動化されたテスト スイートに追加されなければならないという正式な文書化されたポリシーがなければなりません。 [test_policy_mandated]

    We document that "All features or bug fixes must be tested." in contributing.md


    バッジには十分です！

    プロジェクトは、変更提案のための文書化された手順に、重要な新機能用にテストを追加するという方針を含まなければなりません。 [tests_documented_added]

    Documented in https://github.com/AdaCore/e3-core/blob/master/CONTRIBUTING.md and automatically verified (code coverage should not decrease)


  • 警告フラグ


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアにある警告に、実際的な場合には、最大限に厳格にならなければなりません。 [warnings_strict]

    All warnings reported by the linter tools are addressed.


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


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

    適用できる場合、プロジェクトはセキュア設計原則（「know_secure_design」から）を実装しなければなりません。プロジェクトでソフトウェアが作成されていない場合は、「該当なし」（N / A）を選択します。 [implement_secure_design]

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

    一部のソフトウェアは暗号化メカニズムを使用する必要がないことに注意してください。あなたのプロジェクトが作成するソフトウェアが、(1) 暗号化機能を含む、アクティブ化する、または有効化し、(2) 米国（US）から米国外または米国市民以外にリリースされる可能性がある場合は、法的に義務付けられた追加手順の実行を要求される可能性があります。通常、これにはメールの送信が含まれます。詳細については、 Understanding Open Source Technology & US Export Controls（「オープンソース技術と米国の輸出管理について」）の暗号化のセクションを参照してください。

    バッジには十分です！

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

    We use SHA1 checksum to verify the downloaded content BUT it is possible to configure the download to go through HTTPS. We do not consider the checksum to be a security mechanisms, they are used to detect possible download issues.


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

    プロジェクトは複数の暗号アルゴリズムをサポートするべきですので、ユーザーは破られた場合に素早く切り替えることができます。一般的な対称鍵アルゴリズムには、AES、Twofish、およびSerpentがあります。一般的な暗号化ハッシュ アルゴリズムには、SHA-2（SHA-224、SHA-256、SHA-384およびSHA-512を含む）およびSHA-3があります。 [crypto_algorithm_agility]

    バッジには十分です！

    プロジェクトは、他の情報（構成ファイル、データベース、ログなど）とは別にしたファイルに、認証資格情報（パスワードやダイナミックトークンなど）やプライベート暗号鍵を格納することをサポートしなければなりませんし、ユーザーがコードの再コンパイルなしにそれらを更新や置き換えできるように許可しなければなりません。プロジェクトが認証資格情報とプライベート暗号化鍵を決して処理しない場合は、「該当なし」（N/A）を選択します。 [crypto_credential_agility]

    The project won't read credentials, we rely on external tools, e.g. AWS cli or SSH


    バッジには十分です！

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

    Network communications that would be typically used by projects based on e3-core would be implemented using the Python standard library. Our HTTPS wrappers are verifying SSL certificates by default.


    バッジには十分です！

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

    Provided by the Python standard library.


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

    TLSをサポートしている場合、プロジェクトで作成されたソフトウェアは、TLSを使う時には、サブリソースを含めて、デフォルトでTLS認証を受けなければなりません。ソフトウェアがTLSを使用しない場合、「該当なし」（N/A）を選択します。 [crypto_certificate_verification]

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

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

  • 公開物の安全性


    バッジには十分です！

    プロジェクトは、広く普及することを意図しているプロジェクト結果のリリースには暗号で署名しなければなりませんし、パブリック署名鍵を入手して署名を検証する方法をユーザに説明するプロセスがなければなりません。これらの署名の秘密鍵は、ソフトウェアを一般に直接配布するために使用されるサイトにあってはなりません。リリースが広く普及することを意図していない場合は、「該当なし」（N/A）を選択します。 [signed_releases]

    We're using Git tag for releases and GitHub is verifying the signature for us.


    バッジには十分です！

    バージョン管理システムでは、 signed_releases で説明されているように、重要なバージョンタグ（メジャーリリース、マイナーリリース、または公開されている脆弱性の一部であるタグ）を暗号署名して検証することが推奨されています。 [version_tags_signed]

    We're using Git tag for releases and GitHub is verifying the signature for us.


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


    バッジには十分です！

    プロジェクトの結果は、潜在的に信頼できないソースからのすべての入力をチェックして有効であること（*allowlist*）を確認し、データに何らかの制限がある場合は無効な入力を拒否しなければなりません。 [input_validation]

    The only possible untrusted sources would be the external store containing binary files. The tool require that the checksum is stored separately and verify that the download file has the right checksum.


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

    プロジェクトによって作成されたソフトウェアで強化メカニズムを使用するべきですので、ソフトウェア欠陥がセキュリティ上の脆弱性を引き起こす可能性が低くなります。 [hardening]

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

    プロジェクトは、そのセキュリティ要件が満たされていることを証明する保証ケースを提供しなければならない。保証ケースには、脅威モデルの説明、信頼境界の明確な識別、セキュアな設計原則が適用されていることの議論、共通の実装セキュリティの弱点が対処されたことの議論が含まれなければならない。 (URLが必要です) [assurance_case]

  • 静的コード解析


    バッジには十分です！

    プロジェクトは、選択された言語でこの基準を実装できる少なくとも1つのFLOSSツールがある場合、解析された言語または環境で共通の脆弱性を探すためのルールまたはアプローチを備えた少なくとも1つの静的解析ツールを使用しなければならなりません。 [static_analysis_common_vulnerabilities]

    bandit


  • 動的コード分析


    バッジには十分です！

    もしプロジェクトで作成されたソフトウェアにメモリ安全でない言語（CやC ++など）を使用して作成されたソフトウェアが含まれているならば、そのときには 少なくとも1つの動的ツール（たとえば、ファジーまたはウェブ アプリケーション スキャナ）を、バッファの上書きなどのメモリの安全性の問題を検出するメカニズムと一緒にいつも使用します。プロジェクトがメモリ安全でない言語で書かれたソフトウェアを作成しない場合は、「該当なし」（N/A）を選択します。 [dynamic_analysis_unsafe]

    Python is a memory safe language



このデータは、Creative Commons Attribution version 3.0以降のライセンス（CC-BY-3.0 +）のもとで利用できます。すべての人がデータを自由に共有および適応できますが、適切にクレジットを入れる必要があります。 Olivier RamonatとOpenSSFベストプラクティス バッジ貢献者のクレジットを入れてください。

プロジェクト バッジ登録の所有者： Olivier Ramonat.
エントリの作成日時 2017-05-19 15:48:47 UTC、 最終更新日 2021-05-19 13:54:17 UTC 最後に2020-01-18 19:53:50 UTCにバッジ合格を達成しました。

もどる