Content last updated 2026-02-06

GitLab Application Securityインベントリ

AppSecインベントリは、AppSecにとって重要なすべてのプロジェクト、コンポーネント、依存関係を識別および追跡するためのプライベートGitLabプロジェクトです

GitLab Application Securityインベントリ

GitLabをセキュアにするということは、大規模なセキュリティプログラムを構築することを意味します。コードベースの変更数は、サイドプロジェクトの数とともに常に増加しています。 これらの動的に変化するパーツをすべて把握するには、現在のGitLabソフトウェアアーキテクチャに関する私たちの理解とビジョンだけに頼ることはできません。 自動化は私たちの作業の重要な側面であり、GitLabも例外ではありません。

AppSecインベントリは、私たちにとって重要なすべてのプロジェクト、コンポーネント、依存関係を識別および追跡するためのプライベートGitLabプロジェクトです。 プロジェクトはGitLabチームメンバー向けに https://gitlab.com/gitlab-com/gl-security/product-security/inventory で利用可能です。 インベントリは、このCLIツールを使用して構築されています。

すべてのプロジェクトが重要なわけではなく、POC、デモ、テストであるプロジェクトを監視したくはありません。 そのため、GitLabチームメンバーが作成したプロジェクトをカテゴライズし、その性質を理解し、大規模に意思決定を行う必要があります。

カテゴリ

プロジェクトの目的と特性をすばやく特定するために、厳密なカテゴリ化が必要です。 以下のカテゴリを使用して、監視したいプロジェクトを装飾できます。

カテゴリ説明
productGitLabのソフトウェアサプライチェーンの一部(つまり、GitLabのビルド、パッケージ化、リリース、デプロイに使用される、または製品の一部として使用される)
libraryライブラリ、パッケージソース、コンポーネント(必ずしも product のものではない)
deployGitLab.comのデプロイに使用
websiteWebサイトにデプロイされている(URLが必要)
api/service
green/yellow/orange/red_dataData classification standard
3rdpartyサードパーティとの対話
demo/test/poc
temporary一時的なプロジェクト(いずれ削除される必要がある)
internalGitLabチームメンバーのみ利用可能
externalユーザー向け
use_patパーソナルアクセストークンが使用されている
marked_for_deletionプロジェクトを削除すべき
keep_private無期限にプライベートのまま維持すべき
docsドキュメントの生成に使用
toolingエンジニアリングツール
containerDockerイメージがビルドされる
fork別のプロジェクトのフォーク(gitlab.com上または他の場所)
secrets_monitoringグループ内のシークレットを監視(このコンフィデンシャルIssueを参照)
security_policy_projectGitLabセキュリティポリシープロジェクト

ポリシー

上記で定義されたカテゴリに応じて、いくつかのポリシーを適用します。これらのポリシー(セキュリティ要件を含む)は、こちらおよび(社内のみの)インベントリで利用可能です。

これらは、私たちのGitLab Projects Baseline Requirementsのためのコントロールとして使用されます。

プロジェクトをカテゴリ化する方法

インベントリは、data/ フォルダ内のフォルダツリー構造をデータベースとして使用しています。 リーフはフォルダで、グループまたはプロジェクトであり、特定のファイル(プロジェクトの場合は project.json、グループの場合は group.json)で識別されます。 これらのファイルは、インベントリを同期する際に自動的に作成されます。

ツリー構造は、GitLabインスタンス(私たちの場合は https://gitlab.com)におけるグループとプロジェクトの組織を反映しています。 例えば、GitLabプロジェクトはインベントリのdata/gitlab-org/gitlab/ 配下に配置されます。

プロジェクトは、フォルダ内に properties.yml ファイルを作成することでカテゴリ化できます。このファイルには、プロジェクトのカテゴリを含む categories 配列を含められます。

例えば、product および library カテゴリを追加するには:

categories:
  - product
  - library

サブグループは、フォルダに ignore ファイルを追加することで無視(同期中にスキップ)できます。

GitLab Inventory Builder Documentation、およびこのサンプルインベントリで詳しく学んでください。

GitLabプロジェクトの追加または更新方法

  1. プロジェクトの名前空間をメモする。
  2. https://gitlab.com/gitlab-com/gl-security/product-security/inventory/-/tree/main/data/ にアクセスする
  3. フォルダ構造をナビゲートして、プロジェクトの既存の properties.yml ファイルを見つける。
    1. プロジェクトが存在しない場合は、data/your-namespace/your-project/properties.yml にファイルを作成する。
    2. GitLabの名前空間で作成されたプロジェクトは、毎週自動的に追加される。
  4. カテゴリを追加または更新するマージリクエストを開く。「何を」だけでなく「なぜ」を伝えることを忘れないでください。

Webサイト

プロジェクトのカテゴリ化に加えて、インベントリはデプロイするWebサイトとプロジェクトをリンクするためにも使用されます。properties.yml ファイルには、プロジェクトのすべてのURL(https:// で始まる)をリストする urls 配列を含めることができます。これらのURLは、サーバーのSSL設定を検証するために使用され、安全でない検出結果が報告されます。

例えば、GitLab WebサイトのURLを追加するには:

urls:
  - https://gitlab.com

週次トリアージプロセス

同期パイプラインは毎週月曜日の朝に実行されます。成功すると、変更をレビューするためのマージリクエストが生成されます。

レビューの目的は以下のとおりです。

  1. 新規作成されたプロジェクトをカテゴリ化する: プロジェクトフォルダに properties.yml ファイルを追加してそのカテゴリを指定する。不明な場合はプロジェクトオーナーに尋ねる。
  2. 追跡したくない新規作成されたグループを無視する: グループを無視する必要がある場合は ignore ファイルを追加する。レビューマージリクエストでそのサブグループとプロジェクトを削除する。
  3. プロジェクトとグループの更新をレビューする: project.json および group.json の変更、特に可視性(public/private)をレビューする。

マージリクエストはテストカバレッジを報告し、これはカテゴリ化されたプロジェクトの比率に対応します。理想的には、これらのレビューマージリクエストは同じカバレッジを維持し、新規プロジェクトがマージされる前にカテゴリ化されることを意味します。

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License