vector_unity_cor

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

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

私たちは多言語で情報を提供していますが、翻訳版に矛盾や意味の不一致がある場合は、英語版を正式な記述とします。

これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください！バッジステータスは次のようになります。

バッジステータスの埋め込み方法は次のとおりです。

バッジステータスを表示するには、あなたのプロジェクトのマークダウンファイルに以下を埋め込みます

[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/12787/badge)](https://www.bestpractices.dev/projects/12787)

あるいは、以下をHTMLに埋め込みます

<a href="https://www.bestpractices.dev/projects/12787"><img src="https://www.bestpractices.dev/projects/12787/badge"></a>

これらは

レベルの基準です。

または

レベル基準を表示することもできます。

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

分析 8/8 ●

静的コード解析

Criterion [static_analysis]
適合

不適合

該当なし

?

選択した言語でこの基準を実装するFLOSSツールが少なくとも1つある場合、少なくとも1つの静的コード分析ツール（コンパイラの警告と「安全な」言語モード以外）を、ソフトウェアの主要な製品リリースの提案に、リリース前に適用する必要があります。 ^{[static_analysis]}
静的コード解析ツールは、ソフトウェアコードを実行せずに特定の入力を用いて（ソースコード、中間コード、または実行可能ファイルとして）調べます。この基準のために、コンパイラの警告と「安全な」言語モードは、静的コード解析ツールとしてカウントされません（これらは通常、速度が重要なため深い解析を行いません）。このような静的コード解析ツールの例には、cppcheck (C, C++)、clang静的解析 (C, C++)、SpotBugs (Java)、FindBugs (Java) (FindSecurityBugsを含む)、PMD (Java)、Brakeman (Ruby on Rails)、lintr (R)、goodpractice (R), Coverity Quality Analyzer、SonarQube、 Codacyおよび HP Enterprise Fortify Static Code Analyzer.大きなツールのリストは、静的コード解析のためのWikipediaツール一覧, 静的コード解析に関するOWASP情報、 NISTソースコードセキュリティアナライザのリスト、およびウィーラーの静的解析ツール一覧などがあります。使用する実装言語で使用できるFLOSS静的解析ツールがない場合は、「該当なし」（N/A）を選択します。

Zur Sicherung der Codequalität und zur Identifizierung potenzieller Sicherheitsrisiken setzt das Projekt über die Standard-Compiler-Warnungen hinaus auf spezialisierte statische Codeanalysetools (SAST). Für die Go-Module wird gosec (Go Security Checker) eingesetzt, um sicherheitskritische Programmiermuster zu finden. Für die Python-Komponenten werden Tools wie bandit und pylint genutzt. Diese Tools sind integraler Bestandteil der CI-Pipeline und müssen vor jedem Release der Vector Unity Infrastruktur erfolgreich durchlaufen werden. Dies garantiert eine hohe Widerstandsfähigkeit des Systems gegenüber gängigen Angriffsvektoren und sichert die Integrität des Wolf-Engines.

Criterion [static_analysis_common_vulnerabilities]
適合

不適合

該当なし

?

static_analysis基準に使用される静的解析ツールの少なくとも1つが、分析された言語または環境における共通の脆弱性を探すためのルールまたはアプローチを含むことが、推奨されています。 ^{[static_analysis_common_vulnerabilities]}
一般的な脆弱性を探すために特別に設計された静的解析ツールは、それらを見つける可能性が高いです。つまり、静的ツールを使用すると、通常は問題を見つけるのに役立ちますので、利用を提案しますが、「合格」レベルのバッジには要求しません。

Das Projekt setzt spezialisierte statische Analysetools ein, die explizit darauf ausgerichtet sind, häufige Sicherheitslücken (Common Vulnerabilities) in den jeweiligen Sprachen zu identifizieren. Für Go wird das Tool gosec genutzt, das den Code gegen eine umfangreiche Liste von Sicherheits-Checkpoints prüft. Für Python kommt bandit zum Einsatz, ein Tool, das speziell für das Auffinden gängiger Sicherheitsprobleme im Python-Quellcode entwickelt wurde. Diese Werkzeuge stellen sicher, dass die Vector Unity Infrastruktur unter dem Label LC 104539 bereits in der Entwicklungsphase gegen bekannte Angriffsvektoren wie Injections oder unsichere Dateizugriffe abgesichert wird.

Criterion [static_analysis_fixed]
適合

不適合

該当なし

?

静的コード解析で発見された中程度および重大度の悪用可能な脆弱性はすべて、それらが確認された後、適時に修正されなくてはなりません。 ^{[static_analysis_fixed]}
Common Vulnerability Scoring System (CVSS)の基本的な定性的なスコアが中程度以上であれば、脆弱性は中程度以上の深刻度とみなされます。CVSS のバージョン 2.0 から 3.1 では、これは CVSS のスコア 4.0 以上に相当します。プロジェクトは、広く利用されている脆弱性データベース（国家脆弱性データベースなど）で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを用いて使用することができます。また、脆弱性が公開された時点で計算入力が公開されている場合には、脆弱性が公開された時点でのCVSSの最新バージョンを用いて深刻度を計算することもできます。基準 vulnerabilities_fixed_60_days では、公開後 60 日以内にすべての脆弱性を修正することが要求されていることに注意してください。

Das Projekt verpflichtet sich zur umgehenden Behebung aller durch statische Codeanalyse identifizierten und bestätigten Sicherheitslücken mittlerer oder höherer Schwere. Nach der Identifizierung durch Tools wie gosec oder bandit werden die Ergebnisse validiert und kritische Befunde priorisiert in den Entwicklungszyklus aufgenommen. Ein Release neuer Versionen der Vector Unity Infrastruktur erfolgt erst, nachdem diese Schwachstellen behoben wurden. Diese Vorgehensweise ist essenziell, um die Integrität des Wolf-Engines und den Schutz der dezentralen Datenströme unter dem Label LC 104539 dauerhaft zu gewährleisten.

Criterion [static_analysis_often]
適合

不適合

該当なし

?

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

Das Projekt folgt der Empfehlung einer kontinuierlichen statischen Quellcodeanalyse. Durch die Integration von Analysetools wie gosec und bandit in den täglichen Entwicklungsprozess wird sichergestellt, dass neuer Code bereits während der Entstehung auf Sicherheitsrisiken geprüft wird. Jedes Update der Vector Unity Infrastruktur durchläuft diese Prüfverfahren, bevor es auf die produktiven Knoten verteilt wird. Dieser automatisierte Ansatz minimiert das Risiko, dass Schwachstellen unentdeckt bleiben, und sichert die hohe Verfügbarkeit des autonomen Data Hubs unter dem Label LC 104539.

動的コード分析

Criterion [dynamic_analysis]
適合

不適合

?

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

Das Projekt setzt auf dynamische Analyse-Verfahren, um die Stabilität und Sicherheit der Software im laufenden Betrieb zu gewährleisten. Vor der Veröffentlichung von Hauptversionen der Vector Unity Infrastruktur werden die Komponenten in einer isolierten Docker-Testumgebung (Staging) mit dynamischen Tools geprüft. Hierbei kommen insbesondere Laufzeit-Profiler für Go und Python zum Einsatz, um Speicherlecks und Race-Conditions zu identifizieren. Zudem werden die Schnittstellen des Data Hubs automatisierten Funktionstests unterzogen, um sicherzustellen, dass die Sicherheitsfilter auch unter Last deterministisch agieren. Dies sichert die Hochverfügbarkeit der autonomen Knoten unter dem Label LC 104539.

Criterion [dynamic_analysis_unsafe]
適合

不適合

該当なし

?

プロジェクトで作成されたソフトウェアにメモリ安全でない言語（CやC ++など）を使用して作成されたソフトウェアが含まれている場合、少なくとも1つの動的ツール（たとえば、ファジーまたはウェブアプリケーションスキャナ）を、バッファの上書きなどのメモリの安全性の問題を検出するメカニズムと一緒にいつも使用します。プロジェクトがメモリ安全でない言語で書かれたソフトウェアを作成しない場合は、「該当なし」（N/A）を選択します。 ^{[dynamic_analysis_unsafe]}
メモリの安全性の問題を検出するメカニズムの例としては、アドレスサニタイザー（ASAN）（GCCおよびLLVMで利用可能）、 Memory Sanitizer 、および valgrind が含まれます。他に使用される可能性のあるツールには、スレッドサニタイザと定義されていない動作サニタイザを参照してください。広範なアサーションも機能します。

Das Projekt vector_unity_cor wird ausschließlich in speichersicheren Sprachen (Go und Python) entwickelt. Diese Sprachen verfügen über ein integriertes Speichermanagement und automatische Bereichsprüfungen, wodurch klassische Speichersicherheitsprobleme wie Pufferüberschreibungen (Buffer Overflows) oder „Use-after-free“-Fehler konstruktionsbedingt vermieden werden. Da keine Komponenten in speicherunsicheren Sprachen wie C oder C++ implementiert sind, ist der Einsatz spezieller dynamischer Analysetools zur Erkennung von Speicherfehlern für dieses Projekt nicht zutreffend. Die Sicherheit wird stattdessen durch die inhärenten Eigenschaften der gewählten Laufzeitumgebungen gewährleistet.

Criterion [dynamic_analysis_enable_assertions]
適合

不適合

?

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

Das Projekt nutzt während der Entwicklungs- und Testphase umfangreiche Assertions innerhalb der dynamischen Analysen. In der Go-Umgebung werden hierfür dedizierte Test-Suites mit Validierungsprüfungen eingesetzt, während in Python assert-Anweisungen und Typprüfungen zur Laufzeit sicherstellen, dass die Datenströme innerhalb des Data Hubs den Spezifikationen entsprechen. Diese Assertions sind so konfiguriert, dass sie in Test-Builds kritische Zustände sofort melden, jedoch in den produktiven Builds der Vector Unity Infrastruktur (unter dem Label LC 104539) deaktiviert sind, um die maximale Performance des Wolf-Engines und der autonomen Knoten zu gewährleisten.

Criterion [dynamic_analysis_fixed]
適合

不適合

該当なし

?

動的コード分析で発見されたすべての中程度および重大度の悪用可能な脆弱性は、確認された後、適時に修正されなければなりません。 ^{[dynamic_analysis_fixed]}
動的コード分析を実行しておらず、この方法で脆弱性が見つからない場合は、「該当なし」（N/A）を選択してください。 Common Vulnerability Scoring System (CVSS)の基本的な定性的スコアが中以上の場合、脆弱性は中程度以上の重大度と見なされます。 CVSSバージョン2.0から3.1では、これは4.0以上のCVSSスコアに相当します。プロジェクトは、広く使用されている脆弱性データベース（ National Vulnerability Databaseなど）で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを使用して使用できます。代わりに、脆弱性が公表された後に計算入力が公開された場合、プロジェクトは脆弱性の開示時に最新バージョンのCVSSを使用して重大度を自ら計算することができます。

Das Projekt verpflichtet sich zur sofortigen Behebung aller durch dynamische Analysen identifizierten und bestätigten Sicherheitslücken mittlerer oder höherer Schwere. Ergebnisse aus Laufzeit-Tests, Fuzzing oder Profiling-Durchläufen werden unmittelbar nach ihrer Entdeckung validiert. Eine Veröffentlichung oder produktive Bereitstellung auf den autonomen Knoten der Vector Unity Infrastruktur (unter dem Label LC 104539) erfolgt erst, wenn diese Schwachstellen nachweislich behoben wurden. Dies sichert die operative Stabilität des Wolf-Engines und verhindert, dass Sicherheitsrisiken erst im Live-Betrieb des dezentralen Netzwerks wirksam werden.

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

プロジェクトバッジ登録の所有者： Vitalij Wolf.
エントリの作成日時 2026-05-08 23:50:40 UTC、 最終更新日 2026-05-10 20:46:48 UTC 最後に2026-05-10 20:46:48 UTCにバッジ合格を達成しました。

vector_unity_cor

基本的情報 13/13 ●

一般

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

FLOSSライセンス

ドキュメンテーション

その他

変更管理 9/9 ●

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

一意的なバージョン番号

リリースノート

報告 8/8 ●

バグ報告プロセス

脆弱性報告プロセス

品質 13/13 ●

作業ビルドシステム

自動テストスイート

新機能テスト

警告フラグ

セキュリティ 16/16 ●

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

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

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

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

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

分析 8/8 ●

静的コード解析

動的コード分析

vector_unity_cor

基本的情報 13/13 ●

一般

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

FLOSSライセンス

ドキュメンテーション

その他

変更管理 9/9 ●

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

一意的なバージョン番号

リリースノート

報告 8/8 ●

バグ報告プロセス

脆弱性報告プロセス

品質 13/13 ●

作業ビルドシステム

自動テスト スイート

新機能テスト

警告フラグ

セキュリティ 16/16 ●

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

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

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

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

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

分析 8/8 ●

静的コード解析

動的コード分析

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

自動テストスイート