アプリケーションセキュリティテスト、Vulnerability Research

ミッション

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

優先事項

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

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

GitLab の既存のセキュリティ製品の結果の品質を分析および改善する:
- 業界標準またはカスタムベンチマークに対して現在の品質を評価する。
- 品質向上に必要な作業の種類を特定する。
- 検出の有効性を向上させるための新しい検出ルールの作成または既存の検出ルールのキュレーション。
GitLab のセキュリティプロダクトカテゴリの成熟度を高めるためのリサーチ実験を実施する:
- プロダクトグループと協調・調整した短期的な取り組み。
- Application Security Testing ステージのリーダーシップと協調・調整した長期的な取り組み。
GitLab 依存関係スキャンおよびコンテナスキャンで使用される GitLab Advisory Database を管理・発展させる。
CVE Numbering Authority（CNA）の職務を遂行する。GitLab は CNA です。

共通リンク

Slack チャンネル: #g_ast-vulnerability-research
GitLab グループ: gitlab-org/secure/vulnerability-research

Vulnerability Research チーム

チームメンバー情報は原文 (英語) を参照してください。

働き方

アイデア出し

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

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

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

優先度付け

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

プロトタイプ

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

ビルドとリリース

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

メトリクス

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

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

ルール更新

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

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

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

ルールの重大度:
- 高重大度のルールは顧客のワークフローを妨害する可能性が高い。
- 誤検知（見逃し）の結果は、より高重大度の脆弱性を報告できない場合に特に懸念される。
不正確または欠落したファインディングによるルールに関する顧客のエスカレーション
誤検知率に焦点を当てたベンチマーク結果とプラットフォーム全体のデータ分析

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

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

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

ステータス Open - Issue はまだ検証も優先度付けもされていない。Vulnerability Research（VR）は 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 のアサインされた人がこの状態を設定する