サプライチェーン攻撃を成立させないための対策(リポジトリ編)

This content is a draft and will not be included in production builds.

方針

サプライチェーン攻撃の文脈では、ソーシャルハッキングなどで侵害される側の視点もあるが、ここでは利用しているモジュールで侵害された悪性バージョンが公開されたものとして、どう対策をするかについて考える。ここではリポジトリでの対策を挙げるが、サプライチェーン攻撃を成立させないための対策(クライアント編)もある。

GitHub Actions侵害 — 相次ぐ事例を振り返り、次なる脅威に備えるを元に具体的な対策内容をまとめる。

受け入れ評価の強化
評価済みの依存への固定
DevOpsアーキテクチャの堅牢化
DevOpsエンドポイント統制の強化

能動的な操作への対策

ビルドとデプロイを分ける

デプロイでは強い権限を与える必要がある。そしてビルドは任意のスクリプトが動くので強い権限を与えてはいけない。なのでこの2つは明確に分けるべき。

受動的な操作への対策

pull_request_targetを使わない

使ってはいけない。厳密には pwn request という攻撃手法で、pull_request_target イベントでPRの HEAD ブランチをチェックアウトしなければ問題ないらしいが、気にするのも面倒なので使わない。pwn request についてのRussが書いた投稿を引用する。

When your feature has its own dedicated name for exploits of it - namely pwn requests - you have failed at security. Very very badly.

自動アップデートをしない

よくあるパッケージマネージャには ^v1.2.3 のように記述しておくと、新しいマイナーまたはパッチバージョンが公開されたら自動でアップデートする機能がある。これをすると気づかない場所でアップデートが行われるので停止しておくほうが良い。

脆弱性の修正を早く反映したいという反論はあるが、Russの投稿にある通り、最近はマルウェアをすぐ適用してしまうリスクのほうが目立つ。

And speaking of NPM (which GitHub owns), postinstall.js is a decision worth reconsidering. So is “always download the latest version of all dependencies”. The justification was to push the latest security fixes immediately, but more often these days it pushes the latest malware immediately instead.

組織で開発している場合はそのポリシーにも依るだろうから ^ を禁止するのは難しいと思うが、npm コマンドだと npm ci を使えばそれ相当の動作になる。

署名を検証する

過去に公開したバージョンが書き換えられてしまうことを避ける。そのためにはハッシュ値や署名を検証して、改ざん検知を行う必要がある。

脆弱性を作らない

GitHubでのセキュリティ改善対策も参照するといい。