ソフトウェアサプライチェーン脆弱性調査
概要
脆弱性管理（Vulnerability Management）チームは、侵害された、あるいはその他の理由で脆弱な依存関係やツールの痕跡がないか、GitLab のソフトウェアサプライチェーンを監査するよう依頼されます。通常、この作業の依頼は #security_discuss Slack チャンネル経由、または SIRT や PSIRT 経由で行われます。
調査用 Issue の作成
依頼を受けたら、作業を追跡するための機密の追跡用 Issue を トラッカープロジェクト に作成し、以下の詳細を必ず含めます:
- アドバイザリ、ブログ記事、その他調査に関連する情報源へのリンク
- 以下の詳細を記載した表:
- 影響を受けるコンポーネント／パッケージの名称
- 影響を受けるコンポーネントのバージョン
- 該当コンポーネントが、以下のプロジェクトグループのいずれかの Dependency List に出現するか:
- GitLab 製品本体に出現するか。出現する場合、影響を受けるバージョンに依存しているか。
gitlab-orgグループ配下のいずれかのプロジェクトに出現するか。出現する場合、影響を受けるバージョンに依存しているか。gitlab-comグループ配下のいずれかのプロジェクトに出現するか。出現する場合、影響を受けるバージョンに依存しているか。
- 重大度に基づく、必要なフォローアップやアクションに関する推奨事項（判明している場合）
- パッケージがまだインストール可能な状態か（⚠️）、あるいはパッケージレジストリから取り下げられたか（✅）
ツール
GitLab 依存関係リスト／SBOM
Dependency List は GitLab の機能で、任意のプロジェクトまたはグループの Secure > Dependency List メニューから利用できます。Dependency List を使う際は、まず検索バーで Component = を選択し、続いてコンポーネント名を入力してコンポーネントを検索します。結果が表示されなければ、そのコンポーネントは依存関係ではありません。名前が表示された場合は、リストからコンポーネントを選択し、リスト外をクリックしてから検索を実行すると、グループ内で影響を受けるプロジェクトの一覧が得られます。
Dependency List のクエリには GraphQL API も使用できます。例えば、gitlab-org 配下のいずれかのプロジェクトにこれらのパッケージがあるかを確認するには、次のような GraphQL クエリを使います:
{
group(fullPath: "gitlab-org") {
dependencies(componentNames: ["golang.org/x/crypto", "golang.org/x/net"]) {
nodes {
id
name
componentVersion {
version
}
packager
location {
path
blobPath
}
}
}
}
}
ログインしている場合、GraphQL Explorer を使って GitLab プロジェクトに対して GraphQL クエリを実行できます。
Package Query
Package Query は、GitLab Dependency List のデータを素早くクエリするために利用できる小さなツールです。
Package Query のクエリは JSON ファイルに保存でき、次のような形になります:
{
"timestamp": "2025-12-04T10:33:54+08:00",
"groupPath": "gitlab-org",
"packagesQueried": [
"golang.org/x/crypto",
"golang.org/x/net"
]
}
GitLab Gem Database
Ruby gem を調査する場合、Gem Database は、どの gem が GitLab の各リリースで実際にインストールされ使用されているかを判断するのに役立ちます。lock ファイルに記載されているすべての gem が必ずインストールされているとは限りません。
Commit Hunter
commit hunter ツールは、侵害された依存関係がインストールされた個々のコミットを、たとえそのコミットがデフォルトブランチ上になくても見つけ出すために使用できます。
従来の脆弱な依存関係とは異なり、悪意のある依存関係は、開発環境でしか実行されなかったとしても認証情報の窃取などの被害をもたらす可能性があります。依存関係のスキャン結果はデフォルトブランチに基づくため、標準的な依存関係クエリではこうしたインスタンスを見つけられません。このツールを使えば、個々の開発者やボット（例: Renovate）が悪意のあるバージョンをインストールしたインスタンスを、まだマージされていない場合でも検索できます。
チームとの連携
この初期情報に基づいて、脆弱性管理チームは他の Security チームと協力し、さらなる調査と緩和策の優先順位付けを進められます。影響が特定された場合は、修正・緩和作業をインシデントとして扱えるよう SIRT と PSIRT を確実に巻き込み、必要に応じてエンジニアリングおよびリリース管理と協力して更新済みパッケージを出荷します。Issue 上で PSIRT をメンションするには @gitlab-com/gl-security/product-security/appsec/psirt-group を使います。詳細は PSIRT Case Lifecycle ハンドブックページを参照してください。
週次トリアージのローテーションに入っている脆弱性管理チームメンバーが、すべての分析・修正・緩和作業を行うことは想定されていません。対応をスケールさせ、影響を伝えられるよう、関連するチームを適切に巻き込むべきです。
メディアおよび顧客からの問い合わせ
サプライチェーン関連の脆弱性はしばしばメディアで報じられ、GitLab が影響を受けるかどうかについて顧客の懸念を引き起こします。そのため、サプライチェーン調査の一環として PSIRT と協力し、顧客への先回りのコミュニケーションを推進することが重要です。具体的には、私たちが認識して調査中であること、調査の結果影響がないと判明したこと、あるいは影響を確認し GitLab のホスト型サービスに対して講じた措置を含め顧客に特定のアクションを求めることを、顧客に伝えて安心してもらいます。通常このプロセスを主導するのは私たちではありませんが、コミュニケーションの目的で適時かつ正確な影響判定を提供できるよう、このプロセスに確実に関与することが重要です。
bfd74782)