アプリケーション脆弱性管理手順

目的

この手順は、GitLab 製品またはその依存プロジェクトで特定された脆弱性に適用され、脆弱性管理標準 の実装を保証します。この手順は、私たちの環境への洞察を提供し、健全なパッチ管理やその他の予防的なベストプラクティスを促進し、リスクを是正することを目的に設計されています——すべては、私たちの環境と製品をより安全にするという最終目標に向かっています。

範囲

ここで示されている手順は、GitLab 製品またはその依存プロジェクトで特定された脆弱性に適用されます。

範囲内の Issue

バックログレビュー用に定義された期間中に、bug::vulnerability のラベルが付いた Issue がレビューされます。

以下は範囲内になりうるものの非網羅的なリストです。

• GitLab (gitlab-org/gitlab)
  • HackerOne
  • bug::vulnerability
• Gitaly
• Pages
• Runner
  • HackerOne
  • bug
• Shell
• Customers
• GitLab Dedicated

役割と責任

手順

脆弱性報告

脆弱性報告には多くのソースがありますが、最終的には常に GitLab 上の Issue になります。

ソースの一部:

• HackerOne レポート: 関連プロジェクトの GitLab Issue としてインポートされます (HackerOne プロセス を参照)
• ユーザーまたは顧客: 多くの場合、[email protected] または ZenDesk 経由で送信されます (HackerOne または GitLab Issue トラッカーへリダイレクトされます)
• 妥当なスキャナーの検出: 脆弱性レポートページから直接インポートされます (このドキュメント を参照)
• GitLab リポジトリで作成されたコンフィデンシャル Issue: 通常、ユーザー、顧客、または GitLab チームメンバーによって作成されます

プロダクトチームの巻き込み

Issue が作成されると、セキュリティエンジニアが正しい ~group:: および ~devops:: ラベルを設定し、影響を受ける機能を所有するチームのエンジニアリングおよびプロダクトマネージャーに @ メンションを行います。

セキュリティエンジニアは、git blame 機能を使用して、最後にコードを変更した人物に基づいてグループを見つけたり、#development Slack チャンネルで尋ねたりすることができます。

時には受け取ったグループが正しいグループではないこともありますが、セキュリティエンジニアとそのグループは協力して、再アサインに適切なグループを見つけることができます。~group:: を判別できない場合は、~devops:: ラベルだけで十分です。この場合、セキュリティエンジニアはその Issue を当該ステージのディレクター/Sr. EM にアサインするべきです。

ある Issue が脆弱性ではなく、セキュリティ強化と判断された場合、それは公開され、~"type::feature" ラベルが付けられ、優先順位付けは他の通常の Issue と同様にプロダクトチームに委ねられます。(脆弱性 vs. 機能 vs. バグ？ を参照)。脆弱性については、セキュリティエンジニアが ~severity:: および ~priority:: ラベルを設定し、それらが Issue の期日と SLO を決定します。これはハンドブックのプロダクトセキュリティのメインページ に記載されています。

レポートが ~severity::1 のレポートである場合、SIRT とリーダーシップを巻き込むための特別な手順があります。

脆弱性の修正

GitLab Web アプリケーションおよび Omnibus パッケージにバンドルされている他のすべての製品の脆弱性は、パッチリリースプロセス に従って修正されます。GitLab には 2 種類のセキュリティリリースがあります: 通常の月次リリースと、~severity::1 の Issue が報告されるたびに行われるクリティカルセキュリティリリースです。詳細については、メインのプロダクトセキュリティハンドブックページのセキュリティリリース セクションを参照してください。

セキュリティ強化として扱える可能性があり、セキュリティリリースプロセスをスキップできる脆弱性に取り組んでいる場合は、お気軽に @gitlab-com/gl-security/product-security/appsec にピンを送ってください。

独立したリリースサイクルに従い、月次の GitLab セキュリティリリースに合わせていない GitLab 製品も、セキュリティ修正を開発し、それを顧客に開示するためのプロセスを持つ必要があります。GitLab パッチリリースプロセス または以下の推奨される最低限のプロセスのいずれかに従うことができます:

• 脆弱性と修正が公開可能になる前に開示されないよう、セキュリティ Issue を公開で修正しないでください。セキュリティ Issue に取り組むには、プライベートなSecurity グループ 配下のセキュリティミラープロジェクトを使用してください。製品がプライベートプロジェクトでメンテナンスされている場合は、そのプロジェクトで直接修正を行えます。
• AppSec チームにセキュリティ修正をレビューしてもらいます。
• 製品が顧客自身のインストール用にリリースされている場合、AppSec チームに修正された脆弱性の CVE リクエストを作成するよう要請します。
• セキュリティ修正について顧客に通知 します。
• 開示ポリシー に従ってセキュリティ Issue を開示します。

公開での修正

アプリケーションセキュリティチームは、セキュリティ Issue を全部または一部公開で対処することについて、承認を与えることがあります。公開の Issue や MR には、機密のままにすべき情報を絶対に含めてはいけません。また、公開で修正されたセキュリティ Issue にはバックポートは必要ありません。アプリケーションセキュリティエンジニアは次のことを行うべきです:

• まず、Issue 全体を再分類 して公開できるかどうか評価します。
• 次に、特定の作業項目に対して公開のリンク済み Issue を作成することを検討します。
• 最後に、Issue を機密のままにする必要があり、追加 Issue の作成も望まない場合は、何が公開でできて何が機密のままにすべきかを明確に実装提案として更新し、~"security-fix-in-public" ラベルを追加します。

セキュリティチームは、機密 Issue を参照する公開 MR からの意図しない情報開示を監視しており、このプロセスに従わない公開ブランチや MR を削除します。

GitLab ユーザーへの通知

修正された脆弱性はセキュリティリリースのブログ投稿 で言及されており、メールまたは RSS で通知を受け取る ことができます。

セキュリティリリースプロセスの外で処理された Issue は、プロダクトマネージャーが適切と判断した場合、通常のリリース投稿で言及される可能性があります。

GitLab 製品で修正されたセキュリティ Issue は、月次の GitLab セキュリティリリースと一緒にリリースされる場合のみ、セキュリティリリースのブログ投稿で言及される可能性があります。セキュリティリリースのブログ投稿で言及される必要があるすべてのセキュリティ Issue は、~"upcoming security release" Issue にリンクされていることが期待されます。リンクが不可能な場合は、セキュリティリリースマネージャー に連絡し、セキュリティリリースのブログ投稿にセキュリティ Issue を含めるよう依頼してください。

独立したリリースサイクルに従い、月次の GitLab セキュリティリリースに合わせていない GitLab 製品は、新しいリリースのセキュリティ修正に関する詳細を公開するために、プロジェクトリポジトリ内の CHANGELOG.md ファイルや別のセキュリティアドバイザリファイルを利用できます。

バックログレビュー

アプリケーションセキュリティチームは、製品に存在する脆弱性が正確に反映されていることを確認するため、脆弱性バックログのレビューを行います。これらのレビューの頻度は、コンプライアンス要件に基づいて、またはチームによって決定されます。このプロセスは、開いている Issue がまだ妥当か、クローズできるか、リスク受容の対象になるかを判断することを意図しています。

ラベル

スコープ付きラベルが各 Issue を分類するのに使用されます。ラベルは次のとおりです:

• ~security-backlog::valid
• ~security-backlog::closed
• ~security-backlog::reclassified
• ~security-backlog::risk-acceptance
• ~security-backlog::needs-input
• ~security-backlog::review-complete

Issue レビュープロセス

各 Issue について、その分類を判断する必要があります。以下は、AppSec エンジニアが適切なカテゴリーと取るべきステップを判断するために従うべきガイドラインです。

レビュー完了

~security-backlog::review-complete ラベルは、フィルタリングと追跡を支援するため、レビューされた Issue に適用するべきです。

妥当 (Valid)

Issue は、製品にまだ存在する脆弱性である場合、valid です。

• ~security-backlog::valid ラベルを適用します

クローズ済み (Closed)

Issue は、すでに修正されている、別の Issue の既知の重複である、または製品の進化により関連性がなくなったと判断された場合、closed です。

• ~security-backlog::closed ラベルを適用します
• 判断した理由を述べるコメントを残し、Issue をクローズします。
  • 重複の場合: /duplicate <#issue> スラッシュコマンドを使って Issue をクローズします

再分類 (Reclassified)

Issue は、製品の進化、私たちの脅威モデル、または Issue に関する理解に基づいて、~type::feature、~type::maintenance、または非セキュリティの ~type::bug と見なすことができる場合、reclassified です。以下の脆弱性 vs. 機能 vs. バグ の質問を参考にしてください。

• ~security-backlog::reclassified ラベルを適用します
• セキュリティエンジニアにより割り当てられている場合は重大度と優先度を削除します
• 次のいずれかを行います:
  • ~type::bug ラベルを削除し、適切なラベルを適用します。
  • ~security ラベルを削除します。
• 再分類の理由を述べるコメントを残します。
• Issue に機密情報がないかをレビューし、可能であれば公開します。

リスク受容が必要 (Needs Risk Acceptance)

リスク受容の対象となる Issue の一般的なガイドラインを以下に示します。完璧な公式はないので、エンジニアの判断に委ねられます。

• 長期間存在し、修正の見込みがほとんどない
• 影響なく公開できるか？
  • ~“Seeking community contributions” のラベルを付けることができるか？
• ユースケースに基づいて、プロダクトマネージャーが ~security::reclassified として ~"type::maintenance" にできるか？（例: ゲストユーザーが X の数を見ることはできるが、個々の X を見ることはできない）
• S3/P3 以下か？

Issue がリスク受容の対象となる場合:

• なぜその Issue がリスク受容の対象として検討されるべきかを述べるコメントを追加します
• ~security-backlog::risk-acceptance ラベルを適用します
• セキュリティが脆弱性管理標準のリスク受容（例外） に従います

インプットが必要 (Needs Input)

AppSec エンジニアが適切なカテゴリーを判断できない場合、Issue は needs input です。

• ~security-backlog::needs-input ラベルを適用します

脆弱性 vs. 機能 vs. バグ？

Issue（特に S4/P4）を受け取ったり再分類したりする際、それが脆弱性、強化、またはバグであるかを判断するのが難しい場合があります。役立つ可能性のある質問をいくつか挙げます:

• 悪用可能で、GitLab のシステムやデータの機密性、完全性、または可用性に影響を与える可能性があるか？それに対して CVSS スコア を作成できるか？ 脆弱性
• 同様の Issue が脆弱性として扱われており、それは依然として理にかなっているか？ 脆弱性
• Issue は、セキュリティや多層防御を改善する新しいものを導入しているか？ 強化 （おそらく ~type::feature）
• 該当する機能は設計どおりに動作しているが、セキュリティや多層防御を改善するためにそれを洗練しているか？ 強化 （おそらく ~type::maintenance）
• 該当する機能は設計どおりに動作していないが、セキュリティ上の影響はなく、CVSS を作成できないか？ 非セキュリティの バグ
• 現在サポートされているどのバージョンでも、GitLab が悪用可能な方法で使用していない脆弱な依存関係やコードを削除しているか？（「理論上の」/ 悪用不可の脆弱性）。 強化 （おそらく ~type::maintenance）

不明な場合は、慎重を期して、Issue を脆弱性として扱ってください。エンジニアリング作業タイプ分類 のページもガイドとして役立つかもしれません。

AppSec レビューからの Issue 作成

AppSec レビュー の結果として Issue を作成する際、レビューを行うエンジニアは正しいラベルを設定し、Issue を適切なグループにアサインする責任があります。Issue 作成時の適切な分類は、PSIRT による不必要なトリアージ作業を減らし、Issue がより速く適切なチームに届くことを保証します。

ラベル付けとアサイン

1. 上記の脆弱性 vs. 機能 vs. バグ？ ガイダンスを使って Issue タイプを判断します。
2. Issue に type:: ラベルを設定します:
   • 実証可能なセキュリティ影響を持つ悪用可能な脆弱性であれば、~"type::bug" と ~"bug::vulnerability"。
   • 新しいセキュリティ改善や多層防御策を導入する場合は、~"type::feature"。
   • セキュリティを改善するために既存の機能を洗練する、または実際には悪用できない依存関係を削除する場合は、~"type::maintenance"。
3. 責任あるグループに Issue をアサイン し、彼らのバックログに直接届くようにします。

Issue が確認された ~"bug::vulnerability" （多層防御の強化ではない）である場合、レビューを行うエンジニアは、十分なコンテキストがある場合に CVSS スコア を提案するべきです。スコア付けに自信がない場合は、PSIRT チームに任せてください。

実験的およびベータ機能の Issue

実験的またはベータ 段階の機能は、CVE を必要とせず、是正の SLA/SLO もありません。AppSec によってレビューされる機能のほとんどがこれらの初期段階にあるため、この区別は非常に重要です。

実験的またはベータ機能の検出事項について:

• Issue を ~"bug::vulnerability" としてラベル付けする場合は、必ず ~securitybot::ignore ラベルも適用してください。これにより、Issue が PSIRT のトリアージにルーティングされないようにし、セキュリティボットが Issue に SLA/SLO を付けるのを防ぎます。
• リスクの評価に基づいて、~severity:: および ~priority:: ラベルを 自分で設定します。
• 責任あるエンジニアリンググループに Issue を直接アサイン します。
• 標準の脆弱性是正 SLO は適用されません。これらの機能のセキュリティ修正は、セキュリティリリースではなく、通常 (canonical) リリースでリリースされる可能性があります。

機能の成熟度ステージを判断するには、関連機能について GitLab Development Stage Support documentation を確認してください。

セキュリティ強化はいつ脆弱性にエスカレートされるか？

関連リスクを効果的に緩和するための適切な対策が確実にとられるよう、次のいずれかの条件が満たされた場合、セキュリティ強化は脆弱性にエスカレートしなければなりません:

• 別の脆弱性と組み合わさることで、Critical または High 重大度のセキュリティ Issue やインシデントにつながる証拠が示された場合
• その Issue が実環境で活発に悪用されている証拠がある場合

パッチ後の CVSS 更新

時折、リリースが行われた後に、AppSec チームでの議論によりバグとその CVSS をより深く理解できるようになることがあります。Issue の重大度が Critical に引き上げられる場合は、S1/P1 プロセス に従ってください。それ以外の場合:

• 適切に HackerOne のレポートを更新し、追加の金額を授与します
• cves-private プロジェクトで MR を作成して CVE レコードを更新し、@gitlab-org/vulnerability-research をメンションします
• セキュリティリリースのブログ投稿を更新する MR を作成します
• 適切であれば、トリアージや是正プロセスの改善に向けた MR を特定し、開きます

例外

脆弱性管理標準のリスク受容（例外） を参照してください

参考資料

• 脆弱性管理標準
• インフラ脆弱性管理手順
• Bug Bounty

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