シンガポール オープンソースソフトウェアとサードパーティ依存のSBOMとリアルタイム脆弱性監視に関するアドバイザリー (2025.02.20)

こんにちは、丸山満彦です。

シンガポールのサイバーセキュリティ庁が、OWASPと協力してソフトウェア開発者に対し、脆弱性管理に対する持続可能で自動化されたアプローチを実装する方法についてのガイダンスを公表していましたね...

SBOMの必要性は理解はされているが、実装はなかなか難しいというのは、どこでも同じかもです。でも、必要ですよね...

⚫︎ Cyber Security Authority: CSA

・2025.02.20 Advisory on Software Bill of Materials and Real-time Vulnerability Monitoring for Open-Source Software and Third-Party Dependencies

・[PDF] 

Advisory on Software Bill of Materials and Real-time Vulnerability Monitoring for Open-Source Software and Third Party Dependencies	オープンソースソフトウェアとサードパーティ依存関係のソフトウェア部品表とリアルタイム脆弱性モニ タリングに関する助言
Introduction	序文
1. The integration of Open-Source Software (OSS) in software development introduces significant cybersecurity challenges, particularly regarding vulnerabilities in third-party dependencies. Notable incidents, such as Log4j and Heartbleed, underscore these risks. On Log4j, many organisations struggled to assess system compromises due to a lack of visibility into their software components and dependencies, with delayed responses to discovered vulnerabilities. On Heartbleed, it affected the widely used OpenSSL cryptography library, leading to the theft of 4.5 million medical records from a major overseas hospital chain.	1. ソフトウェア開発におけるオープンソースソフトウェア（OSS）の統合は、特にサードパーティ依存の脆弱性に関して、重大なサイバーセキュリティ上の課題をもたらす。Log4jやHeartbleedのような注目すべきインシデントが、こうしたリスクを浮き彫りにしている。Log4jでは、ソフトウェア・コンポーネントや依存関係の可視化が不十分であったため、多くの組織がシステム侵害のアセスメントに苦慮し、脆弱性の発見に対する対応が遅れた。Heartbleedについては、広く使われているOpenSSL暗号ライブラリに影響を及ぼし、海外の大手病院チェーンから450万件の医療記録が盗まれることになった。
2. These dependency threats are exacerbated by extent of third-party dependencies and critical vulnerabilities found in software development projects. According to studies, there are on average 68.8[1] dependencies per project and 5.1[2] critical vulnerabilities in an application. If developers are unaware of the full composition of their applications, the risks of cybersecurity breaches are significant. In the light of such trends, there is an impetus for developers to easily identify and address OSS dependencies to mitigate cybersecurity risks.	2. このような依存関係の脅威は、サードパーティーの依存性の広さと、ソフトウェア開発プロジェクトで発見された重大な脆弱性によって悪化している。調査によると、1つのプロジェクトあたり平均68.8[1]の依存性と5.1[2]の重大な脆弱性がアプリケーションに存在する。開発者が自分のアプリケーションの完全な構成を知らない場合、サイバーセキュリティ侵害のリスクは大きい。このような傾向を踏まえ、サイバーセキュリティリスクを緩和するために、開発者は OSS の依存関係を容易に識別し、対処することが求められている。
Intended audience of advisory	助言の対象読者
3. The advisory is intended for all software developers, especially those who incorporate OSS and third-party dependencies into their projects. While many developers are aware of cybersecurity risks, they may not have the resources and guidance to enforce cybersecurity during software development and implementation. To aid developers, the advisory offers guidance on a sustainable and automated approach to vulnerability management through Software Bill of Materials (SBOM) and real-time vulnerability monitoring.	3. この勧告は、すべてのソフトウェア開発者、特に OSS やサードパーティとの依存関係をプロジェクトに組み込んでい る開発者を対象としている。多くの開発者はサイバーセキュリティリスクを認識しているが、ソフトウ ェアの開発・実装時にサイバーセキュリティを実施するためのリソースやガイダンスを持っていない可能性がある。開発者を支援するために、この勧告では、ソフトウェア部品表（SBOM）とリアルタイムの脆弱性監視を通じた脆弱性管理の持続可能で自動化されたアプローチに関するガイダンスを提供している。
Value proposition of SBOM and real-time monitoring of vulnerabilities	SBOMと脆弱性のリアルタイム・モニタリングの価値提案
4. The traditional way of manually managing OSS dependencies is inefficient and prone to errors. Furthermore, developers must sift through complex codebases to identify and fix vulnerable software components.	4. OSSの依存関係を手作業で管理する従来の方法は、非効率的でエラーが発生しやすい。さらに、開発者は脆弱性のあるソフトウェア・コンポーネントを特定し、修正するために、複雑なコードベースをふるいにかけなくてはならない。
5. Generating Software Bill of Materials (SBOM) ensures developers are not using known vulnerable dependencies and provide them full visibility into software components. SBOM provides a structured and formal record of components used to build software. It equips organisations with a clear view of their software environment, ensuring that vulnerabilities can be managed more effectively. Through the integration of SBOM tools into software development workflows, developers can automatically track each component from the start, reducing manual effort and human error. It enables them to significantly reduce technical debt by identifying outdated or vulnerable components much earlier, in turn decreasing future remediation workloads.	5. ソフトウェア部品表（SBOM）を生成することで、開発者が既知の脆弱な依存関係を使用していないことを保証し、ソフトウェア部品に対する完全な可視性を提供する。SBOMは、ソフトウェア構築に使用されるコンポーネントの構造化された正式な記録を提供する。これにより、組織はソフトウェア環境を明確に把握できるようになり、脆弱性をより効果的に管理できるようになる。SBOMツールをソフトウェア開発ワークフローに統合することで、開発者は各コンポーネントを最初から自動的に追跡できるようになり、手作業や人的ミスを減らすことができる。これにより、開発者は、古くなったコンポーネントや脆弱性のあるコンポーネントをより早い段階で特定し、技術的負債を大幅に削減することができる。
6. SBOM also improves response times by allowing developers to quickly identify and fix vulnerable components and collaborate across the organisation for holistic vulnerability management. This streamlined process not only minimises complexity but also fosters collaboration among developers and cybersecurity professionals, allowing cybersecurity risks to be addressed proactively without stifling innovation. If SBOM is integrated into CI/CD pipelines, it allows real-time monitoring of new vulnerabilities through automation of SBOM generation, signing and alerts. The SBOM can also be used to foster collaboration across teams, including SecOps, Incident Response (IR) and development teams for holistic vulnerability management and improved response times.	6. SBOMはまた、開発者が脆弱性コンポーネントを迅速に特定して修正し、組織全体で協力して全体的な脆弱性管理を行えるようにすることで、対応時間を改善する。この合理化されたプロセスは、複雑さを最小限に抑えるだけでなく、開発者とサイバーセキュリティ専門家のコラボレーションを促進し、イノベーションを阻害することなく、サイバーセキュリティリスクにプロアクティブに対処することを可能にする。SBOMをCI/CDパイプラインに統合すれば、SBOMの生成、署名、アラートの自動化を通じて、新しい脆弱性をリアルタイムで監視できる。SBOMはまた、SecOps、インシデントレスポンス（IR）、開発チームを含むチーム間のコラボレーションを促進し、全体的な脆弱性管理とレスポンスタイムの改善に利用できる。
Three step approach to managing vulnerabilities through SBOMs	SBOMによる脆弱性管理の3ステップアプローチ
Figure 1. Three step approach to managing vulnerabilities through SBOMs	図1. SBOMによる脆弱性管理の3ステップアプローチ
7. The three-step approach is as follows[3] :	7. 3段階のアプローチは以下のとおりである[3]：
• Select tool: The chosen tool should accurately identify and list components as well as direct[4] and indirect[5] dependencies of the software. The tool should also integrate seamlessly with continuous integration/continuous deployment (CI/CD)[6] pipelines such as GitHub Actions, GitLab CI/CD or equivalent software.	- ツールを選択する： 選択したツールは、ソフトウェアの直接[4]および間接的[5]な依存関係だけでなく、コンポーネントを正確に識別してリスト化する必要がある。また、ツールは、GitHub Actions、GitLab CI/CD、または同等のソフトウェアなどの継続的インテグレーション／継続的展開（CI/CD）[6]パイプラインとシームレスに統合する必要がある。
• Generate and sign the SBOM: The tool should be used to generate an SBOM that complies with industry standards such as CycloneDX or SPDX[7] . Signing the SBOM after its generation ensures authenticity and provides assurance that it originates from a trusted source. Developers should leverage on available tools[8] to publish signed records into transparency logs, enhancing trust and verifiability through immutable records of signing events.	- SBOM の生成と署名：ツールは、CycloneDX や SPDX[7]などの業界標準に準拠した SBOM を生成するために使用されるべきである。生成後に SBOM に署名することで、認証が保証され、信頼できるソースから生成されたことが保証される。開発者は利用可能なツール[8]を活用して、署名されたレコードを透明性ログに公開し、署名イベントの不変の記録を通じて信頼性と検証可能性を高めるべきである。
• Proactive vulnerability management: The generated SBOM should be published to a secure repository and automatically ingested by tools like OWASP Dependency-Track[9] for continuous vulnerability monitoring and Nday vulnerability identification.	- プロアクティブな脆弱性管理： 生成された SBOM を安全なリポジトリに公開し、OWASP Dependency-Track[9]のようなツールに自動的に取り込ませて、脆弱性の継続的なモニタリングと Nday 脆弱性の特定を行う。
8. As the software development environment varies for each system, developers should also take note of the following practical considerations:	8. ソフトウェア開発環境はシステムごとに異なるため、開発者は以下の実用的な考慮事項にも留意すべきである：
• The SBOM is only as comprehensive as the manifest files generated. If the codebase includes obscure or less common programming languages, some dependencies may not be detected;	- SBOM は、生成的なマニフェストファイルと同程度に包括的である。コードベースに不明瞭なプログラミング言語や一般的でないプログラミング言語が含まれている場合、一部の依存関係が検知されない可能性がある。
• For SaaS and closed-source software, developers should request the SBOMs from their third-party providers as these SBOMs provide the most comprehensive coverage of the software components and dependencies. If developers are unable to obtain SBOMs from their third-party providers, the selected SBOM generation tool need to be able to perform supplementary checks in the respective environments. In particular, SaaS software could use runtime SBOMs[10] , capturing dynamically loaded or run-time injected components during execution. For closed-source software, binary-based SBOM tools[11] could be used to create an inventory of the software components used. Such tools inspect the compiled binary code, which is the final product of the software. Once developers discover vulnerabilities through the SBOMs, they need to inform their third-party providers to remediate them;	- SaaS およびクローズドソースソフトウェアの場合、開発者はサードパーティプロバイダに SBOM を要求すべきである。これらの SBOM はソフトウェアコンポーネントと依存関係を最も包括的にカバーしているからである。開発者がサードパーティプロバイダからSBOMを入手できない場合、選択したSBOM生成ツールは、それぞれの環境で補足的なチェックを実行できる必要がある。特にSaaSソフトウェアでは、実行時に動的にロードされるコンポーネントや実行時に注入されるコンポーネントをキャプチャする、ランタイムSBOM[10]を使用することができる。クローズドソースソフトウェアの場合、バイナリベースのSBOMツール[11]を使用して、使用されているソフトウェアコンポーネントのインベントリを作成することができる。このようなツールは、ソフトウェアの最終成果物であるコンパイル済みバイナリコードを検査する。開発者は、SBOMを通じて脆弱性を発見したら、その脆弱性を修正するようにサードパーティ・プロバイダに通知する必要がある。
• Developers need to verify identified vulnerabilities for exploitability as the vulnerabilities may not be relevant in their software development environments. Without appropriate verification, there could be a high volume of vulnerabilities surfaced through the SBOM and developers risk being overwhelmed with false positives and time spent on subsequent remediation. Developers should start the verification process by using industry filters such as CISA’s Known Exploited Vulnerabilities (KEV)[12] that only alerts on CVEs that are actively exploited. Once the vulnerabilities are filtered, vulnerabilities can be assessed for the likelihood of being exploited through the Exploit Prediction Scoring System (EPSS)[13] . After identifying vulnerabilities that are likely to be exploited, they can be prioritised for remediation using Common Vulnerability Scoring Systems (CVSS), which rates the severity of vulnerabilities.	- 開発者は、特定された脆弱性の悪用可能性を検証する必要がある。脆弱性は、開発者のソフトウェア開発環境では関連性がない可能性があるからである。適切な検証を行わなければ、SBOMを通じて大量の脆弱性が表面化する可能性があり、開発者は誤検知に圧倒され、その後の修正に時間を費やすリスクがある。開発者は、CISAのKnown Exploited Vulnerabilities（KEV）[12]のような、活発に悪用されているCVEのみに警告を発する業界フィルタを使用して検証プロセスを開始すべきである。脆弱性のフィルタリングが完了したら、エクスプロイト予測スコアリングシステム（Exploit Prediction Scoring System：EPSS）[13]を用いて脆弱性が悪用される可能性を評価することができる。悪用される可能性の高い脆弱性を特定した後は、脆弱性の深刻度を評価する共通脆弱性スコアリングシステム（CVSS）を用いて、脆弱性を改善するための優先順位をつけることができる。
Automating capabilities in code repositories platforms to manage OSS vulnerabilities	OSSの脆弱性を管理するために、コードリポジトリプラットフォームの機能を自動化する
9. Both commercial and Open-Source Software projects commonly rely on opensource dependencies, typically hosted on code repository platforms such as GitHub and GitLab. As central hubs for OSS development, GitHub and GitLab are used by developers who collaborate on projects of varying scope and complexity. Given the widespread use of such code repository platforms, managing vulnerabilities are even more critical for maintaining a secure software ecosystem. Such environments provide automated workflow functionalities on managing vulnerabilities, with automation enabling a seamless integration of security practices into the development process.	9. 商業プロジェクトもオープンソースソフトウェアプロジェクトも、一般的にオープンソースの依存関係に依存しており、GitHub や GitLab のようなコードリポジトリプラットフォームにホストされている。OSS開発の中心的なハブとして、GitHubとGitLabは、様々な範囲と複雑さのプロジェクトで共同作業する開発者によって使用されている。このようなコード・リポジトリ・プラットフォームが広く使用されていることを考えると、脆弱性の管理は、安全なソフトウェア・エコシステムを維持するためにさらに重要になっている。このような環境は、脆弱性の管理に関する自動化されたワークフロー機能を提供し、自動化によって、開発プロセスにセキュリティ対策をシームレスに統合することを可能にする。
10. Developers should use tools such as GitHub Actions and GitLab CI/CD that allow for the automated creation and vulnerability checking of SBOMs. While SBOM signing is not a native feature, external tools[14] can be integrated into the workflow. Refer to Annex A for the full script that automates these actions for GitHub Actions and a similar workflow can be implemented for GitLab CI/CD (Annex B).	10. 開発者は、GitHub Actions や GitLab CI/CD のような、SBOM の自動作成と脆弱性チェックを可能にするツールを使用すべきである。SBOM署名はネイティブな機能ではないが、外部ツール[14]をワークフローに統合することができる。GitHub Actionsのこれらのアクションを自動化するスクリプトの完全版については附属書Aを参照のこと。GitLab CI/CDについても同様のワークフローを実装することができる（附属書B）。
11. Developers should either remove vulnerable components if the functionalities provided through these components are not crucial or update these components to non-vulnerable versions. Developers should thoroughly test their applications to verify the application works as intended and update the SBOM documentation to record which components were removed and updated. This approach enhances the cybersecurity of the software and protects users from known exploits.	11. 開発者は、脆弱性のあるコンポーネントを通じて提供される機能が重要でない場合は、脆弱性のあるコンポーネントを削除するか、脆弱性のないバージョンに更新する。開発者は、アプリケーションが意図したとおりに動作することを検証するためにアプリケーションを徹底的にテストし、どのコンポーネントが削除され更新されたかを記録するために SBOM ドキュメントを更新するべきである。このアプローチは、ソフトウェアのサイバーセキュリティを強化し、既知の悪用からユーザを保護する。
12. Developers should publish SBOM, its signature and certificate alongside the digital files. This allows downstream users in the software development ecosystem to easily access and verify the SBOM, ensuring that they are working with a secure and authentic version of the software. Users can also leverage the SBOM to continuously monitor for new vulnerabilities.	12. 開発者は、SBOM、その署名、および証明書をデジタルファイルと一緒に公開する。これにより、ソフトウェア開発エコシステムの下流のユーザーは、SBOM に簡単にアクセスして検証することができ、安全で認証されたバージョンのソフトウェアを使用していることを確認できる。ユーザーはまた、SBOM を活用して、新しい脆弱性を継続的に監視することもできる。
Real-time monitoring of vulnerabilities through OWASP Dependency Track	OWASP Dependency Track による脆弱性のリアルタイム監視
13. OWASP Dependency Track (DT) provides real-time vulnerability monitoring capabilities through SBOM ingestion and continual checking against current threat intelligence. OWASP Dependency Track (DT) goes beyond basic scanning by incorporating the Exploit Prediction Scoring System (EPSS), allowing developers to prioritise vulnerabilities based on their likelihood of exploitation. Refer to Annex C for more details on the deployment of OWASP DT.	13. OWASP Dependency Track（DT）は、SBOM の取り込みと、最新の脅威インテリジェンスとの継続的なチェッ クを通じて、リアルタイムの脆弱性監視機能を提供する。OWASP Dependency Track（DT）は、Exploit Prediction Scoring System（EPSS）を組み込むことで、基本的なスキャンを超え、開発者が悪用の可能性に基づいて脆弱性に優先順位をつけることを可能にする。OWASP DT の展開の詳細については、附属書 C を参照されたい。
14. Developers should integrate the OWASP DT tool into CI/CD pipelines for realtime monitoring, consistent automation of SBOM generation and signing, and alerts for new vulnerabilities. Developers should securely store signed SBOM into centralised repositories to support collaboration across teams, including SecOps, Incident Response (IR) and development teams. In addition, developers need to establish governance policies for SBOM storage, access control and lifecycle management in collaboration with their Chief Information Security Officers (CISOs).	14. 開発者は、リアルタイムの監視、SBOM 生成と署名の一貫した自動化、および新たな脆弱性に対する警告のために、OWASP DT ツールを CI/CD パイプラインに統合すること。開発者は、SecOps、インシデントレスポンス（IR）、開発チームを含むチーム間のコラボレーションをサポートするために、署名された SBOM を一元化されたリポジトリに安全に保管すべきである。さらに、開発者は、最高情報セキュリティ責任者（CISO）と協力して、SBOMの保管、アクセス管理、ライフサイクル管理に関するガバナンスポリシーを確立する必要がある。
Conclusion	結論
15. SBOMs and real-time monitoring of vulnerabilities provide developers a sustainable and automated approach to address risks posed by Open-Source Software (OSS) and third-party software components, in turn enhancing the cybersecurity posture of the software supply chain. Such an approach allows developers and system owners to have visibility on software components and dependencies and improve response times to address vulnerabilities.	15. SBOMと脆弱性のリアルタイムモニタリングは、オープンソースソフトウェア（OSS）とサードパーティ製ソフトウェアコンポーネントがもたらすリスクに対処するための持続可能で自動化されたアプローチを開発者に提供し、ひいてはソフトウェアサプライチェーンのサイバーセキュリティ態勢を強化する。このようなアプローチにより、開発者とシステムオーナーは、ソフトウェアコンポーネントと依存関係を可視化し、脆弱性に対処するためのレスポンスタイムを改善することができる。
Acknowledgement	謝辞
16. This advisory was jointly developed by the Cyber Security Agency of Singapore and OWASP Foundation.	16. この勧告は、シンガポールのサイバーセキュリティ庁と OWASP 財団が共同で作成した。
Disclaimer	免責事項
17. The information and advice contained in this document is provided "as is" without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by the Cyber Security Agency of Singapore, OWASP Foundation or GitHub. This document shall not be used for advertising or product endorsement purposes.	17. 本文書に含まれる情報および助言は、いかなる保証もなく「現状のまま」プロバイダとして提供される。商号、商標、製造事業者、その他による特定の商用製品、プロセス、サービスへの言及は、Cyber Security Agency of Singapore、OWASP Foundation、GitHub による推奨、推薦、支持を意味するものではない。本文書は、広告や製品の推奨を目的として使用してはならない。
List of References	参考文献一覧
S/N Document Source Year of Publication	S/N 文書出典 発行年
1 The Minimum Elements for a Software Bill of Materials (SBOM) NTIA 2021	1 The Minimum Elements for a Software Bill of Materials (SBOM) NTIA 2021
2 Addressing Cybersecurity Challenges in OpenSource Software OpenSSF 2022	2 Addressing Cybersecurity Challenges in OpenSource Software OpenSSF 2022
3 Guidance on Introduction of Software Bill of Materials (SBOM) for Software Management METI 2023	3 Guidance on Introduction of Software Bill of Materials (SBOM) for Software Management METI 2023
4 Recommendations for Software Bill of Materials (SBOM) Management NSA 2024	4 Recommendations for Software Bill of Materials (SBOM) Management NSA 2024
5 Documentation on OWASP Dependency-Track OWASP 2024, v4.11	5 Documentation on OWASP Dependency-Track OWASP 2024, v4.
6 CycloneDX Authoritative Guide to SBOM OWASP 2024, 2nd edition	6 CycloneDX Authoritative Guide to SBOM OWASP 2024, 2nd edition
Annex A – Sample workflow. yaml script for GitHub Actions	附属書 A - サンプルワークフロー。GitHub Actions 用 yaml スクリプト
Annex B – Sample workflow. yaml script for GitLab CI/CD	附属書 B - サンプルワークフロー。GitLab CI/CD 用 yaml スクリプト
Annex C – Deploying and using Dependency-Track	附属書 C - Dependency-Track の展開と使用。

[1] PDF
[2] [web]
[3] The approach is adapted from existing best practices found in sources 1,3 to 6 of bibliography.	[3] このアプローチは、参考文献のソース1,3から6にある既存のベストプラクティスから採用されている。
[4] Direct refers to software components that are explicitly required by the code.	[4] 直接とは、コードによって明示的に必要とされるソフトウェアコンポーネントを指す。
[5] Indirect refers to software components required by the direct dependencies.	[5] 間接的とは、直接的な依存関係によって必要とされるソフトウェア・コンポーネントを指す。
[6] GitHub Actions and GitLab CI/CD are CI/CD tools to automate workflows like building, testing, and deploying code.	[6] GitHub ActionsとGitLab CI/CDは、コードのビルド、テスト、展開のようなワークフローを自動化するためのCI/CDツールである。
[7] These are industry standards for SBOM creation, distribution, and consumption, enabling interoperability and integration into existing workflows.	[7] これらはSBOMの作成、配布、消費のための業界標準であり、相互運用性と既存のワークフローへの統合を可能にしている。
[8] An example of such a tool is Sigstore, which provides signing, verification, and provenance checks to secure Open-Source Software distribution.	[8] このようなツールの例として、オープンソースソフトウェアの安全な配布のために、署名、検証、出所チェックを提供するSigstoreがある。
[9] OWASP Dependency-Track tracks and identify software vulnerabilities through SBOM analysis.	[9] OWASP Dependency-Trackは、SBOM分析を通じてソフトウェアの脆弱性を追跡し、特定する。
[10] Runtime SBOMs requires the system to be analysed when running. Some detailed information may be available only after the system has been run for a period of time until the complete functionality has been exercised. Example of runtime SBOM tools are Anchor Syft and Slim.AI.	[10] ランタイムSBOMは、実行時にシステムを分析することを要求する。一部の詳細情報は、完全な機能が発揮されるまで、システムが一定期間実行された後にのみ利用可能となる場合がある。実行時SBOMツールの例としては、Anchor SyftとSlim.AIがある。
[11] Example of binary-based SBOM tools are Black Duck Binary Analysis and Tern.	[11] バイナリベースの SBOM ツールの例としては、Black Duck Binary Analysis と Tern がある。
[12] CISA’s Known Exploited Vulnerabilities (KEV) is a catalogue of actively exploited vulnerabilities to help prioritise security remediation.	[12] CISAの既知の脆弱性（KEV：Known Exploited Vulnerabilities）は、積極的に悪用されている脆弱性のカタログであり、セキュリティ改善の優先順位付けに役立つ。
[13] Exploit Prediction Scoring System (EPSS) is a predictive model that scores the probability of a software vulnerability being exploited, aiding in prioritising security responses.	[13] Exploit Prediction Scoring System（EPSS）は、ソフトウェアの脆弱性が悪用される確率をスコア化する予測モデルであり、セキュリティ対応の優先順位付けに役立つ。
[14] An example is Cosign, which is a tool to sign, verify and attest software artifacts securely.	[14] Cosign は、ソフトウェア成果物に安全に署名、検証、証明するツールである。