Skip to main content

Snykのコンテナセキュリティ調査と相対的重要度への取り組み

2020年12月14日

0 分で読めます

コンテナの脆弱性への対処は簡単ではありません。Linuxセキュリティとコンテナイメージのアーキテクチャの両方を理解する必要があります。コード内で発生する可能性のある脆弱性を除けば、コンテナで対処する脆弱性の大半は、Linux OSパッケージとその依存関係に関するものです。しかし、コンテナを扱うのは通常、OSのメンテナンスを専門としていない開発者であり、これらのパッケージは、サーバー上で稼働するOS全体にパッチを適用する場合のようには更新されません。そこで、コンテナの脆弱性の優先順位付けと修正をより分かりやすくする新機能「相対的重要度」を発表します。

コンテナセキュリティにおける相対的重要度とデータの完全性

相対的重要度とは、セキュリティチームがコンテナパッケージの脆弱性の深刻度を評価する方法です。Snyk ContainerでDebianまたはUbuntuベースのコンテナイメージをスキャンしたことがあれば、すでにこの情報を確認できます。今後、さらに多くのディストリビューションのデータを追加する予定です。簡単に言うと、各ディストリビューションのメンテナーやセキュリティ研究者による評価を取り入れ、Snyk Containerの脆弱性評価に反映するものです。Linuxパッケージの脆弱性には通常NVDによる評価が付与されますが、ディストリビューションごとにリリースの構築・保守方法が少しずつ異なるため、脆弱性のあるパッケージに対するメンテナーのリスク評価が異なる場合があります。これを相対的重要度と呼んでいます。

下の例では、元のNVD評価で深刻度がHIGHとなっているコンテナの脆弱性を確認できます。しかし、対象のコンテナはDebianパッケージを使用しています。Debianディストリビューションにおける_bash_shellの扱い方を踏まえ、Debianのメンテナーはこの脆弱性をUNIMPORTANTと分類しています。Snykの評価では低深刻度に相当し、深刻度評価(左上)に反映されるほか、右側に表示された優先度スコア(321)の算出にも使用されます。

権限の放棄に関する不適切なチェックのコンテナ脆弱性の詳細。深刻度は低く、エクスプロイトは成熟段階にあり、セキュリティスコアの要因が表示されています。

この新機能を有効にするための操作は不要です。現在、Snyk UIとCLIの両方で利用でき、Snyk Containerが脆弱性に最も適した評価を自動的に使用します。以下はCLIのJSON出力を一部抜粋したもので、severity、nvdSeverity、および relativeImportanceが表示されています。

各フィールドの仕組みは次のとおりです。

  • relativeImportance - ディストリビューションのメンテナーがトリアージを行い、評価を割り当てている場合、その深刻度評価が表示されます。Snykはディストリビューションによる評価が最も正確だと考えているため、利用可能な場合はこの深刻度を表示します。ただし、ディストリビューションによってトリアージする脆弱性の数や種類は異なります。このデータがない場合はnvdSeverityを使用します。

  • nvdSeverity - 脆弱性に元々割り当てられているNVDの深刻度です。ディストリビューションが脆弱性をトリアージ済みの場合、このフィールドは最も正確性が低いものです。通常、NVDに基づく厳格なSLAを設けている組織や、CVSSスコアと深刻度の一致が必須の組織にのみ役立ちます。表示されている深刻度の背景を把握できるよう、脆弱性レポートにこのデータを表示しています。ディストリビューション固有の評価がない場合は、この深刻度が表示されます。

  • severity - Snykが実際に表示する深刻度です。ディストリビューションによるトリアージが行われ、relativeImportanceの評価がある場合は、その評価を使用するため、severityはrelativeImportanceと同じ値になります。ディストリビューションが脆弱性をトリアージしていない場合は、nvdSeverityを使用します。これにより、ディストリビューションが独自のデータを公開していないという理由で、深刻度が高または重大の問題を見逃すことはありません。

APIまたはJSON出力を利用する場合は、基本的にデフォルトのseverityフィールドを使うことをおすすめします。コンテナイメージに最も正確な深刻度を提示できるよう、Snykが必要な処理を行うためです。追加フィールドを使えば、特定の深刻度とスコアが異なる理由を把握するための情報を得られます。一方で、こうしたフィールドを別の方法で活用するニーズを持つお客様もいらっしゃいます。

{
      "title": "Improper Check for Dropped Privileges",
      "credit": [
        ""
      ],
      "packageName": "bash",
      "language": "linux",
      "packageManager": "debian:9",
.
.
.
      "severity": "low",
      "cvssScore": 7.8,
      "CVSSv3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:F",
      "nvdSeverity": "high",
      "relativeImportance": "unimportant",
      "from": [
        "docker-image|purpledobie/blog@demo",
        "bash@4.4-5"
      ],
      "name": "bash",
      "version": "4.4-5"
}

コンテナの脆弱性に関するSnykの調査プロセスを詳しく見る

新しいrelativeImportanceデータは、お客様に代わってSnykのセキュリティ調査チームが尽力していることの一例です。脆弱性を調査し、お客様にとって有用なセキュリティ情報を提供するにあたり、私たちは次の4つの要素を重視しています。

  • 網羅性:単一の脆弱性データソースにとどまらず、複数のソースからデータを集約し、独自の一次調査で情報を補完する

  • 適時性:関連するすべてのデータを迅速にまとめ、エンドユーザーが利用できるようにする

  • 正確性:誤検知と見逃しを減らし、時間の浪費や重要なリスク要因の見落としを防ぐ

  • 実用性:Snykはセキュリティチームと開発者の両方が利用するソリューションですが、見つかった問題を最終的に修正するのは、通常、開発者です。調査結果の提示方法を検討する際には、常にこの点を考慮しています。

コンテナの脆弱性に対処するには、Linuxとコンテナの世界を隅々まで理解し、エンドユーザー(通常は開発者)に関係する情報を抽出して、コンテナのビルドやメンテナンスの工程で活用できる形にする必要があります。Snykでは、セキュリティ調査チームがこうした大変な作業を担い、お客様の負担を軽減します。Snykに無料登録して、コンテナのセキュリティを強化しましょう。

開発者ファーストのコンテナセキュリティ

Snykは、コンテナイメージとKubernetesワークロードの脆弱性を検出し、自動的に修正します。

続きを読む

feature customer snowflake
Article

開発初期からセキュリティを確保:Snowflake Cortex Code向けSnyk Studioインテグレーションを発表

Snyk StudioがSnowflake Cortex Codeと連携し、開発中にAI生成コード、依存関係、コンテナの脆弱性をスキャンします。

blog feature pypi spoof
Article

オープンソースのメンテナーに、Snyk AI Security Platformをすべて無料で提供

オープンソースのメンテナーは、実際の脆弱性レポートに追われ、優先順位付けや修正、修正版のリリースを迅速に進めるための支援を必要としています。SnykのSecure Developer Programでは、条件を満たすプロジェクトにSnyk AI Security Platformを無料で提供します。

feature insights announcement
Blog

Node-gypサプライチェーン侵害:binding.gypに潜む自己増殖型npmワーム

新たなnpmワームがbinding.gypを悪用し、インストール時にnode-gypを起動。ライフサイクルスクリプトを使わずに悪意あるパッケージからコードを実行します。認証情報を窃取し、GitHub上に潜伏し、メンテナー間で自己増殖します。