trivy-action

GitHub Actions で checkout@v7 のようなバージョン指定を書くのはやめよう！ 時代は actions.lock！ Progate で業務委託エンジニアをしている横江( @yokoe24 )です！ セキュリティの話が重要視される昨今ですが、 みなさんは GitHub Actions の Workflow ファイルで、こんな書き方をしていませんか？ steps: - uses: actions/checkout@v7 ・・・私は書いています！！🙈 この記事を書きながら、過去の個人リポジトリ、直さなきゃなぁ……って思っています。 @v7 と書くリスク npm の件などで敏感になっている方はお気付きかもしれませんが、 @v7 のような書き方は、最新の v7.x.x が使えて便利な一方1、 攻撃者が公開した、悪意のあるバージョンをインストールしてしまう危険を孕みます。 仮に actions/checkout が攻撃されて、 会社の非公開コードを攻撃者へ送信する Action になったら大変ですよね！ 調べたところ、過去の事件としては 2026年3月に脆弱性スキャナー「Trivy」の GitHub Action である aquasecurity/trivy-action への攻撃があり、 （詳細： github.com/aquasecurity/trivy/security/advisories… ） 攻撃者はほとんどのバージョンタグを force push で書き換え、 認証情報を盗むマルウェアへと変貌させたことがあったそうです。 バージョンタグの中身を書き換えられているので、 仮に @v7 でなく @v7.0.1 のようにパッチバージョンまで指定していたとしても意味がなかったということです。 参考：Immutable Releases @v7.0.1 のようにパッチバージョンまで指定していたとしても意味がなかった という話を今しましたが、パッチバージョン指定が意味のある場合もあります。 それは GitHub の Immutable Releases の機能を使っている場合です。 この機能を使って公開されたリリースと同じタグ名を使ってリリースすることはできません。 github.com/aquasecurity/trivy-action/releases/tag… 先述した trivy-action ではこの機能が使われ、上の画像のように Immutable の印が付いていますが、 残念ながら actions/checkout では、2026年10月29日現在、この機能は使われていません。 （GitHub がメンテナンスしていると思っていたので、機能を活用していないのは意外） じゃあどうするか？ 解決方法は２つあります！ コミットのハッシュ値（SHA）を指定する方法と、lockfile を使う方法です。 GitHub の公式ドキュメントでも、 ロックファイルを使って固定するか、導入できない場合はコミット SHA を固定するかを案内しています。 解決策１：コミット SHA で固定する 完全な長さのコミット SHA を指定する方法から書きます。 こうなります。 steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 長いですね！！！ 「完全な長さの」と言われているように、 3d3c42 などと省略せずハッシュ値全体を書くのがポイントです。 たまたま別のものと前方一致するといけませんからね。 これであれば、あとから v7.0.1 のタグが別のコミットへ付け替えられても、その変更には追従しません。 解決策２：ロックファイル ( actions.lock ) を使う これは2026年10月14日にパブリックプレビューが発表され、 10月28日に一般提供（GA）となったばかりのアツアツな(?)機能です！🔥 公式ドキュメントで『最善の対策』とも言っています。 全体の作りとしては、 Workflow ファイルにバージョン番号を書き、 コミット SHA はロックファイル側に書かれる仕組みです。 ロックファイルは .github/workflows/actions.lock に置かれます。 Workflow 側 steps: - uses: actions/checkout@v7.0.1 actions.lock 側 dependencies: 'actions/checkout@v7.0.1': ref: 'v7.0.1' commit: 'sha1-3d3c42e5aac5ba805825da76410c181273ba90b1' ただ、これを見ると、 結局ハッシュが書かれるなら、 uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 の書き方でも良くない？！ ファイルが2つに分かれてむしろ読みにくくなってない？！ ……って思いますよね？ そう思ったのでAIに聞いてみたところ、 Action の内部で、さらに別の Action が使われている場合に、その依存先まで固定できることが肝要と知りました！ 先述した trivy-action の件、実は私たち使用者が - uses: aquasecurity/trivy-action@915b19bbe73b92a6cf82a1bc12b087c9a19a5fe2 # v0.28.0 のような書き方をしていたとしても、事件当時、trivy-action の内部では uses: aquasecurity/setup-trivy@v0.2.1 と書かれていたため、 setup-trivy が改ざんされるだけで被害に巻き込まれる脆弱さがありました。 github.com/aquasecurity/trivy-action/blob/v0.28.0… lockfile の場合、内部の Action への参照もたどり、それぞれのコミットハッシュを記録してくれるため、 このような問題にも対処できるのだそうです！ つよい！💪💪 実際にロックファイルを作って見てみましょう。 actions.lock を作ってみる！ gh コマンドのインストールがまだなら GitHub CLI をインストールし、 gh auth login でログインしておきましょう。 その後、公式の拡張機能をインストールします。 gh extension install github/gh-actions-lock そして、リポジトリのルートで以下のコマンドを実行すれば完了です！ gh actions-lock .github/workflows/ 内の Workflow が読み込まれ、 .github/workflows/actions.lock が生成されます。 また、Workflow ファイル側も以下のように具体的なバージョンへと書き換えられます。 - uses: actions/checkout@v7 - uses: actions/checkout@v7.0.1 便利ですね！ @v7 のような曖昧なバージョンは許されません。 actions.lock があると GitHub Actions は "Using locked action versions from the workflow's lockfile" とメッセージを出し、 指定されたバージョンをセットアップ時にダウンロードします。 actions.lock を見てみる 複数の Workflow を用意して、バージョン違いや依存関係の記録がどうなるのか見てみましょう。 Workflow 使う Action ci.yml checkout@v7.0.1、setup-node@v6.5.0 scan.yml checkout@v6.1.0、trivy-action@0.35.0 生成される actions.lock は以下のようになります。 This file is machine-generated by gh actions-lock. Do not edit by hand; run gh actions-lock to update. Docs: gh.io version: 'v0.0.3' workflows: '.github/workflows/ci.yml': - 'actions/checkout@v7.0.1' - 'actions/setup-node@v6.5.0' '.github/workflows/scan.yml': - 'actions/checkout@v6.1.0' - 'aquasecurity/trivy-action@0.35.0' dependencies: 'actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809': ref: 'v4.2.4' commit: 'sha1-0400d5f644dc74513175e3cd8d07132dd4860809' owner_id: 44036562 repo_id: 215566462 'actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8': ref: 'v5.0.0' commit: 'sha1-08c6903cd8c0fde910a37f88322edcfb5dd907a8' owner_id: 44036562 repo_id: 197814629 'actions/checkout@v6.1.0': ref: 'v6.1.0' commit: 'sha1-d23441a48e516b6c34aea4fa41551a30e30af803' owner_id: 44036562 repo_id: 197814629 'actions/checkout@v7.0.1': ref: 'v7.0.1' commit: 'sha1-3d3c42e5aac5ba805825da76410c181273ba90b1' owner_id: 44036562 repo_id: 197814629 'actions/setup-node@v6.5.0': ref: 'v6.5.0' commit: 'sha1-249970729cb0ef3589644e2896645e5dc5ba9c38' owner_id: 44036562 repo_id: 189476904 'aquasecurity/setup-trivy@e6c2c5e321ed9123bda567646e2f96565e34abe1': ref: 'main' commit: 'sha1-e6c2c5e321ed9123bda567646e2f96565e34abe1' owner_id: 12783832 repo_id: 869952525 uses: - 'actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809' - 'actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8' 'aquasecurity/trivy-action@0.35.0': ref: '0.35.0' commit: 'sha1-57a97c7e7821a5776cebc9bb87c984fa69cba8f1' owner_id: 12783832 repo_id: 268833180 uses: - 'actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809' - 'aquasecurity/setup-trivy@e6c2c5e321ed9123bda567646e2f96565e34abe1' uses の項で、その Action が依存している Action の一覧がわかりますね！ バージョンアップしたくなったら？ Workflow 内で使っている外部 Action のバージョンを更新する場合は、 まずは通常通りファイル内のバージョンを書き換えます。 悪意のあるバージョンへ更新しないよう、更新先のリリースノートや、更新から日が浅くないかはチェックしておきましょうね！ - uses: actions/checkout@v6.0.2 - uses: actions/checkout@v6.0.3 そのあとで actions-lock コマンドを実行します。 gh actions-lock これだけでOKです！ actions.lock が更新されます。 なお、 gh actions-lock を忘れて Workflow ファイルだけを更新してコミット・pushした場合、 GitHub Actions は Invalid lockfile エラーで CI を失敗させます。 まとめ： gh actions-lock を使おう！ ってなわけで、 actions/checkout@v7 のような書き方のリスクと、 その対策を話してきたわけですが、まとめとしては簡単ですね！ 拡張機能のインストール gh extension install github/gh-actions-lock actions.lock の作成・更新コマンド gh actions-lock github/gh-actions-lock 拡張機能を gh コマンドにインストールしたあと、 リポジトリで gh actions-lock ！ これだけ！ 今から出来ますね！！ これだけで、サードパーティーの GitHub Action を使っていることによる 予期せぬ攻撃から身を守ることにつながります。 みんなでインターネットを守っていきましょう！！🛡️🦾 ここまでお読みくださり、ありがとうございました！💝 脚注 厳密には、メンテナーが v7 タグを最新バージョンのコミットに付け直してくれている場合に限る。たいていはありがたいことにやってくれている…… ↩︎

GitHub ActionsとTrivyでTerraformの設定ミスをPR時に検出する はじめに TerraformでAWSなどのインフラを管理する場合、設定ミスがそのままセキュリティ上のリスクにつながることがあります。 たとえば、意図せずリソースを公開してしまったり、暗号化の設定が不足していたりすると、あとから気づいて修正するよりも、変更を取り込む前に気づける方が安心です。 そこで今回は、GitHub ActionsとTrivyを使い、Pull Request（PR）作成時にTerraformの設定をスキャンする仕組みを試してみました。 今回やること PR作成時にGitHub Actionsを実行する TrivyでTerraformなどの設定ファイルをスキャンする HIGH・CRITICALの検出結果を確認する 検出があったときにCIを失敗させるかどうか、exit-code の違いを確認する 使ったワークフロー .github/workflows/ 配下にワークフローを作成し、PRをトリガーにTrivyを実行します。 name: GitHub Actions Trivy Scan on: [pull_request] permissions: contents: read jobs: trivy-scan: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v4 - name: Trivy Scan Config uses: aquasecurity/trivy-action@v0.36.0 with: scan-type: config scan-ref: . severity: HIGH,CRITICAL exit-code: '0' ※ Trivy Actionのバージョンや設定項目は、利用時点の公式ドキュメントも確認してください。実際に利用するリポジトリに合わせて、ファイル名やスキャン対象を調整します。 設定のポイント on: [pull_request] Pull Requestに関連するイベントでワークフローを実行します。PRを使った変更の確認フローにセキュリティチェックを組み込めるのがポイントです。 permissions: contents: read このワークフローでは、チェックアウトに必要なリポジトリの読み取り権限を指定しています。必要以上の権限を付与しないようにすることも、CIを作るうえで意識したい点です。 actions/checkout 実行環境にリポジトリの内容を取得します。Trivyは、その後のステップで取得したファイルをスキャンします。 scan-type: config と scan-ref: . scan-type: config は、TerraformなどのIaC設定に含まれる設定ミスを検査するための指定です。scan-ref: . は、チェックアウトしたリポジトリのカレントディレクトリをスキャン対象にしています。 コンテナイメージの脆弱性や、アプリケーションの依存ライブラリを調べるスキャンとは対象が異なるので、ここは区別しておきたいところです。 severity: HIGH,CRITICAL 今回は、重大度がHIGHまたはCRITICALの検出結果を対象にしました。最初からすべての検出項目を扱うのではなく、まず重要度の高いものを確認する方針です。 exit-code を変えるとどうなる？ 今回、実際に試していて分かりやすかったのが exit-code の設定です。 exit-code: '1' この設定では、指定した条件に合う検出結果があった場合にTrivyが終了コード1を返します。その結果、GitHub Actionsのステップが失敗扱いになります。 一方で、次のように設定すると、 exit-code: '0' 検出結果を出しつつ、検出があったことだけを理由にステップを失敗させない動きにできます。 実際にexit-code: '1'で実行したとき、HIGH・CRITICALの検出結果が表示されたあと、ジョブが終了コード1で失敗しました。設定を'0'に変更して実行すると、検出結果を確認しながらワークフローを成功扱いにできました。 ただし、exit-code: '0'は「問題がない」という意味ではありません。検出結果は別途確認し、必要な修正につなげる必要があります。 最初からCIを止めるべき？ これはリポジトリやチームの運用方針によると思います。 たとえば、次のように段階を分ける方法が考えられます。 まずはスキャンを実行し、どのような項目が検出されるか把握する 検出内容を確認し、誤検知や既存設定も含めて対応方針を決める 対応できる状態になったら、重要な検出についてCIを失敗させる運用を検討する 最初からCIを止めると、既存の設定や対応方針が整理されていない場合に、開発の妨げになることもあります。反対に、検出結果を出すだけの運用が長く続き、誰も確認しない状態になってしまうのも避けたいところです。 大切なのは、スキャンを導入すること自体をゴールにせず、検出結果を誰が確認し、どう修正につなげるかまで考えることだと感じました。 まとめ 今回は、GitHub ActionsとTrivyを使って、PR作成時にTerraformなどの設定ファイルをスキャンする仕組みを試しました。 やってみて特に勉強になったのは、スキャンを実行するだけでなく、exit-codeによってCIの失敗条件を変えられることです。 セキュリティチェックは、ただ導入すればよいわけではありません。おまじないのように入れるだけで終わらせず、検出結果を確認して修正につなげられるように、開発フローに合わせて運用を考える必要があります。 参考リンク Trivy公式ドキュメント Trivy GitHub Action GitHub Actionsのワークフロー構文

AIで脆弱性を自動検知？OSS Scannerの実力【ふかぼりAI】 Anthropic提供のOSS Scannerや、個人の開発に強い代替ツールを解説します。 ▼本編(約10分)はこちら youtu.be 【出典】 ・12 Free Open-Source SCA Tools 2026 (Compared) | AppSec Santa appsecsanta.com ・Best Open-Source Vulnerability Scanners in 2026 cveplayground.com ・Free Vulnerability Scanning Tools: Top Open-Source Options Compared rafter.so ・GitHub ActionsでTrivyのスキャンを実行する | SIOS Tech Lab tech-lab.sios.jp ・Getting Started - OSS IQ ossiq.dev ・GitHub - aquasecurity/trivy-action: Runs Trivy as GitHub action to scan your Docker container image for vulnerabilities aquasecurity/trivy-action ・OSS Vulnerability Scanning echo.ai ・veracode.com veracode.com ・Open Source Scanning (OSS) Vulnerability Automation Services rsisecurity.com ▼チャンネル登録はこちら youtube.com ※音声合成に VOICEVOX を使用しています(VOICEVOX:四国めたん / VOICEVOX:白上虎太郎) ※公開情報にもとづく解説です。投資その他の助言ではありません。 #Shorts #AI #Claude #OSSScanner #ClaudeCode #脆弱性 #セキュリティ #ふかぼりAI #深掘りAI #AI解説