Content last updated 2026-02-26

Security Capabilities Engineering

Security Capabilities Engineering チームチャーター

組織構造

Security Capabilities Engineering は、3 つの相補的なチームで構成されています:

Vulnerability Management

  • フォーカス: 脆弱性検出、ワークフロー自動化、リスクの可視化
  • 主な成果物: 自動トリアージ、スキャンカバレッジ、お客様向けアーティファクト、FedRAMP 自動化

Product Security Incident Response Team (PSIRT)

  • フォーカス: 脆弱性トリアージ、調整された是正と開示、セキュリティリリース
  • 主な成果物: バグバウンティプログラム管理、バリアントハンティング、調整された脆弱性是正、セキュリティリリースの調整

Product Security Engineering (ProdSecEng)

  • フォーカス: セキュリティ自動化、製品への貢献、ツール統合
  • 主な成果物: セキュリティ機能、プロセス自動化、カスタムツールのメンテナンスと移行

ミッションステートメント

Security Capabilities Engineering は、お客様の信頼を構築するために、協力的なプロセス、データインサイト、自動化を通じて GitLab を支えます。私たちは Product Security のフォース・マルチプライヤーとして、脆弱性インテリジェンスを実用的なインサイトに変換し、スケーラブルなセキュリティ機能を作成し、GitLab が高速にセキュアなソフトウェアを出荷できるようにするプロセスとツールを確立します。

価値提案

私たちは、包括的な脆弱性ライフサイクル管理、スケーラブルな自動化ソリューション、データ駆動型のセキュリティインサイトを提供します。これにより、GitLab のエンジニアリングチームは自信を持ってセキュアなソフトウェアを構築・出荷でき、お客様は透明性が高くタイムリーなセキュリティ情報を受け取り、Product Security チームは手動運用ではなく価値の高い戦略的イニシアティブに集中できます。

戦略的ビジョン

Security Capabilities Engineering は、3 つの重要な機能の交差点で活動します:

  • 意思決定を支えるデータインサイト: 脆弱性データを実用的なインテリジェンスと透明性のあるお客様向けアーティファクトに変換する
  • スケールする製品ファースト自動化: GitLab のセキュリティを GitLab で確保することを支援するセキュリティ機能を構築し、お客様が採用する前にソリューションを検証する
  • 他者を支援するプロセス: 標準化された文書化済みのワークフローを確立し、セキュリティライフサイクル全体で一貫性と効率性を生み出す

スコープと責任

主な所有領域

Security Capabilities Engineering は、GitLab 全体のエンドツーエンドの脆弱性ライフサイクルと、それを支える自動化を所有しています:

脆弱性インテリジェンスとライフサイクル管理

  • 検出と相関: GitLab がホストする環境、アーティファクト、関連するサプライチェーンを横断する包括的な脆弱性スキャン
  • トリアージとアセスメント: 脆弱性の深刻度、悪用可能性、ビジネスへの影響の技術的評価
  • 是正調整: Engineering チームと協力したセキュリティ修正の優先順位付けと検証
  • 調整された開示: バグバウンティプログラムと責任ある脆弱性開示の管理

セキュリティ自動化とエンジニアリング

  • Product Security ツーリング: スケーラブルな Product Security 運用を可能にする専用自動化の開発と保守
  • セキュリティ機能拡張: GitLab のリスクを軽減し、お客様のセキュリティ機能を拡張する製品への貢献
  • ツール統合と廃止: カスタムセキュリティツールの GitLab 製品機能への移行

データとメトリクス

  • 脆弱性メトリクスとレポート: セキュリティ態勢の可視化のための戦略的および運用メトリクス
  • コンプライアンスアーティファクト: コンプライアンス向けセキュリティドキュメントの自動生成
  • リスクコミュニケーション: GitLab 全体の戦略的意思決定に役立つデータ駆動型のナラティブ

インターフェースポイント

内部セキュリティチームとのコラボレーション

  • Application Security (AppSec): ナレッジ共有、インシデント時の専門的な製品知識
  • Security Platforms & Architecture (SPA): 悪用可能性 POC の開発、Product Security Risk Register (PSRR) の整合
  • Infrastructure Security: クラウド／インフラ脆弱性のトリアージ、Wiz 統合
  • Security Operations (SecOps): インシデントサポート、脅威検出 IOC/POC の開発
  • Security Assurance: コンプライアンスアーティファクト

Engineering と製品とのコラボレーション

  • Development チーム: GitLab における脆弱性 Issue、是正の協働
  • 製品チーム: セキュリティ機能の早期エンゲージメント、ユーザーストーリーの検証、ツール統合計画
  • Release Management: セキュリティパッチの調整、バージョン互換性のアセスメント

外部ステークホルダー

  • お客様: 透明性のある脆弱性開示、セキュリティアドバイザリ、コンプライアンスアーティファクト
  • セキュリティ研究者: HackerOne プログラム管理、調整された開示プロセス
  • セキュリティコミュニティ: 公開開示の調整、業界ベストプラクティスの共有

スコープ外

Security Capabilities Engineering が所有していないもの:

  • 機能セキュリティレビューと脅威モデリング (AppSec が所有)
  • インフラとクラウドセキュリティアーキテクチャ (InfraSec が所有)
  • エンドユーザーシステムの脆弱性とパッチ適用 (CorpSec が所有)
  • 直接的な脆弱性是正 (Engineering が所有)
  • セキュリティコンプライアンスプログラム (Security Assurance が所有)
  • GitLab セキュリティ製品機能 (Sec セクションの製品チームが所有)

オペレーティングモデル

コアプロセス

脆弱性ライフサイクルワークフロー:

  1. 検出: Wiz、Trivy、カスタムツールを使用した環境横断の自動スキャン
  2. 相関とエンリッチメント: VulnMapper が検出結果を正規化し、コンテキストデータを付与
  3. トリアージ: 脆弱性タイプとチームの専門性に基づく分散モデル
  4. 是正: Engineering との調整、GitLab Issue を通じた追跡
  5. 検証: 修正が完了し、バイパスできないことの確認
  6. 開示: セキュリティリリース、CVE、アドバイザリを通じたお客様コミュニケーション

自動化開発:

  1. インテイクと評価: 自動化基準と製品適合性に対するリクエストの評価
  2. ユースケースのドキュメント化: 明確な問題ステートメントと成功基準
  3. 製品との整合: GitLab 製品ビジョンとの適合性の評価
  4. 開発: GitLab ワークフローラベルに従った反復開発
  5. 検証: セキュリティチームのステークホルダー (Customer Zero) によるテスト
  6. ハンドオフ: 適切な製品チームまたは運用保守への移行

メトリクスとレポート:

  1. データ収集: VulnMapper、GitLab Issue、HackerOne からの自動取得
  2. 分析: コンテキストエンリッチメントとトレンド特定
  3. ステークホルダーコミュニケーション: 異なるオーディエンス向けにテーラーされたレポート
  4. 継続的改善: プロセスと優先事項を洗練させるためのフィードバックループ

作業トラッキング

データは私たちのチームにとって重要です。私たちは以下を確認するためにデータが必要です:

  • 適切なタイプの作業 を計画・優先順位付けすること（ミッションを進め、オペレーティングモデルの目標達成を支援するため）
  • BAU/KTLO の責任を満たし、重要な土壇場のリクエスト（つまり計画外の作業）に対応するために、マイルストーンの途中でも作業の余地を作って引き受けること
  • 作業のスコープとサイジングを正確に行うこと（四半期と戦略目標を効果的に設定できるように）
  • リスク、依存関係、ブロッカーを早期に提起すること（プロアクティブに管理できるように）
  • ステークホルダーに進捗の可視性を提供すること

3 つのチーム全体で一貫してこれを測定できるようにするため、Security Capabilities Engineering は以下の作業トラッキングプラクティスを採用しています:

トラッキング次元スケール／ラベル何を測定するかなぜ
計画期間製品マイルストーン作業を計画する頻度Product と Engineering のステークホルダーと作業を整合させるため、製品マイルストーンを使用して計画します
優先度priority::1 (緊急)
priority::2 (高)
priority::3 (中)
priority::4 (低)		作業の緊急性と重要性;
目標解決時間枠		重要なセキュリティ作業に最初に対応し、ステークホルダーの期待を設定し、チーム間でマイルストーンと期日を整合できるようにします
作業計画Unplanned ラベルマイルストーン計画後に追加された作業;
計画／計画外キャパシティ比率		プロアクティブな作業をリアクティブな BAU/KTLO の責任とバランスさせ、中断の発生源を特定して将来の混乱を最小化するのに役立ちます
サイジングと工数Weight: 1, 2, 3, 5, 8
(フィボナッチ数列)		必要な複雑度と工数;
チームのキャパシティとベロシティ		マイルストーンと四半期計画を正確にし、計画／計画外作業の % の追跡を支援し、作業を管理可能なピースに分解する必要がある時を特定するのに役立ちます

これらのプラクティスの詳細は以下にまとめられています。

適切なタイプの作業

私たちのチームの作業は、チームによって異なる複数のソースからもたらされます。一般的に、「適切な」タイプの作業のバランスを取る際は、常に以下を考慮します:

  • 作業が会社の目標と整合しているか
  • 作業が戦略的能力開発と整合しているか
  • 作業が GitLab 製品機能の構築とフィードバック提供と整合しているか
  • 作業が戦略的目標とクリティカルプロジェクトと整合しているか
  • 作業が、お客様および GitLab に対する責任とコミットメントを果たすために BAU および／または時間的制約があるか

優先度

個々の Issue の優先度を反映するために、標準の GitLab Engineering の priority スコープラベル を使用します。具体的なユースケースは以下の通りです:

優先度重要性意図ユースケース
~"priority::1"緊急チームのキャパシティ制限に関係なく、できるだけ早く対応します。目標解決時間は 30 日です。セキュリティインシデント、活発な悪用、P1 脆弱性、本番ブロッカー
~"priority::2"高これに早く対応し、次の数リリースでチームからキャパシティを提供します。60～90 日以内に解決される可能性が高いです。重要なセキュリティ改善、P2 脆弱性、計画されたセキュリティ機能
~"priority::3"中これに対応したいですが、他の優先度の高い項目があるかもしれません。90～120 日以内に解決される可能性が高いです。標準的なセキュリティ作業、技術的負債、P3 脆弱性
~"priority::4"低いつ対応するかの可視性はありません。タイムラインは指定されていません。あれば良い改善、ドキュメント、軽微な拡張

優先度はマイルストーン計画中に EM が決定し、会社全体のクリティカルプロジェクト、ステークホルダーリクエスト、お客様コミットメント、リスク評価、チームのニーズによって決定されます。

計画外の作業と中断

計画が決定された後にマイルストーンに追加された Issue や MR には既存の ~Unplanned ラベルを使用します。これは、マイルストーンの任意の時点で実施できる作業であるか、チームが直ちに切り替える必要のある作業（緊急中断）であるかに関係ありません。

これは、計画／計画外キャパシティの割合が適切であるかを判断し、遅れた作業項目の発生源や理由を特定する（将来最小化したり、より良い期待値を設定できるように）ために重要です。

サイジングと見積もり

Issue の重みを設定するために、標準の(修正された) フィボナッチ数列スケール を使用します。これにより、複雑度に基づいて作業完了に必要な工数とリソースを追跡できます。

Weight複雑度時間見積もりユースケース
1簡単、可能な限り単純な変更; 副作用がないことに自信がある1 日ドキュメント更新、シンプルな設定変更またはバグ修正
2小、ある程度のテストが必要だが複雑なものではない; 要件をすべて理解している1～2 日小さなバグ修正、軽微な機能追加
3中程度、ある程度の時間と協働が必要; コードフットプリントは大きいが、要件は明確2～3 日標準的なセキュリティレビュー、いくつかのファイル／テストに影響する機能作業
5複雑、終わらせるためにかなりの時間と協働が必要; 要件は理解されているが、進める中で対処すべきギャップがある可能性が高い3～5 日セキュリティアーキテクチャ変更、複雑な統合
8非常に複雑、作業開始前に高レベルの調査と研究が必要; コードベースの大部分に関与し、要件を理解するために多くの人からの入力が必要5～10 日主要なセキュリティイニシアティブ、大規模リファクタ
13+分割が必要、より小さな Issue に分解するN/A

これにより通常、マイルストーンあたり（チームメンバーごと）約 20 weight の作業項目になり、他のコミットメント（休暇、祝日、G&D など）に基づいて減少します。この一定の割合（60～80%）はマイルストーン開始前に計画され、残りの weight キャパシティは計画外、リアクティブな作業のためにマイルストーン中に割り当てられます。

マイルストーンキャパシティは時間見積もりによって主に決定されますが、私たちのチームは作業の優先順位を付ける際に複雑度のレベルも考慮します。たとえば、マイルストーン中に複数の複雑な作業項目にコミットすることは、ギャップや追加の作業が必要であることが判明し、時間見積もりが増加する可能性があるため、高いリスクを伴います。私たちのチームは、各マイルストーンで最大 weight 制限内で複雑度のバランスを取ることに焦点を当てています。

コミュニケーションチャネル

GitLab:

  • それぞれのチームプロジェクトの Issue トラッカー
  • セキュリティ修正に関する MR レビューとコラボレーション
  • チーム横断の戦略的イニシアティブの Epic トラッキング
  • @gitlab-com/gl-security/product-security/vulnerability-management (Vulnerability Management)
  • @gitlab-com/gl-security/product-security/psirt-group (PSIRT)
  • @gitlab-com/gl-security/product-security/product-security-engineering (ProdSecEng)

Slack:

  • #security_help - セキュリティ質問とリクエストのプライマリチャネル
  • #security-discuss - より広範なセキュリティ討議とナレッジ共有
  • @vulnerability-management - VM チームの Slack ハンドル
  • @psirt-team - PSIRT チームの Slack ハンドル
  • @product-security-engineering - ProdSecEng チームの Slack ハンドル

FY27 イニシアティブ

  • データを戦略的資産として活用する
  • 統一された脆弱性ライフサイクルを確立する
  • 製品ファーストのマインドセットを構築する
最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License