Security_standard on GitLab ハンドブック (非公式日本語訳)

セキュリティインシデント対応ガイド

Wed, 25 Feb 2026 07:10:33 -0800

Visibility: Audit

目的

セキュリティインシデントレスポンスチーム (SIRT) は、あらゆるセキュリティインシデントの支援のために 24/7/365 のオンコール体制を取っています。緊急のセキュリティインシデントが特定された場合、またはインシデントが発生した可能性があると思われる場合は、セキュリティエンジニアオンコールへのエンゲージを参照し、Slack で自分自身またはパブリック/プライベートチャンネルへの新しいメッセージを書いて /security コマンドを使用してください (このコマンドは Slack のスレッド内では動作しません)。

SIRT の責任とインシデントオーナーシップに関する情報は、SIRT オンコールガイドで確認できます。

スコープ

インシデントの特定

セキュリティインシデント調査は、GitLab.com、その他の GitLab サービス、または GitLab 社の一部としてセキュリティイベントが検知されたときに開始されます。これらの調査は、資格を持つセキュリティチームメンバーによりトリアージされ、トリアージ証拠が明白でリスクのないものであれば誤検知として処理されます。GitLab の顧客、サービス、プロダクト、チームメンバー、サードパーティサービス等に対して潜在的に有害または悪影響を及ぼす可能性があるかどうかについて疑義がある場合、セキュリティチームがインシデントを調査します。

インシデントの兆候は、内部の GitLab チームメンバーまたは外部の方から SIRT に報告できます。セキュリティインシデントの特定および検証に応じて調査をいつ実施するかを判断するのは、セキュリティチームの責任です。

GitLab セキュリティチームは、GitLab セキュリティ、利用規約、その他の関連ポリシーの違反または違反の脅威を、セキュリティインシデントとして特定します。

SIRT は、サードパーティ侵害を含めて GitLab に重大な影響を及ぼす可能性のあるセキュリティインシデント (個別または合計で重大な侵害となる可能性があるもの) について、Material Breach Determination internal handbook page のプロセスに従います。重大化する可能性のあるインシデントは MNPI (重要非公開情報) として扱います。

役割と責任

役割	責任
GitLab チームメンバー	本手続きの要件に従う責任
SIRT	本手続きの実装および実行の責任
SIRT 経営層 (Code Owners)	本手続きの重要な変更および例外の承認の責任

手続き

インシデントレスポンスプロセス: 本ガイドはすべてのセキュリティインシデントについて以下の活動をカバーします

検知
- SIRT、その他の社内、または社外のエンティティが、セキュリティ脆弱性または弱点の悪用の可能性、または設定ミスや無意識のエラーの結果と思われるセキュリティまたはプライバシーイベントもしくはリスクを特定する
- 私たちのセキュリティ検知コントロールの 1 つが、確立されたセキュリティベースラインの範囲外のイベントを特定する
- 慎重を期すため、また仮定を検証するために、セキュリティ Issue がインシデントにエスカレーションされる
分析
- SIRT は、報告されたセキュリティまたはプライバシーイベントが実際にセキュリティまたはプライバシーイベントであるかを判断する
- SIRT は以下のインシデント分類方法論に基づいてインシデントの重大度と優先度を判断する
封じ込め
- 影響を受けたシステムまたはデータの不正使用または悪意のある使用の拡散を防ぐ
- インシデントの根本原因を軽減し、最終的に完全に是正することで、さらなる損害や露出を防ぐ
- SIRT はインシデントの結果として生じる損害を最小化するために、追加のコントロールを実施することがある
- 影響を受けたシステムでの運用を継続することが安全かどうかを判断する
- 影響を受けたシステムの運用を許可または拒否する
根絶
- セキュリティインシデントを引き起こした構成要素を排除する
- 環境または対象システムへの攻撃者のアクセスを除去する
- 影響を受けたシステム周辺のコントロールを強化する
復旧
- インシデントの原因となった問題が修正された後、影響を受けたシステムの運用を回復する努力
- 追加の監視コントロールの実装
- 関連する詳細でインシデントレコードを更新する
インシデント後の分析および活動
- 振り返りと教訓の活動

漏洩した認証情報のインシデント対応プロセス

認証情報の漏洩が確認された場合、認証情報を直ちに失効させて露出時間を最小化することが重要です。これは自動化、またはセキュリティチームによる手動取り消しによって実現できます。Security はその時点で行動による潜在的な影響が明確に把握されていなくても、さらなる悪用を防ぐため認証情報を直ちに失効させます。場合によっては、認証情報が正当なプロセスで使用されている場合に支障を来すことがあります。失効した認証情報に依存するサービスへの影響の可能性があるため、Security は #security-revocation-self-service Slack チャンネルに通知を投稿し、認証情報の所有者がこのチャンネルを手動または自動のセルフサービスとして使用できるようにします。認証情報はすでに公開され失効しているため、また認証情報所有者がチャンネル内で自分の認証情報を見つけやすくするため、失効した認証情報のクリアテキスト版が通知の一部として公開されます。

GitLab 暗号化標準

Wed, 06 May 2026 17:37:54 -0500

Visibility: Audit

目的

暗号化標準は、GitLab 製品で使用されるさまざまなシステムやサブシステム内で保存中または転送中のデータを暗号化する目的で、承認された暗号化アルゴリズム、設定、暗号化モジュールを定義します。

暗号化標準は、GitLab 内での暗号化使用に対するより一貫したアプローチ、業界標準やコンプライアンスフレームワーク (FedRAMP など) へのより容易な適応、および全体的により安全な製品と作業環境を可能にします。さらに、ほとんどの標準は NIST (米国国立標準技術研究所) の推奨事項に基づいています。多くのコンプライアンスフレームワークが NIST 標準に基づいており、NIST は世界中の多くの組織によって採用される堅実な推奨事項を一貫して提供しているためです。

スコープ

暗号化標準は、GitLab のデータを取り扱い、管理、保存、または送信するすべての GitLab チームメンバー、契約者、コンサルタント、ベンダー、その他のサービスプロバイダーに適用されます。

これは、GitLab 製品自体の暗号化に関わるクライアントおよびサーバー設定だけでなく、コーディングのベストプラクティスにも必要です。現在、これらの標準を確実に満たし維持するために、複数のエンジニアリングチームによる多数の取り組みが社内で行われています。スコープには、暗号化設定が必要なサードパーティモジュールやソフトウェア設定が含まれます。基本的に、GitLab または GitLab の顧客データに触れる場合、この標準が適用されます。

役割と責任

役割	責任
GitLab チームメンバー	この標準で概説された要件を遵守する責任
セキュリティ管理および暗号化担当者 (Code Owners)	この標準に対する重要な変更や例外を承認する責任

GitLab の責任

GitLab チームメンバー、契約者、コンサルタント、ベンダー、その他のサービスプロバイダーは、この暗号化標準と、特に注記がない限り以下に定義される保存中および転送中のデータの暗号化ニーズの取り扱い方法をレビューして理解する必要があります。

顧客の責任

GitLab 顧客は自分自身のデータを管理する責任があり、これらの標準を強く推奨されるものとして考慮し、独自の内部要件に従って採用する必要があります。GitLab は相互秘密保持契約に記載された秘密保持義務に従って顧客データを社内で取り扱い、この標準で特定されているコントロールを使用します。

標準

コンプライアンスと認証の標準

これらの標準は GitLab 製品の全体的なセキュリティを向上させるためのセキュリティベースラインと考えていますが、コンプライアンスと認証の取り組みについては、以下の一般的なガイドラインを使用します。

GitLab データ分類標準

Thu, 30 Apr 2026 16:57:54 +0000

Visibility: Audit

目的

データ分類標準は、データの種類とカテゴリーを定義し、GitLab および顧客データのライフサイクル全体を通じて適用される保護レベルを決定する目的で、それぞれに関連付けられたデータ分類を提供します。

スコープ

データ分類標準は、GitLab のデータを取り扱い、管理、保存、または送信するすべての GitLab チームメンバー、契約者、コンサルタント、ベンダー、その他のサービスプロバイダーに適用されます。

役割と責任

役割	責任
GitLab チームメンバー	この標準で概説された要件を遵守する責任
データオーナー	所有するデータタイプに対するこの標準への例外を承認する責任。これらは一般にシステムのビジネスオーナーです。
セキュリティおよび法務 (Code Owners)	この標準への重要な変更や例外を承認する責任

GitLab の責任

GitLab チームメンバー、契約者、コンサルタント、ベンダー、その他 GitLab に代わって行動するすべてのサービスプロバイダーは、このデータ分類標準と、特に注記がない限り以下の分類レベルに従ってデータを取り扱う方法をレビューして理解する必要があります。
データオーナーは、この標準に従ってデータの分類を決定するものとします。データ分類インデックス (内部のみ) は、さまざまな種類のデータとその分類レベルのリストを提供します。データ要素を特定できない、またはデータに関連するリスクとそれをどのように分類して取り扱うべきかについて確信が持てない場合は、Slack の @security-risk 経由でセキュリティリスクチームに連絡してください。
セキュリティ、透明性の文化を維持し、機密データと顧客に対するリスクを最小限に抑えるために、GitLab チームメンバーは、GitLab のセキュリティ意識向上トレーニングの一環としてデータ分類トレーニングを完了することが必要です。これは、GitLab のさまざまな種類のデータと、それを SAFE に保つ方法を理解するのに役立ちます。トレーニングは GitLab の内部学習プラットフォームである LevelUp 経由で利用できます。

顧客の責任

GitLab 顧客は自分自身のデータを管理する責任があり、独自の内部要件に従って識別と分類を含めて行います。GitLab は相互秘密保持契約に記載された秘密保持義務とこの標準で識別された分類に従って、顧客のデータを社内で取り扱います。

標準

データ分類の定義

個人データ: 個別または他のデータと組み合わせて、識別可能な自然人 (「データ主体」) に直接的または間接的に関連付けられる、または合理的に関連付けまたは結びつけられる可能性のあるデータ。

GitLab パスワード標準

Thu, 02 Apr 2026 12:48:42 -0700

Visibility: Audit

目的

本書は、技術的に実現可能な範囲において、機密情報（Red および Orange）を含む GitLab の情報システムやその他のリソースを不正利用から保護することを目的とした、情報セキュリティのパスワード標準を定めます。

適用範囲

GitLab のコンピューティングリソースに関わり、機密データにアクセスするすべての GitLab チームメンバー、契約社員、アドバイザー、契約当事者に適用されます。

役割と責任

役割	責任
GitLab チームメンバー	本標準に記載された要件を遵守する責任を負います
Security	クリティカルなアプリケーションについて、本標準の定義および導入状況のモニタリングを行う責任を負います
Security Management（コードオーナー）	本標準への重大な変更および例外を承認する責任を負います

標準

セキュアなパスワードを構築し、適切なパスワード管理を確保することは不可欠です。GitLab のパスワード標準は、NIST 800-63B の推奨事項を一部参考にしています。本当にセキュアなパスワードとは何かについて学ぶには、こちらの記事、またはパスワード強度に関するカンファレンス発表をご覧ください。

注: 技術的な制約により、システムが本標準の特定の設定をサポートできない場合は、本標準に最も近い設定を行わなければなりません。例外はこちらで起票し、リクエスト Issue 内のマトリクスに従って関連するリスク評価と例外レビュー期限が割り当てられます。

パスワード要件

最小長 = 12 文字
特殊文字 = 不要
パスワードの再利用 = 不可
パスワードの有効期限 = なし
多要素認証（MFA） = 可能な限り使用すること

覚えやすくセキュアなパスワードを作るには、5 個以上のランダムな単語の組み合わせを使うことを検討してください。「好きな色は何ですか？母親の旧姓は何ですか？」のようなセキュリティ質問は、当てにくいランダムな単語または単語のセットで回答してください。1Password で回答を生成し、ノートとして保存できます。これにより回答が容易に推測されず、サイトごとに一意になることが保証されます。

GitLab プロジェクトのベースライン要件

Mon, 02 Mar 2026 07:33:04 -0500

目的

このページの目的は、GitLab 製品を構成するコードに最終的に影響を与える、および/または GitLab のビルド、リリース、デプロイに影響を与える GitLab プロジェクトを構成する際に遵守すべき最小限の要件セットを概説することです。最終的な目標は、GitLab のコードベースに最終的に影響を与える変更がレビューなしで行われないようにすることです。このページはまた、GitLab のユーザーが重要だと考えるプロジェクトを保護するためのいくつかの可能な構成を提供することで、ユーザーを支援できます。

GitLab のドッグフーディングへのコミットメントと GitLab の効率の価値を念頭に置くと、これらのベースラインプロジェクト構成はすべてのプロジェクトで必要とされるわけではなく、(直接的または間接的に) GitLab のコードベースに影響を与えるプロジェクト、または別の伝達された理由で重要であると見なされるプロジェクトでのみ必要とされることを理解することが重要です (これらのインスタンスでは、これらのベースライン構成の必要性の背後にある「理由」の根拠が明確に伝えられる必要があることに注意してください)。

ただし、チームメンバーがプロジェクトを作成または作業する際に、これらのベースライン構成を念頭に置くことが推奨されます。これらは、GitLab プロジェクトでなされる貢献のセキュリティと品質を向上させるように設計されているためです。

スコープ

これらのベースライン構成を適用すべきプロジェクトのスコープは、GitLab のコードベースに直接的または間接的に影響を与えるプロジェクト、および/または GitLab のビルド、リリース、デプロイに影響を与えるプロジェクトです。

この基準に当てはまるプロジェクトの例:

GitLab のコンポーネントをビルドするプロジェクト
GitLab のコンポーネントのコードベースを管理するのに役立つボットをビルドするプロジェクト
重要な非 GitLab システム (例: Salesforce) のコードベースを更新するために使用されるプロジェクト

この基準に当てはまらないプロジェクトの例:

コードを持たないプロジェクト
GitLab のコードベースに影響を与えないボットをビルドするプロジェクト (例: YAML ファイルを CSV に変換するスクリプト)

プロジェクトの使用法は時間の経過とともに自然にシフトする可能性があり、継続的にプロジェクトの使用法を再評価することが重要です。プロジェクトはどちらのカテゴリーにも入ったり出たりする可能性があるため、毎日プロジェクトで作業する際にそれを念頭に置いてください。期待されるのは、プロジェクトにこれらのベースライン構成が設定されている場合でも、チームメンバーが作業で協力し合い、知識のサイロで作業することを避けることで、効率が低下しないことです。これは、個人が単一障害点になるリスクも増加させます。これらの価値観はまた、変更に複数のチームメンバーを関与させることで、私たちの透明性の価値を促進します。

自分のプロジェクトがどこに当てはまるかわかりません

それは大丈夫です! そして、確かに珍しいことではありません。質問がある場合は、私たちが対処し、適切なカテゴリーに当てはめられるよう、提起してください。プロジェクトの分類方法をここで反復することができ、セキュリティと品質、そして効率へのコミットメントを確保できます。

自分のプロジェクトは基準に当てはまらないようですが、それでもこれらの構成が必要ですか?

プロジェクトがベースライン構成を要求するための一般的な基準を厳密に満たさないが、何らかの理由でプロジェクトをベースライン構成を使用して構成すべきと判断される場合もあります。これらのインスタンスでは、これらのベースライン構成の必要性の背後にある「理由」の根拠が明確に伝えられる必要があります。既存の基準を満たさないと思われるプロジェクトに対して多くの類似した根拠が提供される場合、それはプロジェクトのスコープと基準を調整すべきという指標である可能性があります。

保護されたブランチのベースライン構成

一般的なルールとして、私たちは誰もが保護されたブランチに MR を提出することを要求するような方法でブランチを保護したいと考えています。MR を使用するこの要件により、なされた変更とその背後にある根拠の追跡がより容易になり、最も重要なことは、保護されたブランチに変更を加えるために MR を使用する必要があることです。これは、構成された MR 承認ルールと密接に連携します。アカウントが保護されたブランチに直接プッシュできる場合、そのアカウントは MR を使用する必要がなく、別のチームメンバーの関与なしに変更を加えることができます。

セキュリティ第三者リスク管理

Fri, 13 Feb 2026 09:20:12 -0600

Visibility: Audit

GitLab の統合 Third-Party Risk Management プログラム

GitLab は、自動化、継続的なモニタリング、およびビジネス機能全体にわたる深い統合を活用して、外部関係者と共有される GitLab データのセキュリティを検証する、業界をリードする Third Party Risk Management (TPRM) Program を維持しています。

ベンダー調達フロー内に GitLab の TPRM プログラムを統合することで、Privacy、Legal、IT、People Operations 間の機能横断的なコラボレーションを可能にし、透明性のあるリスクベースの意思決定、ビジネスおよびステークホルダーに焦点を当てた Results、そして GitLab の規制および Compliance Obligations の遵守を促進します。このプログラムを通じて維持されるベンダー関係は、組織全体で効率を生み出すために活用されます。

範囲

この手順は、GitLab データにアクセス、保管、処理、または送信するすべてのサードパーティプロバイダーに適用されます。

目的

GitLab の Security Third Party Risk Management (TPRM) プログラムは、GitLab またはお客様のデータにアクセスできるサードパーティから引き起こされるセキュリティ脅威に対する保護を支援します。これらのリスクには、データ侵害、不正使用または開示、データの破損または喪失が含まれる可能性があります。適切な TPRM は、セキュリティの懸念を軽減し、GitLab が契約上の義務を満たすことを可能にするベストプラクティスです。TPRM はまた、GitLab が ISO、SOX、GDPR、およびベンダー監視を必要とするその他の州法および連邦法に関連する規制要件と標準を満たすことを可能にします。

GitLab トークン管理標準

Thu, 12 Feb 2026 20:47:52 +0000

目的

トークン管理標準は、GitLab 製品で使用される様々なシステムおよびサブシステム内で認証と認可を提供する目的のために、承認された GitLab のトークン使用、設定、配布を定義します。

本標準のいくつかの要素では、現在実装されていない技術、テクニック、設定、およびそれらのバリエーションが参照されます。それらの場合、本標準は将来の開発と実装に対する具体的なガイダンスを提供することを意図しています。

トークン管理標準により、GitLab 内でのトークン使用に対するより一貫したアプローチ、業界標準やコンプライアンスフレームワーク（FedRAMP など）へのより容易な適応、そして全体としてよりセキュアな製品と作業環境が可能になります。さらに、ほとんどのコンプライアンスフレームワークが NIST 標準に基づいており、NIST が世界中の多くの組織で採用される確かな推奨事項を一貫して提供していることから、本標準のほとんどは NIST（National Institute of Standards and Technology）の推奨事項に基づいています。

適用範囲

トークン管理標準は、GitLab データを取り扱う、管理する、保存する、または送信するすべての GitLab チームメンバー、契約社員、コンサルタント、ベンダー、その他のサービスプロバイダーに適用されます。

これは、GitLab 製品自体のトークンを伴うアカウントおよび認証子管理だけでなく、コーディングのベストプラクティスにも必須です。基本的に、GitLab または GitLab 顧客データに触れるものであれば、本標準が適用されます。

役割と責任

役割	責任
GitLab チームメンバー	本標準に記載された要件を遵守する責任を負います
Security Management および Cryptographic Officer	本標準への変更と例外を承認する責任を負います
トークンの DRI	すべての Owner および Maintainer ロール割り当てのレビューと承認権限を持ちます
Management	すべてのグループおよびプロジェクトメンバーシップのレビューと承認権限を持ちます
Group Owners、Group Maintainers、Project Owners、Project Maintainers	グループおよびプロジェクトのアカウント管理、ならびに Group、Project、Deploy、Runner Token オブジェクトの作成、失効、使用および配布の監視を含む（ただしこれらに限定されない）トークン管理業務

GitLab の責任

GitLab チームメンバー、契約社員、コンサルタント、ベンダー、その他のサービスプロバイダーは、本トークン管理標準を定期的にレビューして理解し、セキュリティを維持するために GitLab トークンをどのように要求、承認、配布、使用、保護するかを把握することが求められます。本書はいつでも更新される対象であり、上記の人々は変更を追跡する責任を負います。

GitLab セキュリティロギング標準

Thu, 12 Feb 2026 20:47:52 +0000

目的と適用範囲

このセキュリティロギング標準の目的は、GitLab のセキュリティロギング要件を定義することです。本書は、GitLab の SIEM（Devo）におけるセキュリティロギングと、SIEM にログを送信していないシステム向けのセキュリティロギング要件の双方をカバーします。

役割と責任

役割	責任
GitLab システムオーナー（GitLab の tech stack で定義）	本標準に記載された要件を遵守することに直接的な責任を負います
Security Operations チーム	Security チームの SIEM（Security Information Event Management）システムである Devo において、ログの優先順位付け、オンボーディング、保守を直接的に担当します。

セキュリティロギング要件

セキュリティログは GitLab で使用されるアプリケーションとシステムによって生成され、主にセキュリティ監視、セキュリティインシデント対応、サイバー脅威ハンティングに使用されます。

GitLab Security Operations チームは、既存システムのセキュリティログの優先順位を反復的に評価し、セキュリティ可観測性を向上させるためにオンボーディングする必要がある新規ログソースのリクエストを評価します。Security Operations チームは、SIEM 内のセキュリティログに関する Single Source of Truth（SSOT）を維持しています。

GitLab で新しいアプリケーション、システム、サービスがオンボードされた際に、システムのセキュリティログ（例: アプリ、OS、トランザクションログ）が GitLab の SIEM に送信されない場合、セキュリティログは保持ポリシーに沿った期間、承認されたセキュアストレージに保存される必要があります。

セキュリティログ保持要件

セキュリティログの説明	保持要件
本番システムのセキュリティログ	最低 1 年
本番ではないクリティカルシステムのセキュリティログ	最低 90 日

セキュリティログ収集要件

最低限、GitLab の本番システムおよび本番外のクリティカルな GitLab システムについて、認証イベントとトランザクションイベントを収集しなければなりません。

ソフトウェア開発ライフサイクル標準

Thu, 12 Feb 2026 20:47:52 +0000

Visibility: Audit

目的

セキュアなソフトウェア開発は、安全で信頼されるアプリケーションを開発・維持するうえで重要です。本標準は、GitLab のソフトウェア開発ライフサイクルの一般的な構成要素を概説します。

適用範囲

本標準は、GitLab の本番アプリケーションを支えるために GitLab でコードを開発するすべての人に適用されます。開発プロセスの詳細については product development flow を参照してください。

役割と責任

役割	責任
Security Governance	本標準を作成し実装する責任を負います
チームメンバー	本標準の各項目を実行する責任を負います

標準

構想と要件

このステージは、各チームの個別プロセスに応じて異なる媒体で行われます。

このステージでは、次の情報が確立されます:

課題の明示と望ましい結果
スコープの定義
主要なステークホルダーの特定
関連するステークホルダーと協力して、マイルストーンと成果物を含む詳細なプロジェクト計画を作成

要件は最低限、次を特定する必要があります:

アプリケーションまたは機能が何を行うか
プロジェクトを完了するために必要なリソース

特定された要件はプロジェクト管理ツールに文書化され、関連するステークホルダーがレビューおよび承認できるようにします。

設計

設計ステージでは、設計ドキュメントはプロジェクト管理ツールにバージョン管理されたドキュメントとして取得されます。

設計ドキュメントの考慮事項は次のとおりです:

アーキテクチャ: チームは特定のテンプレートを希望するか、業界慣行を実装するかを定義します。
ユーザーインターフェース: チームはユーザーがアプリケーションや機能とどのように対話するかを定義します。
セキュリティ: 開発者はアプリケーションをどのようにセキュアに保つかを定義する必要があります。これには、ユーザーデータと一般的なアプリケーションデータをどのように保護するかを決定することが含まれます。
プログラミング: プロジェクトの技術およびツールスタックを定義します。
コンポーネント: ソリューションをサポートするために必要なコンポーネントを定義します。

設計ドキュメントは、マージ（プロトタイピング）される前に関連するステークホルダーによって承認される必要があります。

会社資産の物理セキュリティ標準

Thu, 12 Feb 2026 20:47:52 +0000

Visibility: Audit

目的

本書は、GitLab のオールリモート環境における情報資産の保護を支援するための資産管理上の対策と要件を定義します。本標準で言及される対策と要件は、安全なインフラと作業環境を構築し、機密情報を物理的脅威から保護するように設計されています。

適用範囲

本標準は、GitLab のコンピューティングリソースに関わり、会社または顧客のデータにアクセスするすべての GitLab チームメンバー、契約社員、アドバイザー、契約当事者に適用されます。

役割と責任

役割	責任
Security Assurance	本標準を実装し実行する責任を負います
Security Assurance Management（コードオーナー）	本標準への重大な変更および例外を承認する責任を負います
チームメンバー、契約社員、アドバイザー、契約当事者	本標準の「物理デバイスとロケーション」要件を遵守する責任を負います

概要

オールリモート企業として、情報資産の物理的保護は定義された「セキュリティゾーン」に分類できます。セキュリティゾーンとは、物理的な場所における情報資産の取り扱い要件として定義されます。

GitLab には 2 つの異なるセキュリティゾーンがあります:

インフラ（SaaS 製品向け）

サードパーティのサービスプロバイダーによってホストされ、物理的に保護されます
責任共有モデル
物理セキュリティ要件への準拠は、年次の Third Party Risk Management（TPRM）レビューおよび Complementary User Entity Controls（CUEC）レビューの一部としてレビューされます。これには独立した第三者が、以下を含む（ただしこれに限定されない）効果的な物理セキュリティ手順を証明していることの確認が含まれます:
- 訪問者管理
- 構内保護
- 環境セキュリティ
- アクセス管理

物理デバイスとロケーション

ラップトップは Endpoint Management Procedures によって保護され、IT Security - System Configurations ハンドブックページで定義されたシステム構成によってセキュアにされています。これには次のものが含まれますが、これらに限定されません:

記録の保持と廃棄

Thu, 12 Feb 2026 20:47:52 +0000

Visibility: Audit

目的

GitLab の記録保持・廃棄標準は、重要な GitLab 記録に関する具体的な保持および安全な廃棄要件を列挙しています。これらの最小要件は、すべての GitLab tier 1 および tier 2 のクリティカルシステムに対する設計および保守の判断を導きます。

適用範囲

以下の保持および安全な廃棄要件は、GitLab tier 1 および tier 2 のクリティカルシステムに保存されている、下表に列挙されたすべての GitLab 記録に適用されます。

役割と責任

役割	責任
GitLab チームメンバー	本管理対象ドキュメントの要件に従う責任を負います。
Security Compliance Team	本管理対象ドキュメントをレビューし、保守する責任を負います。
Control Owners	以下の要件をサポートする手順を定義し実装する責任を負います。
Security Assurance Management（コードオーナー）	本管理対象ドキュメントへの重大な変更および例外を承認する責任を負います。

保持と廃棄の要件手順

記録	保持要件	廃棄要件
事業継続計画の承認	3 年	[GCP/AWS Secure Deletion]
事業継続テストの結果	3 年	[GCP/AWS Secure Deletion]
本番バックアップテスト	1 年	[GCP/AWS Secure Deletion]
本番変更	3 年	[GCP/AWS Secure Deletion]
セキュリティポリシーレビュー／承認	3 年	[GCP/AWS Secure Deletion]
利用規約への同意	ユーザーがアクティブな間	[GCP/AWS Secure Deletion]
アクセスリクエスト／変更記録	1 年	[GCP/AWS Secure Deletion]
チームメンバーのオフボーディング Issue	現地法による	[GCP/AWS Secure Deletion]
システムアクセスレビュー	1 年 3 か月	[GCP/AWS Secure Deletion]
共有およびグループ認証レビュー	1 年 3 か月	[GCP/AWS Secure Deletion]
本番監査ログ	1 年	[GCP/AWS Secure Deletion]
GCP ファイアウォール構成成果物	1 年	[GCP/AWS Secure Deletion]
職務役割と責任	1 年	[GCP/AWS Secure Deletion]
顧客へのセキュリティインシデント連絡	3 年	[GCP/AWS Secure Deletion]
人事ファイル記録	現地法による	[GCP/AWS Secure Deletion]
1:1 ミーティングノート	現地法による	[GCP/AWS Secure Deletion]
オンボーディングチケット	現地法による	[GCP/AWS Secure Deletion]
年次リスク評価レポート	2 年	[GCP/AWS Secure Deletion]
リスク対応計画	3 年	[GCP/AWS Secure Deletion]
セキュリティ観察 Issue	3 年	[GCP/AWS Secure Deletion]
取締役会議事録	無期限	N/A
リリースノート	1 年	[GCP/AWS Secure Deletion]
クリティカルシステムのアクティビティログ	60 日	[GCP/AWS Secure Deletion]
セキュリティ監視アラート／メトリクス	3 年	[GCP/AWS Secure Deletion]
ベンダーセキュリティレビュー Issue	3 年	[GCP/AWS Secure Deletion]
顧客が署名した MSA	無期限	N/A
ベンダー NDA	無期限	N/A
年次セキュリティアウェアネストレーニング記録	3 年	[GCP/AWS Secure Deletion]
セキュアコーディングトレーニング記録	2 年	[GCP/AWS Secure Deletion]
ペネトレーションテストレポートおよび是正 Issue	2 年	[GCP/AWS Secure Deletion]
システムパッチ記録	1 年	[GCP/AWS Secure Deletion]
ソースコードスキャン結果	1 年	[GCP/AWS Secure Deletion]
ZenDesk チケット	3 年	[GCP/AWS Secure Deletion]
非公開情報レビュー記録	3 年	[GCP/AWS Secure Deletion]
ロールベースのセキュリティトレーニング記録	3 年	[GCP/AWS Secure Deletion]
監査ログレビュー記録	3 年	[GCP/AWS Secure Deletion]
セキュリティアセスメントレポート／観察	3 年	[GCP/AWS Secure Deletion]
セキュリティ構成レビュー／アラート	3 年	[GCP/AWS Secure Deletion]
セキュリティ認可記録	3 年	[GCP/AWS Secure Deletion]
システム接続要件	3 年	[GCP/AWS Secure Deletion]
構成変更記録	3 年	[GCP/AWS Secure Deletion]
セキュリティ影響分析記録	3 年	[GCP/AWS Secure Deletion]
本番資産インベントリ	3 年	[GCP/AWS Secure Deletion]
BC トレーニング記録	3 年	[GCP/AWS Secure Deletion]
本番バックアップ	組織別に定義	[GCP/AWS Secure Deletion]
顧客データバックアップ	組織別に定義	[GCP/AWS Secure Deletion]
雇用申請書および面接ノート（米国ベースの応募者のみ）	4 年（2021-07 更新）	N/A
PII データを含む一時ファイル	業務目的で必要な間	システムの既定の削除スケジュールに従う

例外

これらの要件への例外は、情報セキュリティポリシー例外管理プロセスに従って追跡されます。

脆弱性管理

Fri, 06 Feb 2026 19:27:57 -0500

Visibility: Audit

脆弱性管理は、脆弱性の特定、優先順位付け、緩和、および修正を継続的に行うプロセスです。GitLab では、分析対象のコンポーネントに応じて、さまざまな方法で脆弱性を特定します。このプロセスと関連するツールは、脆弱性管理チームが所有しています。

このページでは、主に GitLab における脆弱性管理ポリシーと手順について説明します。GitLab で脆弱性を管理するために使用されるポリシーと手順を総称して脆弱性管理標準と呼びます。

クイックリファレンス

GitLab における脆弱性管理は何をカバーするか？

脆弱性管理は、GitLab クリティカルシステムの階層化方法論に基づき、GitLab 本番および/または GitLab 顧客データを保存・処理・送信するすべてのシステム、および GitLab が管理するソフトウェアおよびソフトウェア依存関係をカバーします。具体的には:

GitLab 管理のインフラ
GitLab ソフトウェア、パッケージ、イメージ、依存関係
後から検出されたもの (HackerOne レポート、コミュニティまたはチームメンバーからのバグ報告、ペネトレーションテストの所見)

アプローチと戦略

GitLab の脆弱性管理は、主に脆弱性、脆弱性検出、攻撃対象領域に関するデータの収集にフォーカスしています。これは、さまざまなソースのデータを収集・正規化・関連付けし、所見に直接対応または緩和する自動化されたアクション可能なワークフローに変換するツールを構築することで行います。これが自動的に行えない場合、このプロセスの出力を、所見の緩和または修正の責任を持つ GitLab の DRI が容易に利用・理解できるようにすることを目指しています。私たちのゴールは、このツールを GitLab 自体にフィードバックし、可能な限り GitLab の機能を構築・利用して、自分たちと顧客のワークフローをサポートすることです。

アクセスレビュー手順

Fri, 16 Jan 2026 15:03:53 -0600

Visibility: Audit

目的

GitLab のユーザーアクセスレビューは、内部および外部の IT 監査に必要な重要なコントロールアクティビティであり、脅威を最小化し、適切な人々が重要なシステムやインフラストラクチャに対する適切なアクセス権を持っていることを保証するのに役立ちます。この手順では、プロセスのステップを詳述し、アクセスレビューに関するコントロールオーナー向けのガイダンスを提供します。

組織への利益

セキュリティリスクを低減する
休眠アカウントや無効化されたアカウントを特定する
必要なチームメンバーのみがシステムにアクセスできることを保証する
ロールが変更されたユーザーが、もはや関連性のないアクセス権を保持していないことを検証する
退職したチームメンバーが会社のシステムにアクセスできなくなることを保証する
顧客の信頼を維持する GitLab のコンプライアンスおよび規制要件をサポートする

範囲

対象システム

セキュリティコンプライアンスは、要因のサブセットに基づいて対象システムのアクセスレビューを実施します。以下を含みます。

起源: 外部認証への影響、Red Data System
重要度: ミッションクリティカル
Lumos コネクタが利用可能な場合のビジネスクリティカル

すべての GitLab システムとベンダー、および関連するクリティカルシステムティアの最新リストについては、テックスタックを参照してください。

対象外システム

上記の対象システム要因のしきい値の範囲外にあるシステム。一般的なベストプラクティスとして、すべてのシステムオーナーは、このプロセスをガイドとして使用し、自分が所有するシステムに対して少なくとも年次の退職者アクセスレビューを実施することを強く推奨されます。

役割と責任

役割	責任
セキュリティコンプライアンスチーム	完全な権限レビュー、特権アクセス、退職ユーザーレビューの実行特定された所見に対する観察事項の作成と是正活動の監督
IT コンプライアンスチーム	SOX 対象システムに対する完全な権限レビュー、特権アクセス、退職ユーザーレビューの実行特定された所見に対する観察事項の作成と是正活動の監督
システムオーナー	特権権限の検証ユーザー権限の検証タイムリーな証拠サポート特定された観察事項に対する是正計画の実行 * アクセス削除の実行
システム管理者	特権権限の検証ユーザー権限の検証タイムリーな証拠サポート特定された観察事項に対する是正計画の実行 * アクセス削除の実行
マネージャー	特権権限の検証をサポートユーザー権限の検証をサポート
IT 運用	* アクセス削除の実行
セキュリティアシュアランスマネジメント (Code Owners)	この手順への重要な変更や例外の承認に責任を持つ

Lumos とは何か、なぜ Okta タイルがあるのか？

Lumos は GitLab のユーザーアクセスレビューツールです。すべてのユーザーアクセスレビューを促進するために使用されます。デフォルトでは、すべてのチームメンバーはオンボーディング時に Lumos へのアクセス権を受け取ります。Lumos にアクセスするには、チームメンバーは Okta の Lumos タイルを選択できます。アクセスレビューが割り当てられた場合は、以下にリンクされているランブックに従ってアクセスレビューを完了してください。

Security and Technology Operational Risk Management (STORM) プログラム & 手順

Wed, 17 Dec 2025 08:09:08 -0600

Visibility: Audit

GitLab チームメンバーではないけれど、STORM プログラムについてフィードバックを提供したいですか?

私たちは GitLab チームメンバーから定期的にフィードバックを受けており、GitLab チームメンバー以外の方からもフィードバックを提供できる仕組みを設けたいと考え、これによりイテレーションを行い、私たちの価値観により近づくことができます。GitLab チームメンバーではなく、Security and Technology Operational Risk Management (STORM) プログラムまたはその方法論についてフィードバックを提供したい場合は、このフィードバックフォームを使用して匿名でフィードバックを送信してください。

目的

GitLab における Security and Technology Operational Risk Management（「STORM」）プログラムの目的は、GitLab の戦略を支援するために、セキュリティおよびテクノロジーの運用リスクを特定、モニタリング、治療、および報告することによって、より良い意思決定を可能にすることです。Security Risk Team は、GitLab に影響を及ぼす可能性のあるセキュリティおよびテクノロジーリスクが効果的に管理されるように、以下の手順（NIST の SP 800-39、SP 800-30 Rev. 1、および ISO 31000 Risk Management Methodology に示されたガイダンスを考慮して形成されたもの）を活用します。

範囲

STORM プログラムの範囲は、テクノロジーに依存しない運用リスクに限定されます。これらのリスクは、リスクアセスメント、チームメンバーからの報告、業界トレンド、またはコンプライアンス活動の結果など、さまざまな方法で特定できます。アプリケーションの内部統制における役割が非常に重要であるために、そのシステム専用のリスクを作成するインスタンスがある場合があります。これは、その使用がすべての活動で広く普及している GitLab.com に主に限定されます。

GitLab オフボーディング標準

Wed, 19 Nov 2025 12:25:32 -0800

Visibility: Audit

目的

これらの標準は、すべての GitLab 関連のコンピューティングリソースとデータ資産から GitLab チームメンバーをオフボーディングすることに関連する要件を規定し、当社の顧客、チームメンバー、契約者、会社、その他のパートナーを、故意および偶発的な誤用によって生じる損害から保護します。これらの標準を公開する目的は、GitLab の資産を保護することを意図した情報セキュリティ標準を概説することです。

範囲

これらの標準は、GitLab のコンピューティングリソースとやり取りし、会社または顧客データにアクセスするすべての GitLab チームメンバー、契約者、アドバイザー、契約当事者に適用されます。

役割と責任

役割	責任
GitLab チームメンバー	このドキュメントの要件に従う責任を負う
People Operations	このドキュメントを実装し実行する責任を負う
People Operations (Code Owners)	このドキュメントへの重要な変更と例外を承認する責任を負う

オフボーディング手順

オフボーディングの通知

Workday で退職するチームメンバーの直属マネージャー（自発的）または Team Member Relations（非自発的）によって退職プロセスが承認・完了されると、所定の自動化が新しいオフボーディングを検出し、指定された日の有効なオフボーディング期間内であれば Issue を開こうとします。自発的退職の場合、このプロセスはチームメンバーが Workday で直接開始した辞任プロセスに従います。

People Operations と IT Operations のニーズに沿って、予定されたオフボーディングは、Slack で月曜日から金曜日の チームメンバーの現地タイムゾーンの午後 4:00 - 5:00 の間に開かれます。

アクセスリクエスト（AR）

Wed, 19 Nov 2025 12:25:32 -0800

Visibility: Audit

アクセスリクエストは IT チームが所有し、オンボーディング、オフボーディング、内部異動リクエストは People Operations チームが所有します。

アクセスリクエストに関する質問がある場合は、Slack の #it_help またはツールのプロビジョナーにお問い合わせください。

アクセスリクエストに関連するページ

はじめに

すべてのオープンおよびクローズ済みの AR は access-requests project で確認でき、新しい Issue はこちらから作成できます。

新しい AR を作成すると、リクエストを満たすために必要な追加情報や追加の承認が必要かを正確に判断するため、さまざまなテンプレートから選択するオプションが与えられます。各 Issue タイプに必要なすべてのラベルを追加するよう努めましたが、見落としがあるかもしれませんので、送信前にリクエストを再確認してください。

利用可能なテンプレートは多数ありますが、通常以下のいずれかのカテゴリに該当します。

利用可能なすべてのテンプレートの完全なリストはこちらで確認できます

個別または一括アクセスリクエスト

個別または一括アクセスリクエストは、他のテンプレートが希望するものと一致しない場合に使用してください。

このテンプレートは、すべての人が同じシステムへのアクセスをリクエストする限り、個人または複数人のアクセスをリクエストするのに使用できます。複数人が異なるシステムへのアクセスを必要とする場合は、複数の Issue を作成してください。

アクセス変更リクエスト

アクセス変更リクエストは、チームメンバーが現在プロビジョニング済みのシステムへのアクセスを必要としなくなった場合や、同じレベルのアクセスを必要としなくなった場合（管理者からユーザーへのアクセスダウングレードなど）に記録されます。追加情報については、GitLab ハンドブックの For Total Rewards Analysts: Processing Promotions & Compensation Changes セクションを参照してください。

セキュリティ意識向上トレーニング標準

Wed, 19 Nov 2025 12:25:32 -0800

Visibility: Audit

目的

セキュリティトレーニングと意識向上は、進化する脅威、コンプライアンス義務、安全な職場慣行に関する継続的なユーザー教育活動と演習を GitLab チームメンバーに提供し、彼らの意識を磨き向上させるために重要です。

適用範囲

この標準は、GitLab の法令、規制および契約上の要件をサポートするために、GitLab データを取り扱い、管理し、保管し、または送信するすべての GitLab チームメンバー、コントラクター/Temporary Service Provider (TSP)、コンサルタント、ベンダーおよびその他のサービスプロバイダーに適用されます。

定義

GitLab チームメンバー: gitlab.com のメールアドレスを持つユーザー
コントラクター/TSP およびコンサルタント: GitLab の外部にいて gitlab.com のメールアドレスを持たず、GitLab の法令、規制および契約上の要件をサポートするために GitLab データの取り扱い、管理、保管、または送信に関わる契約/合意のもとにある人員。

役割と責任

役割	責任
GitLab チームメンバー	この標準の要件に従う責任を負う
Security Governance チーム	この標準で概説されているセキュリティトレーニングおよびプログラムの管理と実行に責任を負う
Security Governance Management	この標準の監督、エスカレーション、および例外承認に責任を負う
Security Assurance Management (Code Owners)	この標準への重要な変更および例外を承認する責任を負う

標準

すべての GitLab チームメンバーおよびコントラクター/TSP は、GitLab の General Security Awareness Training、新入社員トレーニング、および継続的なフィッシングシミュレーションとトレーニングに参加するか、暦年内に同等のトレーニング完了の証拠を提示することが求められます。参加が必要なセキュリティトレーニングには以下が含まれます。