ハッカーがパッケージを次々と乗っ取るペースは目が回るほどで、その事後検証レポートには毎回のようにGitHub Actionsが登場する。

2月下旬、hackerbotという名のAI¹がある一つのプロジェクトのリリース鍵をかすめ取った。そこから1か月も経たないうちに、50ほどのプロジェクトに認証情報窃取ツールが仕込まれた。感染したリポジトリが、次のリポジトリの認証情報を次々と盗んでいったのだ。

この一連のサプライチェーン攻撃は、GitHub Actionsの罠から始まった。単純で出来の悪いデフォルト設定、そして5年前から修正が提案されたまま放置されている問題だ。

GitHub Actionsとその代償

Trivyはオープンソースのセキュリティスキャナだ。だが3月下旬にTrivyを使っていたなら、ひどい目に遭ったはずだ。

3月19日、ハッカーはTrivyが動くあらゆる場所から秘密情報をくすねようと細工したバージョンをプッシュした。Trivy側は、継続的インテグレーション（CI）システムであるGitHub Actionsの「設定ミス」が原因だと説明した。

しかしこれは設定ミスというより、GitHub Actionsの罠と呼ぶべきものだった。

Trivyがどのようにやられたのか、単純化した例がこれだ²：

# INSECURE. DO NOT USE.
on:
  pull_request_target

jobs:
  check:
    steps:
      - uses: action/checkout@deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
      - uses: ./.github/actions/setup-go
      - uses: some/go-static-analysis@c0ffeec0ffeec0ffeec0ffeec0ffeec0ff

一見、このコードは問題なさそうに見える：

• シークレットを参照していない。
• サードパーティのアクションは不変のハッシュでピン留めされている。
• プルリクエストをチェックアウトして、静的解析を実行するだけだ。

だがこのコードは、2021年のGitHubのブログ記事「preventing pwn requests」で、そのままアンチパターンとして紹介されているものだ：

もしpull_request_targetワークフローが […] 信頼できないコードを実行するだけで、シークレットを参照していない場合でも、脆弱なのでしょうか？

はい、脆弱です

– GitHub Security Lab

問題はpull_request_targetにある：

• pull_request_target — 環境に美味しそうなGITHUB_TOKENをぽんと放り込んでくれる。
• actions/checkout — persist-credentialsという任意のパラメータがあり、falseに設定するとシークレットを削除してくれる。だがデフォルトはtrueだ。

persist-credentialsパラメータをfalseにすべきという指摘は、2021年からGitHub Actionsの未解決のイシューとして残ったままだ2021年から。

あなたの$HOMEは犯罪現場だ

ハッカーがTrivyの鍵を手に入れると、さらに多くの鍵を盗むために改ざんした新バージョンのTrivyを公開した。

LiteLLMはCIでTrivyを使っていた。しかもそれは、PythonのパッケージレジストリであるPyPIへコードを公開するのと同じCIだった。LiteLLMのCIで汚染されたTrivyが実行されたとき、ハッカーはその公開鍵を奪い取った。

そして3月24日、Callum McMahonがIDEを立ち上げると、MacBookがフリーズした。それがLiteLLMハイジャック発覚のきっかけだった。

McMahonのMacBookは、ハッカーがLiteLLMに忍び込ませた不正なコードにあえいでいた。そのコードは次のような認証情報を盗もうとしていた：

• ~/.netrc
• ~/.aws/credentials
• ~/.config/gcloud
• ~/.config/gh
• ~/.azure
• ~/.docker/config.json
• ~/.npmrc
• ~/.git-credentials
• ~/.kube/

いずれも$HOMEディレクトリに無造作に散らばっていることが多く、トークンや鍵が詰まっていて、しかも大抵は暗号化すらされていないファイルだ。

AIとサプライチェーン破滅のスパイラル

暗号化されていない認証情報、ピン留めされていない依存関係、CIの自爆スイッチといった問題には、ずっと前から悩まされてきた。

だがAIはあらゆるものを加速させた。セキュリティ上の過ちの繰り返しまでもだ。

Trivyが侵害されたその日、私はClaudeにこう尋ねた。「Dockerレジストリのイメージを脆弱性スキャンするにはどうすればいい？」

その返答の一部がこれだ：

CI/CD Integration Example (GitHub Actions with Trivy)

    - name: Scan image for vulnerabilities
      uses: aquasecurity/trivy-action@master

二つの点で間違っている：

1. ピン留めされていない参照 — masterは常時変わり続ける参照だ。もしハッカーがリポジトリをゾンビ化したら、私が最初の被害者になる。
2. 既知の脆弱性 — その日に公開されたCVEについて一切触れていない。私が尋ねなかったから、Claudeも確認しなかったのだ。

一方、VercelのCEOは最近の自社データ侵害について、ハッカーが「AIによって加速された」ものだと説明した。そしてAnthropicの最新の宣伝ツアーでは、自社のフロンティアモデルが発見した脆弱性について米国連邦準備制度理事会議長に説明までしている。

LLMを手にした悪者は超能力を得る。LLMを手にした善人は2010年代半ばのCIの問題に足をすくわれる。

そして、OpenBSDに27年間潜んでいたセキュリティ問題を掘り起こせる同じツールが、GitHub Actionsは@masterでピン留めしろと平気で教えてくるのだ。