サプライチェーン攻撃を成立させないための対策

方針

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

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

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

能動的な操作への対策

公開直後のバージョンは避ける

Dependabotにcooldownを設定するでも書いたが、公開されてすぐに発覚する検体が多いので、完全ではないが一定期間を置けば安全だと判断しても良いだろう。日数は宗派があると思うけれどRussの例では7日だったので、そのくらいでいいんじゃないだろうか。

latestで実行を避ける

例えば即席のスクリプトで go run module@latest のように latest を指定することがあるけれど、これだと悪性バージョンの入り込む余地が存在する。開発で使うツールなどは go tool にしておいて、バージョンは go.mod で管理するのが良いだろう。

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

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

GitHubトークン認証をしない

強い権限があるものを git-credential-xxx で参照したり、gh auth コマンドで出力したりできてしまう。Russの投稿でも言及されている。

On the topic of tokens, it is very wrong that a project on GitHub or NPM can insist on 2FA for people logging in, but then those same systems allow using these short easily stolen strings as 1FA methods with equivalent power. Recent attacks demonstrate the significant lateral movement this enables.

受動的な操作への対策

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

よくあるパッケージマネージャには ^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.

署名を検証する

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