Threat Research グループ

Threat Research グループは、 Security Factory ステージの一部です。FY27 の Sec 再編前は Vulnerability Research という名称で、group::vulnerability research ラベルは group::threat research になりました。

ミッション

私たちのミッションは、GitLab のセキュリティ機能を長期的なビジョンに向けて前進させ、セキュリティコミュニティにおける GitLab の存在感を高めることです。セキュリティリサーチの実施、GitLab のセキュリティ機能の有効性向上、概念実証の開発、論文の公開、カンファレンスでの講演、セキュリティの専門知識と実践的な経験の広範な共有を通じてこれを実現します。

優先事項

Threat Research（VR）はリサーチ＆ディベロップメントチームです。THR は GitLab のビジネスに貢献するため、プロダクトグループと協力して GitLab のセキュリティ製品を改善します。高度なセキュリティは GitLab Ultimate の収益の主要な推進力です。

私たちの優先事項は次のとおりです。

1. GitLab の既存のセキュリティ製品の結果の品質を分析および改善する：

   • 業界標準またはカスタムベンチマークに対して現在の品質を評価する。
   • 品質向上に必要な作業の種類を特定する。
   • 検出の有効性を向上させるための新しい検出ルールの作成または既存の検出ルールのキュレーション。

2. GitLab のセキュリティプロダクトカテゴリの成熟度を高めるためのリサーチ実験を実施する：

   • プロダクトグループと協調・調整した短期的な取り組み。
   • Application Security Testing ステージのリーダーシップと協調・調整した長期的な取り組み。

3. GitLab 依存関係スキャンおよびコンテナスキャンで使用される GitLab Advisory Databaseを管理・発展させる。

4. CVE Numbering Authority（CNA）の職務を遂行する。GitLab は CNAです。

共通リンク

• Slack チャンネル：#sec-threat-research
• GitLab グループ：gitlab-org/secure/vulnerability-research

Threat Research チーム

働き方

アイデア出し

• 改善のタイプ：DevSecOps 採用、収益、セキュリティ品質／有効性、コスト、効率性
• プロダクト志向：このアイデアからプロダクトが最も恩恵を受けられる方法は？
• 評価基準：進捗と成功をどのように測定するか？
• レビュアー：Application Security Testing プロダクトマネージャーとエンジニアリングマネージャー
• 公開の可能性：この作業を発表、ブログ投稿、または特許申請できるか？
• 追跡：gitlab-org/gitlab の Issueに group::threat research ラベルを使用し、SSOTとする

これらのタイプのイニシアチブは、イニシアチブの性質に応じて threat research::initiative ラベルを使用して追跡されます。

• プロダクト関連のイニシアチブは threat research::initiative::product で追跡される
• 独立したリサーチ関連のイニシアチブは threat research::initiative::independent で追跡される

優先度付け

• 成功率：短期的な取り組みと長期的な取り組みのバランスを取る
• タイミング：POC プロジェクトは常に短期または長期のプロダクトビジョンと一致させ、最終的にそれを引き継ぐプロダクトチームと協議して開発し、その予想される引き渡し時期を共同で理解しておく必要があります。
• 公開：公開情報のソースとして使用できる可能性

プロトタイプ

• タイムボックス：短期的な取り組みは 3 か月以内に継続するかどうかを判断できる成熟度に達すべきです。長期的な取り組みの期間は 6 か月以内です。
• お客様と見込み客：プロトタイプの検証を支援するためにチーム外の人材を特定する（PM および UXR との調整を含む）

ビルドとリリース

Threat Research 担当者のトッププライオリティは、必要に応じて、機能が GitLab で利用可能になるまでエンジニアリングチームをサポートすることです。次の焦点は、ブログ、講演などの形で公開情報を発信することです。

メトリクス

現在取り組んでいるメトリクス：

• 報告されたルールの誤検知率 - 進行中
• アドバイザリーデータベース更新の平均公開時間 - 検討中
• 新しい CVE 公開への平均対応時間 - 検討中

ルール更新

グループはルールセットの精度と再現率の向上に焦点を当てています。前者は誤検知を減らすことで、後者は偽陰性（見逃し）を減らすことで達成します。

不正確さ（誤検知）または見逃し（偽陰性）を報告するには、新しいヘルプリクエスト Issueを開いてください。

私たちはプロダクトマネジメントの方向性に基づいてルールの更新と追加を優先します。これには次のような要因を考慮した最大のお客様価値が含まれます。

1. ルールの重大度：

   • 高重大度のルールはお客様のワークフローを妨害する可能性が高い。
   • 偽陰性（見逃し）の結果は、より高重大度の脆弱性を報告できない場合に特に懸念される。

2. 不正確または欠落したファインディングによるルールに関するお客様のエスカレーション

3. 誤検知率に焦点を当てたベンチマーク結果とプラットフォーム全体のデータ分析

1 から 4 の範囲の priority ラベルを適用して作業を優先します。前者が最高優先度、後者が最低優先度です。

ワークフローラベルの使用

チームは Issue に次のワークフローラベルを使用しています。

• ステータス Open - Issue はまだ検証も優先度付けもされていない。Threat Research（THR）は PM と必要に応じて協力して優先度を付け、workflow::ready for development ラベルを追加する
• workflow::refinement - Issue は開発準備のためにチームからのさらなるインプットが必要
• workflow::ready for development - Issue はリサーチャーが作業を開始できる状態
• workflow::in dev - リサーチャーが作業中で、Issue に自分自身をアサインし、このラベルを追加している
• workflow::blocked - 外部依存関係によりこの Issue の作業を続けられない。Issue に協力している誰でも設定でき、通常はアサインされた人。このコメントを使用する際は、Issue がブロックされている理由を記載するか、ブロックしている Issue をリンクする
• workflow::in review - Issue に関連する MR が選ばれたレビュアーによってレビュー中。開発が完了したら Issue のアサインされた人がこのラベルを適用する
• workflow::complete - Issue に関連するすべての MR がマージされた。Issue のアサインされた人がこのラベルを設定する
• ステータス：Closed - Issue に関連する MR がお客様に利用可能なリリースに組み込まれた。Issue のアサインされた人がこの状態を設定する

ページのソースコードを見る - ページの編集 - please contribute.