Bartholomew Autonomous Trust Protocol (BTP)

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

ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。また、プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。しかし、ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。たとえば、いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。バッジを獲得するには、すべてのMUSTおよびMUST NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合は満たさなくても構いません。そしてすべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮することが望まれます。フィードバックは、 GitHubサイトのissueまたはpull requestとして提示されれば歓迎します。また、議論のためのメールリストも用意されています。

私たちは多言語で情報を提供していますが、翻訳版に矛盾や意味の不一致がある場合は、英語版を正式な記述とします。
これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください！バッジステータスは次のようになります。 プロジェクト 14198 のバッジ レベルは silver です バッジステータスの埋め込み方法は次のとおりです。
バッジステータスを表示するには、あなたのプロジェクトのマークダウンファイルに以下を埋め込みます
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14198/badge)](https://www.bestpractices.dev/projects/14198)
あるいは、以下をHTMLに埋め込みます
<a href="https://www.bestpractices.dev/projects/14198"><img src="https://www.bestpractices.dev/projects/14198/badge"></a>


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

Baseline Series: ベースラインレベル1 ベースラインレベル2 ベースラインレベル3

        

 基本的情報 5/5 ●

  • 一般

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

    In-process execution guardrail, mathematical invariant engine, and cryptographic attestation substrate for autonomous AI agents and tool pipelines.

    SPDXライセンスの表現形式を使用してください。 例：「Apache-2.0」、「BSD-2-Clause」、「BSD-3-Clause」、「GPL-2.0+」、「LGPL-3.0+」、「MIT」、「(BSD-2-Clause OR Ruby)」。一重引用符または二重引用符を含めないでください。
    複数の言語がある場合は、コンマを区切り（スペースを入れてもよい）としてリストし、使用頻度の高いものから順に並べます。使用言語が多くある場合は、少なくとも最初の3つの最も多く使われるものをリストアップしてください。言語がない場合（例：ドキュメントだけ、またはテスト専用のプロジェクトの場合）、1文字 " - "を使用します。言語ごとにある大文字・小文字の慣用を踏襲してください（例：「JavaScript」）。
    Common Platform Enumeration（CPE）は、情報技術（IT）システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

    Bartholomew is an autonomous trust protocol, invariant engine, and execution guardrail library for AI agents and distributed machine execution.

  • 前提要件


    バッジには十分です！

    プロジェクトは、シルバー レベル バッジを達成しなければなりません。 [achieve_silver]

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


    バッジには十分です！

    プロジェクトは2以上の "バス ファクタ"を持つ必要があります。 (URLが必要です) [bus_factor]
    「バス ファクタ」（別名「トラック ファクタ」）は、知見があり有能な人材が離脱して、プロジェクトが停止に至る時に、プロジェクトから突然消失する（「バスに当たった」）プロジェクトメンバーの最小人数です。 トラック ファクタツールは、GitHub上のプロジェクトに対してこれを見積もることができます。詳細については、Cosentino et al。の Gitリポジトリのバス ファクタの評価を参照してください。

    Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json


    バッジには十分です！

    プロジェクトには少なくとも2人の関係を持たない重要な貢献者がいなければなりません。 (URLが必要です) [contributors_unassociated]
    同じ組織によって作業に対しに支払われ（従業員または請負業者）、組織がプロジェクトの成果の恩恵を受ける場合、貢献者は関連します。財務補助金が他の組織を通過する場合、同じ組織のものであると見なされません（例えば、共通の政府やNGOのソースから異なる組織に支払われた科学補助金は、貢献者を関連させません）。過去1年間にプロジェクトに些細でない貢献をしていれば、その人は大きな貢献をしています。重要な貢献者の良い指標の例としては、少なくとも1,000行のコード、50個のコミット、または少なくとも20ページの文書化が挙げられます。

    Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json


  • その他


    バッジには十分です！

    プロジェクトは、各ソースファイルにライセンスステートメントを含まなければなりません。これは、各ファイルの先頭近くに次のコメントを含めることによって行うことができます： SPDXライセンス識別子：[プロジェクトに対するSPDXライセンス表現] [license_per_file]
    これは、ライセンスを特定する自然言語での記述を含めることによっても行うことができます。プロジェクトには、ライセンス テキストまたは完全なライセンステキストを指し示す安定したURLを含めることもできます。 license_location基準は、プロジェクトライセンスが標準の場所にあることを要求します。 SPDXライセンスの詳細については、このSPDXチュートリアルを参照してください。 copyright_per_file との関係に注意してください。その内容は通常、ライセンス情報に先行します。

    Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json


 変更管理 4/4 ●

 品質 7/7 ●

 セキュリティ 4/5 ●

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

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

    バッジには十分です！

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

    Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json


    バッジには十分です！

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

    Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json


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


    バッジには不十分です。

    プロジェクトウェブサイト、リポジトリ（ウェブからアクセス可能な場合）、およびダウンロードサイト（別々の場合）には、許容できない値を持つキー強化ヘッダーが含まれていなければなりません。 (URLが必要です) [hardened_site]
    GitHubやGitLabはこれを満たしていることが知られているので注意してください。https://securityheaders.com/ のようなサイトは、これをすぐに確認することができます。重要なセキュリティ強化ヘッダーは以下の通りです。Content Security Policy (CSP)、HTTP Strict Transport Security (HSTS)、X-Content-Type-Options (「nosniff」として)、および X-Frame-Options 。Web ページからログインする機能のない完全に静的な Web サイトでは、いくつかの強化ヘッダーを省略してもリスクは少なくて済みますが、そのようなサイトを検出する信頼できる方法がないため、完全に静的なサイトであってもこれらのヘッダーが必要です。

    Required security hardening headers missing: https://bartholomew.info: content-security-policy, x-content-type-options, x-frame-options


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


    バッジには十分です！

    プロジェクトは過去5年間にセキュリティレビューを実施していなければなりません。このレビューは、セキュリティ要件とセキュリティ境界を考慮しなければならりません。 [security_review]
    これは、プロジェクトメンバーおよび/または独立した評価によって行うことができます。この評価は、静的および動的解析ツールによってサポートされることができますが、ツールが検出できない問題（特に設計上）を特定するためには、人間によるレビューが必要です。

    Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json


    バッジには十分です！

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

    Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json


 分析 2/2 ●

  • 動的コード分析


    バッジには十分です！

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

    Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json


    バッジには十分です！

    プロジェクトは、生成するソフトウェアに多くの実行時アサーションを含めるべきであり、動的分析中にそれらのアサーションをチェックするべきです。 [dynamic_analysis_enable_assertions]
    この基準は、本番環境でアサーションを有効にすることを示唆するものではありません。それは完全にプロジェクトとそのユーザーが決定することです。この基準の焦点は、展開前の動的分析中の障害検出を改善することです。プロダクション環境でのアサーションの有効化は、動的分析（テストなど）中にアサーションを有効にすることとはまったく異なります。場合によっては、プロダクション環境でアサーションを有効にすることは非常に賢明ではありません（特に高整合性コンポーネントの場合）。プロダクション環境でアサーションを有効にすることには多くの議論があります。たとえば、ライブラリは呼び出し元をクラッシュさせてはなりません。ライブラリが存在するとアプリストアによる拒否が発生する可能性があります。また、プロダクション環境でアサーションをアクティブにすると、秘密鍵などの秘密データが公開される可能性があります。多くのLinuxディストリビューションではNDEBUGが定義されていないため、これらのディストリビューションのプロダクション環境ではデフォルトで C/C++ assert() が有効になります。これらの環境でのプロダクション環境では、別のアサーションメカニズムを使用するか、 NDEBUGを定義することが重要です。

    Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json



このデータは、Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0)のもとで利用可能です。これは、データ受領者が、データ受領者がこの契約のテキストを共有データとともに利用可能にする限り、変更の有無にかかわらずデータを共有できることを意味します。ivegotahunnitonitおよびOpenSSFベストプラクティスバッジのコントリビューターにクレジットを表示してください。

プロジェクト バッジ登録の所有者： ivegotahunnitonit.
エントリの作成日時 2026-08-22 02:49:08 UTC、 最終更新日 2026-08-22 03:47:42 UTC 最後に2026-08-22 03:14:33 UTCにバッジ合格を達成しました。