Security Recipes

security-recipes.ai

CVE を検索。AI エージェントで脆弱性を修正します。 情報の出典を明示し、 修正の範囲を限定します。すべての計画には検証、ロールバック、停止条件を含めます。 これは公開サイトと、このリポジトリが掲げる約束です。

security-recipes.ai は、出典を明示した CVE インテリジェンスと、 証拠に基づく脆弱性修正を提供する Eleventy サイトです。AI エージェントがデプロイや本番環境に 対する権限を引き継ぐことなく利用できます。

このプロジェクトの対象範囲は意図的に限定されています。

• Medium／High／Critical の CVE を網羅する継続更新データベース
• 証拠に基づいて適格性を確認した、CVE 修正の正規レコード
• 実用的なセキュリティ修正レシピ
• プロンプトとルールファイルの例
• エージェントのセットアップガイド
• MCP 統合パターン
• レシピ検索と承認済みの上流 MCP コンテキストを提供する、オプションの読み取り専用 MCP サーバー
• このガイダンスを切り替え可能な CI ヘルスチェックに活用する 再利用可能な GitHub Action

これは、スキャナー、チケット管理システム、SOAR プラットフォーム、デプロイツール、 独自のセキュリティツールキットではありません。検出結果は既存のセキュリティツールで生成し、 このサイトを使って、エージェントが適切な修正コンテキストを使い、適切なタイミングで停止できるようにします。

特定の脆弱性を調べるには、公開中の CVE データベースから始めてください。 証拠からパッチ適用までのワークフローについては、 AI 脆弱性修正プレイブックをご覧ください。 エージェント別のガイドでは、 Codex、 Claude Code、 Cursor、 GitHub Copilot、 Devin、 Shiba Studio、 Hermes Desktop、 OpenClawを取り上げています。 ビジュアルガイドでは、情報源の適格性確認と検索による発見から、 範囲を限定した計画、証明、ロールバック、人によるレビューまでの全工程を紹介しています。 エージェントシステムの ID、ツール、コネクター、コンテキスト、メモリ、ランタイム、 復旧制御を保護するという別の課題には、 AI エージェントのセキュリティをご利用ください。

現在のプロダクトとワークフロー

条件を満たした検索への掲載

カタログ全体は引き続き検索可能ですが、公開される正規 CVE ページは、レビュー済みまたはエビデンスの条件を満たしたレコードに限定されます。これらのページには、固有の検索メタデータ、サーバー側でレンダリングされる基本情報と影響を受けるバージョンのエビデンス、1 つの修復情報源（安定したレビュー済みガイダンスを優先し、それがなければソースにリンクされた完全な AI 拡張情報）、承認を条件とする簡潔な AI 実装プロンプト、正規 URL、パンくずリスト、Article／TechArticle 構造化データが含まれます。CVE データベースはカタログを Dataset として記述し、修復の柱では、表示される 7 ステップのワークフローを HowTo として公開します。年別に分割された CVE サイトマップには、インデックス可能な正規ルートのみが含まれます。また、サイトマップとの整合性、正規ページの所有権、クロール可能性、メタデータの上限、同一オリジンのリンクにずれが生じると、ビルドは失敗します。

大量のテンプレートから生成されたレシピの子ページも、インデックス登録の対象外です。開発用コード衛生レシピ 72 件と、コンプライアンスフレームワークから生成されたレシピ 39 件は、共通の手法を共有している間は、正規ハブから閲覧できる状態を維持しつつ、noindex,follow が設定されます。レンダリング済み本文を対象とする類似度ゲートに上限を設けることで、エビデンス、例、テストに実質的な違いが生まれるまで、子ページがサイトマップに再登録されないようにします。ハブは引き続きインデックス可能で、共通の検索コンテキストを提供します。

SEO に関わるリリース後は、サイトマップの送信や URL 検査を行う前に、公開リビジョンがマージコミットと一致している必要があります。 Caddy のデプロイガイドでは、DNS 検証済みの Search Console への引き渡し、優先 URL のライブ確認、サイトマップの送信、インデックス登録のリクエスト、検索クエリのモニタリングについて説明しています。送信は検索エンジンに発見を促すヒントであり、インデックス登録や特定の順位を保証するものではありません。

修復の柱には、brace-expansion の CVE-2026-13149 に関する実際のリポジトリ事例も記録されています。依存関係だけを変更した内容を、レビュー済みのプルリクエスト、テスト、アドバイザリのエビデンス、復旧手順に結び付けつつ、同じ PR に含まれる無関係な Fail2Ban 作業とは明確に区別しています。

CVE 検索から正規レコードへ	CVE のエビデンスから範囲を限定したエージェント計画へ
証拠と人によるレビュー	読み取り専用の MCP コンテキスト

このプロジェクトの目的

AI コーディングエージェントは、作業範囲が限定されている場合に、セキュリティ上の指摘への対応に役立ちます。指摘 1 件、レシピ 1 件、レビュー済みの出力 1 件です。

security-recipes.ai は、チームが次の問いに答えるのを支援します。

• この指摘に一致するレシピはどれですか？
• エージェントはどのプロンプトを使うべきですか？
• Copilot、Claude、Cursor、Codex、Devin 向けの指示はどこに記載すればよいですか？
• アドバイザリ、スキャナー、リポジトリ、ランブックのコンテキストを読み取るには、エージェントはどの MCP サーバーを使うべきですか？
• レビュー担当者が信頼できるようにするには、PR やトリアージノートに何を含めるべきですか？

提供内容

• Eleventy ドキュメントサイト（高速な静的ビルド、Go ツールチェーン不要）。
• CVE を優先したオブザーバトリーのホームページと、データを重視した CVE データベース。
• 依存関係、SAST、機密データ、ベースイメージ、CVE、デフォルトのハードニング対策に関するレシピハブ。
• エージェントがパッチを適用する前にアドバイザリーシグナルを振り分けるための、CVE インテリジェンス取り込みポリシー、プロンプト、フィクスチャ、評価ツール。
• 整合性が検証された NVD JSON 2.0 フィード、CISA KEV メタデータ、該当するすべての精査済み修復アーキタイプから構成される、過去 10 年分をローリング更新する Medium／High／Critical CVE カタログ。レビュー済みの stable Markdown ページのみが、この保守的なベースラインを上書きします。
• 整合性ハッシュ付きの検索許可リスト。レビュー済みの stable Markdown、または決定論的なレシピ対応エビデンス契約に合格した AI エンリッチメントに対してのみ、正規 CVE ページを公開します。レコードが検索インデックスの対象外であっても、データベース全体を検索できます。
• カタログ内のすべての CVE を対象とした、バージョン管理された 7 フェーズのエージェント型変更契約：検出、評価、緩和、修復、検証、ロールバック、トリアージ。各アクションでは、推測でパッチや固定バージョンを指定することなく、対象となりそうなファイル、変更および承認の境界、必要なエビデンス、出力、失敗時の動作を宣言します。
• ライセンス対象の管理策テキストを複製することなく、39 のセキュリティ、プライバシー、保証、レジリエンス、ソフトウェアサプライチェーンのフレームワークを網羅する、構造化されたコンプライアンスライブラリ。フレームワークハブを検索対象とし、テンプレート化された子アセスメントは、内容に差異が付くまで noindex,follow のままです。
• 言語横断およびエコシステム固有の監査、修復、検証、停止条件のワークフローを網羅する、72 件のレシピからなるコード衛生ライブラリ。開発中の子ページは、本文で生成テンプレートを共有している間、noindex,follow のままです。
• 既存のプロンプトコレクションを維持したレシピ。
• GitHub Copilot、Claude、Cursor、Codex、Devin 向けのエージェント設定ガイド。
• 公開および組織で承認されたセキュリティデータソース向けの MCP 統合ガイダンス。
• レシピの検索、取得、オプトインによる上流 MCP コンテキスト取得に対応する、mcp_server.py のオプションの読み取り専用 FastMCP サーバー。
• ローカルまたは droplet でのホスティング向けの Docker と Docker Compose の設定。
• サイトの保守、検証、インポート、デプロイ用のヘルパースクリプト。

リポジトリ構成

パス	用途
content/	レシピ、ドキュメント、修復ガイド、エージェント設定ページ。
eleventy.config.js	サイトのビルド設定（パーマリンク、フィード、タグページ）。
_includes/	ページレイアウト：ドキュメント用の共通部分と独立したホームページ。
lib/	ビルドモジュール：ショートコードの移植、JSON フィードのビルダー、SEO ヘッド。
assets/	レシピブラウザー、ナビゲーション、ヘルパーツール向けのサイト CSS と JavaScript。
static/	画像、ロゴ、スキーマ、静的アセット。
static/api/cve-catalog/	完全なシャーディング済み CVE カタログ、年別に分割されたマシン向けインデックス、圧縮されたブラウザー検索用インデックス、出典マニフェスト、アーキタイプ。
data/cve/	人手でレビューされた修復アーキタイプ、決定論的 AI エンリッチメントキャッシュ、生成レシピの所有権台帳。
data/compliance-frameworks/	構造化されたコンプライアンスフレームワークカタログとソースレジストリ。
data/code-hygiene/	構造化されたコード衛生カタログ、ソースレジストリ、振り分け用フィクスチャ。
docs/	リポジトリのドキュメントと旧スクリーンショットアセット。現在の README とビジュアルガイドの画像は static/images/ にあります。
mcp_server.py	レシピ検索と承認済み上流 MCP コンテキスト用の、オプションの読み取り専用 MCP サーバー。
mcp-server.toml.example	MCP サーバー設定テンプレート。
Dockerfile	サイトのイメージ。
Dockerfile.mcp-server	オプションの MCP サーバーイメージ。
docker-compose.yml	本番環境を想定したローカルスタック。
scripts/	保守とデプロイ用のヘルパースクリプト。

主なコンテンツ領域

• CVE データベース：情報源を明示した CVE 情報、影響を受けるバージョンの根拠、標準的な修正記録を提供します。
• AI 脆弱性の修正： 1 件の検出結果から、レビュー済みのパッチまたはトリアージメモに至るまで、証拠に基づいて進めるプレイブックです。
• AI エージェントのセキュリティ： AI エージェントシステム自体を対象に、脅威モデリング、本番環境のベースライン、ソースの境界、制御の振り分け、証拠、インシデントへの備えを扱います。
• クイックスタート：1 件の検出結果から、レビュー済みの PR またはトリアージメモを作成します。
• AI エージェントの比較：Copilot、Claude Code、Cursor、Codex、Devin について、確認済みの動作モード、標準の指示、想定される成果物、前提条件、レビューのゲートを紹介します。
• レシピ：再利用可能なプロンプト、指示、ルール、スキル、レビューチェックリストです。
• MCP 統合：セキュリティコンテキストを安全に接続する方法を説明します。
• ビジュアルガイド：条件に合った検索と発見、CVE から計画への移行、証明、ロールバック、レビュー、読み取り専用 MCP のフローを 5 つの図で紹介します。
• ドキュメント：サイトの使い方、エージェントによる活用パターン、貢献方法のガイドです。

Python による修正ツール

Python スイートは、ドキュメントを補完する任意の実行ツールです。対象を限定したワークスペースを検査し、75 件の修正プレイブックから任意のものを選択して、永続的な実行パケットを作成し、整合性ハッシュ付きの証拠を記録したうえで、エージェントまたはレビュアーへの引き渡し前にパケットを検証できます。ローカルで保守的に動作し、コードのマージ、変更のデプロイ、外部システムの独自呼び出しは行いません。

python scripts/security_recipes_remediation_suite.py playbook list
python scripts/security_recipes_remediation_suite.py playbook inspect \
  --playbook vulnerable-dependencies --workspace .
python scripts/security_recipes_remediation_suite.py playbook start \
  --playbook vulnerable-dependencies --workspace . \
  --finding finding.json --run-dir .security-recipes/runs/dependency-fix
python scripts/security_recipes_remediation_suite.py playbook verify \
  --run-dir .security-recipes/runs/dependency-fix

また、このリポジトリには、より豊富な証拠パックや実行時のポリシー判断を必要とするプレイブック向けに、ドメイン固有のジェネレーターと評価ツールも含まれています。Python がなくても、サイトと JSON レジストリは利用できます。これらのツールを使うと、同じワークフローの契約を CI、オーケストレーター、承認済みのコーディングエージェントから直接実行できます。

知っておくと便利なデプロイ用ヘルパー：

• scripts/setup_digitalocean_droplet.sh：Docker、ホストの強化、Caddy による HTTPS 管理のオプションを含む、Ubuntu ドロップレットの初期設定スクリプトです。
• scripts/configure_nginx_letsencrypt.sh：Caddy ではなく nginx で Let's Encrypt を使いたいチーム向けの、ホスト上の nginx リバースプロキシ設定スクリプトです。
• README.nginx-letsencrypt.md：nginx を使ったデプロイ方法を、運用担当者向けに解説しています。

推奨される運用モデル：

1. 既存の SCA、SAST、シークレット管理、CI、クラウド、チケット管理システムで検出結果を生成します。
2. 対応する security-recipes.ai のレシピとプロンプトを添付します。
3. 検出結果に必要なファイルと MCP コンテキストだけをエージェントに読み取らせます。
4. マージ前にテストと人によるレビューを必須にします。
5. 広範な自動化、書き込みアクセス、デプロイは、最初のサイクルの対象外にします。

ガイドブックと実行ツール

このサイトは、修正作業のためのガイドブックです。レシピ、プロンプト、エージェントのセットアップ、MCP/API 統合のメモ、レビューパターンを掲載しています。実行時の自動化は、サイト上でホストされるチャットボットではなく、ユーザーが承認したエージェントホスト、CI システム、チケット管理ワークフロー、またはスキャナープラットフォームで行います。

scripts/、tools/、mcp_server.py の Python ツールは、保守担当者やセルフホストするユーザー向けに、プレイブック実行パケットの作成、証拠の検証、ドメイン固有の評価と生成、検証、アドバイザリのインポート、レシピ検索、任意の読み取り専用 MCP アクセスをサポートします。

オプションの MCP サーバー

MCP サーバーは、デフォルトで読み取り専用です。基本的な役割は、MCP 互換エージェントがレシピを検索して取得できるようにすることです。セルフホストのデプロイでは、パブリックサイトに認証情報を配置せずに、承認済みの上流 MCP サーバー用のコンテキストハブとしても設定できます。 取得したコンテキストによって変更権限が与えられることはありません。リポジトリ、チケット、シークレット、デプロイ、または本番システムを変更できるコネクターは、呼び出し元のホストで個別に設定し、承認する必要があります。

一般的なツール：

• recipes_search
• recipes_list
• recipes_get
• recipes_cve_catalog_info
• recipes_cve_search
• recipes_cve_get
• recipes_match_finding
• recipes_playbooks_list
• recipes_playbook_get
• recipes_playbook_plan
• recipes_mcp_upstream_servers
• recipes_mcp_upstream_tools
• recipes_mcp_upstream_call
• recipes_mcp_upstream_context

MCP サーバーは、生成された次の両方のレシピフィードを受け付けます。

• /api/recipes.json は、カテゴリ、重大度、CVE/GHSA、エコシステム、引き継ぎメタデータを含む、エージェント向けの推奨フィードです。
• /recipes-index.json は、従来の利用者向けに引き続きサポートされています。
• /recipes-browser.json は、インタラクティブライブラリ向けのコンパクトなフィードです。/recipes/ ページは、クロール可能なレシピカードを18件と、それらに完全に一致するハイドレーション用シードをサーバー側でレンダリングし、訪問者が検索にフォーカスする、フィルターを適用する、並べ替える、フィルター済み URL を開く、またはさらに読み込む場合にのみ、完全なフィードをリクエストします。

完全な CVE カタログは、MCP を使わずに利用することもできます。

• /api/cve-catalog/manifest.json では、正確な日付／重大度ポリシー、ソースハッシュ、カバレッジ件数、シャード一覧を宣言します。
• /api/cve-catalog/runtime-summary.json は、カバレッジ合計と、すべてのランタイムアセットのコンテンツ由来キャッシュバージョンを含む、ブラウザー起動用の小さなファイルです。
• /api/cve-catalog/index.json は、/api/cve-catalog/indexes/ 以下にある公開年ごとの完全なパーティションの小さなマニフェストです。オフラインの利用者は必要な年のパーティションだけを取得できます。ブラウザーページの読み込みでも、MCP による完全一致検索でも、これらのパーティションは解析されません。
• /api/cve-catalog/search は、同一オリジンの範囲制限付き広範検索エンドポイントです。runtime-summary.json で宣言されたシャードセットのリビジョンに固定され、nginx によるレート制限が適用され、プレビューを最大 100 件返します。本番の MCP イメージでは、同じマニフェストを基に構築され、ファイル全体の整合性が検証された読み取り専用 SQLite FTS データベースから結果を提供します。フォーカスだけの場合や、不完全な CVE-YYYY-NNNN 識別子の場合は検索リクエストを行いません。
• /api/cve-catalog/records/{cve} は、同一オリジンの範囲制限付き完全一致レコードエンドポイントです。各リクエストはシャードセットのリビジョンに固定され、MCP サービスは該当する CVE を含む決定的なシャード 1 つだけを検証して開きます。現在のブラウザーは、シャードの名前空間を取得する代わりに、このエンドポイントを使用します。
• /api/cve-catalog/browser-index.json.gz は、古いランタイムサマリーで検索 API とレコード API が宣言されていない場合に備えた、1 回限りの互換期間中も引き続き提供されます。API が宣言されている場合、現在のブラウザーはこのファイルをダウンロードしません。そのため、訪問者がコーパス全体の転送やメモリー使用にかかるコストを負担することはなくなりました。
• 正規 CVE ページでは、概要、影響を受けるバージョンの根拠、選定された修正方針の根拠、AI による実装と検証への引き継ぎ、ソース、来歴、引用、スキーマをサーバー側でレンダリングします。カタログアプリケーションの埋め込みやハイドレーションは行いません。ブラウザーからの追加取得を発生させずに機械可読な来歴を確認できるよう、gzip 圧縮された JSON Lines 形式のシャードへの簡潔なリンクを引き続き提供します。
• /api/cve-catalog/search-indexable.json は、正規 CVE ページ、関連 CVE へのリンク、検索結果の発見性を実現する、コンパクトで整合性ハッシュ付きの許可リストです。このポリシーで受け入れられるのは、レビュー済みの安定版 Markdown、または決定論的なレシピ準備完了の根拠要件を満たす完全な AI エンリッチメントのみです。ブラウザーのすべての検索結果は、ローカルの /cve/<ID>/ レコードにリンクします。許可リストに含まれるレコードは、インデックス対象の静的ページとして生成されます。それ以外のすべてのレコードは、noindex,follow を設定した範囲制限付きランタイムレンダラーを使用し、レコード内に公式の CVE.org ソースを保持します。
• /api/cve-catalog/archetypes.json には、カタログのすべてのレコードに対する保守的なレシピの構成に使用する、レビュー済みの修正契約が含まれます。また、ブラウザーと MCP サーバーで共有する、バージョン管理されたエージェント型アクションのスキーマと、エコシステム固有のファイルターゲットヒントも含まれます。
• 各パーティションは、対象範囲内のすべての CVE を、整合性ハッシュ付きの圧縮 JSONL シャードに対応付けます。シャードのレコードには、CVE の完全一致取得に必要な CVSS、CWE、範囲制限付き CPE、参照情報、KEV の来歴が含まれます。
• レコードのサイズを抑えるため、シャードには脆弱な CPE／バージョンの行が最大 12 件まで格納されます。ソースの一致総数と明示的な切り捨てフラグも併せて格納されます。このフラグが設定されている場合、利用者は NVD やベンダーの根拠情報を確認する必要があります。

正規 CVE ページでは、表示するソース一覧と構造化データの引用に、共通の主要参照セットを使用します。生成された生レコードで認められるのは、NVD、CVE.org、スコープが限定された CISA KEV レコード、およびソースにリンクされたベンダーのアドバイザリ、パッチ、リリースノート、緩和策です。リンク切れ、サードパーティのみのリンク、エクスプロイトのみのリンク、汎用の脆弱性データベースへのリンクは、自動的には昇格されません。安定版のレビュー済み Markdown では、「References」セクションに HTTPS の根拠情報を追加で引用できます。修正が複数のサポート対象ブランチや製品ファミリーにまたがる場合、表示されるアクションでは、ガイダンスを不完全な単一のアップグレードに集約せず、信頼できる修正版リリースに関する主張をすべて保持します。 開発用およびカタログ管理の安定版 CVE Markdown は、純粋な静的ビルドでは独立したページを生成せず、Eleventy や汎用のレシピ／検索フィード、タグページ、RSS、サイトマップから除外されます。カタログ導入前に作成された安定版レシピのうち、残る 3 件は通常どおりコンテンツとしてレンダリングされます。 本番環境では、nginx と MCP を利用するランディングサービスを通じて、従来のレシピ URL を正規の CVE ルートへのリダイレクトとして維持できます。すべての情報を検索するには、専用カタログまたは recipes_cve_* MCP ツールを使用してください。

ブラウザーの正確な ID による検索経路とリビジョン固定の検索 API は、マニフェストに記載された対象範囲内の Medium、High、Critical の全レコードをカバーします。MCP サーバーは、SQLite を基盤とする同じカバレッジを recipes_cve_search で公開します。recipes_cve_get が成功すると、正規化されたソースレコード、ソース識別子と参照情報、該当するアーキタイプ、統合された修復契約、および自己完結型の agentic_change_plan が返されます。このプランでは、各緩和策と修復手順を、検証、ロールバック、エビデンス、承認、トリアージの要件を伴う、順序付けられたコード／ファイル操作に展開します。また、ソースの一致セットがレコードの上限を超えた場合も、CPE の明示的な切り捨てメタデータを保持します。

日次 CVE 同期と任意の AI 拡充

.github/workflows/cve-catalog-sync.yml は毎日 09:23 UTC に実行され、手動での実行も可能です。NVD JSON 2.0 の年間フィードと CISA KEV カタログを検証して結合し、すべてのカタログインデックス／シャードを再生成して結果を検証し、依存関係の順序に従ってレシピから派生した決定論的エビデンスを更新し、カタログテストを実行してから、automation/cve-catalog-sync をデフォルトブランチへのプルリクエストとして作成または更新します。初回のプルリクエスト公開には、リポジトリの Settings > Actions > General > Workflow permissions で、GitHub Actions によるプルリクエストの作成を許可する必要があります。

CVE_AUTO_MERGE_ENABLED=true を設定すると、専用の検証ワークフローで正確なヘッドリビジョンの検証に合格した、安全性の承認済みカタログ PR が配信されます。CVE_AUTOMATION_APP_CLIENT_ID と CVE_AUTOMATION_APP_PRIVATE_KEY シークレットが設定されている場合、通常の PR とメインブランチの Build 実行が自然に起動するよう、このワークフローは GitHub App の ID を優先します。App の認証情報がない場合も、ワークフローは自動で実行されます。保護措置を適用した GITHUB_TOKEN によるマージ後、返されたマージ SHA が引き続き現在の main であることを確認し、その正確な SHA を指定して実際の build.yml ワークフローをディスパッチします。本番デプロイゲートが認識するのは、CVE の条件を満たすこれらの Build ディスパッチのみです。そのため、定期モニターや無関係な手動ワークフローがリリースを妨げたり、リリース条件を満たしたりすることはありません。

ソース同期にシークレットは不要です。カタログの拡充には、既存の XAI_API_KEY Actions シークレットを使用し、デフォルトで xAI grok-4.7 を利用します。1 つのリポジトリ変数 CVE_ENRICH_MODEL でプロバイダーとモデルを選択します。Leftover-gold のレビュー、コンテンツの更新、AI メンテナンス、AI イシューメンテナンス、およびこのリポジトリのセキュリティ健全性アクションでは、引き続き XAI_API_KEY を通じて Grok を使用します。

gh secret set XAI_API_KEY --repo stevologic/security-recipes.ai
gh secret set OPENAI_API_KEY --repo stevologic/security-recipes.ai

カタログワークフローはデフォルトで grok-4.7 を使用し、1 回の実行で新規またはソースが変更されたレコードを最大 20 件処理します。スケジュールされたキューは、追跡対象の NVD／CISA カタログから導出されます。候補には、有効なタグ付きベンダーアドバイザリ、パッチ、リリースノート、または緩和策の URL が必要です。ソースが揃ったレコードも、出典に基づく修復の統合が必要なため、引き続き対象となります。各 KEV および深刻度の区分内では、ソースに基づく情報が不足していることを示す決定論的な記録があるレコードよりも先に処理され、その後は影響を受ける製品／バージョンのエビデンスと情報の新しさに基づいて順位付けされます。これは既存の日次リクエスト予算内で実行され、追加の手動実行は不要です。モデルと上限は任意の Actions 変数で変更できます。拡充の上限は 0～50 に制限されています。

gh variable set CVE_ENRICH_MODEL --body "grok-4.7" --repo stevologic/security-recipes.ai
gh variable set CVE_ENRICHMENT_LIMIT --body "20" --repo stevologic/security-recipes.ai

CVE_ENRICH_MODELのみが切り替え用の設定です。grok-*はxAIとXAI_API_KEYを使用します。 gpt-*はOpenAIとOPENAI_API_KEYを使用します。後でDaybreakに切り替える場合は、 この変数をgpt-6-sol+daybreak_blueに変更します。workflow_dispatchの入力 daybreak_probe=trueを指定すると、設定されているプロバイダーに対してプローブ呼び出しを1回行い、 カタログの同期をスキップします。

AIの出力は補足情報であり、その旨が明示されます。厳格な構造化出力を使用し、 Responses APIのウェブ検索の来歴で実際に返されたURLのみを引用して、 data/cve/ai-enrichments.jsonに再現可能な形式で保存します。完全なエンリッチメントがCVE固有のMarkdownドラフトになるのは、 別のゲートで、タグ付きの信頼できるアドバイザリ参照の正確なURLに紐付いた、クレーム単位の影響を受ける製品、露出、修正、検証の証拠が見つかった場合のみです。必須の各クレームは、個別にこのルールを満たす必要があります。また、生成される各手順には、引用元が示された具体的な修正版のクレームが必要です。

キャッシュされたエンリッチメントは恒久的なものとして扱わず、再評価します。レシピ作成可能なエントリーは30日後、KEVエントリーは60日後、その他の完全だが特定されていないエントリー、または証拠不十分なエントリーは180日後に更新候補になります。手動で優先指定されたCVEは、既存のリクエスト上限内で更新を強制します。更新に失敗した場合は、最後に有効だったキャッシュ結果を保持します。ソースのフィンガープリントが無効な場合は、引き続きフェイルクローズとします。同期待ちレポートと自動化の健全性サマリーには、更新期限到来数と手動優先指定数が表示されます。

対象となるドラフトは、maturity: developmentが設定された content/recipes/cve/ai-enrichment-cve-*.mdという名前のファイルとして書き込まれます。これらは一般的なレシピ検出の対象外であり、安定版のレビュー済みレシピを上書きすることもありません。人間のレビュアーは、証拠がそろったエンリッチメントを公開用の修正情報として使用しないようにするにはai_enrichment_review_status: human-reviewed-development-draftを設定し、その用途を承認するにはai_enrichment_review_status: approved-for-ai-authorityを設定できます。注釈のないジェネレーター所有のドラフトには自動証拠ゲートが適用され、常に安定版Markdownが優先されます。data/cve/ai-generated-recipes.jsonの所有権台帳には、生成された各ファイルのハッシュが記録されます。自動化によって更新または削除できるのは、変更されておらずハッシュが一致するドラフトのみです。人による編集、または同じCVEに対応する既存の人間所有の開発版／安定版レシピがある場合、そのMarkdownは人間所有となり、自動置換がブロックされます。AIによる生成は、ソースのCVSS／KEV情報、影響を受けるバージョンのデータ、アーキタイプの選択、レビュー済みの安定版Markdownを変更しません。 キーの欠落、APIによる拒否、タイムアウト、レート制限があっても、NVD／CISAの更新はブロックされません。連続して3回失敗するか15分の予算に達すると呼び出しを停止し、有効なキャッシュ済みエンリッチメントは保持されます。手動実行ではCVEを名前で優先指定できますが、それらのIDは実行ごとの既存上限内の枠を消費し、レシピ作成可能性に関する証拠ゲートを迂回することはありません。

gh workflow run cve-catalog-sync.yml --ref main \
  -f ai_enrichment_limit=20 \
  -f priority_cve_ids="CVE-2026-58644,CVE-2026-56164"

手動ディスパッチは追加のワークフロー実行であり、そのため追加のリクエストが発生する可能性があります。毎日の決定論的なキューでは必要ありません。デフォルト以外のブランチで手動実行すると、レビュー用に、エンリッチメントキャッシュ、所有権台帳、生成されたドラフトが短期間のワークフローアーティファクトとしてアップロードされます。

.github/workflows/leftover-review.ymlは毎日13:17 UTCに実行され、残存するleftover-goldのCVEをGitHub AdvisoriesとNVDに照らしてライブ検証します。 leftover-goldの重大および高の項目が先に処理されます。それらが解消された後、各実行でleftover-goldの中および低のページを最大25件レビューし、完了したIDをdata/cve/leftover-review-state.jsonに記録して、ラベル付きの自動マージPRを作成します。 leftover-reviewジョブはXAI_API_KEYを使用するGrok Build CLIを使い、このシークレットがない場合、またはleftover-goldキューが空の場合は何も実行しません。

実行時のパスは、カタログ規模のトラフィックに対応できるよう、意図的に上限を設けています。

• ハブはコンパクトなランタイムサマリーから起動し、完全一致の検索ではリビジョンに固定された同一オリジンのレコード API を呼び出し、タイトル／製品／ベンダー／フィルター検索では、明示的に検索が意図された場合にのみ検索 API を呼び出します。
• 幅広い検索では、不変で読み取り専用の SQLite から最大 100 件のプレビューを返します。HTTP 境界は 3 秒で、訪問者プロセスやブラウザーのメインスレッドでカタログ全体をデコードすることはありません。
• 完全一致レコードのサービスは、リクエストごとに 1 つのシャードを検証して開きます。MCP の完全一致取得も同じシャードのみを使う経路を利用し、完全一致以外のテキスト検索では、専用エグゼキューター、上限付きの受付キュー、クエリの期限、nginx のレート制限を備えた、マニフェストで固定された SQLite データベースを使用します。
• 不変のブラウザーキャッシュキーは、上流のタイムスタンプではなく、宣言されたレコード／検索コントラクト、アーキタイプのハッシュ、シャードセットのリビジョンに基づきます。

実装済みのビルド境界、完全一致シャードの配信モデル、エビデンスに基づく SEO ポリシー、SQLite 検索ランタイム、残るアーティファクト公開の移行については、CVE スケールアーキテクチャに記載されています。

本番イメージでは、キャッシュ可能なイメージレイヤーで SQLite アーティファクトを一度だけビルドし、個別の SHA-256 サイドカーファイルを記録します。起動時には、スキーマ、カタログのリビジョン、レコード数、マニフェストのダイジェスト、ファイルのダイジェスト、代表的な FTS の投稿を検証します。RECIPES_MCP_EAGER_CVE_SEARCH は、SQLite パスが設定されていない場合の従来のローカルフォールバックにのみ適用されるようになりました。継続的な検索トラフィックには、MCP インスタンスを複数ペアで実行してください。完全一致のシャード読み取りは、上限付きのテキスト検索エグゼキューターおよびキューから引き続き分離されています。

サイトのマークを変更した後は、npm run icons を実行してください。これにより、非公開の Apple タッチアイコンと、本番パフォーマンスゲートで検査される 192／512／マスカブル形式のインストール済みアプリアセットが再生成されます。

本番ビルドでは、大容量の JSON／XML フィードを nginx の gzip_static 用に事前圧縮し、安定版／ドラフトの検出境界を検証するとともに、npm run check:performance でペイロードとファイル数の上限を適用します。

Docker で実行します：

docker build -f Dockerfile.mcp-server -t security-recipes-mcp .
docker run --rm -p 8123:80 security-recipes-mcp

MCP クライアントを次の URL に接続します：

http://localhost:8123/mcp

Python でローカル実行します：

python -m venv .venv
source .venv/bin/activate
pip install -r requirements-mcp-server.txt
python mcp_server.py

Windows PowerShell での有効化：

.\.venv\Scripts\Activate.ps1
python mcp_server.py

サイトをローカルで実行する

前提条件：

• Node.js >= 20
• Python >= 3.10。本番用の npm run build における CVE の事前レンダリング手順では、requirements-mcp-server.txt のインストールが必要です
• Git

python -m pip install -r requirements-mcp-server.txt
npm install
npm run serve

次を開きます：

http://localhost:8080

npm run serve は変更を監視し、増分で再ビルドします。一度だけ本番ビルドを行うには npm run build を実行します（出力先は public/ です）。ビルドでは、既存の出力を削除する前に Python／依存関係の事前チェックを実行し、その後、MCP ランタイムと同じ CVE レンダラーを使用します。Eleventy では static/api/cve-catalog/ のパススルーコピーを意図的に行いません。ページの生成後、上限付きのポストビルド手順でリンク、孤立ファイル、安全でないパス、マニフェストのバイト数／ハッシュの不一致を検出してから、そのカタログサブツリーを配置します。ルートのドットファイルを含むカタログ以外の静的アセットには、通常のパススルー動作が適用されます。

カタログを分離してビルドするには、SECURITY_RECIPES_CVE_CATALOG_ROOT に絶対パスの公開ディレクトリを設定します。Eleventy のデータ、修飾済みページの生成、検証済みカタログのコピーには、すべて同じルートが使用されます。npm run serve はマテリアライザーやカタログのコピーを再実行しないため、開発サーバーで正規の /cve/<ID>/ ページとカタログ API ツリーが必要な場合は、最初に npm run build を一度実行してください。その後の増分ビルドでは、これらのポストビルド出力が保持されます。

Docker Compose

環境ファイルを作成します：

cp .env.example .env

スタックを起動します：

docker compose up -d --build

Docker Compose v2 プラグイン（docker compose）を使用してください。従来の Python docker-compose v1 パッケージはこのスタックではサポートされていません。新しい Docker Engine リリースでは、ログの追跡中に KeyError: 'id' が発生したり、コンテナーの再作成中に KeyError: 'ContainerConfig' が発生したりして、クラッシュすることがあります。

Ubuntu/Debian ホストでは、次のコマンドで Compose v2 と互換性シムをインストールします：

sudo bash scripts/install_docker_compose_v2.sh

デフォルトのルート：

site: http://127.0.0.1:8080/
agent recipe feed: /api/recipes.json
MCP endpoint: /mcp

Compose スタックでは、公開サイトと動的な CVE/MCP レンダラーを、対応するブルー／グリーンのペアで稼働させます：

• security-recipes / mcp-server-blue：ブルーのサイトとレンダラー。
• security-recipes-green / mcp-server-green：グリーンのサイトとレンダラー。
• mcp-server：最初のペアでのロールアウト時、および後方互換性のある手動 Compose ワークフローのために残されている、移行期の単独コンテナーです。ローカルでビルドされたサイトのフィード http://security-recipes/api/recipes.json を読み込むため、フォークや Droplet は公開されている本番インデックスに依存せず、独自のレシピを提供します。

deploy.sh は、撤退するスロットの MCP コンテナーをサイトコンテナーより先に起動してリビジョンを検証し、正規の CVE を直接検証してから、そのペアを Caddy に追加します。手動での Compose 起動では、以前インストールされたスクリプトとの互換性を保つため、最初のロールアウトでも単独コンテナーをデフォルトとして維持します。

Let's Encrypt を使用する nginx または Caddy のリバースプロキシでは、Docker のバインド先をループバックにして、公開ポート 80 と 443 はプロキシに割り当てます：

SECURITY_RECIPES_HTTP_PORT=127.0.0.1:8080

次に、以下へプロキシします：

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

nginx + Let's Encrypt をホストにまとめて簡単にセットアップするには、次を実行します：

sudo bash scripts/configure_nginx_letsencrypt.sh \
  --domain security-recipes.ai \
  --email [email protected]

オペレーター向けガイドの全文は README.nginx-letsencrypt.md にあります。

DigitalOcean Droplet

新しい Ubuntu Droplet では、ヘルパースクリプトを使用します：

sudo bash scripts/setup_digitalocean_droplet.sh \
  --domain security-recipes.ai \
  --email [email protected]

このスクリプトは Docker/Compose をインストールし、ロックされたアプリユーザーを設定して、基本的なホストのセキュリティ強化を有効にし、Compose スタックを起動します。また、HTTPS 用に Caddy を前段に配置できます。さらに、Caddy 対応の Fail2Ban jail も有効にします。1 つのクライアントから 5 秒以内に、高い確度でエクスプロイトを試みていると判断できるパス（例：.env、Git、WordPress、phpMyAdmin、PHPUnit のプローブ）への HTTP 404 応答が最終的に 5 回あった場合、そのアドレスからサイトの TCP ポートおよび HTTP/3 ポートへのアクセスを 1 時間ブロックします。時間が経過すると、アクセスは自動的に再開されます。通常のページの不在、CVE 形式のページの不在、アーカイブのページネーションによる不在は、ブロックの判定回数に含まれません。

セットアップの前に、apex と www の両方の DNS レコードを Droplet に向けてください。管理対象の Caddy は両方のホスト名の証明書を取得し、www から apex の正規ホストへ恒久的にリダイレクトします。HTTP のみでリダイレクトすると、HTTPS のクローラーは TLS ハンドシェイクを完了できません。同じスタックで、これらの上流から security-recipes.si と www.security-recipes.si（SECURITY_RECIPES_MIRROR_DOMAIN）を提供できます。表示されるブランド要素はリクエストの Host に従いますが、SEO の canonical URL は https://security-recipes.ai/ のままです。README.caddy-deploy.md を参照してください。

既存の Droplet では、jail を含むコミットのデプロイ後に、次のコマンドを一度実行して有効化してください。この操作は繰り返し実行しても安全です：

sudo bash scripts/configure_caddy_404_ban.sh
sudo fail2ban-client status security-recipes-caddy-404

Droplet で古い名前付きログボリュームを使用する同梱 Caddy が稼働している場合は、まず .env に SECURITY_RECIPES_TRAFFIC_LOGS_SOURCE=/var/log/caddy を設定し、メンテナンス時間中に Caddy のみを一度再作成してください：

docker compose --profile caddy up -d \
  --no-deps --force-recreate --pull never caddy
sudo bash scripts/configure_caddy_404_ban.sh

このフィルターは Caddy の構造化された client_ip を使用し、偽装可能な転送ヘッダーや User-Agent の値は使用しません。オリジンが後に CDN またはロードバランサーの背後に配置された場合は、ブロック処理をそのプロバイダーの WAF/API に移してください。オリジンのファイアウォールでは、信頼されたプロキシからパケットが届くエンドクライアントを直接ブロックできません。 jail は Googlebot の User-Agent 文字列を信頼しません。公開クライアントとしてカウントする前に、Google の逆引き・正引き DNS チェックを実行します。PTR ホスト名が googlebot.com 配下であり、そのホスト名を解決すると同じ IP が返される必要があります。結果は IP ごとに 1 時間キャッシュされます。ルックアップエラーや 5 秒のリゾルバー期限を超えた場合はフェイルクローズとなり、未検証のクライアントは引き続きスキャナーパスの 404 上限の対象となります。

Caddy を完全に Compose で管理するデプロイでは、Fail2Ban をスタック内で実行することもできます。.env に DEPLOY_COMPOSE_FAIL2BAN=true を設定し、Caddy のログソースはデフォルトの caddy_logs ボリューム（またはホストのバインドマウント）のままにしてください。次回の実行時に、deploy.sh は Fail2Ban コンテナをプルして起動し、ヘルスチェックを行い、その後も更新します。また、Fail2Ban では設定されたファイルが存在している必要があるため、jail の起動前に Caddy のアクセスログファイルも初期化します。デプロイを待たずに手動で起動するには、次のコマンドを実行します。

docker compose up -d caddy fail2ban
docker compose exec fail2ban fail2ban-client status security-recipes-caddy-404

このコンテナはホストのネットワーク名前空間を共有し、ホストおよび Docker 経由で転送される Web トラフィックに jail の nftables ルールを適用するために必要な NET_ADMIN／NET_RAW ケイパビリティのみを持ちます。ホストの security-recipes-caddy-404 jail が有効な状態で、Compose の jail を有効にしないでください。ファイアウォールルールを管理するのは、どちらか一方にしてください。これにより、アプリケーション層で繰り返される 404 スキャンを軽減できますが、上流での大規模な DDoS 保護やリクエストレート制限の代わりにはなりません。このオプションが false の場合、deploy.sh はホストに fail2ban パッケージがインストールされていることを要件としません。ホスト管理のインストールは、droplet のセットアップおよび scripts/configure_caddy_404_ban.sh のワークフローで引き続き対応します。

droplet で Caddy の代わりに nginx を使用する場合は、プロキシなしでホストをブートストラップしてから、nginx ヘルパーを実行します。

sudo bash scripts/setup_digitalocean_droplet.sh --no-caddy
sudo bash scripts/configure_nginx_letsencrypt.sh \
  --domain security-recipes.ai \
  --email [email protected]

ローカル専用またはプロキシ設定済みの droplet の場合：

sudo bash scripts/setup_digitalocean_droplet.sh --no-caddy --no-firewall --no-upgrade
docker compose up -d --build

以前の docker-compose v1 の実行が KeyError: 'ContainerConfig' で失敗した場合は、Compose をアップグレードし、スタックを再作成する前に古いプロジェクトコンテナを削除してください。

sudo bash scripts/repair_docker_compose_containerconfig.sh
hash -r
command -v docker-compose
docker-compose version

本番デプロイでは、必須の GitHub Actions Build ワークフローが main 上で公開するコミット指定のサイトイメージと MCP イメージをプルし、https://security-recipes.ai/ で提供します。同じタイマーで development イメージも https://dev.security-recipes.ai/ にデプロイされます。デプロイ中に Droplet で Node、Eleventy、pip を実行したり、Docker イメージをビルドしたりすることはありません。そのため、デプロイは 1 CPU／2 GB メモリの範囲内に収まります。

MCP のペアデプロイを一度だけアップグレードする

ペアになった MCP サービスを導入する最初のデプロイの前に、デプロイスクリプトだけを更新してから実行してください。すでに実行中の古い deploy.sh プロセスは、ペア構成の Compose ファイルが存在する前に解析済みのため、そのままではこの一度のロールアウトで稼働中の単独 MCP を再作成してしまいます。

git fetch origin main
git checkout origin/main -- deploy.sh
bash deploy.sh

新しいスクリプトは稼働中の単独構成をそのまま維持し、非アクティブな MCP とサイトをまとめて準備してから、ひとまとまりとして切り替えます。この一度だけの手順を終えれば、既存の bash deploy.sh cron エントリを変更する必要はありません。

main ワークフローが初めて成功すると、GHCR パッケージが 2 つ作成されます。これらを公開するか、パッケージの読み取り権限を持つファイングレインドトークンで、デプロイサービスが使用する root アカウントを認証してください。

printf '%s' "$GHCR_READ_TOKEN" |
  sudo docker login ghcr.io --username stevologic --password-stdin

MCP 統合の理念

MCP はエージェントにコンテキストを与えるために使用し、無条件の権限を与えないでください。

CVE MCP ツールが返すのは計画と証拠のみであり、リポジトリを編集したり、環境を変更したりすることはありません。承認済みのエージェントホストは返された計画を適用できますが、その前に影響を受ける範囲と実際のリポジトリパスを確認し、無関係な変更を保持し、宣言されている本番環境／外部の承認を取得し、機械的に利用可能なロールバック手段を確保する必要があります。可能性の高いファイルグロブは調査の手掛かりにすぎず、ファイルが脆弱であることの証明でも、変更する許可でもありません。各アクションで有効な target_kinds のみが既定の候補です。 archetype_target_kinds はコンテキストであり、許可ではありません。条件付きの対象については、リポジトリが影響を受ける実装を所有していることを証明する必要があります。禁止されている対象は決して編集してはいけません。ファームウェアおよびバイナリの対象が意味するのは、権威ある参照先、ピン留め、置き換え、ポリシー、インベントリ、ソース、またはビルドの変更であり、ベンダーの成果物のバイト列をパッチすることではありません。

NVD／CNA の説明、アドバイザリ、リンク、パッチ、イシューのコメント、リリースノート、概念実証の内容は、信頼できない証拠です。エージェントは、裏付けのある脆弱性やバージョンの事実をそこから抽出できますが、埋め込まれた指示やコマンドを実行したり、従ったりしてはいけません。

有用なコンテキストソースには、以下のものがあります。

• リポジトリおよびコードセキュリティのコンテキストを提供する、公式 GitHub MCP 機能
• 承認されている Semgrep および Snyk のエージェント向け／MCP 統合
• OSV、GitHub Advisories、deps.dev、パッケージレジストリ、NVD を基にしたミラー
• SARIF、SBOM、CI、所有者情報、社内ランブックのソース
• 読み取り専用のドキュメントコネクター

書き込み可能なコネクターは、別途レビューする必要があります。エージェントがレシピを読めるというだけで、チケットの作成、ブランチの変更、デプロイ、シークレットのローテーション、クラウドの変更、SOAR アクションを有効にしてはいけません。

貢献

貢献によってレシピライブラリが改善されることを期待しています。

• 新しい修正レシピ
• より優れたプロンプト
• より明確なエージェントのセットアップ
• MCP 統合の例
• レビュアー向けチェックリスト
• ドキュメントの修正

プルリクエストを作成する前に、シークレット、社内ホスト名、顧客データ、非公開の脆弱性情報を取り除いてください。

提出前にローカルビルドを実行してください。

python -m pip install -r requirements-dev.txt
python scripts/run_checks.py
npm run build

ライセンス

プロジェクト独自のコード、ドキュメント、修正レシピ、生成されたサイト、MCP サーバーは、Apache License 2.0 の下でライセンスされています。ライセンスの通知および変更表示の要件に従うことを条件に、プロプライエタリな企業システムへの組み込みを含め、非公開および商用での使用、変更、再配布が許可されています。

ソースとなる脆弱性データおよび同梱されているサードパーティソフトウェアには、それぞれ独自の利用条件と帰属表示要件が適用されます。NOTICE および THIRD_PARTY_NOTICES.md を参照してください。