脆弱性管理の自動化
脆弱性管理は、この標準と関連する手順を可能な限り自動化することを目指す自動化ツールを保守しています。私たちは常に、GitLab とユーザーの安全を保ちながら、すべての関係者の時間を節約する方法をイテレーションしています。
VulnMapper
VulnMapper は、脆弱性管理が使用する主要な自動化ツールです。これはクローズドソースのツールで、セキュリティプロセスの自動化と、Product Security の dogfooding ゴールの一環として、機能を GitLab に組み込むことを目標としています。
VulnMapper の機能
VulnMapper の主要な機能は以下の通りです:
- インフラ、コード、設定セキュリティの所見ソースから脆弱性を取り込み
- GLAD を含むアドバイザリソースから脆弱性メタデータを取り込み
- 脆弱性アドバイザリと所見の正規化と関連付け
- 脆弱性の解決にフォーカスした追跡 Issue を GitLab に作成
- 一般的な SLA 例外シナリオの自動処理
既知の制限事項
現在の Issue と制限事項は 非公開の VulnMapper Issue トラッカー で追跡されています。現時点での主要な制限事項のいくつかは以下の通りです:
- コンテナの修正情報はパッケージベースの所見情報ほど信頼性が高くなく、その結果、パッケージベースの修正利用可能性ラベルの方が信頼できると見なされる
- RHEL/UBI 以外の OS、または依存関係/言語パッケージの所見については、アドバイザリと修正利用可能性情報が利用できない
サポートされている OS
vulnmapper はすべての所見をサポートすることを目指していますが、脆弱性に関連するパッケージの修正の利用可能性を判定するには、アドバイザリと関連する修正利用可能性に関する高品質なデータソースが必要です。
vulnmapper で修正利用可能性追跡をサポートしている現在のベース OS および対応するベースイメージのリストは以下の通りです:
- Red Hat Enterprise Linux 7, 8, 9
- Red Hat Universal Base Image (UBI) 7, 8, 9
これらのサポートされている OS の所見のみが、パッケージ修正が判定され、関連する GitLab 脆弱性追跡 Issue にラベル付けされます。
現在 Debian と Alpine の修正利用可能性の追加に取り組んでおり、サポートしてほしい他のベース OS パッケージタイプについては、チームメンバーが Issue を起票することを歓迎します。
GitLab で使用される脆弱性自動化に関するフィードバックや改善のアイデアについては、チームメンバーが Issue を起票 できます。さらに、GitLab チームメンバーがイメージや環境をオンボーディングしたい場合や、脆弱性自動化について話したい場合は、Slack（#g_security_vulnmgmt）で連絡するか、こちら の（非公開）トラッカーに Issue を作成してください。
プロバイダー
VulnMapper は、GitLab を含む外部システムと統合するためのプロバイダーモデルを使用しています。プロバイダーは、アドバイザリ情報の取り込み（NVD、Red Hat、Ubuntu などのソースから）、脆弱性検出の取り込み（GitLab スキャン、Wiz、AWS Inspector などのソースから）、追跡プロバイダーでの追跡 Issue の自動作成または更新（現在は GitLab Issue を使用）などのタスクを含む、VulnMapper データベースへのデータ投入や操作を担当します。
Issue の作成
現在 GitLab では、特定のグループが、自分たちが出荷する資産における脆弱性所見の追跡 Issue のトリアージと作成を VulnMapper に自動的に処理してもらうようにオプトインしています。現在これに含まれているのは:
- Distribution（CNG イメージを含む）
- Runner
- Application Security Testing チーム
これらのグループに対して、VulnMapper は GitLab を使用して関連するコンテナイメージのスキャンを自動的に実行し、関連するアドバイザリ情報の正規化と関連付けの後、修正のために正しくラベル付けされた追跡 Issue を GitLab に作成します。作成された Issue でトリアージと修正作業を行うチームメンバーは、標準脆弱性管理ラベルページ を参照すべきです。適用されたラベルと Issue の説明から、Issue が実行可能かどうかが明確になるはずです。通常、これらの Issue は、更新されたパッケージまたはイメージが利用可能な場合、所見を解決するためにパッケージまたはベースイメージの更新を必要とします。利用できない場合は、Issue にそのラベルを付け、優先度を下げることができます。
注記: VulnMapper のデフォルト動作は、修正が利用可能な脆弱性に対してのみ追跡 Issue を作成します。修正が利用可能になると、これがピックアップされ、Vulnmapper が追跡 Issue を作成します。
Issue のクローズ
以下の状況では、VulnMapper はチーム効率を向上させるために追跡 Issue を自動的にクローズします。
- 依存関係のベンダーが修正を利用可能にしないことになり、Deviation Request が自動的にオープンされた場合
- GitLab またはその他のサポートされている VulnMapper プロバイダーでリンクされた脆弱性所見が解決またはディスミスされた場合（プロジェクトに対して Issue クローズが有効になっている場合）
Issue クローズは現在、以下のグループで有効になっています:
- Distribution（CNG イメージを含む）
- 本番インフラの所見（Wiz により検出）
- Dedicated インフラの所見（AWS Inspector により検出）
Deviation Request の自動化
GitLab の FedRAMP コンプライアンスと SLA 例外プロセスの一環として、VulnMapper が使用するデータソースが、ベースライン (NVD) の脆弱性影響と、コンポーネントのベンダーが評価した影響（重大度）との違いを示している場合（リスク調整）、またはベンダーによる評価が修正は提供されないことを示している場合（運用要件）、運用要件およびリスク調整の Deviation Request が VulnMapper によって自動的に作成されます。これらのケースでは、Deviation Request Issue が自動的に投入・作成され、修正が利用できない場合は、脆弱性追跡 Issue にラベルが付けられ、この Deviation Request にリンクされた後、Issue はチームメンバーが対応できないものとしてクローズされます。この自動プロセスが行われるのに、チームメンバーの操作は必要ありません。
c955a93f)