in-toto

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

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

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

        

 基本的情報 13/13 ●

  • 識別情報

    in-toto is a framework to protect supply chain integrity.

    どのようなプログラミング言語を使ってプロジェクトを実装していますか？

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


    バッジには十分です！

    プロジェクトのウェブサイトは、ソフトウェアが何をするのか（何の問題を解決するのか）を簡潔に記述しなければなりません。 [description_good]

    The project website's landing page provides an introductory video and key aspects about the in-toto project. A textual description of the project is found in the menu item "About->What is in-toto?"

    https://in-toto.github.io/ https://in-toto.github.io/in-toto.html


    バッジには十分です！

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

    The project website has a menu item "Community" with two subitems "Contact", providing handles for the project's mailing list, GitHub Organization and IRC channel; and "Contribute", which links directly to the projects main repository.

    https://in-toto.github.io/contact.html https://github.com/in-toto/in-toto/


    バッジには十分です！

    貢献する方法に関する情報は、貢献プロセス（たとえばプル リクエストが使用されか、など）を説明する必要があります。 (URLが必要です) [contribution]

    Projects on GitHub by default use issues and pull requests, as encouraged by documentation such as https://guides.github.com/activities/contributing-to-open-source.


    バッジには十分です！

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

    What is expected of contributions is covered in the README and GOVERNANCE documents.

    https://github.com/in-toto/in-toto/blob/develop/GOVERNANCE.md https://github.com/in-toto/in-toto#instructions-for-contributors


  • FLOSSライセンス

    プロジェクトのライセンスはどのようなものですか？


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアは、FLOSSとしてリリースされなければなりません。 [floss_license]

    The Apache 2.0 license is approved by the Open Source Initiative (OSI).


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアに必要なライセンスは、オープンソース・イニシアチブ（OSI）によって承認されていることが推奨されています。 [floss_license_osi]

    The Apache 2.0 license is approved by the Open Source Initiative (OSI).


    バッジには十分です！

    プロジェクトは、結果のライセンスをソースリポジトリの標準的な場所に投稿しなければなりません。 (URLが必要です) [license_location]

    Non-trivial license location file in repository: https://github.com/in-toto/in-toto/blob/develop/LICENSE.


  • ドキュメンテーション


    バッジには十分です！

    プロジェクトは、プロジェクトによって作成されたソフトウェアに関する基本的なドキュメンテーションを提供しなければなりません。 [documentation_basics]

    The project's README file provides basic documentation, installation instructions, demo, etc.


    バッジには十分です！

    プロジェクトは、プロジェクトによって作成されたソフトウェアの外部インタフェース（入力と出力の両方）を記述する参照ドキュメントを提供しなければなりません。 [documentation_interface]

    The project's README describes the typical workflow and how the use the provided command line tools for the different steps of the workflow.

    https://github.com/in-toto/in-toto/#carrying-out-software-supply-chain-steps https://github.com/in-toto/in-toto/#release-final-product https://github.com/in-toto/in-toto/#verification


  • その他


    バッジには十分です！

    プロジェクトサイト（ウェブサイト、リポジトリ、およびダウンロードURL）は、TLSを使用したHTTPSをサポートしなければなりません。 [sites_https]

    The project website is hosted on GitHub pages and has free certificates from Let's Encrypt. The repository is hosted on GitHub. Download URLs are available via GitHub and PyPI (HTTPS).

    https://in-toto.github.io/ https://github.com/in-toto/in-toto https://pypi.python.org/pypi/in-toto


    バッジには十分です！

    プロジェクトは、議論（提案された変更や問題を含む）のための1つ以上の検索可能なメカニズムを持たなければならず、メッセージやトピックがURLでアドレス指定され、新しい人々がディスカッションのいくつかに参加できるようにしなければならず、クライアント側でプロプライエタリなソフトウェアのインストールを必要としないようにします。 [discussion]

    GitHub supports discussions on issues and pull requests.

    https://github.com/in-toto/in-toto/issues https://github.com/in-toto/in-toto/pulls


    バッジには十分です！

    プロジェクトは英語で文書を提供し、英語でコードに関するバグ報告とコメントを受け入れることができるべきです。 [english]

    All of the project's material is written in English, and it accepts bug reports and comments in English.

    https://github.com/in-toto/in-toto/blob/develop/README.md https://in-toto.github.io/ https://github.com/in-toto/docs/blob/master/in-toto-spec.md


    バッジには十分です！

    プロジェクトはメンテナンスされている必要があります。 [maintained]


（詳細）このバッジエントリを編集する権限を持つユーザーは？ 現在：[]



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


    バッジには十分です！

    プロジェクトには、公開され、URLを持つ、バージョン管理のソース リポジトリがなければなりません。 [repo_public]

    Repository on GitHub, which provides public git repositories with URLs.


    バッジには十分です！

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

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.


    バッジには十分です！

    共同レビューを可能にするために、プロジェクトのソースリポジトリには、リリース間のレビューのための中間バージョンが含まれなければなりません。最終リリースのみを含めることはできません。 [repo_interim]

    Development occurs on the "develop" branch of the project's GitHub repository. Before final releases, collaborative review happens on the "develop" branch and pull requests that are merged into it.


    バッジには十分です！

    プロジェクトのソース リポジトリに共通の分散バージョン管理ソフトウェア（gitなど）を使用することを推奨します。 [repo_distributed]

    Repository on GitHub, which uses git. git is distributed.


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


    バッジには十分です！

    プロジェクトの結果には、ユーザーが使用することを意図されたリリースごとに固有のバージョン識別子が必要です。 [version_unique]

    The project's source code is versioned via the setup.py Python module, which includes a field for the version number. https://github.com/in-toto/in-toto/blob/v0.3.0/setup.py#L36

    The project's specification document is also versioned. https://github.com/in-toto/docs/blob/master/in-toto-spec.md


    バッジには十分です！

    リリースには、Semantic Versioning (SemVer)またはCalendar Versioning (CalVer)のバージョン番号形式を使用することが推奨されます。CalVerを使用する場合は、マイクロレベル値を含めることが推奨されます。 [version_semver]

    バッジには十分です！

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

    The project's releases are available on the GitHub repository. Each release is tagged with git and signed with gpg. https://github.com/in-toto/in-toto/releases


  • リリースノート


    バッジには十分です！

    プロジェクトは、各リリースにおいて、ユーザーがアップグレードすべきかどうか、また、アップグレードの影響を判断できるよう、そのリリースの主要な変更の要約を説明したリリースノートを提供しなければなりません（MUST）。リリースノートは、バージョン管理ログの生の出力であってはなりません（例えば、 "git log"コマンドの結果はリリースノートではない）。プロジェクトの成果物が複数の場所で再利用されることを意図していないプロジェクト（単独のウェブサイトやサービスのためのソフトウェアなど）で、かつ、継続的・断続的な配布を行う場合は、「該当なし」を選択することができます。 (URLが必要です) [release_notes]

    The project's provides a CHANGELOG file that summarizes the changes introduced by the release.

    https://github.com/in-toto/in-toto/blob/develop/CHANGELOG.md


    バッジには十分です！

    リリースノートでは、このリリースで修正された、リリースの作成時にすでにCVE割り当てなどがあった、公に知られているランタイムの脆弱性をすべて特定する必要があります。 ユーザーが通常、ソフトウェアを実際に更新できない場合（たとえば、カーネルの更新によくあることです）、この基準は該当なし（N/A）としてマークされる場合があります。 この基準はプロジェクトの結果にのみ適用され、依存関係には適用されません。 リリースノートがない場合、または公に知られている脆弱性がない場合は、[N/A]を選択します。 [release_notes_vulns]

    There have been no publicly known vulnerabilities identified in the specification or code.


  • バグ報告プロセス


    バッジには十分です！

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

    The project's users can submit bug reports using the GitHub issue tracker or emails to the project's consensus builder.

    https://github.com/in-toto/in-toto/issues https://github.com/in-toto/in-toto#security-issues-and-bugs


    バッジには十分です！

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

    The project uses GitHub's issue tracker to track individual issues.

    https://github.com/in-toto/in-toto/issues


    バッジには十分です！

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

    The majority of bug reports submitted in the last 2-12 months have been acknowledged.

    https://github.com/in-toto/in-toto/issues?q=is%3Aissue+created%3A%3E%3D2017-01-01


    バッジには十分です！

    プロジェクトは、直近2〜12ヶ月（2ヶ月を含む）に増強要求の多数（> 50％）に対応すべきです。 [enhancement_responses]

    The majority of enhancement requests have been acknowledged in the last 2-12 months.

    https://github.com/in-toto/in-toto/issues?q=is%3Aissue+created%3A%3E%3D2017-01-01


    バッジには十分です！

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

    All reports and responses are publicly available on GitHub's issue and pull request pages and can be searched using GitHub's searching syntax:

    https://github.com/in-toto/in-toto/issues https://github.com/in-toto/in-toto/pulls https://help.github.com/articles/searching-issues-and-pull-requests/


  • 脆弱性報告プロセス


    バッジには十分です！

    プロジェクトは、脆弱性を報告するプロセスをプロジェクト サイトに公開しなければなりません。 (URLが必要です) [vulnerability_report_process]

    The project publishes the process for reporting vulnerabilities.

    https://github.com/in-toto/in-toto#security-issues-and-bugs


    バッジには十分です！

    プライベート脆弱性報告がサポートされている場合、プロジェクトは、プライベートに保持された方法で情報を送信する方法を含んでいなくてはなりません。 (URLが必要です) [vulnerability_report_private]

    The project allows users to encrypted their reports when emailing them.

    https://github.com/in-toto/in-toto#security-issues-and-bugs


    バッジには十分です！

    過去6ヶ月間に受け取った脆弱性報告に対するプロジェクトの初期応答時間は、14日以下でなければなりません。 [vulnerability_report_response]

    There have been no vulnerabilities reported in the last 6 months.


  • 作業ビルドシステム


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアを利用するためにビルドが必要な場合、プロジェクトは、ソース コードからソフトウェアを自動的にリビルドできる作業ビルド システムを提供しなければなりません。 [build]

    The project uses Travis CI to ensure the software can be built from the source code.

    https://travis-ci.org/in-toto/in-toto


    バッジには十分です！

    ソフトウエアをビルドするために、一般的なツールを使用することをお勧めします。 [build_common_tools]

    The project uses the standard Python tools to "build", package, and distribute the software.

    https://pypi.python.org/pypi/in-toto


    バッジには十分です！

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

    The project uses the standard Python tools to "build", package, and distribute the software.

    https://pypi.python.org/pypi/in-toto


  • 自動テスト スイート


    バッジには十分です！

    プロジェクトは、FLOSSとして公開されている自動テストスイートを少なくとも1つ使用する必要があります（このテストスイートは、別個のFLOSSプロジェクトとして維持される場合があります）。 プロジェクトは、テストスイートの実行方法を明確に示すか文書化する必要があります（たとえば、継続的インテグレーション（CI）スクリプトを介して、またはBUILD.md、README.md、CONTRIBUTING.mdなどのファイルの文書を介して）。 [test]

    The project uses "Tox," "coverage," and "coveralls", which are all released as FLOSS.

    https://github.com/in-toto/in-toto/blob/v0.3.0/tox.ini https://github.com/in-toto/in-toto/blob/v0.3.0/.coveragerc https://coveralls.io/github/in-toto/in-toto


    バッジには十分です！

    テスト スイートは、その言語の標準的な方法で呼び出すことができるべきです。 [test_invocation]

    The project's tests are written using Python's standard unittest module. The test suite also uses tox, a popular way of invoking a project's test suite.

    https://github.com/in-toto/in-toto/blob/v1.0.0/tests/runtests.py https://github.com/in-toto/in-toto/blob/v1.0.0/tox.ini


    バッジには十分です！

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

    Our test suite covers over 99% of the source code.

    https://coveralls.io/github/in-toto/in-toto


    バッジには十分です！

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

    The project implements continuous integration using GitHub Actions, running tests on Linux, macOS and MS Windows.

    https://github.com/in-toto/in-toto/actions https://github.com/in-toto/in-toto/tree/develop/.github/workflows


  • 新機能テスト


    バッジには十分です！

    プロジェクトは、プロジェクトで作成されたソフトウェアに主要な新機能が追加されたときに、その機能のテストを自動化されたテスト スイートに追加する必要があるという一般的な方針（正式でも、正式でなくても構いません）を持っていなければなりません。 [test_policy]

    The project's .tox.ini config and continuous integration system requires 99% coverage of the source code, otherwise a build failure results. It's policy is captured in the GOVERNANCE document and pull request template.

    https://github.com/in-toto/in-toto/blob/develop/GOVERNANCE.md https://github.com/in-toto/in-toto/blob/develop/.github/PULL_REQUEST_TEMPLATE.md


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアの最新の大きな変更で、テストを追加するための test_policy が守られているという証拠がプロジェクトに存在しなければなりません。 [tests_are_added]

    The project's continuous integration system requires at least 99% coverage of the source code at all times.

    https://github.com/in-toto/in-toto/blob/v0.3.0/tox.ini#L41


    バッジには十分です！

    テストを追加するこのポリシー（test_policyを参照）を変更提案に関する手順で文書化することを推奨します。 [tests_documented_added]

    The project's pull request template documents the policy of verifying that tests have been added to the change. https://github.com/in-toto/in-toto/blob/develop/.github/PULL_REQUEST_TEMPLATE.md


  • 警告フラグ


    バッジには十分です！

    プロジェクトは、選択した言語でこの基準を実装することができる少なくとも1つのFLOSSツールがあれば、1つまたは複数のコンパイラ警告フラグ、「安全」言語モードを使用可能にするか、分離 「リンター」ツールを使用してコード品質エラーまたは共通の単純なミスを検索しなければなりません。 [warnings]

    The project uses two separate "linter" tools, Pylint and Bandit, to look for code quality errors and simple mistakes.

    https://github.com/in-toto/in-toto/blob/v0.3.0/tox.ini#L18-L36


    バッジには十分です！

    プロジェクトは警告を出さなければならない。 [warnings_fixed]

    The linter tools are executed during Continuous Integration builds with Travis CI and tox. If a linter detects an error, the CI build fails and the corresponding pull request won't be merged.

    https://github.com/in-toto/in-toto/blob/v0.3.0/.travis.yml#L27 https://github.com/in-toto/in-toto/blob/v0.3.0/tox.ini#L18-L36


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアにある警告に、実際的な場合には、最大限に厳格になることを推奨されています。 [warnings_strict]

    The project is strict with warnings and requires that pull requests emit no linter warnings, i.e. that CI builds pass. https://travis-ci.org/in-toto/in-toto


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


    バッジには十分です！

    プロジェクトには、安全なソフトウェアを設計する方法を知っている少なくとも1人の主要な開発者が必要です。 （正確な要件については、「詳細」を参照してください。） [know_secure_design]

    The primary developers of the project are familiar with secure software design and work in a security lab at a university.


    バッジには十分です！

    プロジェクトの主要開発者の少なくとも1人は、この種のソフトウェアの脆弱性につながる一般的な種類のエラーを知っていなければならず、それぞれを対策または緩和する少なくとも1つの方法を知っていなければなりません。 [know_common_errors]

    The primary developers of the project are familiar with secure software design and work in a security lab at a university.


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

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

    バッジには十分です！

    プロジェクトによって作成されたソフトウェアは、デフォルトで、一般に公開され、専門家によってレビューされている暗号プロトコルとアルゴリズムを使用しなければなりません。（暗号プロトコルとアルゴリズムが使用される場合） [crypto_published]

    The project uses only cryptographic protocols and algorithms that are publicly published and reviewed by experts.

    More infos about the protocols and algorithms can be found at: https://github.com/secure-systems-lab/securesystemslib

    Securesystemslib is an internal interface to renowned cryptography libraries (pyca/cryptography and pyca/PyNaCl).


    バッジには十分です！

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

    The project does not reimplement its own cryptographic functions. It uses an internal interface to renowned cryptography libraries (pyca/cryptography and pyca/PyNaCl):

    https://github.com/secure-systems-lab/securesystemslib


    バッジには十分です！

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

    All functionality in the project that depends on crypto uses FLOSS.

    https://github.com/secure-systems-lab/securesystemslib


    バッジには十分です！

    プロジェクトによって作成されたソフトウェア内にあるセキュリティ メカニズムは、少なくとも、2030年までのNIST最小要件（2012年）を満たすデフォルト鍵長を使用しなければなりません。より小さな鍵長を完全に無効になるおうに、ソフトウェアを構成できなければなりません。 [crypto_keylength]

    The project uses safe defaults that follow NIST requirements, and disallow smaller key lengths.

    https://github.com/secure-systems-lab/securesystemslib


    バッジには十分です！

    プロジェクトによって生成されたソフトウェア内のデフォルトのセキュリティメカニズムは、壊れた暗号化アルゴリズム（MD4、MD5、シングルDES、RC4、Dual_EC_DRBGなど）に依存したり、実装する必要がない限り、コンテキストに不適切な暗号化モードを使用したりしてはなりません。相互運用可能なプロトコル（実装されたプロトコルがネットワークエコシステムによって広くサポートされている標準の最新バージョンであり、そのエコシステムではそのようなアルゴリズムまたはモードの使用が必要であり、そのエコシステムはこれ以上安全な代替手段を提供しません）。これらの壊れたアルゴリズムまたはモードが相互運用可能なプロトコルに必要な場合、ドキュメントには、関連するセキュリティリスクと既知の緩和策を記載する必要があります。 [crypto_working]

    The project does not depend on broken cryptographic algorithms.

    https://github.com/secure-systems-lab/securesystemslib


    バッジには十分です！

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

    The project's default security mechanisms do not depend on weak algorithms or modes.

    https://github.com/secure-systems-lab/securesystemslib


    バッジには十分です！

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

    The project does not depend on key agreement protocols.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアが外部ユーザーの認証用のパスワードの保存を引き起こす場合、パスワードは、キーストレッチ（反復）アルゴリズム（Argon2id、Bcrypt、Scrypt、PBKDF2など）を使用して、ユーザーごとのソルトで反復ハッシュとして保存される必要があります。OWASP Password Storage Cheat Sheetも参照してください）。 [crypto_password_storage]

    The project uses PBKDF2 for encrypted keys.

    https://github.com/secure-systems-lab/securesystemslib


    バッジには十分です！

    プロジェクトによって作成されたソフトウェア内のセキュリティ メカニズムは、暗号学的にセキュアな乱数発生器を使用して、すべての暗号鍵とナンスを生成しなければなりません。暗号学的にセキュアでない発生器を使用してはいけません。 [crypto_random]

    The project's cryptography interface uses only Python's os.urandom which is considered cryptographically secure.

    https://github.com/secure-systems-lab/securesystemslib


  • MITM（man-in-the-middle：中間者）攻撃に対応できる安全な配信


    バッジには十分です！

    プロジェクトは、MITM攻撃に対抗する配信メカニズムを使用しなければならない。httpsまたはssh+scpを使用することは許容されます。 [delivery_mitm]

    The project website and the repository are available via https. The project itself does not use any network protocols.


    バッジには十分です！

    暗号ハッシュ（たとえばSHA1SUM）は、http経由で運んではならず、暗号署名をチェックすることなしに使用してはいけません。 [delivery_unsigned]

    The project's signed metadata, which includes cryptographic hashes, is always validated by the client software before accepting it.

    https://github.com/in-toto/in-toto/blob/v0.3.0/in_toto/verifylib.py


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


    バッジには十分です！

    60日を超えて公的に知られている中程度または重大度のパッチが適用されていない脆弱性は存在してはなりません。 [vulnerabilities_fixed_60_days]

    There are now publicly known vulnerabilities.


    バッジには十分です！

    プロジェクトは、すべての重要な脆弱性を、報告された後迅速に修正するべきです。 [vulnerabilities_critical_fixed]

    Although the project has not received reports for critical vulnerabilities, the developers should be able to rapidly fix any that are reported in the future.


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


    バッジには十分です！

    公開リポジトリは、パブリックアクセスを制限するための有効なプライベートクレデンシャル（たとえば、有効なパスワードやプライベートキー）を漏らしてはなりません。 [no_leaked_credentials]

    The project's public repository does not leak valid private credentials. Private keys found in the repository are used for testing only.


  • 静的コード解析


    バッジには十分です！

    選択した言語でこの基準を実装するFLOSSツールが少なくとも1つある場合、少なくとも1つの静的コード分析ツール（コンパイラの警告と「安全な」言語モード以外）を、ソフトウェアの主要な製品リリースの提案に、リリース前に適用する必要があります。 [static_analysis]

    The project uses the Python source code analyzer pylint, which is executed as part of Continuous Integration testing. The configuration file is customized to follow the project's code style guideline.

    https://github.com/PyCQA/pylint https://github.com/in-toto/in-toto/blob/v0.3.0/tox.ini#L18-L20 https://github.com/in-toto/in-toto/blob/v0.3.0/.travis.yml#L27 https://github.com/in-toto/in-toto/blob/develop/pylintrc


    バッジには十分です！

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

    The project uses the security linter for Python source code Bandit, which is executed as part of Continuous Integration testing.

    https://github.com/PyCQA/bandit https://github.com/in-toto/in-toto/blob/v0.3.0/tox.ini#L22-L36 https://github.com/in-toto/in-toto/blob/v0.3.0/.travis.yml#L27


    バッジには十分です！

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

    Static code analysis is executed as part of Continuous Integration testing. Pull Requests only get merged if Continuous Integration testing passes.

    https://github.com/in-toto/in-toto/blob/v0.3.0/tox.ini#L18-L36 https://github.com/in-toto/in-toto/blob/v0.3.0/.travis.yml#L27


    バッジには十分です！

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

    Static code analysis is executed as part of Continuous Integration testing.

    https://github.com/in-toto/in-toto/blob/v0.3.0/tox.ini#L18-L36 https://github.com/in-toto/in-toto/blob/v0.3.0/.travis.yml#L27


  • 動的コード分析


    バッジには十分です！

    リリース前に、ソフトウェアの主要な製品リリースに少なくとも1つの動的解析ツールを適用することが示唆されています。 [dynamic_analysis]

    Dynamic analysis is automatically applied to every push to the repository:

    https://github.com/in-toto/in-toto/blob/v0.3.0/.travis.yml#L27 https://github.com/in-toto/in-toto/blob/v0.3.0/tox.ini


    バッジには十分です！

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

    The project does not produce software written in a memory-unsafe language.


    バッジには十分です！

    プロジェクトでは、多くのアサーションを可能にする少なくとも一部の動的分析（テストやファジングなど）の構成を使用することをお勧めします。多くの場合、これらのアサーションは本番ビルドでは有効にしないでください。 [dynamic_analysis_enable_assertions]

    Run-time assertions are checked in the dynamic analysis test code using Python unittest's assert methods.

    https://github.com/in-toto/in-toto/tree/develop/tests https://docs.python.org/3.7/library/unittest.html#assert-methods


    バッジには十分です！

    動的コード分析で発見されたすべての中程度および重大度の悪用可能な脆弱性は、確認された後、適時に修正されなければなりません。 [dynamic_analysis_fixed]

    Dynamic code analysis is executed as part of Continuous Integration testing. Pull Requests only get merged if Continuous Integration testing passes. https://github.com/in-toto/in-toto/blob/develop/.travis.yml



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

プロジェクト バッジ登録の所有者： Lukas Puehringer.
エントリの作成日時 2018-01-03 16:15:50 UTC、 最終更新日 2022-11-02 15:08:49 UTC 最後に2018-01-05 21:31:54 UTCにバッジ合格を達成しました。

もどる