アプリケーション脆弱性管理のベストプラクティス
2024年8月6日
0 分で読めますアプリケーション脆弱性管理は長年にわたり、チーム間でセキュリティ責任を共有するDevSecOpsに欠かせないものでした。
しかし、開発手法の進化に伴い、セキュリティチームには、開発者の既存のワークフローに合わせて対応することが求められています。たとえば、コンテナ化、Infrastructure as Code（IaC）、AIコーディングアシスタント、サードパーティーコードへの依存の高まりは、一般的な開発ライフサイクルで当たり前のものになりました。これらの手法は10年前には存在しなかったため、セキュリティチームは時間をかけてこうした「新しい常識」に適応してきました。
適応するために、セキュリティチームは従来の手法と新しい手法のバランスを取る必要がありました。多くの場合、実績のある手法は今も有効ですが、今日の開発者のソフトウェア構築方法の変化に対応する新しいプラクティスで補う必要があります。
脆弱性管理もその一例です。長年にわたって活用され、現代のセキュリティ対策において重要な役割を担っていますが、チームはほかのベストプラクティスも取り入れて補完する必要があります。
この記事では、アプリケーション脆弱性管理の基本、つまりその概要や限界、そして急速に進化する今日のSDLCで効果を高めるベストプラクティスについて解説します。
アプリケーション脆弱性管理とは
アプリケーション脆弱性管理とは、アプリケーションの脆弱性を特定、分類、修正、軽減するための包括的なアプローチです。脆弱性管理の主な要素は次のとおりです。
アプリケーションのライフサイクル全体を通じて脆弱性を特定する。
特定した脆弱性の性質、深刻度、潜在的な影響を把握するために、分類して分析する。
パッチの適用、設定の変更、回避策となる制御の実装によって、特定した脆弱性を修正・軽減する。
脆弱性管理のプロセスと結果をすべて報告し、文書化する。
新たな脅威に適応できるよう、組織のアプリケーションを継続的に監視・レビューする。
これらの手順を大規模に実施し、改善するために、大規模な組織では次のようなエンタープライズ脆弱性管理の手法も活用できます。
構成管理データベース（CMDB）、パッチ管理システム、セキュリティ情報イベント管理（SIEM）システムなどのエンタープライズ管理ツールを活用する。
スキャン、脅威評価、パッチの適用、レポート作成などの主要な業務を自動化する。
高度な脅威インテリジェンスデータベースを活用する。
組織全体の脆弱性データを一元的に把握する。
脆弱性管理のベストプラクティス2選
チームは、いくつかの方法で脆弱性管理をアプリケーションセキュリティの取り組みに活用できます。AppSecの効果を高めるために、脆弱性管理をうまく活用する2つのベストプラクティスをご紹介します。
可能な限り自動化する
新たな脆弱性や更新が大量かつ頻繁に発生するため、手作業で管理するのは負担が大きく、ミスも起こりやすいうえ、どの組織にとっても現実的ではありません。自動化すれば人的ミスを減らし、脆弱性管理のプロセスを迅速化できるため、セキュリティ担当者はより戦略的な業務に専念できます。
自動化に適した領域には、次のようなものがあります。
Snykのように、定期的なスキャンを実行できるツールを使った脆弱性スキャン。
Microsoft IntuneやSolarWinds Patch Managerなどのツールを使ったパッチ管理。
適切なチームメンバーへのリアルタイムアラートの送信など、レポート作成と監視。
自動化によってプロセスを迅速化し、人的ミスのリスクを減らせますが、自動化ツールのルールを適宜更新するには、引き続き人による監督が必要です。
開発者が脆弱性管理に参加できるようにする
前述のとおり、アプリケーションセキュリティを成功させるにはDevSecOpsが不可欠です。開発チームが脆弱性管理に参加しやすくする方法には、次のようなものがあります。
脅威モデリングのセッションを実施し、セキュリティプログラムの明確な方向性を定める。
ソフトウェア開発ライフサイクル全体でポリシー・アズ・コード（PaC）を活用し、安全なコーディング標準とプラクティスを徹底する。
コーディングでよくあるセキュリティ上の落とし穴と、その解決方法を開発者に周知する。
開発者がコードをコミットした時点で、静的アプリケーション・セキュリティ・テスト（SAST）やソフトウェア構成分析（SCA）を実施するツールを使う。ツールがセキュリティ上の問題を早く検出するほど、開発者は容易に軽減できます。
脆弱性管理の限界
脆弱性管理はアプリケーションセキュリティにおいて重要な役割を果たしますが、いくつかの点で不十分です。アプリケーション脆弱性管理は、複雑で変化の速い今日の開発環境ではもはや正確とは言えない、いくつかの前提に基づいて運用されがちです。
限界1：従来の脆弱性管理は、各脆弱性を個別のものとして捉える。
従来、脆弱性管理では、個々の脆弱性を個別に軽減することに重点が置かれてきました。しかし、ある脆弱性を修正することでコードの別の部分に変更が生じ、新たな脆弱性が連鎖的に発生したらどうでしょうか。このような状況は、時間をかけてアプリケーションのセキュリティを高めようとするチームの助けになるどころか、妨げになる可能性があります。
一般的なアプリケーション脆弱性管理では、アプリケーション全体のコンテキストを把握できません。そのため、修正時にアプリケーション全体を考慮できず、時間の経過とともに脆弱性が増える可能性があります。
限界2：従来の脆弱性管理は、共通脆弱性評価システム（CVSS）などの標準スコアでリスクを判断する。
一般に、アプリケーション脆弱性管理では、CVSSなどの標準スコアを使って各脆弱性に伴うリスクを判断します。その結果、開発者はCVSSスコアが高く、深刻度が重大な脆弱性の修正を優先します。しかし、こうした標準スコアでは、その脆弱性が存在するアプリケーションなど、ほかの重要な要素が考慮されません。たとえば、ビジネスクリティカルなアプリケーションのCVSS中程度の脆弱性は、社内向けアプリケーションのCVSS重大な脆弱性よりも優先して対処すべき場合があります。
一般的なアプリケーション脆弱性管理はCVSSのみに依存しており、それだけでは脆弱性の全体像を把握できません。
限界3：従来の脆弱性管理では、スキャンを実施するために開発者が使い慣れた環境を離れる必要がある。
脆弱性管理は長年にわたって存在するため、レガシーな要素がいくつか残っています。時代遅れの慣行の一つが、開発者はSDLCの早い段階でテストするために、別のセキュリティプラットフォームへ移動しなければならないという考え方です。
開発者はアプリケーション開発のほかの多くの領域でも責任を負っているため、こうしたコンテキストの切り替えはうまく機能しません。代わりにチームは、開発プラットフォーム内でのスキャンや、リアルタイムで実行可能な学習・修正アドバイスの提供など、開発者が使い慣れたワークフローにテストや脆弱性管理の基本要素を組み込む方法を検討する必要があります。
一般的なアプリケーション脆弱性管理では、開発者が別のセキュリティプラットフォームでコードをスキャンして修正することを前提としています。しかし、開発者には効果的に対応するための時間も余裕もなく、作業のコンテキストを切り替える必要があります。
限界4：従来の脆弱性管理は、すべての脆弱性を一元的に可視化しようとする。
脆弱性管理は、すべての脆弱性を単一のビューに集約しようとする点でも不十分です。しかし、複雑な開発環境では、時間の経過とともに脆弱性が常に増えるため、この目標は現実的ではありません。まずビジネスクリティカルなアプリケーションのコンテキストを把握し、そこから取り組みを進めるべきです。多くの場合、組織内のすべての脆弱性を網羅的に数え上げる必要はありません。
一般的なアプリケーション脆弱性管理は、すべての脆弱性を単一のビューに集約しようとします。しかし、これは現実的でなく、リスクの真のコンテキストを把握するうえでも効果的ではありません。
Snykによる脆弱性管理の支援
Snykのアプリケーションセキュリティは、コンテキスト重視、リスクベース、開発者ファーストのアプローチを採用し、従来の脆弱性管理の限界に直接対応します。Snykのツールは、次のようなプラクティスと視点を提供します。
開発者が使い慣れた環境内で、SASTやSCAなどのセキュリティテストを実施できます。開発チームはCLI上で脆弱性を見つけて修正し、検出された問題について役立つ知識を得られます。
アプリケーションセキュリティポスチャ管理により、汎用的なCVSSではなく、ビジネス上の重要性に基づいて最も重要な資産を優先する資産優先のアプローチを企業に提供します。
ASPMが提供する深いビジネスおよびアプリケーションのコンテキストを活用し、アプリケーションのほかの重要な領域に影響を与えない、コンテキストに基づいたセキュリティ修正を実現します。
ASPMで脆弱性管理をさらに進化させる方法をご覧ください。
