依存パッケージやAIモデルに潜む危険を手元で調べるOSS「ForgeGuardian」を解説

「開発の現場でAIにコードを書かせ始めたら、知らない部品（パッケージ）が次々に増えている。中身を誰も確かめていない」「AIモデルやMCPの道具まで外から取り込むようになったが、どこから手を付けて調べればよいのか分からない」——ソフトウェアの調達や開発の管理を任された担当者から、ここ一年で増えてきた声です。これは新しい検査の道具を一つ足せば片づく話ではありません。本当は、自社のソフトウェアが何に依存しているかを把握し、取り込む前に人が確かめる流れを持てているかという、調達と開発の統制の問題です。この記事では、依存パッケージやAIモデルに潜む危険を手元で調べるOSS「ForgeGuardian」を題材に、何を調べる道具なのか、導入の案内にどんな注意点があるのか、企業はどう備えるべきかを整理します。導入や操作の手順は扱いません。

ForgeGuardianとは何か。2026年10月時点で確かめられる事実

ForgeGuardian は、GitHub で公開されているソフトウェアの供給網（サプライチェーン：自社のソフトウェアが依存する外部の部品や、それを作り配る流れ全体）の安全を調べる道具です。リポジトリの説明文は「手元で動き、AIを組み込んだソフトウェア供給網のセキュリティの基盤」と名乗っています。READMEの冒頭では、依存するすべてのパッケージを対象にした検査の道具であり、8つの検査の仕組み、9つの配布の場、223件以上の検知の決まりを備え、外部への接続なしでも動くと説明しています。

2026年10月23日時点で確かめられる事実を並べます。リポジトリの作成は2026年8月15日、最後の更新は9月19日で、スターは97、派生（フォーク）は9です。ライセンスはApache-2.0で、オープンソースの定義を管理する団体（OSI）が承認したライセンスです。そのため、この記事ではOSSと呼びます。公開されているリリースは2026年8月31日付の版3.0.0の1つで、主な実装の言語は Go と TypeScript です。

作っているのは企業ではなく、個人のアカウントです。作者のアカウントは2019年8月に作られ、公開リポジトリは135、フォロワーは10で、所属の会社は書かれていません。変更の記録（コミット）は147件あり、そのうち143件を作者本人が占め、もう1人の協力者が4件です。事実上、一人の開発者が支えているOSSだと分かります。この点は、後の「安全性の評価」で扱う注意点につながります。

なぜ今、依存する部品の検査が話題になるのか

現代のソフトウェアは、自社で書いた部分よりも、外から取り込んだ部品のほうが多いことが珍しくありません。部品がさらに別の部品に依存するため、実際に何が入っているかを人が把握するのは難しくなっています。悪意のある人が人気の部品を乗っ取ったり、よく似た名前の偽物を登録したりする攻撃は、以前から繰り返し報告されてきました。

ここにAIが加わりました。AIがコードを書くと、目的に合いそうな部品を提案し、そのまま取り込む流れが速くなります。AIが実在しない部品の名前を挙げることがあり、その名前で悪意のある部品が登録されると取り込んでしまうおそれがある、という指摘もあります。つまり、部品を選ぶ判断の一部がAIに移ったことで、人が一つずつ確かめる機会が減っているのです。

さらに、取り込む対象はプログラムの部品だけではなくなりました。外部で公開されたAIモデルのファイルや、AIエージェントに道具を渡すMCPのサーバーも、社外から取り込む部品です。ForgeGuardian が注目されるのは、こうしたAI時代に増えた新しい種類の部品まで、同じ検査の流れに入れようとしているからです。ただし、道具があれば判断まで任せられるわけではない点は、後で詳しく扱います。

8つの検査の仕組み：既知の脆弱性から振る舞いまで

READMEによると、ForgeGuardian は検査のたびに、使える検査の仕組みを同時に動かします。常に動くのは5つで、残りの3つは利用者が別に用意したときだけ動く任意のものです。常に動く5つの1つ目は、公開された脆弱性の情報の集まり（OSV）と照らして、既知の脆弱性（CVE）を持つ部品を見つけるものです。

2つ目は振る舞いの検査で、部品を導入するときに自動で動く処理に悪意がないか、人気の部品に似せた名前（タイポスクワット）ではないかを見ます。3つ目はマルウェアの検査で、バイト列や文字の並びの特徴と照らし合わせます。4つ目と5つ目は後の節で扱う、AIモデルとMCPの検査です。照合だけでは見つからない悪意ある部品そのものを拾おうとしている点が、従来の脆弱性検査との違いです。

任意の3つは、外部で広く使われている検査の道具（Grype・Trivy・Semgrep）を呼び出すもので、成果物やコンテナの中身、ソースコードの書き方の問題（静的解析）を深く調べます。対応する配布の場として、READMEは npm、PyPI、Go、Maven、RubyGems、Cargo、NuGet、Hugging Face、GitHub Actions の9つを挙げています。ふだん使う言語ごとに別々の道具を使い分けていた組織にとっては、一つの画面でまとめて見られることが利点になりえます。

AIモデルとMCPの道具の説明まで調べる点

ForgeGuardian の特徴として目を引くのが、AIに関わる2つの検査です。1つはAIモデルの検査で、READMEは「危険な Hugging Face の重み（学習済みのモデルのファイル）」を見つけると説明しています。モデルのファイルの形式によっては、読み込んだだけでプログラムが動いてしまうものがあり、この危険は以前から指摘されてきました。検知の決まりの一覧にも、危険なモデルのファイルや、説明書き（モデルカード）が欠けたモデルを見つける決まりが12件あると書かれています。

もう1つはMCPの検査です。MCPのサーバーは、AIエージェントに道具を渡すとき、その道具の説明文もAIに読ませます。この説明文に、AIをだます指示（プロンプトインジェクション：AIへの指示に紛れ込ませて意図しない動作をさせる攻撃）を仕込む手口が知られています。READMEによると、ForgeGuardian は道具の説明文に紛れ込んだ指示や、別の道具になりすます手口、MCPを通じた情報の持ち出しを狙う形を、13件の決まりで検知します。

AIを業務に取り込むほど、取り込む部品のうち「プログラム以外のもの」の比率は上がります。モデルのファイルや道具の説明文は、従来の脆弱性検査では対象外になりがちでした。その範囲に検査を広げようとする方向性そのものは、守る側にとって参考になります。ただし、13件や12件という決まりの数で、未知の手口まで防げるわけではないことは押さえておく必要があります。

223件以上の検知の決まりと、その中身

READMEは、2016年から2026年までに実際に起きた供給網への攻撃をもとに、223件以上の検知の決まりを同梱していると説明しています。内訳の表では、悪意があると確認された部品の一覧が80件、導入時に環境の情報や鍵を盗むといった振る舞いの決まりが42件、難読化した読み込み処理や暗号資産の採掘、遠隔操作の道具などの特徴が44件、名前の紛らわしい部品の候補が27件、MCPの決まりが13件、モデルのファイルの決まりが12件とされています。

ここで一つ、読み手として気づいておきたい点があります。表の内訳を足し合わせると218件で、見出しの「223件以上」とは一致しません。決まりは別のリポジトリで管理され、更新で増えていく仕組みのため、数え方や時点の違いによる差の可能性があります。いずれにしても、数字は目安であり、検知できる範囲を保証するものではないと読むのが妥当です。

決まりは利用者が自分で追加でき、READMEは協力の入り口として、まず検知の決まりを書くことを勧めています。共同体で決まりを育てる形は、新しい攻撃への追従を速くする利点がある一方、誰がどの決まりを書き、どう確かめたかを利用者側でも見る必要があるという面もあります。決まりの質が、検査の質をそのまま左右するからです。

部品表・署名・方針の決まりで「何を使っているか」を残す

検査のほかに、READMEは管理のための機能も並べています。代表的なのが、ソフトウェア部品表（SBOM：ソフトウェアに含まれる部品とその版の一覧）の作成です。広く使われている2つの形式（CycloneDX と SPDX）に対応するとされます。部品表があれば、新しい脆弱性が公表されたとき、自社のどの製品が影響を受けるかを素早く調べられます。

また、成果物に電子的な署名を付けて確かめる仕組み（Sigstore を使う方式）、出どころの記録（来歴）の追跡、方針を設定ファイルとして書いて自動で適用する機能、使ってよい部品と使ってはいけない部品の一覧の管理も挙げられています。部品ごとにAからFの評価を付ける機能や、依存関係を図にして危険の集まる場所を示す機能もあります。

開発の自動化の流れ（CI/CD）に組み込み、重大度が一定以上の問題が見つかったら処理を止める使い方も、READMEで案内されています。結果は GitHub のセキュリティの画面に取り込める形式で出せるとされます。こうした機能は、検査の結果を「その場で見て終わり」にせず、記録と規則として残すためのものです。統制の観点では、検査そのものよりもこの部分のほうが価値が大きい場合もあります。

画面とAIの機能：助言と修正の代行

ForgeGuardian には利用者の手元で動く管理画面があり、READMEは30以上の画面を7つの分類で備えると説明しています。検査の履歴、監視、部品の一覧、方針、外部への通知（Slack や Discord など）、そして画面から操作の命令を打てる端末の機能まで含まれます。監視の機能について、READMEは「自動の隔離」を挙げていますが、リポジトリ内の説明文書では監視は変化を見つけて報告するものとして書かれており、隔離が具体的に何をするのかは確認できませんでした。

AIの機能は、使うかどうかを利用者が選ぶ形です。READMEによれば、AIによる助言（見つかった問題を平易な文章で説明し、直し方を示す）と、修正を代行するエージェントがあり、複数のAIの提供元や、手元で動かすAIモデルにも対応するとされます。リポジトリ内の説明文書は、助言の機能を使うと見つかった問題の情報が、設定したAIの提供元へ送られると明記しています。

修正の代行については、同じ文書が、既定では書き換えをしない試し実行で動き、明示的に適用を指示したときだけ依存関係の定義ファイルを書き換えると説明しています。一方で、適用を前提にした別の入口もあると書かれており、人の承認を挟む仕組みについての記述は見当たりませんでした。AIが直した内容を、誰がいつ確かめるかは利用者が決める必要があるということです。

想定される使い方・使う場面

一次情報から読み取れる使い方は、大きく3つです。1つ目は、開発者が自分の手元でプロジェクトを検査し、取り込もうとしている部品に問題がないかを確かめる使い方です。外部に接続しない運用にも対応するとされるため、ソースコードを外に出したくない組織でも検討しやすい形です。

2つ目は、開発の自動化の流れに組み込み、一定以上の問題があれば取り込みを止める関門として使う場面です。AIが提案した部品をそのまま取り込む流れが速くなっている今、人の目が届かない速さで増える部品に、機械的な関門を置く意味は大きくなっています。3つ目は、管理画面で部品表や評価を一覧し、組織全体の依存の状態を把握する使い方です。

どの場面でも、ForgeGuardian は判断の材料を出す道具であって、取り込むかどうかを決めるのは人です。また、遠隔の機械を接続して検査する機能も説明文書に書かれており、読み取りだけで遠隔の機械には何も書き込まないとされています。便利な半面、検査のために渡す接続の権限は、それ自体が管理すべき資産になる点は意識しておきたいところです。

類似の手段との違い

依存する部品を調べる手段は、ForgeGuardian のほかにもあります。比べると、この道具の立ち位置が見えます。以下は、一次情報で確認できる範囲と一般的な傾向をもとにした整理で、個別の製品の優劣を示すものではありません。

観点	ForgeGuardian	既知の脆弱性だけを照合する道具	商用の供給網セキュリティのサービス
調べる範囲	既知の脆弱性・導入時の振る舞い・マルウェアの特徴・AIモデル・MCP（READMEより）	既知の脆弱性が中心	製品により幅広い（契約で確認）
動く場所	手元・自社の環境。外部接続なしにも対応とされる	手元や開発の流れの中	提供元のクラウドが多い
運営の体制	個人1人が中心。有料版で組織向け機能と保守の約束	道具による	企業が運営し、保守の約束がある
AIの使い方	任意で助言と修正の代行。問題の情報を設定先へ送る	使わないものが多い	製品による
導入の負担	公式の導入スクリプトが追加の道具や常駐まで設定	比較的軽い	契約と接続の設定

表から分かるのは、ForgeGuardian が無料で広い範囲を一つにまとめている代わりに、運営の体制と導入の作法は自社で見極める必要があるという構図です。READMEによれば、検査の本体や操作の道具は無料で、有料版は組織での権限管理、クラウドでの提供、保守の約束（SLA）を加えるものです。中心はOSSで、組織向けの一部が有料という形です。

既に脆弱性の照合の道具を使っている組織なら、置き換えではなく、振る舞いやAIモデルの検査を補う形で比べるのが現実的です。どの手段を選んでも、検査で見つからなかったことは安全の証明にならない、という前提は変わりません。

安全性の評価：注意付きとした根拠

このラインでは、OSSを取り込んだり動かしたりせず、公開されている情報だけで安全性を精査しています。ForgeGuardian の判定は「注意付き」です。まず、問題が見つからなかった点を挙げます。ライセンスはApache-2.0で、公開されたセキュリティ勧告は2026年10月23日時点でありません。セキュリティの方針の文書があり、脆弱性は公開の場ではなくメールか GitHub の勧告の仕組みで報告するよう求め、48時間以内の受付と、重大な問題の14日以内の修正を目標に掲げています。

一方で、注意付きとした根拠は2つあります。1つ目は導入の案内です。READMEは、ネット上のスクリプトを取得してそのまま実行させる方法（ウィンドウズ向けにも同じ形）を最初の導入方法として示しています。2つ目は運営の体制で、作者は2019年作成の個人のアカウントで、変更のほとんどを一人が担っている点です。作者のアカウント自体は古く、作られたばかりの使い捨てのものではありませんが、組織としての保守の体制は確認できません。

念のため添えると、ここで挙げた注意点は「危険なソフトウェアだ」という判定ではありません。悪意のある処理やマルウェアが報告されているわけでもありません。ただし、問題が見つからなかったことは安全の保証ではありません。公開情報の精査で分かるのは、取り込む前に確かめるべき点がどこにあるか、までです。

導入の案内に残る注意点

導入スクリプトの中身を読んで（実行はせずに）確かめた点を、防御の観点から整理します。まず、ダウンロードした本体の整合性の確認（チェックサムの照合）は行われますが、照合が一致しなくても導入は止まらない作りになっています。セキュリティの方針の文書はリリースに署名を付けていると書いていますが、導入スクリプトの中で署名を確かめる処理は見当たりませんでした。

次に、導入スクリプトは管理者の権限を使ってシステムの部品を追加し、任意の検査の道具（Grype・Trivy・Semgrep）も入れようとします。そのうち2つは、それぞれの配布元の開発中の最新版の導入スクリプトを取得して実行する形です。さらに、OSの仕組みを使って管理画面を常に動くサービスとして登録し、利用者がログアウトしても動き続ける設定まで行います。

そして、環境の変数で別の値を渡さない限り、管理画面の管理者の初期パスワードとして固定の値を設定ファイルに書き込み、画面にも表示します。手元の機械の中だけで使うなら影響は限られるかもしれませんが、共有の機械やサーバーで初期のまま動かせば、誰でも入れる管理画面になりかねない点は見落とせません。これらは悪意を示すものではなく、導入を簡単にするための作りと考えられますが、企業の環境に入れるなら一つずつ確かめるべき点です。

悪用されうるリスク

ForgeGuardian は守るための道具ですが、守る道具ほど強い権限と多くの情報を持ちます。ここでは概要の水準で、想定しうる危険を挙げます。いずれも推測を含み、実際に起きたと報告されているものではありません。1つ目は、導入の経路が狙われる危険です。ネット上のスクリプトをそのまま実行する方式では、配布元のアカウントや取得先が乗っ取られた場合、利用者の機械で任意の処理が動く可能性があります。

2つ目は、管理画面が持つ情報と機能です。管理画面には組織の部品表や見つかった弱点の一覧が集まり、画面から命令を打てる端末の機能や、遠隔の機械へ接続する機能もあります。初期パスワードのまま外から届く状態で動いていれば、自社の弱点の一覧と、命令を実行できる窓口を同時に渡すことになりかねません。守るための情報は、攻める側にとっても価値の高い情報です。

3つ目は、AIの機能を通じた情報の流れです。助言の機能を使えば、見つかった問題の情報が設定したAIの提供元へ送られます。どの提供元を使うかを組織で決めていなければ、自社の弱点の情報が、意図しない外部のサービスに渡る可能性があります。4つ目に、一人の開発者に依存するOSSは、作者が離れたりアカウントが乗っ取られたりしたときの影響が大きくなりやすい、という一般的な弱さもあります。

導入を検討するときに確かめること

ForgeGuardian を評価の候補にするなら、次の順で確かめると、検査の道具そのものが新しい危険の入口になる事態を避けやすくなります。手順は確認の観点にとどめ、操作の方法は書きません。

この順番には理由があります。検査の道具は、組織の弱点の情報と強い権限を同時に扱うため、ほかのソフトウェアより先に取り込みの作法を決めておく価値が高いのです。

企業が取るべき対策

ForgeGuardian を使うかどうかにかかわらず、AIがコードを書く時代に企業が整えておきたい対策を4つ挙げます。1つ目は、使ってよい部品と取り込みの経路を決めることです。開発者やAIが外部の部品を自由に取り込める状態から、社内で確かめた取得先を通す状態へ移すことが、供給網の統制の土台になります。

2つ目は、ソフトウェア部品表を作り、継続して更新することです。新しい脆弱性や悪意のある部品が公表されたとき、影響を受ける製品をすぐ調べられるかどうかが、対応の速さを決めます。3つ目は、AIモデルのファイルやMCPのサーバーも、プログラムの部品と同じ調達の手続きに入れることです。取り込む前に出どころと形式を確かめ、承認の記録を残します。

4つ目は、検査の道具そのものの管理です。検査の道具は強い権限と組織の弱点の情報を持つため、導入スクリプトをそのまま実行することを社内の規程で禁じ、成果物の署名を確かめてから使うという決まりを置きます。管理画面の初期パスワードの変更、外からの接続の制限、操作の記録の保管も、導入の条件に含めます。

AIに任せる範囲と、人が決める範囲

ForgeGuardian のようにAIの助言や修正の代行を持つ道具が増えると、「AIが安全な部品を選び、直してくれる」と考えたくなります。けれど、AIを万能と見なすのは危険です。まず、取り込むかどうかの判断はAIにさせないことです。AIの助言は判断の材料であり、最終の判断と責任は人が持ちます。

次に、AIに根拠を書かせることです。どの検知の決まりに当たったのか、どの脆弱性情報をもとにしたのか、直した理由は何かを、AIの出力に必ず添えさせます。根拠のない「安全です」「危険です」は、確かめようがありません。そして、人が確認する範囲を先に決めることです。たとえば、依存関係の定義ファイルの書き換えは必ず人が差分を見てから取り込む、と決めておきます。

• AIが提案した部品を、検査も承認もなしにそのまま取り込む
• 検査で何も見つからなかったことを、安全の証明として扱う
• 修正の代行に適用まで任せ、変更の差分を誰も確かめない
• 見つかった弱点の情報を、どのAIの提供元に送るかを決めずに助言の機能を使う
• 検査の道具を、ネット上のスクリプトから管理者の権限でそのまま導入する

裏を返せば、AIに任せてよいのは、決めた範囲の中で検査の結果を整理し、直し方の案を出すところまでです。何を取り込み、何を直し、いつ止めるかは人が決める。この線を先に引いておけば、AIの速さを安全に生かせます。

よくある質問

ForgeGuardian を入れれば、AIが書いたコードの部品は安全になりますか

なりません。ForgeGuardian は既知の脆弱性や、知られた手口の特徴に当たる部品を見つける道具です。検知の決まりにない新しい手口は見逃す可能性があります。検査は取り込みの手続きの一部であり、取り込む部品を決める統制と組み合わせて初めて意味を持ちます。

無料で使えるのですか

READMEによれば、検査の本体、操作の道具、共同体の検知の決まり、自社で動かす管理画面、AIの機能はApache-2.0で無料です。組織での権限管理、クラウドでの提供、保守の約束は有料版の機能とされています。保守の約束が必要な組織は、有料版の条件を提供元に確かめる必要があります。

外部にデータは送られますか

READMEは、検査は手元で動き、利用状況の送信（テレメトリ）はしないと説明しています。ただし、AIの助言の機能を使うと、見つかった問題の情報が設定したAIの提供元へ送られることが説明文書に書かれています。また、脆弱性の情報の照合や決まりの更新のために外部へ接続する可能性があり、この点は導入前に検証用の環境で確かめるのが確実です。

• ForgeGuardian のライセンス・公開時期・スター数・コミット数・リリース・セキュリティ勧告の有無は、公式リポジトリを2026年10月23日に確かめた範囲に基づきます。数値や機能は更新で変わることがあります
• 導入スクリプトの挙動は、公開されているスクリプトの中身を読んで確かめたもので、実行はしていません。最新版では変わっている可能性があります
• 自動の隔離の具体的な動き、AIの修正の代行の承認の仕組み、外部への接続の範囲は、公開情報では確認できませんでした

まとめ

ForgeGuardian は、依存パッケージ、AIモデルのファイル、MCPの道具の説明文までを手元で検査しようとするOSSです。2026年8月に公開され、Apache-2.0で無料で使え、既知の脆弱性の照合に加えて、導入時の振る舞いや名前の紛らわしさ、危険なモデルのファイルまで調べるとREADMEは説明しています。AIがコードを書き、部品を選ぶ時代に、確かめるべき部品の範囲が広がっていることを示す道具だと言えます。

一方で、主な開発者は個人1人で、公式の導入スクリプトは整合性の確認が一致しなくても止まらず、管理者の権限での追加導入、常駐の設定、固定の初期パスワードの書き込みまで行います。守るための道具も、取り込む前に人が確かめる対象です。検証用の環境で試し、取り込みの経路と初期の設定、AIの機能の扱いを先に決めてから評価してください。

そして、どの道具を使っても、取り込むかどうか、何を直すか、いつ止めるかを決めるのは人です。AIの助言には根拠を添えさせ、人が確認する範囲を先に決める。この記事が、自社の供給網の統制を見直すきっかけになれば幸いです。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。