Content last updated 2025-01-30

Security との協働

各種セキュリティ関連チケットと、Security チームへの通知のためのエスカレーションプロセスを文書化しています。

概要

以前、GitLab はセキュリティ関連の懸念を報告および問い合わせるためにメールアドレス [email protected] を使用していました。しかし、GitLab とセキュリティ部門が成長・拡大するにつれて、その単一のキューを使って顧客が期待する高水準のサービスを提供することが難しくなりました。[email protected] に連絡したユーザーは、各種セキュリティ上の懸念を報告するための具体的な指示を含む自動返信を受け取るようになりました。自動応答が質問に答えられない場合、またはセキュリティ関連のチケットがサポートに送信された場合は、マクロ Security::All Security Questions を使用して、ユーザーに詳細な指示を提供できます。

ワークフロー

以下については、security に転送 せず、関連するワークフローを参照してください:

Security::All Security Questions マクロを使用して、文言の詳細をさらに確認することもできます。上記のワークフローおよびマクロで顧客の懸念が解決されない場合は、#sec-fieldsecurity Slack チャンネルにチケットへのリンクを投稿してください。

トリアージワークフロー

脆弱性の開示は、もはや ZenDesk 経由でトリアージされません。判断に迷う場合は、Application Security チームを関与させてください。

  • レポートが Informative であるか、または ~“type::feature” の場合、申請者に自分で Issue を起票するよう依頼できます。「General -> Ask to create an issue」マクロから始めることができます。
  • レポートが有効なセキュリティ Issue のように見える場合、または判断に迷う場合:
    • Severity が ~severity::1 である可能性がある、またはその他の理由で即時調査が必要な場合:
    • それ以外の場合は、報告者に返信して以下のいずれかを希望するかを確認します:
      • HackerOne 経由での報告
      • セキュリティ Issue 作成手順に従って、自分で confidential Issue を作成
      • チームメンバーに Issue を作成してもらい、承認の希望を返信してもらう。
      • レポートのタイムリーな処理を確実にするため、3 営業日以内に応答がない場合は、GitLab チームメンバーが Issue を作成することを報告者に知らせてください。

セキュリティ更新またはパッチに関する情報リクエスト

時には顧客がリリースされたセキュリティ更新の詳細を要求することがあります。たとえば、「これを心配すべきですか？このパッチは何についてですか？」など。

特定バージョンの GitLab CVE のサマリーは、Customer Success の “What’s New Since” ツールで利用できます。

顧客がリリースの一部として公開されたセキュリティ脆弱性について尋ねている場合、提供できる情報はセキュリティブログ投稿に記載されているもののみです。 セキュリティコミュニケーションの詳細については、セキュリティインシデントコミュニケーションページを参照してください。

Security は、設定された日数の経過後、可能であれば Issue を公開します。

ブログ投稿、または特定の顧客に対してより多くの情報を提供すべきだと考える場合は、security communication tracker で confidential Issue を起票してください。

注: 確認された緩和戦略は通常、セキュリティブログ投稿に追加されます。 記載されていない場合、Issue が修正されているバージョンへのアップグレードのみが推奨されます。 （機能の無効化など）一部の提案は Issue を緩和するように見えるかもしれませんが、セキュリティチームの検証なしには完全な確実性は持てません。

Responsible Disclosure Policy に従い、セキュリティ Issue の報告については以下を参照してください。

セキュリティスタッフ向けの一般的なガイドライン

  1. セキュリティチームのすべてのメンバーは、オンボーディングの一環として Light Agent リクエストプロセスを行い、これらのアカウントを使用して内部コメントを行うべきです。チケットへの返信やステータス変更が必要な場合は、1Password の共有アカウントを使用してください。
  2. 関連する ZenDesk、HackerOne、GitLab Issue は、適切で利用可能な場合に内部コメントで常に相互リンクします。GitLab Issue 内の ZenDesk リンクは “GitLab internal only” として注記する必要があります: Reported via ZenDesk (GitLab internal only): https://gitlab.zendesk.com/.../xxxxx
  3. メールで直接応答する場合、Light Agent アカウントから ZenDesk への返信メールは内部ノートとしてのみ処理され、申請者には送信されないため、申請者のメールアドレスを宛先に含める必要があります。
  4. 直接メールを送信する場合、チケットを “Solved” または “Pending” に設定する責任、または設定権限のある人を見つける責任があります。

顧客がすでに Issue を作成している場合

顧客がすでに脆弱性に関する Issue を起票している場合:

  1. Issue を confidential としてマークします

  2. security、customer、および bug または feature proposal ラベルを追加します

  3. Severity と Priority ラベルを割り当てます

顧客がまだ Issue を作成していない場合

新しいセキュリティ Issue の作成を参照してください。

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