Strigoi

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

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

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

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

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

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

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

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

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

これらは

レベルの基準です。

または

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

基本的情報 13/13 ●

識別情報

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

プロジェクトを簡単に説明してください。

Find AI infrastructure vulnerabilities before attackers do. Security testing for MCP servers, AI agents, CLI AI platforms and LLM systems.

プロジェクト全体のURLは？
https://github.com/macawi-ai/Strigoi

バージョン管理リポジトリのURLは何ですか（プロジェクトURLと同じでもかまいません）。
https://github.com/macawi-ai/Strigoi

どのようなプログラミング言語を使ってプロジェクトを実装していますか？
複数の言語がある場合は、コンマを区切り（スペースを入れてもよい）としてリストし、使用頻度の高いものから順に並べます。使用言語が多くある場合は、少なくとも最初の3つの最も多く使われるものをリストアップしてください。言語がない場合（例：ドキュメントだけ、またはテスト専用のプロジェクトの場合）、1文字 " - "を使用します。言語ごとにある大文字・小文字の慣用を踏襲してください（例：「JavaScript」）。

Implementation languages

プロジェクトの Common Platform Enumeration（CPE）名は何ですか？
Common Platform Enumeration（CPE）は、情報技術（IT）システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。
基本的なプロジェクトウェブサイトのコンテンツ
Criterion [description_good]
適合

不適合

?

プロジェクトのウェブサイトは、ソフトウェアが何をするのか（何の問題を解決するのか）を簡潔に記述しなければなりません。 ^{[description_good]}
これは、潜在的なユーザーが理解できる言語でなければなりません（例えば、それは最小限の専門用語を使用します）。
https://github.com/macawi-ai/strigoi/
(e.g. core capabilities -->
Core Capabilities
🛡️ Security Assessment
```
Interactive CLI - Bash-like navigation with directional reconnaissance (north/south/east/west)
17+ Detection Patterns - API keys, credentials, PII, prompt injection, SSRF, path traversal
MCP Vulnerability Scanner - Specialized scanning for Model Context Protocol servers
Multi-Layer Analysis - 7-layer protocol inspection with Russian doll unpacking
```
📡 Real-Time Monitoring
```
NATS JetStream Integration - Distributed event streaming with persistent storage
A2MCP Bridge - Monitor AI CLI tools (Claude Code, Gemini, ChatGPT) via MCP protocol
Stream Tap - Live STDIO capture with security detection and smart redaction
MetaFrame Protocol - Standardized security telemetry format
```
🏗️ Platform Features
```
Multi-Architecture - AMD64, ARM64, ARMv7 (Raspberry Pi, NanoPi, Orange Pi)
Container-Native - Podman/Docker with rootless support
Web UI Dashboard - Real-time monitoring via http://localhost:8081/
Pre-compiled Binaries - Linux, macOS (Intel/Apple Silicon), Windows
```
Criterion [interact]
適合

不適合

?

プロジェクトのウェブサイトは、取得方法、フィードバックの提供方法（バグ報告や拡張機能）、ソフトウェアへの貢献方法に関する情報を提供しなければなりません。 ^[interact]
The README provides clear information on all three requirements:
1. Obtain: Multiple installation methods documented including pre-built binaries from GitHub Releases, wget commands for Linux/macOS/Windows, and build-from-source
  via install.sh. Direct links: https://github.com/macawi-ai/strigoi/releases
2. Feedback: Bug reports and enhancement requests via GitHub Issues, linked in README: https://github.com/macawi-ai/strigoi/issues
3. Contribute: Contributing section in README links to Development Methodology guide (docs/DEVELOPMENT_METHODOLOGY.md) covering code of conduct, development process, and pull request submission.
Criterion [contribution]
適合

不適合

?

貢献する方法に関する情報は、貢献プロセス（たとえばプルリクエストが使用されか、など）を説明する必要があります。 (URLが必要です) ^{[contribution]}
別段の記載がない限り、GitHub上のプロジェクトは、（GitHubが提供する）課題管理とプルリクエストを使用することを想定します。この情報は不足しているかもしれません。すなわち、プロジェクトがプルリクエストと課題追跡ツールを使うことか、メーリングリストへの投稿を言及している。（どちら？）

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/.

Criterion [contribution_requirements]
適合

不適合

?

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

https://github.com/macawi-ai/strigoi/blob/main/CONTRIBUTING.md
FLOSSライセンス

プロジェクトのライセンスはどのようなものですか？
SPDXライセンスの表現形式を使用してください。例：「Apache-2.0」、「BSD-2-Clause」、「BSD-3-Clause」、「GPL-2.0+」、「LGPL-3.0+」、「MIT」、「(BSD-2-Clause OR Ruby)」。一重引用符または二重引用符を含めないでください。

License
Criterion [floss_license]
適合

不適合

?
プロジェクトによって作成されたソフトウェアは、FLOSSとしてリリースされなければなりません。 ^{[floss_license]}
FLOSSは、オープンソース定義またはフリーソフトウェア定義を満たす方法でリリースされたソフトウェアです。そのようなライセンスの例としては、CC0、MIT、2項型BSD、 3項型BSD、 Apache 2.0 、Less GNU General Public License（LGPL）、および GNU General Public License（GPL）を参照してください。私たちの目的のためには、これはライセンスが以下のものでなければならないことを意味します：
ソフトウェアは他の方法でライセンスされているかもしれません（たとえば、「GPLv2またはプロプライエタリ」は許容されます）。
Open Source License

This software is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0).

Key AGPL-3.0 Requirements:
```
✅ Freedom to use — Use for any purpose including commercial
✅ Freedom to study — Access to source code guaranteed
✅ Freedom to modify — Make changes and improvements
✅ Freedom to distribute — Share copies and modifications
🔒 Copyleft requirement — Derivative works must be open source
🌐 Network copyleft — SaaS use requires offering source code
```
The AGPL-3.0-or-later license is approved by the Open Source Initiative (OSI).
Criterion [floss_license_osi]
適合

不適合

?

プロジェクトによって作成されたソフトウェアに必要なライセンスは、オープンソース・イニシアチブ（OSI）によって承認されていることが推奨されています。 ^{[floss_license_osi]}
OSIは、厳格な承認プロセスを使用して、どのライセンスがOSSであるかを判断します。

We utilize the AGPL-3.0 The AGPL-3.0-or-later license is approved by the Open Source Initiative (OSI).

Criterion [license_location]
適合

不適合

?

プロジェクトは、結果のライセンスをソースリポジトリの標準的な場所に投稿しなければなりません。 (URLが必要です) ^{[license_location]}
たとえば、LICENSEまたはCOPYINGという名前の最上位ファイルです。ライセンスファイル名の後に ".txt" や ".md" などの拡張子を付けることができます。別の規則は、ライセンスファイルを含むLICENSESという名前のディレクトリを持つことです。これらのファイルは通常、 REUSE仕様で説明されているように、SPDXライセンス識別子とそれに続く適切なファイル拡張子として名前が付けられます。この基準は、ソースリポジトリの要件にすぎないことに注意してください。ソースコード（実行可能ファイル、パッケージ、コンテナなど）から何かを生成するときに、ライセンスファイルを含める必要はありません。たとえば、Comprehensive R Archive Network（CRAN）のRパッケージを生成するときは、標準のCRANプラクティスに従います。ライセンスが標準ライセンスの場合は、標準の短いライセンス仕様を使用して（テキストのコピーをさらにインストールしないようにするため）、リストします。 .Rbuildignoreなどの除外ファイル内のLICENSEファイル。同様に、Debianパッケージを作成する場合、著作権ファイルに /usr/share/common-licenses のライセンステキストへのリンクを配置し、作成したパッケージからライセンスファイルを除外できます（たとえば、dh_auto_installを呼び出した後にファイルを削除します）。可能な場合は、生成された形式で機械可読ライセンス情報を含めることをお勧めします。

Non-trivial license location file in repository: https://github.com/macawi-ai/Strigoi/blob/main/LICENSE.
ドキュメンテーション

Criterion [documentation_basics]
適合

不適合

該当なし

?

プロジェクトは、プロジェクトによって作成されたソフトウェアに関する基本的なドキュメンテーションを提供しなければなりません。 ^{[documentation_basics]}
このドキュメントは、インストール方法、起動方法、使用方法（可能であれば例示したチュートリアル）、および、そのソフトウェアの適切なトピックであれば安全に使用する方法（たとえば何をするべきで、何をすべきでないか）を記述し、メディア（たとえば、テキストやビデオなど）に収められている必要があります。セキュリティの文書は必ずしも長文である必要はありません。プロジェクトは、ドキュメンテーションとしてプロジェクト以外の素材へのハイパーテキストリンクを使用してもよいです。プロジェクトがソフトウェアを作成しない場合は、「該当なし」（N / A）を選択します。

Some documentation basics file contents found.
Criterion [documentation_interface]
適合

不適合

該当なし

?

プロジェクトは、プロジェクトによって作成されたソフトウェアの外部インタフェース（入力と出力の両方）を記述する参照ドキュメントを提供しなければなりません。 ^{[documentation_interface]}
外部インターフェイスのドキュメントは、エンドユーザーまたは開発者に、その使用方法を説明します。ドキュメントには、ソフトウェアにアプリケーションプログラムインターフェイス（API）が含まれている場合、アプリケーションプログラムインターフェイスが含まれます。ライブラリの場合、呼び出すことができる主要なクラス/型とメソッド/関数を文書化します。ウェブアプリケーションの場合、URLインタフェース（多くの場合、RESTインタフェース）を定義します。コマンドラインインターフェイスの場合は、サポートするパラメータとオプションを文書化します。多くの場合、ドキュメントのほとんどを自動生成すると、ソフトウェアが変更されたときにドキュメントがソフトウェアと同期したままなので、最も良い方法ですが、これは必須ではありません。プロジェクトは、ドキュメンテーションとしてプロジェクト以外の素材へのハイパーテキストリンクを使用してもよいです。ドキュメンテーションは自動的に生成されるかもしれません（実際的に、しばしばこれを行う最良の方法です）。 RESTインタフェースのドキュメントは、Swagger / OpenAPIを使用して生成することができます。コードインタフェースのドキュメントは、 JSDoc （JavaScript）、 ESDoc （JavaScript）、pydoc（Python）、devtools (R)、pkgdown (R)、およびDoxygen（多数）のいずれかです。実装コードにコメントがあるだけでは、この基準を満たすには不十分です。すべてのソースコードを読むことなく情報を見るための簡単な方法が必要です。プロジェクトがソフトウェアを作成しない場合は、「該当なし」（N/A）を選択します。
┌────────────┬───────────────────────────────────────────┬───────────────────────────────────────────────────────────────────────────────┐
│ Interface │ Documentation │ URL │
├────────────┼───────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ CLI │ USER_GUIDE.md with full command reference │ https://github.com/macawi-ai/strigoi/blob/main/USER_GUIDE.md │
├────────────┼───────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ CLI │ Built-in --help flags │ strigoi --help, strigoi <cmd> --help │
├────────────┼───────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ REST API │ FLEET_MANAGER_API_SPEC.md │ https://github.com/macawi-ai/strigoi/blob/main/docs/FLEET_MANAGER_API_SPEC.md │
├────────────┼───────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ Go Package │ pkg.go.dev (auto-generated) │ https://pkg.go.dev/github.com/macawi-ai/strigoi │
└────────────┴───────────────────────────────────────────┴───────────────────────────────────────────────────────────────────────────────┘

Justification for OpenSSF:

The project provides comprehensive interface documentation:
1. CLI Interface: USER_GUIDE.md documents all commands, subcommands, flags, and usage examples. Built-in --help provides real-time command reference.
2. REST API: docs/FLEET_MANAGER_API_SPEC.md documents all API endpoints with request/response examples in JSON format.
3. Go Package API: Automatically generated documentation available at pkg.go.dev/github.com/macawi-ai/strigoi
URLs:
- https://github.com/macawi-ai/strigoi/blob/main/USER_GUIDE.md
- https://github.com/macawi-ai/strigoi/blob/main/docs/FLEET_MANAGER_API_SPEC.md
その他

Criterion [sites_https]
適合

不適合

?

プロジェクトサイト（ウェブサイト、リポジトリ、およびダウンロードURL）は、TLSを使用したHTTPSをサポートしなければなりません。 ^{[sites_https]}
これには、プロジェクトのホームページのURLとバージョン管理リポジトリのURLが「http：」ではなく「https：」で始まる必要があります。Let's Encryptからフリーの証明書を入手できます。プロジェクトは、（例えば） GitHubページ、 GitLabページ、またはSourceForgeプロジェクトページを使ってこの基準を実装してもよいです。HTTPをサポートしている場合は、HTTPトラフィックをHTTPSにリダイレクトすることを強くお勧めします。

Given only https: URLs.

Criterion [discussion]
適合

不適合

?

プロジェクトは、議論（提案された変更や問題を含む）のための1つ以上の検索可能なメカニズムを持たなければならず、メッセージやトピックがURLでアドレス指定され、新しい人々がディスカッションのいくつかに参加できるようにしなければならず、クライアント側でプロプライエタリなソフトウェアのインストールを必要としないようにします。 ^[discussion]
受け入れ可能なメカニズムの例には、アーカイブされたメーリングリスト、GitHubのイシューとプルリクエストの議論、Bugzilla、Mantis、Tracなどがあります。非同期ディスカッションメカニズム（IRCなど）は、これらの基準を満たしていれば許容されます。 URLアドレス可能なアーカイブ機構があることを確認してください。独自のJavaScriptは、推奨されませんが、許可されています。

GitHub supports discussions on issues and pull requests.

Criterion [english]
適合

不適合

?

プロジェクトは英語で文書を提供し、英語でコードに関するバグ報告とコメントを受け入れることができるべきです。 ^[english]
現在、英語はコンピュータ技術のリンガフランカです。英語をサポートすることで、世界中のさまざまな潜在的な開発者とレビュアーの数を増やします。コア開発者の主要言語が英語でなくても、プロジェクトはこの基準を満たすことができます。

Criterion [maintained]
適合

不適合

?

プロジェクトはメンテナンスされている必要があります。 ^[maintained]
少なくとも、プロジェクトは重大な問題と脆弱性の報告に対応するように努める必要があります。バッジを積極的に追求しているプロジェクトは、おそらくメンテナンスされているでしょう。すべてのプロジェクトや人のリソースには限りがあり、提案された変更をプロジェクトが拒否しなければならないこともあるため、リソースに限りがあることや、提案が拒否されることが、メンテナンスされていないプロジェクトを示すわけではありません。

プロジェクトが今後メンテナンスされなくなることがわかった場合は、この基準を「不適合（Unmet）」に設定し、適切なメカニズムを使用して、メンテナンスされないことを人々に示す必要があります。たとえば、READMEの最初の見出しに「DEPRECATED」（将来のサポートが保証されないので使用すべきでない）を使用し、ホームページの先頭近くに「DEPRECATED」を追加し、コードリポジトリのプロジェクトの説明の先頭に「DEPRECATED」を追加し、そのREADMEおよび/またはホームページにno-maintenance-intendedバッジを追加し、すべてのパッケージリポジトリでdeprecated（非推奨）としてマークしたり（例： npm deprecate ）、コードリポジトリのマーキングシステムを使用してアーカイブします（例：GitHubの"archive" 設定、GitLabの"archived" マーキング、 Gerritの "readonly" ステータス、またはSourceForgeの"abandoned" プロジェクトステータス）。詳細な説明については、こちらを参照してください。

Regular maintenance evidenced on github

プロジェクトに関するその他の一般的なコメント

セキュリティ 16/16 ●

セキュリティに関する開発知識
Criterion [know_secure_design]
適合

不適合

?
プロジェクトには、安全なソフトウェアを設計する方法を知っている少なくとも1人の主要な開発者が必要です。（正確な要件については、「詳細」を参照してください。） ^{[know_secure_design]}
これには、Saltzer and Schroeder の8つの原則を含む以下の設計原則を理解する必要があります。
- メカニズムの経済性（たとえば、スイーピングシンプリフィケーションを採用して、メカニズムを実際的に単純化し小さくする）
- フェイルセーフのデフォルト（アクセスの決定はデフォルトで拒否されるべきであり、プロジェクトのインストールはデフォルトで安全でなければならない）
- 完全なメディエーション（制限されたすべてのアクセスは権限がチェックされ、バイパスされない）
- オープンな設計（セキュリティメカニズムは攻撃者の設計に対する無知に依存するべきではなく、簡単に保護ができて変更ができる鍵やパスワードのような情報に依存すべきです。
- 特権の分離（理想的には、重要なオブジェクトへのアクセスは複数の条件に依存すべきで、1つの保護システムを破ることで完全なアクセスが可能にならないようにします。たとえば、パスワードとハードウェアトークンを必要とする多因子認証は単因子認証より強いです。
- 最低限の権限（プロセスは最低限の権限で動作する必要がある）
- 最低限の共通メカニズム（設計は、複数のユーザに共通のメカニズムや全てのユーザーに依存するメカニズムを最小限に抑えるべきです。）
- 心理学的受容性（ヒューマンインタフェースは、使いやすく設計されていなければならない - 「驚きが最小限になる」という設計が助けになる）
- 限られた攻撃面（攻撃面 - 攻撃者がデータを入力または抽出しようとする部分 - を制限する必要があります）
- ホワイトリストで入力を検証します（入力は通常、この検証はブラックリスト（既知の不良値をリストする）ではなく、ホワイトリスト（既知の値のみを受け入れる）を使用する必要があります。
プロジェクトの「主要な開発者」とは、プロジェクトのコードベースに精通していて、容易に変更を加えることができ、プロジェクトの他のほとんどの参加者によって認められている人です。主要な開発者は、通常、過去1年間に（コード、文書、または質問に回答して）多数の貢献を行います。ある開発者が、プロジェクトを開始している（3年以上プロジェクトから離れていない）、プライベート脆弱性報告チャネル（存在する場合）に関する情報を受け取る、プロジェクトを代表してコミットを受け入れる、最終リリースする、などを行う時主要な開発者とみなすことができます。開発者が1人だけの場合、その人物が主要開発者です。より安全なソフトウェアを開発し、設計について議論する方法を理解するのに役立つ多くの本やコースが利用可能です。たとえば、 Secure Software Development Fundamentals コースは、3つのコースの無料セットです。より安全なソフトウェアを開発する方法を説明しています。
Primary developer Jamie Saker is a senior cybersecurity executive with 30+ years technical hands-on experience with secure networking, infrastructure and code.
Criterion [know_common_errors]
適合

不適合

?

プロジェクトの主要開発者の少なくとも1人は、この種のソフトウェアの脆弱性につながる一般的な種類のエラーを知っていなければならず、それぞれを対策または緩和する少なくとも1つの方法を知っていなければなりません。 ^{[know_common_errors]}
例（ソフトウェアの種類によって異なります）には、SQLインジェクション、OSインジェクション、従来のバッファオーバーフロー、クロスサイトスクリプティング、認証の欠落、承認の欠落などがあります。一般的に使用されるリストについては、 CWE/SANSトップ25またはOWASPトップ10を参照してください。より安全なソフトウェアを開発する方法を理解し、脆弱性につながる一般的な実装エラーについて説明するのに役立つ多くの書籍やコースが用意されています。たとえば、 Secure Software Development Fundamentalsコースは、より安全なソフトウェアを開発する方法を説明する3つのコースの無料セットです（受講は無料です。追加料金を払うと、学習したことを証明する証明書を入手できます）。

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

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

Criterion [crypto_published]
適合

不適合

該当なし

?

プロジェクトによって作成されたソフトウェアは、デフォルトで、一般に公開され、専門家によってレビューされている暗号プロトコルとアルゴリズムを使用しなければなりません。（暗号プロトコルとアルゴリズムが使用される場合） ^{[crypto_published]}
ソフトウェアによっては暗号機能を直接使用する必要がないため、これらの暗号基準は常に適用されるわけではありません。

All cryptographic implementations use publicly published, expert-reviewed algorithms:

Key Derivation: Argon2id (RFC 9106, winner of Password Hashing Competition 2015)

Parameters: 64MB memory, 4 threads, 32-byte key output

Encryption: AES-256-GCM (NIST FIPS 197 + SP 800-38D)

Authenticated encryption with 12-byte nonce

Go's standard library crypto/aes and crypto/cipher

Random Generation: Go crypto/rand (cryptographically secure)

Timing-Safe Comparison: crypto/subtle.ConstantTimeCompare

TLS: Standard Go crypto/tls (optional, configurable)

No custom or proprietary cryptographic algorithms. See implementations:

pkg/strigoictl/crypto/keystore.go - API key encryption

pkg/session/crypto.go - Session encryption

Criterion [crypto_call]
適合

不適合

該当なし

?

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

Software does not implement any cryptography of its own and relies on well supported public libraries for the functionality.

Criterion [crypto_floss]
適合

不適合

該当なし

?

暗号に依存するプロジェクトによって作成されるソフトウェアのすべての機能は、FLOSSを使用して実装可能でなければなりません。 ^{[crypto_floss]}
オープンソースイニシアチブによるオープンスタンダード要件を参照して下さい。

Criterion [crypto_keylength]
適合

不適合

該当なし

?

プロジェクトによって作成されたソフトウェア内にあるセキュリティメカニズムは、少なくとも、2030年までのNIST最小要件（2012年）を満たすデフォルト鍵長を使用しなければなりません。より小さな鍵長を完全に無効になるおうに、ソフトウェアを構成できなければなりません。 ^{[crypto_keylength]}
これらの最小ビット長は、対称鍵112、ファクタリング係数2048、離散対数鍵224、離散対数群2048、楕円曲線224、ハッシュ224（パスワードハッシュはこのビット長でカバーされません。パスワードハッシュに関する詳しい情報は crypto_password_storage 基準にあります）です。さまざまな機関が出している推奨鍵長の比較については、https://www.keylength.comを参照してください。ソフトウェアは、いくつかの構成ではより短い鍵長を許可するかもしれません（これはダウングレード攻撃を許すので、理想的には正しくありません。しかし、短い鍵長は、相互運用性のために時に必要となります）。

All cryptographic key lengths exceed NIST 2030 minimums:

Algorithm Our Implementation NIST 2030 Minimum Status

Symmetric (AES) 256-bit 112-bit ✅ 2.3x minimum

Key Derivation (Argon2id) 256-bit output N/A (password hashing) ✅

GCM Nonce 96-bit Standard ✅

Salt 128-256 bit N/A ✅

Hardcoded, not configurable to weaker values:
// pkg/strigoictl/crypto/keystore.go
argon2KeyLen = 32 // AES-256 (256 bits) - hardcoded constant

// pkg/session/crypto.go
KeyLen: 32 // AES-256 - in DefaultCryptoConfig()

No downgrade path: Key lengths are defined as constants, not user-configurable. There is no option to use AES-128 or smaller keys. The only configurable parameters
are Argon2 work factors (time/memory/threads), which affect security strength, not key length.

See: pkg/strigoictl/crypto/keystore.go:40-41, pkg/session/crypto.go:24

Criterion [crypto_working]
適合

不適合

該当なし

?

プロジェクトによって生成されたソフトウェア内のデフォルトのセキュリティメカニズムは、壊れた暗号化アルゴリズム（MD4、MD5、シングルDES、RC4、Dual_EC_DRBGなど）に依存したり、実装する必要がない限り、コンテキストに不適切な暗号化モードを使用したりしてはなりません。相互運用可能なプロトコル（実装されたプロトコルがネットワークエコシステムによって広くサポートされている標準の最新バージョンであり、そのエコシステムではそのようなアルゴリズムまたはモードの使用が必要であり、そのエコシステムはこれ以上安全な代替手段を提供しません）。これらの壊れたアルゴリズムまたはモードが相互運用可能なプロトコルに必要な場合、ドキュメントには、関連するセキュリティリスクと既知の緩和策を記載する必要があります。 ^{[crypto_working]}
ECBモードは、 ECBペンギンによって示されるように暗号文内の同一のブロックを明らかにするため、ほとんど適切ではありません。また、CTRモードは、認証を実行せず、入力状態が繰り返されると重複を引き起こすため、不適切なことがよくあります。多くの場合、Galois / Counter Mode（GCM）やEAXなど、機密性と認証を組み合わせるように設計されたブロック暗号アルゴリズムモードを選択するのが最善です。プロジェクトは、互換性のために必要な場合、ユーザーが壊れたメカニズムを有効にすることを許可する場合があります（構成中など）が、ユーザーはそれを実行していることを認識します。

No broken algorithms used:

❌ MD4, MD5, DES, RC4, Dual_EC_DRBG - None used

❌ ECB mode - Not used

❌ Unauthenticated CTR mode - Not used

Only secure algorithms/modes:

✅ AES-256-GCM (authenticated encryption, as recommended)

✅ Argon2id (modern password hashing)

✅ crypto/rand (secure PRNG)

Cipher mode verification:
$ grep -E "NewGCM|NewCBC|NewECB|NewCTR" pkg/ cmd/ --include="*.go"

Only NewGCM found (4 occurrences in crypto.go and keystore.go)

Note on MD5 reference: One struct field (Checksums map[string]string // md5, sha256) exists in protocol/layers.go for optional integrity metadata from external
sources - this is not a security mechanism, just a data container. No MD5 hashing is performed by the project.

All encryption uses GCM mode which combines secrecy and authentication as recommended.

Criterion [crypto_weaknesses]
適合

不適合

該当なし

?

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

No weak algorithms or modes used:

❌ SHA-1 - Not used anywhere

❌ CBC mode - Not used (only GCM)

❌ MD5 for security - Not used

Only strong algorithms:

✅ SHA-256 for hashing (HMAC-SHA256, integrity checks)

✅ AES-256-GCM for encryption

✅ Argon2id for password hashing

Verification:
$ grep -riE "sha1|SHA1|NewCBC" pkg/ cmd/ internal/ --include="*.go"

No results

$ grep -r "sha256" pkg/ --include="*.go" | wc -l

14 occurrences - all SHA-256

All cryptographic operations use modern, well-reviewed algorithms without known serious weaknesses.

Criterion [crypto_pfs]
適合

不適合

該当なし

?

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

TLS Communications: The project uses Go's standard crypto/tls library with default configuration. Go 1.17+ (project requires Go 1.25+) defaults to:

TLS 1.2 and TLS 1.3 with ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) cipher suites

All default cipher suites provide PFS via ephemeral key exchange

No custom CipherSuites configured that would disable PFS

Verification:
$ grep -r "CipherSuites" pkg/ cmd/ --include="*.go"

No custom cipher suite configuration found

Go's default TLS cipher suites (as of Go 1.25):

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ✅ PFS

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ✅ PFS

TLS_CHACHA20_POLY1305_SHA256 (TLS 1.3) ✅ PFS

Local encryption: Uses Argon2id key derivation (not a key exchange protocol, so PFS not applicable). Each encryption operation uses unique salt/nonce preventing key
reuse.

See: pkg/a2a/protocol.go, pkg/a2a/bridge.go

Criterion [crypto_password_storage]
適合

不適合

該当なし

?

プロジェクトによって作成されたソフトウェアが外部ユーザーの認証用のパスワードの保存を引き起こす場合、パスワードは、キーストレッチ（反復）アルゴリズム（Argon2id、Bcrypt、Scrypt、PBKDF2など）を使用して、ユーザーごとのソルトで反復ハッシュとして保存される必要があります。OWASP Password Storage Cheat Sheetも参照してください）。 ^{[crypto_password_storage]}
この基準は、ソフトウェアがサーバー側Webアプリケーションなどの外部ユーザーのパスワードを使用してユーザーの認証（別名インバウンド認証）を実施している場合にのみ適用されます。ソフトウェアが他のシステムへの認証用のパスワードを保存している場合（別名、アウトバウンド認証、たとえば、ソフトウェアが他のシステムのクライアントを実装している場合）、そのソフトウェアの少なくとも一部がハッシュされていないパスワードにアクセスできる必要があるため、適用されません。

Strigoi does not store passwords for external user authentication. The project is a security assessment CLI tool, not a multi-user web application.

Authentication model:

Agent authentication: Uses PSK (pre-shared key) and HMAC-SHA256 signatures, not passwords

API key storage: Uses Argon2id encryption for outbound authentication (storing keys to connect TO external services like OpenAI, Gemini) - this is explicitly
excluded by the criterion

Session encryption: Passphrase-derived keys using Argon2id for local file encryption

No inbound user authentication:

No user registration/login system

No user database

No password hashing for user accounts

If password storage were added in the future: The existing Argon2id infrastructure (pkg/strigoictl/crypto/keystore.go, pkg/session/crypto.go) would be used, which
already implements iterated hashing with per-user salt as required by OWASP guidelines.

Criterion [crypto_random]
適合

不適合

該当なし

?

プロジェクトによって作成されたソフトウェア内のセキュリティメカニズムは、暗号学的にセキュアな乱数発生器を使用して、すべての暗号鍵とナンスを生成しなければなりません。暗号学的にセキュアでない発生器を使用してはいけません。 ^{[crypto_random]}
暗号学的にセキュアな乱数発生器は、ハードウェアの乱数発生器でも、Hash_DRBG、HMAC_DRBG、 CTR_DRBG、Yarrow、Fortunaなどのアルゴリズムを使用する暗号学的にセキュアな疑似乱数発生器（CSPRNG）でもよいです。セキュアでない乱数発生器には、Javaのjava.util.RandomとJavaScriptのMath.randomがあります。

All cryptographic key and nonce generation uses Go's crypto/rand (CSPRNG):

Security-critical code uses crypto/rand exclusively:
// pkg/strigoictl/crypto/keystore.go
import "crypto/rand"
rand.Read(salt) // Salt generation
rand.Read(nonce) // Nonce generation

// pkg/session/crypto.go
io.ReadFull(rand.Reader, salt)
io.ReadFull(rand.Reader, nonce)

// pkg/a2a/auth.go
ed25519.GenerateKey(rand.Reader) // Key pair generation
rand.Read(psk) // PSK generation

// pkg/security/auth.go
rand.Read(pskBytes) // Authentication key generation

math/rand usage is non-security only:

pkg/logging/txcontext.go - Transaction IDs for log tracing

cmd/traffic-simulator/ - Test traffic generation

cmd/test.go - Test files

Go's crypto/rand uses the operating system's CSPRNG (getrandom() on Linux, CryptGenRandom on Windows) which meets NIST SP 800-90A requirements.

Algorithm	Our Implementation	NIST 2030 Minimum	Status
Symmetric (AES)	256-bit	112-bit	✅ 2.3x minimum
Key Derivation (Argon2id)	256-bit output	N/A (password hashing)	✅
GCM Nonce	96-bit	Standard	✅
Salt	128-256 bit	N/A	✅

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

Criterion [delivery_mitm]
適合

不適合

?

プロジェクトは、MITM攻撃に対抗する配信メカニズムを使用しなければならない。httpsまたはssh+scpを使用することは許容されます。 ^{[delivery_mitm]}
さらに強力な仕組みは、デジタル署名されたパッケージでソフトウェアをリリースすることです。配布システムへの攻撃を緩和するからです。しかし、これは、署名の公開鍵が正当なものであることをユーザーが確信でき、かつユーザーが実際に署名をチェックする場合にのみ有効です。

Primary delivery via HTTPS:

GitHub Releases: https://github.com/macawi-ai/strigoi/releases (TLS 1.3)

Source clone: git clone https://github.com/macawi-ai/strigoi.git

Container images: ghcr.io/macawi-ai/ (HTTPS registry)

Integrity verification provided:

SHA256 checksums published with each release (checksums.txt)

Git commit signatures available

Container image digests via GHCR

The irony:
Strigoi is literally a security assessment platform that detects MITM attacks, credential exposure, and TLS misconfigurations in AI/LLM systems. The tool includes:

TLS verification scanning (pkg/security/mcp_scanner.go)

Credential leak detection (17+ patterns)

Stream Tap for real-time STDIO security monitoring

We practice what we preach. Be curious if anyone reads this deep - if so, reach out to jamie.saker@macawi.ai and I'll even offer a free tool walkthru if interested :)

Criterion [delivery_unsigned]
適合

不適合

?

暗号ハッシュ（たとえばSHA1SUM）は、http経由で運んではならず、暗号署名をチェックすることなしに使用してはいけません。 ^{[delivery_unsigned]}
これらのハッシュは、送信中に変更することができます。

All checksums delivered via HTTPS:

checksums.txt is published on GitHub Releases at https://github.com/macawi-ai/strigoi/releases

GitHub enforces TLS 1.2+ for all connections

No HTTP endpoints exist for checksum retrieval

Verification instructions in README use HTTPS:
wget https://github.com/macawi-ai/strigoi/releases/download/v1.0.0/checksums.txt
sha256sum -c checksums.txt

Additional integrity mechanisms:

Git tags are used for releases (cryptographically linked to commit history)

Container images use content-addressable digests via GHCR

GitHub's infrastructure provides additional transport security guarantees

No retrieval of cryptographic hashes over unencrypted HTTP.

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

Criterion [vulnerabilities_fixed_60_days]
適合

不適合

?

60日を超えて公的に知られている中程度または重大度のパッチが適用されていない脆弱性は存在してはなりません。 ^{[vulnerabilities_fixed_60_days]}
脆弱性は、プロジェクト自体によってパッチされ、リリースされなければなりません（パッチは他の場所で開発される可能性があります）。脆弱性が無料情報と共にCVE（共通脆弱性識別子）を持つとき（例えば、 National Vulnerability Database ）、またはプロジェクトに情報が伝えられ、その情報が（おそらくプロジェクトによって）一般に公開されたとき、脆弱性は一般に知られるようになります。Common Vulnerability Scoring System (CVSS)の定性的スコアが中程度以上であれば、脆弱性は中程度以上の深刻度とみなされます。CVSS のバージョン 2.0 から 3.1 では、これは CVSS のスコア 4.0 以上に相当します。プロジェクトは、広く利用されている脆弱性データベース（国家脆弱性データベースなど）で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを用いて使用することができます。代わりに、プロジェクトは、脆弱性が公表された時点で計算入力内容が公開されている場合には、脆弱性が公表された時点でのCVSSの最新版を用いて深刻度を計算することができます。注意：これは、ユーザーが最大60日間、世界中のすべての攻撃者に対して脆弱なままになる可能性があることを意味します。この基準は、責任ある開示の再起動でGoogleが推奨しているものよりも、はるかに簡単に満たすことができることが多いです。なぜなら、Googleはレポートが公開されていなくても、プロジェクトが通知された時点で60日間の期間が開始されることを推奨しているためです。また、このバッジの基準は、他の基準と同様に、個々のプロジェクトに適用されることにも注意してください。プロジェクトの中には、より大きな包括組織や大規模プロジェクトの一部であり、複数のレイヤーに分かれている場合もあります。また、多くのプロジェクトでは、複雑なサプライチェーンの一部として、他の組織やプロジェクトに成果を提供しています。個々のプロジェクトは、多くの場合、残りの部分をコントロールできませんが、個々のプロジェクトは、脆弱性パッチをタイムリーにリリースするための作業を行うことができます。そのため、私たちは個々のプロジェクトの対応時間に焦点を当てています。一旦、個々のプロジェクトからパッチが利用可能になると、他のプロジェクトはそのパッチにどのように対処するかを決定することができます（たとえば、新しいバージョンにアップデートすることもできますし、選別されたソリューションのパッチだけを適用することもできます）。

Criterion [vulnerabilities_critical_fixed]
適合

不適合

?

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

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

Criterion [no_leaked_credentials]
適合

不適合

?

公開リポジトリは、パブリックアクセスを制限するための有効なプライベートクレデンシャル（たとえば、有効なパスワードやプライベートキー）を漏らしてはなりません。 ^{[no_leaked_credentials]}
プロジェクトは、パブリックアクセスを制限する意図がない限り、テスト用や重要でないデータベース用の「サンプル」資格情報を漏らす可能性があります。

No valid private credentials in repository:

Scanned and verified clean:

No AWS keys (AKIA...), GitHub tokens (ghp_), OpenAI keys (sk-...)

No private keys (RSA, EC, SSH, OPENSSH)

No hardcoded passwords for production systems

What exists (all safe):

Detection patterns in modules/probe/ - regex patterns for finding credentials (the scanner's job)

Key generation scripts - openssl rand -hex 16 generates new random keys at deploy time

Local dev paths - .env contains only DATABASE_URL=./sqlite.db

Intentional test fixtures (permitted):

examples/insecure-mcps/ contains intentionally vulnerable MCPs for testing

Clearly documented as test targets, not production credentials

Criterion explicitly allows "sample credentials for testing"

Preventive measures:

.gitignore excludes: .env, .env.local, nkeys/*.txt

Keystore encrypts API keys with Argon2id before storage

gosec linter enabled to detect credential patterns

分析 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）を選択します。

Multiple static analysis tools applied before every release:

golangci-lint (meta-linter with 11+ analyzers):

staticcheck - advanced static analysis

gosec - security vulnerability detection

govet - Go vet checks

ineffassign, unused, typecheck, etc.

Run via make lint and in CI

gosec (dedicated security scanner):

Standalone run via make security

Separate CI step using securego/gosec@master action

Checks for: SQL injection, command injection, hardcoded credentials, weak crypto, etc.

Release process requires static analysis:
release: clean lint security test build # All must pass
ci: deps lint security test-coverage test-race build

CI enforcement:

GitHub Actions runs golangci-lint and gosec on every push/PR

Builds blocked if static analysis fails

Results logged for review

See: .github/workflows/strigoi-v1rc1-ci.yml, Makefile, .golangci.yml

Criterion [static_analysis_common_vulnerabilities]
適合

不適合

該当なし

?

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

gosec is specifically designed to detect common vulnerabilities:

Vulnerability categories checked:

G101: Hardcoded credentials

G102: Bind to all interfaces

G103: Unsafe block usage

G104: Unhandled errors

G107: SSRF via variable URL

G108: Profiling endpoint exposure

G201-G203: SQL injection

G301-G307: File permission issues

G401-G404: Weak cryptography

G501-G505: Blocklisted imports

G601: Implicit memory aliasing

Mapped to common vulnerability standards:

OWASP Top 10 coverage

CWE (Common Weakness Enumeration) mappings

SANS Top 25 alignment

Integration:

.github/workflows/strigoi-v1rc1-ci.yml

uses: securego/gosec@master
with:
args: '-no-fail -fmt json -out gosec-results.json ./...'

Additionally, golangci-lint includes staticcheck which detects correctness issues that could lead to vulnerabilities.

See: https://github.com/securego/gosec

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 日以内にすべての脆弱性を修正することが要求されていることに注意してください。

Current status: All confirmed exploitable medium+ vulnerabilities addressed.

Current gosec findings (62 medium+) are documented exclusions or false positives:

Rule Count Status

G115 (integer overflow) 41 Excluded - Go type conversions for array/slice lengths

G304 (file path taint) 9 Intentional - security scanner must read user-specified files

G204 (subprocess variable) 4 Intentional - scanner executes commands by design

G302/G301 (permissions) 7 Non-exploitable - internal config directories

G404 (weak random) 1 Excluded - used in non-security logging context

Evidence of timely fixes (git history):
8586a44 fix: resolve all gosec, unused, and code quality issues
5797609 fix: resolve all 10 golangci-lint issues for clean CI
f533dd1 fix: resolve all remaining linting issues for Go 1.25 compliance

Exclusions documented in .golangci.yml:
gosec:
excludes: [G104, G115, G402, G404] # With justification comments

No CVEs: Zero CVE-assigned vulnerabilities in project history.

Criterion [static_analysis_often]
適合

不適合

該当なし

?

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

動的コード分析

Criterion [dynamic_analysis]
適合

不適合

?

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

Dynamic analysis tools applied before releases:

Go Race Detector (ThreadSanitizer-based):

Instruments code at runtime to detect data races

Run via go test -race in CI on every push/PR

Applied to all packages: ./cmd/... ./pkg/... ./internal/...

CI workflow

run: go test -v -race -short -timeout=10m -coverprofile=coverage.out ./...

Automated Test Suite with Coverage:

Unit and integration tests executed on every build

Coverage tracked and reported via Codecov

make test-coverage generates HTML coverage reports

CI enforces minimum coverage threshold

Release gate (make ci):
ci: deps lint security test-coverage test-race build
All dynamic analysis must pass before builds succeed.

Evidence of effectiveness:
a25b207 Phase 3.1 Complete: ZERO Race Conditions Found! 🎉
a3ed353 Fix CrossSessionChecker deadlock with read-lock optimization
2ee9653 fix: Add comprehensive mutex protection to SessionManager

Race detector has caught and helped fix real concurrency bugs.

Criterion [dynamic_analysis_unsafe]
適合

不適合

該当なし

?

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

Primary language: Go

Garbage collected

Bounds-checked array/slice access

No pointer arithmetic

No manual memory allocation/deallocation

No buffer overflow vulnerabilities by design

Supporting languages (also memory-safe):

Python (A2MCP agents)

Shell scripts (deployment/build)

YAML/JSON (configuration)

No C/C++ code in the project.

Go's memory safety is why we chose it - eliminates entire vulnerability classes (CWE-119, CWE-120, CWE-122, CWE-125, CWE-787) that plague C/C++ security tools.

Note: Go's race detector (used in CI) provides similar runtime instrumentation benefits for concurrency safety.

Criterion [dynamic_analysis_enable_assertions]
適合

不適合

?

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

Race detector enabled during dynamic analysis (testing), disabled in production:

Makefile - test mode with assertions

test-race:
go test -short -race ./cmd/strigoi ./pkg/... ./internal/...

CI runs with race detector

run: go test -v -race -short -timeout=10m ./...

Go's race detector acts as runtime assertions:

Instruments memory access patterns at runtime

Detects data races, deadlocks, and synchronization bugs

Panics (asserts) on any detected race condition

Only enabled via -race flag during testing

Not included in production binaries

Test assertions used throughout:

t.Fatal(err) - Stops test on invariant violation

t.Error() - Records assertion failure

t.Errorf() - Records formatted assertion failure

Bounds checking panics in test scenarios

Production builds:
build:
go build -o strigoi ./cmd/strigoi # No -race flag

This follows the criterion's recommendation: assertions enabled during analysis, disabled in production.

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を使用して重大度を自ら計算することができます。

Dynamic analysis IS performed, and all discovered issues have been fixed:

Race detector findings - all fixed:
a3ed353 Fix CrossSessionChecker deadlock with read-lock optimization
2ee9653 fix: Add comprehensive mutex protection to SessionManager
99183df fix(concurrency): Eliminate race conditions in coordinator and load tester
a25b207 Phase 3.1 Complete: ZERO Race Conditions Found! 🎉

Current status:

Race detector runs on every CI build

Zero race conditions currently detected

All historically detected races were fixed within days of discovery

No CVE-assigned vulnerabilities discovered through dynamic analysis.

If N/A is selected, context:
While dynamic analysis (race detector, test suite) is actively used, no exploitable security vulnerabilities with CVSS 4.0+ have been discovered through these
methods. The race conditions found were correctness/reliability issues, not security vulnerabilities with CVSS scores. Therefore N/A is technically accurate - no
medium+ security vulnerabilities to fix.

Rule	Count	Status
G115 (integer overflow)	41	Excluded - Go type conversions for array/slice lengths
G304 (file path taint)	9	Intentional - security scanner must read user-specified files
G204 (subprocess variable)	4	Intentional - scanner executes commands by design
G302/G301 (permissions)	7	Non-exploitable - internal config directories
G404 (weak random)	1	Excluded - used in non-security logging context

This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Macawi AI and the OpenSSF Best Practices badge contributors.

プロジェクトバッジ登録の所有者： Macawi AI.
エントリの作成日時 2026-01-12 01:24:54 UTC、 最終更新日 2026-01-12 02:24:30 UTC 最後に2026-01-12 02:24:30 UTCにバッジ合格を達成しました。

Strigoi

基本的情報 13/13 ●

識別情報

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

FLOSSライセンス

ドキュメンテーション

その他

変更管理 9/9 ●

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

一意的なバージョン番号

リリースノート

報告 8/8 ●

バグ報告プロセス

脆弱性報告プロセス

品質 13/13 ●

作業ビルドシステム

自動テストスイート

新機能テスト

警告フラグ

セキュリティ 16/16 ●

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

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

Only NewGCM found (4 occurrences in crypto.go and keystore.go)

No results

14 occurrences - all SHA-256

No custom cipher suite configuration found

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

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

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

分析 8/8 ●

静的コード解析

.github/workflows/strigoi-v1rc1-ci.yml

動的コード分析

CI workflow

Makefile - test mode with assertions

CI runs with race detector

Strigoi

基本的情報 13/13 ●

識別情報

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

FLOSSライセンス

ドキュメンテーション

その他

変更管理 9/9 ●

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

一意的なバージョン番号

リリースノート

報告 8/8 ●

バグ報告プロセス

脆弱性報告プロセス

品質 13/13 ●

作業ビルドシステム

自動テスト スイート

新機能テスト

警告フラグ

セキュリティ 16/16 ●

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

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

Only NewGCM found (4 occurrences in crypto.go and keystore.go)

No results

14 occurrences - all SHA-256

No custom cipher suite configuration found

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

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

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

分析 8/8 ●

静的コード解析

.github/workflows/strigoi-v1rc1-ci.yml

動的コード分析

CI workflow

Makefile - test mode with assertions

CI runs with race detector

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

自動テストスイート