サプライチェーン攻撃を学ぶ会2025秋の振り返り
https://scrapbox.io/files/68e3c658bbbd640ebbd299e2.png
Google meetsの文字起こしと、発表資料 + 事例集や対策方法のSmart Context3つをGemini 2.5 proに渡して、何度かディスカッションしたらすごいわかりやすくなった ダイジェストレポートのダイジェストレポート
対策は、寝かせる・隔離・検知の3つである
寝かせる
リリース直後のライブラリをインストールしない
隔離
開発環境をコンテナ化し、ホストとDocker内を分離
開発環境とproductionの設定値を分離し、ダメージコントロールする
検知
予防検知
コード自体の静的解析
ライブラリ開発側の、プロジェクト運営体制の評価
ランタイムセキュリティ
実行時の不審・不正な振る舞いを検出する
パッチバージョン更新を3日寝かせるさえ徹底すれば、実はgithub security alert + dependabot等でかなり防御できると思っているshokai.icon
この検知はコードだけでなくライブラリ開発者の行動も含めた静的解析
クラウドの複数のSaaSや、CVEやOpenSSFスコアカードやsnyc等の連携でより精度があがると思う
これは、かなり「寝かせる」さえ徹底すれば効果が出てくる
クラウドの複数SaaS + DBの連携した検知網を抜けてきた攻撃を、ローカルマシンで、実行前に検知できるとは考えないほうがいい
最悪は、汚染されたライブラリがproductionサーバーまで到達する事である
ローカル開発環境で、実際の攻撃が発生した時点。ここで検知したい
こいつらの挙動確認したい
という世界観を持って発表資料を見て回ると、さらにめちゃくちゃわかってくると思いますshokai.icon ダイジェストレポート
2025年10月2日、ソフトウェア開発における喫緊の課題である「サプライチェーン攻撃」をテーマにした勉強会が開催されました。本レポートでは、その内容をダイジェストでお届けします。
死守すべきライン：2種類の「検知」を軸にした防衛戦略
勉強会では、サプライチェーン攻撃に対する我々の基本的な防衛戦略が共有されました。それは、2種類の「検知」を使い分けるという考え方です。
1. クラウドでの静的解析による「予防検知」
まず、パッチバージョンの更新を3日間「寝かせる」というプラクティスを徹底するだけで、防御の大部分は達成できると考えられます。
2. 手元でのランタイムセキュリティによる、ダメージコントロール
次に、このクラウドの検知網をすり抜けてきた、より巧妙な攻撃に対してはダメージコントロールを最優先に考えます。
高度な静的解析をすり抜けてきた攻撃を、ローカルマシンの実行前スキャンで検知できると考えるのは現実的ではありません 。最悪のシナリオは、汚染されたライブラリが検知されないままプロダクション環境に到達してしまうことです。
そこで、ローカルの開発環境で実際に攻撃が発生した瞬間を検知することが重要になります 。この役割を担うのが、CrowdStrike FalconやFalcoといったランタイムセキュリティツールです。これらのツールで実行時の不審な挙動を監視することで、プロダクションに至る前の最終防衛ラインを構築します。 代表的なサプライチェーン攻撃の事例
会では、過去に発生したいくつかのインシデントが紹介されました。
colors npmご乱心: OSS開発者が経済的困窮から自身の有名ライブラリに悪意のあるコードを混入させた事件です 。これは、OSSと開発者の持続可能性という、技術だけでは解決できない根深い問題を提起しました 。 Nxリポジトリへの攻撃 s1ngularity: GitHub Actionsのワークフローの脆弱性を突かれ、プルリクエストのタイトル経由でスクリプトを実行されてトークンが窃取された事例です 。AIに生成させたコードの脆弱性が見過ごされたことが原因の一つとされています 。 これらの事例から、攻撃がもはや他人事ではなく、すぐ隣にある脅威であることが共有されました。
攻撃はどのように成立するのか？技術的背景
サプライチェーン攻撃が成功する背景には、パッケージマネージャの便利な機能が悪用されるケースが多くあります。
悪意のあるコードは、インストール時に直接実行されるだけでなく、.git/hooks/のような場所に潜伏し、gitコマンド実行時など、後から開発者の意図しないタイミングで発火する可能性も指摘されました。
巧妙ではあるけど、魔法のようなとんでもない事が起きているわけではない事がご理解いただけたと思いますshokai.icon
詳細は発表資料へ
私たちが取るべき対策：「寝かせる・隔離する・検知する」
単一の完璧な解決策はなく、複数の対策を組み合わせた多層防御が重要です。
対策の考え方を「寝かせる」「隔離する」「検知する」の3つのキーワードで整理することが有効です。
寝かせる：リリース直後のライブラリをインストールしない
多くの攻撃は、ライブラリが公開されてから数時間〜数日以内に発覚し、取り下げられます。
以下の設定を活用し、リリースされたばかりのパッケージをすぐに導入しない「寝かせる」運用が極めて有効です。
72時間（3日間）が一つの目安とされています
隔離：開発環境をコンテナ化する
開発環境をDockerコンテナ内に隔離することで、万が一マルウェアが実行されても、その影響範囲をコンテナ内に限定できます。ホストマシン上のSSHキーや各種設定ファイルへのアクセスを防ぐ効果が期待できます。
検知：不審な振る舞いを監視する
Falco: コンテナ環境に特化したランタイム脅威検出ツールです 。Linuxのシステムコールを監視することで、CrowdStrikeが見ることのできないコンテナ内部の不審なファイルアクセスやネットワーク接続を検知し 、プロダクション環境へのマルウェア混入を防ぐ最後の砦として期待されます。 予防検知のプラクティス
pnpmの採用: 依存関係のバージョンを効率的に効率的にまとめ、インストールされるパッケージ数を減らすことで、攻撃対象領域（アタックサーフェス）を削減する効果があります 。 Dependency Pinning: package.jsonのバージョン指定を^や~といった範囲指定ではなく、固定バージョンにピン留めすることで、意図しないバージョンのインストールを防ぎます 。 堅牢化だけうまくまとめれなかったshokai.icon
隔離でもあるし、予防検知の方法でもあるような気もする
単なる手法の1つかもしれない
ディスカッションハイライト
会の中では、参加者から活発な質疑応答や意見交換が行われました。
Q. minimumReleaseAgeを皆が設定すると、逆に攻撃の発覚が遅れるのでは？
Q. pnpmへの移行はすべきか？
A. minimumReleaseAgeは手動インストール時に特に有効ですが、既存の成熟したプロジェクトではライブラリはdependabotやrenovateで更新するので、手動インストールの機会は少ないかもしれません。新規プロジェクトでの採用は有力な選択肢です。標準のnpmにも同様の機能が追って実装されることを期待する声もありました 。
Q. safe-npmのようなコマンドラッパーは信頼できるのか？
A. 便利そうですが、そのツール自体が乗っ取られた場合のリスクも考慮する必要があります 。開発元が信頼できるかが一つの判断基準になるでしょう 。