Dependency Firewall: リスクのあるパッケージをビルド前にブロック

ビルドが依存する公開レジストリには、悪意のあるパッケージが紛れ込むおそれがあります。しかも、何を取り込むかを決めるのは、もはやデベロッパーだけではありません。AIコーディングエージェントがオープンソースの依存関係を自ら追加するようになり、ビルドに何が入ったのかを誰もレビューしていない、見てすらいないというケースが増えています。

つまり、許可の判断を誰も下さないまま、悪意のあるパッケージや脆弱性を含むパッケージがビルドに入り込みかねないということです。いったん入り込めば、そのコードはパイプラインと同じ権限でビルド内部で動き、開発パイプラインが触れるあらゆるシステムへ到達する可能性があります。

本日Transcendで早期アクセス版として発表されたGitLab Dependency Firewallは、マルウェア、脆弱性、コンプライアンス要件を満たさないものなど、ポリシーに一致するパッケージをビルドに届く前にブロックします。組み込みのガバナンスにより、修正に向けた影響範囲の追跡は数週間から数分へと短縮されます。デベロッパーとそのエージェントは手動のセキュリティレビューを待たずに必要な依存関係を取り込み続けられ、ポリシー要件を満たしたパッケージが正式なビルドの一部となります。

Transcendイベントのリプレイでは、新しいプラットフォーム機能のデモをご覧いただけます。エージェント型AIのスピードをソフトウェアライフサイクル全体に展開するために必要な要素を、ぜひご確認ください。

ビルドを壊さずに悪意のあるパッケージをブロック

インストールの時点でポリシーがなければ、問題のあるパッケージはまずビルドに入り、後から検出されることになります。ソフトウェアコンポジション解析（SCA）が調べるのは、すでに取り込まれたものです。マルウェアや重大度の高い脆弱性、法務部門が許容しないライセンスを検出した時点で、その依存関係はすでにインストールされ、アーティファクトとして出荷されている可能性すらあります。どこまで広がったかを追跡し、取り除き、ビルドし直す。この作業は、通常のパイプライン実行をエンジニアリングチームの計画外対応へと変えてしまいます。

Dependency Firewallでは、インストールされる前の段階で、何をビルドに入れてよいかを次のポリシーで定義します。

1. マルウェア判定: GitLabのマルウェアアドバイザリデータベースでフラグが立てられたパッケージ
2. 脆弱性の重大度: 設定した重大度（critical、high、medium、low）と、そのレベルで許容する検出件数（ゼロ件の指定も可能）
3. ライセンスの種類: 正式名称で指定する許可・拒否ライセンスと、ライセンスを判別できないパッケージの扱い
4. パッケージの経過日数: ビルドに入れるまでに必要な最低経過日数。公開から数分しか経っていないバージョンが、誰の検証も経ずに入り込むことを防ぎます

適用を広げるにあたって、デリバリーをリスクにさらす必要はありません。まずは警告モードから始めます。このモードでは、ポリシーが何を検出したかを記録しながら、ビルドはそのまま継続します。監査イベント、ダッシュボードの記録、CIサマリーの1行が残るため、ビルドをブロックすべきかどうかを腰を据えて分析できます。

ポリシーに確信が持てたら、ブロックモードに切り替えます。ポリシーに一致した時点でパイプラインを停止し、その理由を提示する仕組みです。承認済みパッケージをどうしても通す必要がある場合は、記録に残るバイパスによって、指定したユーザーまたはトークンが処理を進められます。

ポリシーを一括で設定し、チーム単位で調整する

レジストリ単位でしか適用できないファイアウォールは、全員に同じポリシーを課すことになりますが、それが実際のチームの働き方に合うことはほとんどありません。決済サービスと社内のプロトタイプではリスクプロファイルが大きく異なります。レジストリ全体に一律のルールセットでは、片方だけをより高い基準に保てません。

Dependency Firewallでは、トップレベルグループでポリシーを1つ設定すれば、配下のすべてのプロジェクトが同じルールを継承します。別の基準が必要なチームには、そのグループまたはプロジェクト単位でポリシーを設定します。レジストリレベルで適用して組織全体を1つのプラットフォームから統制しながら、リスクの高い箇所でルールを厳しくする余地も残せます。

ルールはセキュリティポリシープロジェクトにコードとして置かれ、他の設定と同じようにマージリクエストを通じてレビューし、変更します。ルールはトップレベルグループから各プロジェクトへと継承され、重なる場合は最も厳しいものが適用されます。重要なサービスを組織のベースラインより高い水準に保ちつつ、どのプロジェクトもその水準を下回りません。

取り込む前にパッケージを確認する

デベロッパー、あるいはその代理として作業するエージェントがパッケージの不許可を知るのは、たいていパイプラインが失敗したときです。作業が乗ってきたまさにそのタイミングで、ビルド1回分のコストと集中力が失われます。

GitLab Dependency Firewallなら、依存関係を追加する前に、すでに作業している場所で答えが得られます。一度目から通るパッケージを選べるということです。

ターミナルやスクリプトからGitLab CLIを使えば、そのパッケージがポリシーを通過するのかブロックされるのかを、コマンドラインで判定できます。別のコンソールを開く必要はありません。npm、pip、Poetry、Maven、Gradle、Bundlerといった主要なパッケージマネージャーに対応しており、対応範囲は今後さらに広がる予定です。

すべての判断を可視化し、証明する

セキュリティリーダーは、監査の場でその統制が何をしているのかを証明できなければなりません。記録を残さず静かにブロックするだけの統制では、監査担当者の問いに答えられず、統制の対象となるチームからの信頼も得られません。

ファイアウォールが何を許可し、何に警告し、何をブロックしたのか。その全体像を1つのビューで把握でき、個々の判断の改変できない記録を監査担当者に提出できます。

Dependency Firewallのダッシュボードには、対象となるプロジェクト全体の動作と結果が表示されます。警告、ブロック、バイパスのいずれについても、一致したルール、その背後にあるポリシー、対象パッケージを記録した監査イベントが書き込まれます。

GitLab Dependency Firewallの早期アクセスを申し込む

悪意のあるパッケージ、脆弱性を含むパッケージ、コンプライアンス要件を満たさないパッケージを、ビルドに到達する前に止められます。GitLab Artifact Centralや、Sonatype Nexus Repository、JFrog Artifactoryといった外部レジストリと互換性があり、GitLab環境の隣に別のツールを立ち上げる必要もありません。Dependency Firewallは現在、PremiumまたはUltimateプランをご利用のGitLab.comおよびGitLab Self-Managedのお客様を対象に、早期アクセス版として提供しています。今すぐ早期アクセスをリクエストしてください