脆弱性の修正
概要
このランブックの目的は、脆弱性の一般的なソースとタイプ、および脆弱性 finding を修復するために通常必要な作業を定義することです。 このランブックは、脆弱性 finding のソースに基づいてセクションに分かれており、さらにソースのタイプによって細分化されています。例えば、脆弱性 finding は CI パイプラインの自動化スキャンから発生することが一般的です。自動セキュリティスキャンには、コンテナスキャン、依存関係スキャン、シークレットスキャンなどの複数のサブタイプがあり、それぞれが典型的な解決ワークフローを詳述する独自のサブセクションを持っています。
ソース: セキュリティスキャナ
自動セキュリティスキャナは、GitLab における脆弱性 finding の大多数のソースです。これらは、インフラセキュリティスキャンや、コンテナイメージや公開するソフトウェアパッケージなど、ユーザーに出荷する GitLab 資産に対して実行されるスキャンに及ぶ可能性があります。
ソース: コンテナスキャナ
コンテナスキャナは、ビルド済みコンテナイメージをスキャンして、ソフトウェアコンポーネント、バイナリ、およびイメージに埋め込まれた既知脆弱性を持つコンポーネントについて OS パッケージメタデータ（RPM や .deb パッケージデータベースなど）をスキャンします。一部のスキャナは、Ruby gem、Go ライブラリ、Python モジュールなどの言語ライブラリで既知脆弱性を持ち、イメージ内にデプロイされているものも検出します。一般に、コンテナスキャン finding については、修正がリリースされている場合、検出されたコンポーネントを検出と並んで修正済みとして示されているバージョンに更新することで finding に対処でき、それ以上の作業は必要ありません。特定のコンポーネントをアップグレードすると、コンテナ内の他のコンポーネントやデプロイ済みコードと互換性がなくなる場合（例えば、GitLab の gitlab-ee または gitlab-ce イメージで GitLab に対してまだテストされていない非互換の Ruby gem バージョンなど）、複雑な事態が生じる可能性があります。これらの場合、アップグレードすると問題が発生しないことを検証するためにさらなる作業が必要となる場合があります。
タイプ: サードパーティ OS 依存関係
コンテナイメージ内に存在する OS パッケージが特定の脆弱性（例えば CVE）に対して脆弱であると finding が示される場合、次の 2 つの修復オプションのいずれかが適用されることがしばしばあります:
- ベンダーから入手したベースイメージ、またはベンダーイメージに基づくベースイメージを、最新のベンダーリリースのベースに更新します。
- ベースイメージのビルド時または対象イメージのビルド時の一部として、パッケージマネージャ（
apt、yum、またはmicrodnfなど）を使用して修正済みパッケージバージョンにアップグレードします
通常、ビルド時に該当するベースイメージのタイプでパッケージマネージャを使用してパッケージをアップグレードすることがベストプラクティスとみなされます。なぜなら、イメージが頻繁にビルドされ、ベンダーが修正済みパッケージを迅速にプッシュしている場合、このような finding がまったく検出されないことがしばしばあるからです。通常、ほとんどのベンダーから更新済みベースイメージよりも先に更新済みパッケージが利用可能になります。それらが適時に利用可能にならない場合、SLA 例外 が適切である可能性があります。distroless イメージでよくあるように、パッケージ管理がない場合、唯一の修復策は distroless イメージベンダーからベースイメージを更新するか、イメージビルドプロセスの一部として自分たちで修正済みバージョンをビルドすることかもしれません。この最後のオプションは、時間投資を考慮すると、修正が必要であり、ベンダーが修正を提供しないことを示している場合にのみ追求すべきです。
タイプ: 言語ライブラリ／依存関係
一部のコンテナスキャンツールには、言語ライブラリ（Python モジュール、Ruby gem など）の脆弱性を検出する機能や、コンパイル済み Go バイナリからパッケージ情報を抽出する機能があります。これらのスキャナは、GitLab のようにビルド済みソフトウェアがユーザーに配布されるためにビルド済みコンテナイメージとしてデプロイされる場合によくあるように、コンテナイメージに埋め込まれた脆弱なコンポーネントが検出されると、脆弱性 finding を発生させます。
サードパーティ OS 依存関係と同様に、ここでの修復は典型的には影響を受けるライブラリまたはモジュールを更新し、更新済みコンテナイメージをユーザーに出荷することです。私たちが依存するコンポーネント内の脆弱性への対処に遅延がある場合、SLA 例外 をオープンするか、脆弱ではないが類似の機能を提供する代替ライブラリを評価することが必要となる場合があります。別のライブラリへの移行の労力と、既存ライブラリで脆弱性が上流で対処される可能性、およびそれにかかる時間を比較検討すべきです。
ソース: 依存関係スキャナ
依存関係スキャナは、コンテナスキャナとは異なり、コンテナイメージやパッケージがビルドされる前のプロジェクトソースコードに直接動作します。依存関係スキャナは、言語依存関係（Python モジュール、Ruby gem など）の脆弱性を検出し、典型的には常にではありませんが、脆弱性を修復するための手順を推奨します。ほとんどの場合、これは言語パッケージマネージャを使用して修正を含む新しいバージョンの依存関係にアップグレードすることを伴い、これが脆弱性 finding を解決するために必要なすべてです。依存関係のアップグレードがプロジェクトのビルドを破壊したり、安定性や機能性の問題を引き起こす場合、新しい依存関係にアップグレードするために追加の作業が必要となる場合があります。これらの場合、代替ライブラリを使用できるかどうかを確認するか、アップグレードされた依存関係との相互運用性の問題を説明する SLA 例外 をオープンすることが適切となる場合があります。場合によっては、これらの finding はもはや必要ない、またはプロジェクトに小さな変更を加えれば削除できる依存関係を指している可能性があり、この場合、最も適切な対応は依存関係を完全に削除することかもしれません。これにより脆弱性 finding も解決されます。
ソース: SAST
SAST finding は典型的には、コードベースに脆弱性をもたらす可能性のある既知および疑わしいコードパターンを表しています。典型的には、これらの finding には特定の finding に基づく修復アドバイスが関連付けられていますが、脆弱性が検出されたコードの機能性への影響は、適切な開発グループによって評価されるべきであり、スキャナによって与えられたアドバイスを適用しても他の問題を引き起こさないことを確認するべきです。多くの場合、SAST finding に対処する複数の方法があり、それぞれが考慮すべき異なる複雑性、利点、欠点を持っています。
これに加えて、開発グループが SAST 脆弱性 finding を効果的に緩和できる新しい方法を持っている場合、ソリューションが適用された後でも、将来特定のコードパターンを無視するようにスキャナに指示する特定のコードコメントを追加することが必要となる場合があります。多くの SAST スキャナはコード内の単純なパターンや特定の言語ライブラリの使用を探し、安全なコードでも finding が生成されることがあります。
さらに、脆弱性 finding がそもそも悪用できず、finding でハイライトされたコードが脆弱でない場合、検出されたコードにコードコメント／アノテーションを追加して、将来この finding についてこのコードを無視するようにスキャナに指示することが必要となる場合があります。finding が悪用できない場合（誤検知）であり、コードコメント／アノテーションの結果として再スキャン時に finding が検出されない場合、それも許容可能な解決策です。
ソース: シークレット検出
シークレットスキャナは、認証情報、証明書、またはプロジェクトのリポジトリに直接保存されるべきでないその他の機密情報など、機密情報を表す可能性のあるデータをプロジェクト内で検出します。ほとんどの場合、適切なアクションは、シークレットを削除し、検出された証明書または認証情報をローテーションし、適切な シークレットストレージ を使用してこの情報を保存することです。プロジェクトからシークレットを削除する場合、シークレットの痕跡を削除するためにプロジェクトのバージョン管理履歴もスクラブされることを確認することも重要です。BFG Repo Cleaner のようなツールは、このプロセスを自動化するのに非常に役立ちます。
ソース: IaC スキャン
Terraform などの IaC ツールは、インフラをコードとして表現することでインフラの定義とデプロイを可能にします。IaC セキュリティスキャナは、コードが実際のインフラにデプロイされる前に、コード内の一般的なインフラ誤設定を検出します。典型的には、これらの finding には IaC が適用／デプロイされた場合に導入されるインフラ脆弱性を削除するためにコードを調整する方法に関する提案も含まれています。典型的には、これらの推奨事項は説明されているインフラのコンテキストでレビューされる必要があり、推奨事項を単に適用することは、提案された変更によってインフラに影響がないことを確認するためにレビューされるべきです。finding に記述されている影響に基づいて、検出されたインフラ脆弱性に対処する他の方法もある可能性があります。これらの finding は設定の広いコンテキストを考慮しないことがあり、設定の潜在的影響が設定済みインフラの他の部分によって緩和されている場合があるため、誤検知も検出される可能性があります。この場合、SLA 例外 が適切となる場合があります。
ソース: インフラ＆ネットワーク脆弱性スキャナ
インフラおよびネットワーク脆弱性スキャナは、内部または外部の攻撃面の観点からすでにデプロイされているインフラをスキャンし、システムまたはホステッドアプリケーションコードで検出された潜在的な脆弱性を報告します。これらのスキャナの一部は、SSH キーまたはディスクスナップショットを介してデプロイされたホストへのアクセスを持つため、典型的な外部スキャンツールよりもはるかに高いレベルの検査を提供できます。これらのスキャナによって、それらのスコープと設定に応じてさまざまな種類の finding が検出される可能性があります。このセクションは、異なるユースケースとこれらの種類の finding を修正する方法を説明するために、finding タイプに分割されています。
タイプ: サードパーティ OS 依存関係
コンテナスキャナと同様に、多くのネットワークおよびインフラスキャナは、デプロイされたワークロード（サーバー、サーバーレス、コンテナ）、コンテナイメージ、VM イメージのファイルシステム上のファイルを直接検査できます。この場合、それらはファイルシステム内の OS パッケージメタデータにアクセスして OS パッケージをフィンガープリントするか、バイナリを直接フィンガープリントします。これらのタイプの finding を修復する方法は、典型的には次の 2 つのいずれかを伴います:
- 実行中ワークロードの OS を更新（パッチ適用）して、最新の OS パッケージがインストールされ、イメージ（VM またはコンテナ）が更新されていることを確認する
- ワークロードまたはイメージから不要なパッケージを削除する
通常、ビルド時に該当するベースイメージのタイプでパッケージマネージャを使用してパッケージをアップグレードすることがベストプラクティスとみなされます。なぜなら、イメージが頻繁にビルドされ、ベンダーが修正済みパッケージを迅速にプッシュしている場合、このような finding がまったく検出されないことがしばしばあるからです。通常、ほとんどのベンダーから更新済みベースイメージよりも先に更新済みパッケージが利用可能になります。それらが適時に利用可能にならない場合、SLA 例外 が適切である可能性があります。distroless イメージでよくあるように、パッケージ管理がない場合、唯一の修復策は distroless イメージベンダーからベースイメージを更新するか、イメージビルドプロセスの一部として自分たちで修正済みバージョンをビルドすることかもしれません。この最後のオプションは、時間投資を考慮すると、修正が必要であり、ベンダーが修正を提供しないことを示している場合にのみ追求すべきです。
タイプ: 言語ライブラリ／依存関係
ワークロードに対するファイルシステムアクセスを持つネットワークおよびインフラスキャンツールは、典型的には言語固有のライブラリ依存関係およびそれらに影響を与える脆弱性も発見・フィンガープリントできます。これらの古くて脆弱なライブラリは複数のソースから来る可能性があります:
- サーバー上のデプロイ済みアプリケーションをサポートするためにインストールされたライブラリ。典型的には、これらの finding を解決するには、アプリケーション自体に finding を対処させ、その後更新版をワークロードにデプロイする必要があります。
- ワークロードを管理するために使用されるツールの一部としてインストールされたライブラリ。これには設定管理ツール、バックアップツール、診断ツールが含まれる場合があります。この場合、ツールは削除されるか、脆弱でないバージョンにアップグレードされるべきです。
- ルーチンメンテナンス中に作成されたアプリケーションまたはツールのバックアップ。これらは変更やインシデントが終わった後に忘れられがちですが、脆弱性スキャナに拾われる可能性があり、もはや必要ない場合はクリーンアップされるべきです。
タイプ: シークレット検出
ネットワークおよびインフラスキャンツールは、しばしば 2 種類のシークレットを検出できます:
- デプロイ済みワークロードのファイルシステム上に保存されたシークレット。これらはアプリケーションの機能のために必要かもしれませんし、必要でないかもしれません。必要なシークレットが検出されたか、本物の誤検知の場合、SLA 例外 が適切となる場合があります。それ以外の場合、シークレットは削除され、サポートされているシークレットストレージおよび管理ツール に保存されるべきです。
- デプロイ済みアプリケーションによって露出されたシークレット。典型的には、アプリケーションエンドポイントがシークレットを露出している場合、これは意図しないものであり、シークレットがもはや露出されないようにアプリケーションを修正して再デプロイする必要があります。アプリケーションがサードパーティツールである場合、または問題が迅速に対処できない場合、エンドポイントへのネットワークアクセスを制限することも適切な回避策または緩和策となる場合があります。
bfd74782)