こんにちは、インフラエンジニアのryuです。
「自分は変なコードなんて書いていない。だから安全だ」——そう思っていませんか。
ところが2026年のいま、いちばん多い侵入経路は、あなたが書いたコードではありません。あなたが使っているコード、つまり誰かが作ったライブラリやツールのほうです。
料理でたとえるなら、こうです。あなたは丁寧に手を洗い、清潔なキッチンで調理している。それなのに、仕入れた食材の一つにこっそり毒が混ぜられていたら、どんなに気をつけて料理しても客は倒れてしまいます。
この「仕入れルート」を狙う攻撃を、ソフトウェアサプライチェーン攻撃と呼びます。今日はこの言葉を、初心者の方にもわかるようにほどいていきます。
ソフトウェアサプライチェーン攻撃って、そもそも何？¶
まず「サプライチェーン」という言葉から。これはもともと物流の用語で、原材料の調達から製造、出荷、店頭に並ぶまでの一連の流れを指します。
ソフトウェアにも、まったく同じ流れがあります。
いまのアプリは、ゼロから全部を自作しているわけではありません。ログを出すライブラリ、日付を扱うライブラリ、暗号を計算するライブラリ——数え切れないほどの「他人が作った部品」を組み合わせて動いています。npm install や pip install を打つたびに、あなたのアプリには何十、何百という外部の部品が運び込まれているのです。
この部品の流れのどこかに攻撃者が入り込み、悪意あるコードを紛れ込ませる。それがソフトウェアサプライチェーン攻撃です。
サプライチェーン攻撃とは、標的そのものではなく、標的が信頼して取り込んでいる「部品」や「委託先」を経由して侵入する攻撃手法のこと。
厄介なのは、部品はさらに別の部品を呼び、その部品もまた別の部品を呼ぶ、という入れ子構造になっている点です。あなたが直接選んだ部品は10個でも、その先に芋づる式にぶら下がる部品は数百に膨らみます。この見えない部分こそ、攻撃者が身をひそめる場所になります。
自分で選んだ部品なら、まだ素性を確かめる気にもなります。けれど「自分が選んだ部品が、勝手に連れてきた部品」まで一つずつ目視で確認している人は、まずいません。攻撃者はそこを突きます。人間の注意が届かない奥のほうに、そっと毒を仕込むわけです。
しかも、こうした部品の多くは無償のオープンソースソフトウェア（OSS）で、少人数のボランティアが支えている場合が少なくありません。世界中が頼りきっているのに、メンテナンスは数人の善意で回っている——この構造そのものが、攻撃者にとっては狙いどころになります。
なぜ「いま」これほど騒がれているのか¶
理由はシンプルで、実際に被害が急増しているからです。
セキュリティ企業 Sonatype の集計では、2025年だけで新たに45万件を超える悪意あるパッケージが発見され、累計は120万件を超えました。第三者製ソフトウェアに起因するインシデントを1件以上経験した組織は、7割を超えたとも報告されています。
日本でも他人事ではありません。IPA（情報処理推進機構）の「情報セキュリティ10大脅威」では、サプライチェーンや委託先を狙った攻撃が組織向けの脅威として長く上位に居座り続け、2025年版でも3年連続で2位に選ばれています。
つまりこれは、一部の尖ったエンジニアだけが気にする話ではなく、ソフトウェアを使うすべての組織が向き合わざるを得ないテーマになった、ということです。
実際に何が起きたのか——記憶に新しい事件¶
抽象的な話を続けても実感がわきません。近年、世界を震撼させた具体的な事件を三つ挙げます。
まず、2024年3月に発覚した xz utils の事件です。これはLinuxで広く使われる圧縮ライブラリで、なんと約3万ものDebian／Ubuntuのパッケージが依存していました。
犯人は、数年かけてこのプロジェクトに貢献し、開発者として信頼を勝ち取ったうえで、SSHの認証を密かに突破できるバックドアを仕込みました。深刻度を示すCVSSスコアは満点の10。発覚のきっかけは、あるエンジニアが「SSHログインがいつもより0.5秒ほど遅い」とわずかな違和感に気づいたことでした。あと一歩発見が遅れていたら、世界中のサーバーが乗っ取り可能になっていたと言われています。
次に、2025年3月の GhostAction。これはGitHub Actions、つまりCI/CDの仕組みそのものを狙った攻撃です。一つの汚染されたActionを経由して、多数のリポジトリからビルド時の秘密情報（トークンやパスワード）が抜き取られました。
そして2025年9月の Shai-Hulud。npmの世界で、感染したパッケージが自分自身を複製しながら他のパッケージへ次々と広がっていく、いわば自己増殖するワームでした。500以上のパッケージが巻き込まれたとされています。
xzの一件が多くのエンジニアに衝撃を与えたのは、破られたのが技術ではなく人間の信頼だったからです。犯人は攻撃コードを力ずくで押し込んだのではなく、時間をかけて「信頼できる開発者」になりすまし、正規の手続きで毒を運び込みました。ファイアウォールでもパスワードでも防げない種類の攻撃だった、というわけです。
三つの事件を並べると、狙われる場所が違うことがわかります。
| 事件 | 発覚時期 | 狙われた場所 | 手口の特徴 |
|---|---|---|---|
| xz utils バックドア | 2024年3月 | OSSライブラリ本体 | 信頼を得た内部者が数年がかりで仕込む |
| GhostAction | 2025年3月 | CI/CDパイプライン | 汚染されたActionから秘密情報を窃取 |
| Shai-Hulud | 2025年9月 | npmパッケージ配布網 | 自己増殖して被害を自動で拡大 |
ライブラリ本体、ビルドの仕組み、配布網。仕入れルートのあらゆる段階が標的になり得る、という現実がここに表れています。
守るための3つの武器——見える化・署名・来歴¶
では、どう守るのか。魔法の一手はありません。ただ、2026年の「新常識」として押さえておきたい考え方が三つあります。順番に見ていきましょう。
まず「何を使っているか」を見える化する——SBOM¶
最初の武器は SBOM（エスボム）です。Software Bill of Materials の略で、日本語では「ソフトウェア部品表」と訳されます。
食品の原材料表示を思い浮かべてください。パッケージの裏に「小麦、卵、乳成分を含む」と書いてあるおかげで、アレルギーのある人は口にする前に危険を避けられます。
SBOMはこれのソフトウェア版です。「このアプリは、どのライブラリの、どのバージョンを使っているか」を機械が読める形でリスト化したもの。これがあれば、ある部品に脆弱性が見つかったとき、「うちの製品は影響を受けるのか？」を一覧を見るだけで即座に判断できます。
SBOMは、いまや推奨にとどまりません。米国の大統領令14028を皮切りに、2024年12月に発効したEUのサイバーレジリエンス法（CRA）でも活用が明記され、事実上の「義務」へと向かっています。日本でも経済産業省が2023年7月に「ソフトウェア管理に向けたSBOMの導入に関する手引」を公開し、導入を後押ししています。
SBOMは手作業で書くものではなく、ツールで自動生成します。たとえば syft を使えば、コンテナイメージから部品表を一発で吐き出せます。
# コンテナイメージからSBOMを生成する（Syft）
syft myapp:latest -o spdx-json > sbom.spdx.json
# 生成したSBOMを脆弱性データベースと突き合わせる（Grype）
grype sbom:./sbom.spdx.json
大事なのは、一度作って棚に飾る「紙のSBOM」で終わらせないこと。部品の脆弱性は日々見つかるので、SBOMは継続的に更新し、脆弱性情報と突き合わせ続けて初めて意味を持ちます。
次に「本物である」ことを証明する——署名と来歴¶
SBOMで中身が見えても、「そのライブラリ、本当にオリジナルのまま？途中ですり替えられていない？」という疑問は残ります。ここで二つ目と三つ目の武器が登場します。
一つは署名です。配布物にデジタル署名を付け、受け取る側が「確かに正規の発行者が作ったもので、改ざんされていない」と検証できるようにします。この署名を、鍵の管理を難しくせず手軽に行える仕組みが Sigstore です。公開鍵暗号の考え方がベースになっているので、仕組みをきちんと理解したい方は公開鍵暗号の基礎もあわせて読むと腑に落ちます。
もう一つが来歴（プロベナンス）です。「この成果物は、どのソースコードから、どのビルド環境で、どんな手順で作られたか」を記録し、改ざんできない形で残します。この考え方を段階的に定義した枠組みが SLSA（サルサ）で、いまはバージョン1.0が公開されています。
来歴を残しておけば、GhostActionのようにビルドの途中ですり替えが起きても「作られ方がおかしい」と検知できます。GitHub ActionsやGitLab CIをすでに使っているチームなら、SLSAレベル2の来歴生成とSigstore署名は、数日程度の作業で組み込めると言われています。
三つの武器を、守りの流れとして整理すると次のようになります。
| 武器 | 答える問い | 代表的なツール／標準 |
|---|---|---|
| SBOM | 何を使っているのか？ | Syft、Grype、SPDX |
| 署名 | 本物で、改ざんされていないか？ | Sigstore（cosign） |
| 来歴（SLSA） | 誰が、どう作ったのか？ | SLSA、in-toto |
現場で今日から何を始めるか¶
「大企業の話でしょう」と感じたかもしれません。でも、始めの一歩はとても小さくて構いません。
まずは自分たちが「何を使っているか」を知ること。守りは、見えていないものには効きません。
たとえば、いま動かしているコンテナに対して syft を一度走らせてみる。それだけで、自分のアプリが数百の部品でできている事実を、目で見て実感できます。この驚きこそ出発点です。
次に、CIに脆弱性スキャンを一つ挟む。npm audit や pip-audit、あるいは先ほどの grype を、ビルドのたびに自動で回すようにします。パイプラインに検査を組み込む発想は、GitOpsが変えるKubernetes運用で触れた「すべてをコードとパイプラインで統制する」流れとも地続きです。
そして、秘密情報をコードやログに絶対に置かないこと。GhostActionが盗んだのはビルド時のトークンでした。鍵やパスワードはAWS Secrets Managerで安全に管理するように、専用の金庫に預けるのが基本です。
こうした「入口を減らし、中身を見える化する」考え方は、社内と社外の境界を信じないゼロトラストという設計思想とも深くつながっています。サプライチェーン対策は、その一部を「ソフトウェアの仕入れ」に当てはめたもの、と捉えるとすっきりします。
もう一つ、初心者がつまずきやすい点を先に伝えておきます。「脆弱性が見つかったから、とにかく全部すぐ更新しよう」と焦ると、今度は動かなくなったアプリの復旧に追われて疲弊します。大事なのは、見つかった問題が本当に自分のアプリに影響するのかを見極め、危ないものから順に手を打つことです。SBOMは、その優先順位づけの材料になります。全部を完璧にではなく、危険なものから確実に——この現実的な姿勢が、続けられる守りにつながります。
ただ、こうしたツールを触るには、コンテナやLinuxの基礎体力が欠かせません。syft も grype もコンテナやコマンドラインの上で動くからです。土台から順に固めたい方は、InfraAcademy のAWS学習ロードマップや、コンテナ理解の前提になるKubernetesとは何かの解説から始めるのがおすすめです。手を動かしながら学べるので、「言葉は聞くけれど触ったことがない」を一つずつ潰していけます。
セキュリティは、身構えると難しく感じます。けれど根っこにあるのは「知らないものを減らす」というシンプルな姿勢です。まずは見える化から。そこさえ押さえれば、SBOMも署名も来歴も、怖い専門用語ではなく頼れる道具に変わっていきます。
まとめ¶
今日はソフトウェアサプライチェーン攻撃と、その守り方を見てきました。要点を振り返ります。
攻撃者が狙うのは、あなたが書いたコードよりも、あなたが使っている部品です。xz utils、GhostAction、Shai-Hulud——ライブラリ・ビルド・配布網のどこもが標的になりました。
守りの新常識は三つ。何を使っているかを見える化するSBOM、本物であることを示す署名、どう作られたかを証明する来歴（SLSA）。この三点セットが2026年のスタンダードになりつつあります。
そして始めの一歩は、決して大げさなものではありません。syft を一度走らせ、CIに検査を一つ足し、秘密情報を金庫にしまう。その小さな積み重ねが、見えない仕入れルートを少しずつ明るく照らしてくれます。
知らないものを減らしていけば、守りは自然と強くなります。今日のうちに、自分のアプリが何でできているか、のぞいてみませんか。
