https://www.m3tech.blog/entry/drydock

こんにちは、AI・機械学習チームの山本（@hiro_o918）です。この記事はエムスリー Advent Calendar 2025 18 日目の記事になります。 17 日目は北川さんの「わたしの Language Server にはパーサーが２種類あんねん」でした。

はじめに

皆さんは脆弱性の検知と対応をどのように行っていますか？

エムスリーでは脆弱性管理ツールを導入することで、コンテナイメージやパッケージの脆弱性スキャンを自動化し、検知された脆弱性への対応をチーム全体で協力して行っています。しかし、次の記事にもあるように AI チームでは次々にプロダクトを立ち上げているため、スキャン対象の管理など運用コストが増大してしまう課題がありました。

そこで今回は、Google Cloud の Artifact Registry に組み込まれたスキャン機能の利点を最大限に活用し、さらに自作の OSS ツールで運用することで、運用コストを抑えつつ効率的に脆弱性管理と修正プロセスを進められるようになった話を紹介します*1。

Artifact Registry の機能と運用の課題

まず、Artifact Registry の機能について簡単に説明し、脆弱性スキャンの概要と AI チームでの運用上の課題について説明します。

Artifact Registry の脆弱性スキャン機能

Artifact Registry は、Google Cloud が提供する、コンテナイメージや言語パッケージを一元管理できるサービスです。今回はコンテナイメージの管理に焦点を当てて説明します。

Artifact Registry には、保存されたコンテナイメージの脆弱性スキャン機能が標準で組み込まれています。これは Google が提供する脆弱性データベースを利用し、イメージ内の既知の脆弱性を検出するものです。この Artifact Registry のスキャン機能が検出してくれるのは、主に次の 2 点です。

OS パッケージの脆弱性: コンテナイメージのベースとなる OS（Debian, Alpine, Ubuntu など）に含まれるライブラリ（libc, openssl など）の脆弱性。
アプリケーション依存パッケージの脆弱性: Python の pip や Node.js の npm などでインストールされた、アプリケーションが直接利用する依存ライブラリの脆弱性。

AI チームでは、プロダクトの実行環境として Google Kubernetes Engine (GKE) をフル活用しており、コンテナネイティブな環境で開発・運用を行っています。そのため Artifact Registry のスキャン機能を活用することで、コンテナイメージの脆弱性検知を効率的に行えると考えました。

AI チームにおける運用上の課題

Artifact Registry の脆弱性スキャン機能は非常に便利ですが、検知後の対応を含めた AI チームでの運用にあたってはいくつかの課題がありました。

スキャン結果の可視化と一覧性が低い

Artifact Registry の脆弱性スキャン結果は 2 つのアプローチで確認できます。

Google Cloud Console 上での確認: イメージの詳細ページでの表示が必要であり、AI チームのような大量のイメージを管理する場合、一覧性が低い
gcloud CLI での確認: 複数のコマンドを組み合わせてスキャン結果を取得する必要があり、使用感に課題がある

イメージの担当者や対応状況の管理ができない

Artifact Registry の脆弱性スキャン機能は、あくまでスキャンと検知に特化しており、検知された脆弱性の担当者の割り当てや対応状況の管理などはサポートしていません。 AI チームでは多数のイメージが存在するため、脆弱性対応の担当者や進捗を一元管理する仕組みが必要でした。

そこで、Artifact Registry の脆弱性スキャン結果を取得し、可視化・管理できる自作 OSS ツール「Drydock」を開発しました。

Drydock の概要

Drydock は、Artifact Registry の脆弱性スキャン結果を取得し、JSON や TSV 形式でエクスポートする Go 製の CLI ツールおよびライブラリです。プロジェクト内のすべてのリポジトリ・イメージを横断的にスキャンし、検知された脆弱性情報を一括で取得できます。

Drydock の由来は、造船所における乾ドック（dry dock）から来ています。乾ドックは、船舶がメンテナンスのために陸上に引き上げられる場所を指していて、コンテナイメージの脆弱性を「陸上に引き上げ」、メンテナンス（対応）を容易にすること目指してこの名前を付けました。

Drydock は、次の 2 つの主要な機能を提供することで、上記の課題を解決します。

CLI ツールとしての利用

Drydock は CLI ツールとして提供され、次のコマンドで Artifact Registry の脆弱性スキャン結果を JSON 形式で一括取得できます。デフォルトでは HIGH および CRITICAL レベルの脆弱性のみを取得しますが、オプションで他のレベルも指定可能です。

drydock -p my-project-id -l asia-northeast1 > scan-results.json

また、TSV 形式での出力もサポートしています。

drydock -p my-project-id -l asia-northeast1 -o tsv > scan-results.tsv

オプションについて詳しくは Usage ドキュメントをご覧ください。

ライブラリ機能とカスタマイズ性

Drydock は Go のライブラリとしても利用可能で、他の Go プロジェクトから直接呼び出してスキャン結果を取得できます。

特に、Exporter インタフェースを満たすことで、スキャン結果の出力先やフォーマットを自由に拡張できます。これは、後続で言及するように結果を Google Sheets のような特定の管理ツールへ直接書き込むカスタムバッチを作成する際に非常に強力な機能となります。

// Exporter defines the interface for exporting analysis results
type Exporter interface {
    // Export outputs the analysis results to the configured destination
    Export(ctx context.Context, results []schemas.AnalyzeResult) error
}

Exporter をカスタマイズする方法についてはマークダウンで出力する例をご参照ください。

Google Sheets を活用した AI チームでの運用例

AI チームでは、Drydock を活用して Artifact Registry の脆弱性スキャン結果を定期的に取得し、スプレッドシートにまとめて管理する方針を採用しました。

スプレッドシートであれば、スキャン結果を簡単に共有・可視化できるため、チーム全体での脆弱性対応がスムーズになります。また、脆弱性を参照するシートと担当者を割り振ることで、対応状況の把握や進捗管理も容易になります。

一方で、完全に自動化されたバッチ処理を構築には、スプレッドシート向けの Exporter の実装やインフラ整備など若干追加の工数が必要となります。本当に Drydock を活用した運用が AI チームにとって適しているかどうかを検証してから、上記の完全自動化に踏み切りたいと考えました。

そのため、以下の 2 段階で Drydock を活用した運用を開始しました。

CLI を使った MVP 開発: Drydock の CLI を用い、TSV 形式でスキャン結果をエクスポートし、手動でスプレッドシートにインポートすることで運用を開始。チームへスプレッドシートを共有し、フィードバックを収集しました。
ライブラリ機能を活用した自動化: Export インタフェースを実装したカスタムエクスポーターを作成し、Drydock のライブラリ機能を利用して直接スプレッドシートにスキャン結果を書き込む自動化バッチを開発しました。

これにより、Artifact Registry の機能を最小限に利用しながらも、迅速に運用を始め、最終的には完全自動化された管理バッチでの運用を実現しました。

まとめと今後の展望

今回は、Artifact Registry の脆弱性スキャン機能を自作 OSS ツール「Drydock」で運用し、運用コストと管理性を両立させる方法を紹介しました。ちょっとした業務の課題を OSS 開発で解決することは、AI チームの一つの文化となっています。ぜひ似たような悩みを抱えている方は Drydock をご利用いただき、フィードバックやコントリビューションを頂けると幸いです。

We are hiring!

AI チームでは、プロダクト開発における技術的な課題を自ら見つけ、アジャイルな検証と OSS 開発を通じて解決していくことに興味があるエンジニアを募集しています。ご気軽にカジュアル面談からでも応募をお待ちしております！

*1:ところで、以前まで Google Container Registry と呼ばれていたサービスは 2025 年 3 月 18 日をもって廃止となり、Artifact Registry に統合されました