ハクソク

世界を動かす技術を、日本語で。

再び攻撃を受けたTrivy：広範なGitHub Actionsタグの妥協による秘密情報

47日前原文(socket.dev)

概要

  • 2026年3月、 Trivy関連のDockerイメージとGitHub Actions でサプライチェーン攻撃が発生
  • 複数のTrivyバージョンタグ が情報窃取型マルウェアにより改ざん
  • GitHub Actions経由で CI/CDパイプラインの機密情報 が流出するリスク
  • 攻撃者は force-pushで既存タグを不正コミットへ書き換え
  • タグの完全性確認やSHAピン留め など、セキュリティ対策の重要性が浮き彫りに

Trivyサプライチェーン攻撃の概要

  • 2026年3月、 TrivyのDockerイメージとGitHub Actions が大規模に改ざんされた事案
  • 新たに 0.69.4、0.69.5、0.69.6 のDockerイメージタグが infostealerマルウェア を含むことが判明
  • Docker Hubの latestタグ も一時的に悪意あるイメージを指していた
  • 詳細は Socket公式ブログ 参照

GitHub Actionsリポジトリでの攻撃手法

  • aquasecurity/trivy-action リポジトリの 76タグ中75タグ が攻撃者により force-push で改ざん
  • 10,000以上のGitHubワークフロー がこのアクションを参照しているため、影響範囲は極めて広大
  • @0.34.2、@0.33.0、@0.18.0 など、広く使われるタグが全て マルウェアを実行 する状態
    • 唯一 @0.35.0 のみが正常なタグ
  • 正規のTrivyスキャン処理の前に不正コードが実行 されるため、ユーザーは異常に気付きにくい

マルウェアの挙動と流出リスク

  • entrypoint.sh の先頭約100行に 情報窃取処理 が挿入
    • CI/CDランナーのプロセスメモリやファイルシステムから機密情報を収集
    • SSHキーやAWS/GCP/Azure認証情報、Kubernetesトークン などが標的
  • 収集→暗号化→外部送信 の3段階構成
  • GitHub Actionsランナーの特権昇格 を利用し、 /proc/<pid>/mem からメモリダンプを取得
    • GitHubホステッドランナー ではsudo権限が標準で付与されているため実現可能
  • 暗号化後、攻撃者制御のエンドポイントへ送信、GitHub経由のバックアップ送信も実装

タグの改ざん手法と痕跡

  • 各タグごとに master HEADのファイルツリー＋不正entrypoint.sh で新コミット生成
  • 元のタグコミットの著者情報やメッセージを偽装
  • GPG署名の欠如、 親コミットの日付不整合、 entrypoint.shのみ変更 などが改ざんの痕跡
  • GitHubリリースページの「Immutable」バッジ も信頼できない状態
    • 攻撃者が意図的にImmutableリリースとしてタグをロックした可能性

攻撃の原因と再発防止策

  • TrivyのCI環境から流出した認証情報 が攻撃の起点
  • シークレット・トークンのローテーションが不完全 で、攻撃者が新しい認証情報にもアクセス可能な状態が続いた
  • force-pushによるタグ書き換え はGitHubの通知や履歴に現れにくい
  • GitHubの公式推奨 ：「アクションはタグではなく フルコミットSHAでピン留め」が唯一確実な方法

影響確認方法と今後の対応

  • Socketダッシュボード の Threat Intel → Campaigns や 公開キャンペーントラッカー で影響有無を確認可能
  • Homebrew等の下流エコシステム も影響タグのロールバックを実施
  • 全てのCI/CDパイプライン で該当タグの利用有無を点検し、 フルSHA指定 への切り替えが急務

まとめと教訓

  • サプライチェーン攻撃の巧妙化 と タグ信頼性の限界 が浮き彫り
  • 認証情報管理・ローテーションの徹底、 コミットSHAピン留め、 改ざん検知体制の強化 が必須
  • Immutableバッジやタグ名だけでは完全性を保証できない ため、 最新のセキュリティガイドライン に従う重要性

Hackerたちの意見

最近の関連情報: Trivyエコシステムのサプライチェーンが一時的に侵害されました - https://news.ycombinator.com/item?id=47450142 - 2026年3月（35件のコメント）

└

「一時的に」って言葉は、ちょっと婉曲表現かもね。

2026年3月22日、脅威アクターが侵害された認証情報を使って、悪意のあるTrivy v0.69.5およびv0.69.6のDockerHubイメージを公開しました。(https://github.com/aquasecurity/trivy/security/advisories/GH...) 最初のインシデントは3月19日で、2回目は3月22日です。攻撃者はおそらく、2回の認証情報のローテーションを通じて持続的な侵入を維持していました。

└

私の理解では、彼らのリポジトリ全体が2月にやられて、今が同じ攻撃者による3回目の成功した攻撃なんだよね。

セキュリティソフトを作ってるからって、必ずしもその人が有能だとは限らないし、逆に害を及ぼすこともあるってことを忘れないでね。毎月、セキュリティチームから新しいスキャナーのトライアル用にフルコードやクラウドアクセスを求められるんだけど、彼らは派手なダッシュボードや長いレポートが好きなんだよね。でも、彼らの要求の10%でも許可したら、普通にやられちゃうよ…

└

最近の企業のセキュリティって、すべてのデバイス、サーバー、VMに「エンドポイントセキュリティソリューション」をインストールして、すべてをAI駆動のダッシュボードに流し込むことが多いよね。これで素早く動けるけど、結局何でも壊しちゃう。

└

しばらく前にTrivyのGitHub Actionsを監査したんだけど、いくつか心配な点が見つかった。その中でも特に気になったのは、setup-trivy Actionで、trivyリポジトリのメインをクローンして、その中でシェルスクリプトを実行していたこと。数ヶ月前に誰かがPRを上げるまで、リファレンスピンがなかったんだ。セキュリティ会社がみんなのCIワークフローに恣意的なコード実行を許可してしまったんだよね。Aquaは今月初めに侵害されて、それを抑えられず、先週も再度侵害されて、また抑えられず、今度は攻撃者が彼らのDocker Hubアカウントにも侵入した。こういうことは起こるけど、彼らは明らかにこれを処理する能力がないから、外部の助けを借りるべきだよ。

└

「セキュリティ」ツールに広範なアクセスを与えて、ベンダーがあなたのプロダクションキーを狙うのはリスク軽減じゃないよ。こういうツールのほとんどは、レガシーSIEMよりも騒音を出すレポートプリンターみたいなもので、攻撃者が内部に侵入したら、誰も読まないダッシュボードに結果を放り込むだけ。自己被害を減らしたいなら、新しいスキャナーを狭いサンドボックスに入れて、読み取り専用のミラーデータを与えて、彼らが何を触ってどこにデータが行くのかを退屈なレビューで信頼を得るまで、プロダクションの権限から遠ざけておくべきだよ。そうしないと、秘密を公開のペーストビンに流し込むのと同じことになっちゃうよ。

└

私の仮説では、一般的にセキュリティ部門が「実際、マーケットにある選択肢はどれも十分じゃないから、どれも使わない」と言うことが「許される」品質の底がないんだと思う。普通は、極端な侵入性を受け入れて、常にソフトウェアを追加することにイエスと言うのが当たり前になってる。こういうノルムが部門内で深く根付くと、実質的にひどいセキュリティソフトウェアを避けることができなくなる。Trivyに関して言えば、私はTrivyが悪いソフトウェアだとは思ってないし、仕事で使ってる。私たちはこの侵害の影響を受けてない。なぜなら、Nixを使ってコードスキャンツールを提供していて、自分たちでアクションのワークフローを書いてるから。私たちのTrivyのバージョンはNixによって固定されていて、定期的に手動で更新してるから、こういう悪いリリースはスキップできてるんだ。

脆弱性をスキャンするためにあるんだから、自分が脆弱性になるなよ！

└

脆弱性をじっと見つめると、その脆弱性もこちらをじっと見つめ返してくる。

最初の考えとしては、これが新しい妥協案でないなら、Trivyは古い認証情報をローテーションしていないはずだよね。でも彼らは「秘密とトークンをローテーションしたけど、プロセスが原子的じゃなかったから、攻撃者が更新されたトークンを知ってしまったかもしれない」と主張してる。ここで具体的に何を言ってるのか、誰か知ってる？私の知る限り、GHは発行された後に新しいトークンを公開しないけど、話してる認証の種類によるし、GHには使えるトークンやキーの種類がめちゃくちゃ多いんだよね。

└

OpenClawのクリエイターは、彼が新しい名前でGitHubの組織を作った途端にそれが盗まれたとか言ってて、GitHubの人に原子的にやってもらうよう頼まなきゃいけなかったらしい。

うーん、ここ2週間は仕事で最悪だったな。今は12枚のフォームに記入して、めちゃくちゃな会議に出なきゃいけない。彼らがやられたせいで（2回、もしくは1回だけど、ほんとにひどく :D ）

「GitHub自身のセキュリティガイダンスは、アクションを消費する唯一の本当に不変な方法として、完全なコミットSHAに固定することを推奨しています。」なんでGitHubはアクションの不変バージョンを強制しないの？不変なリリースが欲しくないなら、アクションを公開する権利はないってことにすればいいのに。彼らはこれを強制して、この問題のクラスを軽減することができるはずだよ。

└

なんでGitHubはアクションの不変バージョンを強制しないの？こういう議論には「じゃあ、反対側はどうなの？」っていう応答を含める必要があるといつも思う。そうじゃなきゃ、私に「で？」って聞かせることになっちゃう。コインの裏表：セキュリティは、妥協が引き込まれないように、あなたのように固定されたバージョンを望む。一方で、セキュリティはセキュリティアップデートが引き込まれるように、固定されたバージョンを望まない。もちろん、問題は、前者なしで後者を可能にする解決策を見つけることだ。開発者の生産性を壊さないやつね。そして覚えておいて、…悪のビットなんて存在しない。 （…この法則に名前を付ける必要がある。「ピン留めの逆説」？） （¹明示的に言われてはいないかもしれないけど、セキュリティパッチの常に更新されている状態を望むことは、ピン留めに反対する議論に等しい。）

└

これはgitタグをモデルにしているからだと思うけど、今の段階でこれを変えるのは大きな変更になるね。でも、いつかは始めた方がいいかも。

└

もし数年も compromised なバージョンに固定しちゃったらどうするの？ 更新を許可することでセキュリティの問題も解決できるし、結局静的リンクと動的リンクの議論と同じだよね。それに、確か最新のtrivyを取得するアクションがあったと思う。

└

この機能の本当の名前はVisualSourceSafeアクションだから。ちょっと見ればランナーのコードのあちこちに散らばってるし、ランナー自体も他の機能と同じく、2000年代初頭のマイクロソフト品質って感じで、つまり全然ダメってことだね。

└

それでも、ワークフローの設定だけは不変だけど、その後の多くのワークフローは可変な入力を取り込むことになる（例えば、デフォルトで「最新」バージョンにする）。

└

もしかしたら、なぜ単一のプロバイダー（GitHub）にこんなに脆弱になってしまったのかが、より良い質問かもしれないね。人々が自分たちのフォージを使い始めれば、サプライチェーン攻撃の影響範囲はかなり小さくなるだろうし、GitHubをソーシャルネットワークとして使うのはもう良くないと思う。

└

GitHub ActionをSHAに固定することはできるけど、そのGitHub Actionが可変なDockerイメージラベルを指すDockerのものだったらどうなるの？ 例えば: https://github.com/github-community-projects/issue-metrics/b... > なぜGitHubはアクションに対して不変のバージョニングを強制しないの？ できないよ。彼らは任意のコードを実行できるし、Curl経由で別のbashファイルをダウンロードして実行することもできるから。

└

この推奨は今、壊れてるね。アクションのフルコミットSHAを固定しても、そのアクションが他の固定されてないトランジティブ依存関係（他のアクション）を引き込むことがあるんだよね。

これは「サプライチェーンセキュリティ」製品が、保護しようとしているスタックと同じくらい安全で責任を持って設計されていないことを思い出させてくれる良い警鐘だね。これはセキュリティソフトウェア全般に言えることだけど、こういう「どこでも動かせる」ツールや製品の増加は、攻撃者が一度のキャンペーンで大量のユーザーを侵害する新しくてエキサイティングな方法を招くんだ。

これを見るたびに「なんで？」って思うのが、github actionsを使ってる人たちだね。「他の誰かのスクリプトを使って、自分のコードベースに対して台無しにしてるだけじゃん」