OpenLineage

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

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

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

        

 基本的情報 17/17

  • 識別情報

    OpenLineage is an Open standard for metadata and lineage collection designed to instrument jobs as they are running. It defines a generic model of run, job, and dataset entities identified using consistent naming strategies. The core lineage model is extensible by defining specific facets to enrich those entities.

  • 前提要件


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

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


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

    Our contributor guide presents the requirements for acceptable contributions: https://github.com/OpenLineage/OpenLineage/blob/main/CONTRIBUTING.md#first-time-contributors.


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


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

    Users are required to sign off in their commits, and the project links to the DCO website. Link in GOVERNANCE.md: https://github.com/OpenLineage/OpenLineage/blob/main/GOVERNANCE.md Sign-off requirement in CONTRIBUTING.md: https://github.com/OpenLineage/OpenLineage/blob/main/CONTRIBUTING.md Sign-off reminder in PR template: https://github.com/OpenLineage/OpenLineage/blob/main/.github/pull_request_template.md



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

    Our Governance document presents the governance model: https://github.com/OpenLineage/OpenLineage/blob/main/GOVERNANCE.md.



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

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

    Roles and responsibilities are outlined in the project's governance doc: https://github.com/OpenLineage/OpenLineage/blob/main/GOVERNANCE.md.



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

    Keys and passwords safeguarded and accessible using 1password utility (https://1password.com/).



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

    The project's committers list shows that we have a bus factor great than 2: https://github.com/OpenLineage/OpenLineage/blob/main/COMMITTERS.md


  • ドキュメンテーション


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

    See our Github Project with long-running backlog and milestones: https://github.com/orgs/OpenLineage/projects/2.



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

    For the high-level design, see the Object Model page of our docs site: https://openlineage.io/docs/spec/object-model.



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

    OpenLineage does not store user data, so this is not a concern. As we state in the main README at https://github.com/OpenLineage/OpenLineage/blob/main/README.md, the project is a metadata collection standard for pipelines.



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

    See our Quick Start guide on the project docs site for a doc that serves this purpose: https://openlineage.io/docs/getting-started.



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

    See the up-to-date project docs site: https://openlineage.io/docs/.



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

    The front page of project repo displays our current LFAI & Data badge: https://github.com/OpenLineage/OpenLineage.


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


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

    Although we recognize that accessibility and internationalization are important, they are not concerns for the OpenLineage project because there is no UI.



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

    There is no UI involved, so this is N/A.


  • その他


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

    The project sites do not store passwords.


  • 以前のバージョン


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

    See the Releases page on Github: https://github.com/OpenLineage/OpenLineage/releases. For an example PyPI package with a history, see: https://pypi.org/project/openlineage-airflow/#history. See here for an example Maven library page with previous versions: https://mvnrepository.com/artifact/io.openlineage/openlineage-java.


  • バグ報告プロセス


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

    For our bug-reporting process, see the Issues tab on our Github repository: https://github.com/OpenLineage/OpenLineage/issues.


  • 脆弱性報告プロセス


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

    While we do have a process in place for vulnerability reporting (see: https://github.com/OpenLineage/OpenLineage/blob/main/CONTRIBUTING.md), this is N/A because none have been reported.



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

    Our process for responding to reported issues can be found in this doc: https://github.com/OpenLineage/OpenLineage/blob/main/CONTRIBUTING.md.


  • コーディング標準


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

    For Java, the primary language in the project, we use https://github.com/google/google-java-format, which is enforced by the Spotless plugin for Gradle.



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

    We use a Gradle file with configuration of PMD and Spotless for Java code linting: https://github.com/OpenLineage/OpenLineage/blob/main/client/java/build.gradle. See also this setup.py file showing Mypy and Flake8 linters are required extras for Python client: https://github.com/OpenLineage/OpenLineage/blob/main/client/python/setup.py.


  • 作業ビルドシステム


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

    This requirement is relevant to OpenLineage's SQL parser. There, RUSTFLAGS have this function: https://doc.rust-lang.org/cargo/reference/environment-variables.html.



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

    The project does not feature an installation system, so this is not applicable.



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

    There is a build system, but the project does not recursively build subdirectories.



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

    The project, despite having binary code inside, uses Python wheels, which do not permit this functionality.


  • インストールシステム


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

    In every case we use common, industry-standard tools. For Java, we distribute OpenLineage libraries via Maven Central (https://mvnrepository.com/search?q=openlineage), and the artifacts can be installed using standard Maven or Gradle tools. For Python, we use PyPI, and users can install/uninstall via PIP (https://pypi.org/search/?q=openlineage).



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

    Please see above. Our tools (Maven and PyPI) follow these conventions.



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

    Please see our contributing guide at https://github.com/OpenLineage/OpenLineage/blob/main/CONTRIBUTING.md, where we explain how contributors can trigger builds and tests on CircleCI, a standard tool in the industry.


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


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

    For Java, the build.gradle files (e.g., https://github.com/OpenLineage/OpenLineage/blob/main/client/java/build.gradle) can be processed. For Python, the setup.py files can be processed (https://github.com/OpenLineage/OpenLineage/blob/main/client/python/setup.py).



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

    For dependency monitoring, we use Dependabot, which is a built-in tool offered by GitHub. Our configuration file can be found here: https://github.com/OpenLineage/OpenLineage/blob/main/.github/dependabot.yml.



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

    The project's build system allows us to meet this requirement.



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

    We avoid these issues in part through the use of static code analysis tools that are run automatically on commits (such as PMD for Java: https://github.com/OpenLineage/OpenLineage/blob/main/client/java/build.gradle).


  • 自動テスト スイート


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

    Our workflows on CircleCI include tests. For the details, see: https://github.com/OpenLineage/OpenLineage/tree/main/.circleci/workflows



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

    For an example of the project's automated testing process, see the test suite in the Airflow integration: https://github.com/OpenLineage/OpenLineage/tree/main/integration/airflow/tests.



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

    For another part of our automated test suite, see the tests directory in the Common integration: https://github.com/OpenLineage/OpenLineage/tree/main/integration/common/tests. The project also uses Codecov. You can see how we deploy this tool here: https://github.com/OpenLineage/OpenLineage/blob/main/integration/airflow/setup.cfg.


  • 新機能テスト


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

    The checklist in our PR template states our requirement that new functionalities be accompanied by tests: https://github.com/OpenLineage/OpenLineage/blob/main/.github/pull_request_template.md.



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

    As noted above, the checklist in our PR template states our requirement that new functionalities be accompanied by tests: https://github.com/OpenLineage/OpenLineage/blob/main/.github/pull_request_template.md.


  • 警告フラグ


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

    Warnings are used by the static code analysis tools employed by the project. See: We avoid these issues in part through the use of static code analysis tools that are run automatically on commits (such as PMD for Java: https://github.com/OpenLineage/OpenLineage/blob/main/client/java/build.gradle).


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


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

    Ours is primarily a Java project, so there is no provisioning model in the project. The operations do not require the users to have direct access to functions, so these issues do not apply.


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

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

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


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

    We provide support for multiple cryptographic algorithms through HTTPS. Support is also provided by Java (in the JVM settings).



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

    This functionality is supported through environment variables and configuration files.



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

    Our use of HTTPS for network communications means that we meet this security threshold.



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

    Our use of OpenSSL means that our support for SSL is up to date.



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

    Please see above.



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

    This functionality is built-in thanks to our use of HTTPS.


  • 公開物の安全性


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

    Our releases on PyPI and Maven are both cryptographically signed, as are those on GitHub.



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

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


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

    We do not deal with direct user input, so this is not applicable.



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

    OpenLineage is primarily a Java project, so this is not applicable. Also, we provide a library, not a server.



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

    The threat model is largely determined by the deployment scenario and the consuming organization, both of which vary. We are able and happy to provide examples of threats and mitigation strategies to organizations wishing to deploy OpenLineage.

    For this reason, a single assurance case would be misleading. A general code security and analysis assurance statement is available to users in our main GitHub repository: https://github.com/OpenLineage/OpenLineage/blob/main/CODE_QUALITY_AND_SECURITY.md.


  • 静的コード解析


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

    Please see this build.gradle file showing usage of PMD and Spotless tools for Java linting: https://github.com/OpenLineage/OpenLineage/blob/main/client/java/build.gradle. See also this setup.py file showing usage of Flake8 and Mypy for Python linting: https://github.com/OpenLineage/OpenLineage/blob/main/client/python/setup.py.


  • 動的コード分析


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

    We use Java (and some Python), so this is not applicable.



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

プロジェクト バッジ登録の所有者: Julien Le Dem.
エントリの作成日時 2021-05-21 00:18:40 UTC、 最終更新日 2023-07-26 17:28:35 UTC 最後に2022-07-19 16:28:34 UTCにバッジ合格を達成しました。

もどる