本文の内容は、2023年1月25日にEDUARDO MÍNGUEZ が投稿したブログ（https://sysdig.com/blog/end-to-end-vulnerability-scanning)を元に日本語に翻訳・再構成した内容となっております。
脆弱性のスキャンはベストプラクティスであり、セキュリティ攻撃を防ぐためにアプリケーションのライフサイクルで必ず行うべきステップです。また、このステップをどこで行うかも重要ですが、なぜでしょうか？Sysdigを使った脆弱性スキャンの詳細について説明します。
アプリケーションのライフサイクルには、開発者のワークステーションでコード行の形をした芸術作品を作るところから、Webアプリケーションやモバイルアプリケーションなど、お客様が使用する最終的な本番環境まで、多くの段階があります。脆弱性は、これらのどのステップにおいても入り込む可能性があるため、環境を破壊しないように何らかの障壁を設けることが強く推奨されます。
“defense in depth” のコンセプトでは、アプリケーションのライフサイクルの異なるステップで（時にはオーバーラップして）自動脆弱性スキャンを実行することを推奨しています。これにより、本番環境に持ち込まれる脆弱性の数を減らすことができます。Sysdig Secureがお手伝いします。
Sysdigの脆弱性管理は分散型で、アプリケーションのライフサイクル全体を柔軟に統合する一方、ポリシーを定義したりレポートを作成するための集中型ガバナンスを提供します。また、脆弱性のフィードバックループを常に提供し、修正に必要なすべてのコンテキストを開発者に分かりやすい方法で提供します（どのパッケージとバージョンを更新する必要があるか）。
開発
開発者用ワークステーションから始めましょう。 IDE、CLIツール、ヘッドフォン、そして好みの音楽。あなたは、自分の好きな言語を使って、素晴らしい新しいアプリケーションを作っています。この創造的なプロセスにおいて、あなたはゼロから始めるのではなく（それは意味がありません）、サードパーティのフレームワークやライブラリに依存し、同時に他のサードパーティのフレームワークやライブラリに依存し、さらに、他のサードパーティのフレームワークに依存し、さらにその上にも依存しているのです。 作業中のコード部分が完成したら、おそらくそれをコンテナとしてパッケージングしたいと思うでしょう。これが最近のアプリケーションをデプロイする標準的な方法だからです。しかし、PR (pull request) をサブミットする前に、念のためコードをコミットする前にローカルでデプロイを実行してみたいものです。sysdig-cli-scanner はバイナリで、ダウンロードしてワークステーション（x86_64 か arm64、Linux、OSX のいずれか！）で実行すると、依存関係にある既知の脆弱性についてコンテナイメージをスキャンしてくれます。このように簡単です：
OS=$(uname -s | tr "[A-Z]" "[a-z]")
VERSION=$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)
ARCH="arm64"
curl -sL "https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/${VERSION}/${OS}/${ARCH}/sysdig-cli-scanner" -o ~/bin/sysdig-cli-scanner
pushd ~/bin/
shasum -a 256 -c <(curl -sL "https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/${VERSION}/${OS}/${ARCH}/sysdig-cli-scanner.sha256")
popd
SECURE_API_TOKEN=<your-api-token> ~/bin/sysdig-cli-scanner --apiurl <sysdig-api-url> <image-name>
例えば、OSX 12を使用するM1（arm64）Appleハードウェア上でSysdigのダミー脆弱性アプリケーションを使用してSysdigで脆弱性スキャンを実行すると、次のようになります：
SECURE_API_TOKEN="xxx" ~/bin/sysdig-cli-scanner --apiurl https://eu1.app.sysdig.com sysdiglabs/dummy-vuln-app 2022-12-12T15:24:24+01:00 Starting analysis with Sysdig scanner version 1.3.0-rc 2022-12-12T15:24:24+01:00 Retrieving MainDB... 2022-12-12T15:24:24+01:00 Done, using cached DB 2022-12-12T15:24:24+01:00 Loading MainDB... 2022-12-12T15:24:24+01:00 Done 2022-12-12T15:24:24+01:00 Retrieving image... 2022-12-12T15:24:35+01:00 Done 2022-12-12T15:24:35+01:00 Scan started... 2022-12-12T15:24:36+01:00 Uploading result to backend... 2022-12-12T15:24:36+01:00 Done 2022-12-12T15:24:36+01:00 Total execution time 12.564334s Type: dockerImage ImageID: sha256:b670c067178c876d17363baec279d483ae07384351d1a0be7646230442471ac6 Digest: sysdiglabs/dummy-vuln-app@sha256:bc86e8ba5741ab71ce50f13fbf89a1f27dc4e1d3b0c3345cee8e3238bc30022b BaseOS: debian 9.13 PullString: sysdiglabs/dummy-vuln-app 13 vulnerabilities found 2 critical (0 fixable) 5 high (2 fixable) 6 medium (5 fixable) 0 low (0 fixable) 0 negligible (0 fixable) PACKAGE TYPE VERSION SUGGESTED FIX CRITICAL HIGH MEDIUM LOW NEGLIGIBLE EXPLOIT pip python 9.0.1 19.2 0 2 1 0 0 0 numpy python 1.12.1 1.19.0 0 1 3 0 0 0 pyxdg python 0.25 0.26 0 1 0 0 0 0 Jinja2 python 2.11.2 2.11.3 0 0 1 0 0 0 POLICIES EVALUATION Policy: Sysdig Best Practices FAILED (8 failures - 0 risks accepted) Policies evaluation FAILED at 2022-12-12T15:24:36+01:00 Full image results here: https://eu1.app.sysdig.com/secure/#/scanning/assets/results/173011d6ffadaa53ba8fce6259100c40/overview (id 173011d6ffadaa53ba8fce6259100c40)いくつかの事実を強調しておきましょう。
- 実行時間の合計は12秒ですが、スキャンは1秒しかかかっていません。
2022-12-12T15:24:35+01:00 Scan started... 2022-12-12T15:24:36+01:00 Uploading result to backend... 2022-12-12T15:24:36+01:00 Done
- どのパッケージが脆弱で、どのような修正が提案されているかという情報もすべてここで見ることができます。
PACKAGE TYPE VERSION SUGGESTED FIX CRITICAL HIGH MEDIUM LOW NEGLIGIBLE EXPLOIT pip python 9.0.1 19.2 0 2 1 0 0 0 numpy python 1.12.1 1.19.0 0 1 3 0 0 0 pyxdg python 0.25 0.26 0 1 0 0 0 0 Jinja2 python 2.11.2 2.11.3 0 0 1 0 0 0スキャン結果はSysdigのURLでも観察することができ、同じ結果をより詳細に（そしてきれいな色で！）見ることができます。
SysdigのUIでは、発見された脆弱性の詳細が表示されます。
影響を受けるパッケージとバージョン
評価されたポリシー
そして、特定のイメージに関する詳細も表示されます。
linux/arm64コンテナイメージをサポート。
CI/CD
ライブラリの依存関係を更新することによって、すでにこれらの脆弱性をすべて修正し、PR が提出されたと仮定しましょう。ビルドチェーンの次のステップは、CI/CD パイプラインを実行して、アプリケーションをビルドし、コンテナイメージをビルドし、いくつかのテストを実行し…そして再び脆弱性をチェックすることです。待ってください、何ですか? なぜまた？- プルリクエストをサブミットする前に、すべての開発者がワークステーションでローカルに脆弱性スキャンを行ったと、誰が保証できるでしょうか？
- もし開発者が数日前にスキャンを実行して、新しい脆弱性が見つかっていたらどうするのでしょう？
しかしそれだけでなく、CI/CDスキャンでは、以前のステップで使用したものとは異なるポリシーを使用することができます（脆弱性ポリシーについてはこちらをご覧ください）。コンテナイメージのベストプラクティス、例えばrootとして実行しないなどはどうでしょうか？あるいは、PCI Auditのポリシーはどうでしょうか？”My company baseline” ポリシーはどうでしょうか？
本番ワークロードのゲートとして、開発レベルでSysdigによる脆弱性スキャンを実行し、CI/CDでさらにいくつかの制限を実施することができます。
異なるポリシーを切り離し、ソフトウェアサプライチェーンの異なるステップで実行することができます！ sysdig-cli-scanner の使用方法は、チェックしたいポリシーの –policy フラグを追加するのと同じくらい簡単です。
前に説明したように、sysdig-cli-scanner は事実上あらゆる CI/CD システムで実行することができ、それはただ一つのバイナリに過ぎません。もっと知りたい方は、Jenkins（ヒント：Jenkinsにはすでに公式プラグインがあります）、GitHubアクション、GitLab CI/CD、Azure Pipelinesなどの人気ツールと統合する方法をいくつか例示しています。
「Log4jの最新情報が出たとき、お客様から「どんな影響があるのか」という問い合わせがありました。私たちは、コンテナの脆弱性を迅速にスキャンすることができ、何か問題があればすぐに知ることができました。Sysdig Secureを使用することで、5分以内に潜在的なリスクを知ることができたのです。」 Sam Brown Director, Information Security, Expel
レジストリ
CI/CDパイプラインで既にポリシーが施行されているので、本来ならCI/CDの最後のステップはコンテナイメージをコンテナレジストリにプッシュするはずです。では、なぜレジストリレベルで再びコンテナイメージをスキャンするのでしょうか？ それは、”決して信用せず、常に検証する “というゼロ・トラスト・セキュリティ・モデルに従うためです。もしCI/CDがバイパスされ、誰かがコンテナイメージを直接プッシュしたとしたらどうでしょう？数週間前にスキャンされたイメージはどうでしょうか？最後のスキャン以降に新しい脆弱性が発見されたのでしょうか？ しかし、それだけではありません。サードパーティのコンテナ・イメージはどうでしょうか？企業環境では、アプリケーションに必要なコンテナイメージがサードパーティ（SQLデータベース、イベントストリーミングプラットフォーム、インメモリデータベース、ウェブサーバなど）から提供され、内部のコンテナレジストリにミラーリングされているエアギャップアーキテクチャーがかなり一般的になっています。これらのイメージはCI/CDパイプラインをバイパスしますが、それでも脆弱性スキャンを実行する必要があります。 Sysdigはコンテナレジストリスキャンをサポートしており、定期的に、あるいは新しいコンテナイメージをレジストリにプッシュするなどのイベントに基づいて、すべてのコンテナイメージをスキャンします。 スキャン結果は、SysdigのWebインターフェースの「Vulnerabilities」→「Registries」セクションで確認できます。
レジストリ・スキャンは現在、「Controlled Availability」フェーズにあります。お試しいただく場合は、Sysdigの担当者にお問い合わせください。
ランタイム
すべてのガードレールが整い、コンテナイメージはレジストリに安全に保存されました。Sysdigエージェントは、Kubernetesクラスターで稼働しているコンテナイメージの脆弱性スキャンも行います。問題は、その理由です。 何よりもまず、本番環境で稼働しているコンテナイメージを洞察することは非常に有効です。稼働していないコンテナイメージに影響を及ぼす脆弱性を見つけた場合、本番環境で実際に稼働しているコンテナイメージと比較して、その修正はそれほど緊急ではありません。 しかし、それだけではありません。“in-use” exposureに基づく優先順位付け
Sysdigエージェントは、（カーネルモジュールまたはeBPFアプリケーションを介して）カーネルレベルの計測を行い、Linuxのすべてのシステムコールを観察します。これは、実行中のプロセス、開かれたファイル、ネットワーク接続を含む、ボンネットの下で起こるすべてのことを識別できることを意味し、コンテナ内でどのプロセスが活発に実行されているか、どのライブラリが使用されているかを判断することができます。この素晴らしい機能を脆弱性スキャン機能と連携させることで、使用されている脆弱なパッケージを特定することができ、理想的には、それらを最初に修正することができます。これは私たちが ”Risk Spotlight”と呼んでいるもので、お客様のフィードバックに基づいて、最大で95%の脆弱性がノイズとみなされることを発見しました。Sysdigランタイムスキャナーは、デフォルトで新しい脆弱性管理エンジン（
nodeAnalyzer.secure.vulnerabilityManagement.newEngineOnly=true パラメータを使用）でデプロイされ、“Risk Spotlight” は公式ドキュメントに従って、Helmチャートを使用してSysdigエージェントをデプロイするときに nodeAnalyzer.runtimeScanner.settings.eveEnabled=true パラメータを設定すれば簡単に有効化できるようになっています。
ホストスキャン
侵害されたコンテナイメージはまずい状態です。 脆弱性や脅威者の能力によっては、他のコンテナや最悪の場合、ホスト自体への横移動が行われる可能性があります。幸いなことに、コンテナのセキュリティ分離メカニズムにより、このようなシナリオは稀です（不可能ではありません）。しかし、ホストを直接侵害することは、さらに悪いことです。脅威者がホストを侵害できた場合（もちろん、侵害のレベルにもよりますが）、そのホスト上で動作するほぼすべてのコンテナにアクセスできるようになります。 そのため、コンテナホストをスキャンすることも重要です（「ゼロトラスト」を覚えていますか）。Sysdigエージェントは、情報の停滞を避けるため、12時間ごとにこの手順を実行します。先に示したように、脆弱性スキャンの手続きは数秒しかかからないので、やらない手はありません。 Sysdigの脆弱性管理は、最も一般的なLinux OSをサポートしており、クラウドやイメージベース/イミュータブルOS（Google Container-Optimized OS（COS）、RHCOS、Flatcarなど）であっても対応可能です。基本的に、それらはボンネットの下でパッケージングシステム（RHCOSならrpm-ostree、FlatcarならGentooのebuilds）を使うので、チェックするSBOMが存在することになります。また、Java、Golang、Pythonパッケージなど、多くの種類のパッケージがサポートされています。 ホストスキャンは、デフォルトでsysdig-deploy Helm chart version 1.5.0+ と HostScanner container version 0.3.0+ を使ってデプロイされ、同じ Sysdig Web インターフェイスの Vulnerabilities -> Runtime セクションで、ホスト資産の種類で結果をフィルタリングして公開されます。
レポート作成
Sysdigのレポート機能を利用することで、セキュリティチームはどのコンテナやホストが脆弱で、どこで稼働しているかを迅速に確認することができます。レポートは、最も重要なものに焦点を当てるためにフィルタを適用して生成され、どの脆弱性が異なるチームやイメージに影響するかを理解し、修正できるようにするために有用です。 以下のスクリーンショットは、悪名高い Log4J CVE-2021-44228 に対して脆弱な実行中のイメージのレポートが、毎日午前9時に私たちの受信トレイに送られてきたものです。
また、”demo-kube-aws” クラスターに属する Debian ホストの CVSS スコア > 7 の脆弱性を含むレポートもあります。
リスクをアクセプトする
脆弱性を認識しているが、修正する優先順位が低い場合 (使用されていない、あるいは依存関係がすぐに削除される予定である) はどうしたらよいでしょうか。あなたはそれを「リスクを受け入れる」ことができます リスクを受け入れると、脆弱性ポリシーの例外が発生します。それはまだリストに表示されますが、そのCVEに関連するポリシー違反を無効にします。 以下のような異なるコンテキストに基づいて、リスクを受け入れることができます。
- Global: CVEをグローバルに受け入れる
- Container image or host: 特定のコンテナイメージまたはホストに対して CVE を受け付けます。
- Package: 特定のパッケージ（またはパッケージ＋バージョン）に対してCVEを許可する。
「受け入れる範囲やコンテキストに注意してください。過度に広い例外は偽陰性を生み出す可能性があります。」リスクの受け入れは、”Accept risk” を選択し、フォームに詳細を入力するだけです。
Policies -> Risk Acceptanceセクションには、すでに期限切れになったものも含め、すべてのリスク受容が表示されます。
すっきりしましたね。