脆弱性診断（セキュリティ診断）とは？重要性とツールの種類について

あらゆる業種や企業がデジタルサービスを提供するにつれて、セキュリティはますます重要になりました。一度セキュリティインシデントが起こると、サービスの安全性やブランドが毀損され、ビジネスに悪影響を与えかねません。ゆえに、デジタルサービスを運営する組織では、ユーザーが安心してサービスを利用できるように、セキュリティ向上を課題とした企業ニーズが増えています。

本記事では、このようなセキュリティ向上に取り組む開発や運用エンジニアの人へ向けて、セキュリティ向上を実現する脆弱性診断（セキュリティ診断）の基本知識、必要な理由と重要度、およびツールについて解説します。

脆弱性診断（セキュリティ診断）とは？脆弱性診断の定義とアプリケーション中心のセキュリティへシフトする潮流について

脆弱性診断（セキュリティ診断）とは、ITシステム内にセキュリティ上の欠陥を特定、評価する検査のことです。これはITシステムを構成する各要素にセキュリティ上の欠陥、つまり、悪用されうる脆弱性を特定し、その脆弱性がどれほど大きな悪影響を与えうるかをリスク評価するための手段です。脆弱性診断を実行することでセキュリティリスクを可視化し、適切な対応へと導くことで、セキュリティ向上のためのプロセスを回します。

加えて、ITシステムを構成する要素の幅は広いため、検査対象も広範囲に及びます。検査対象は、例えば、サーバーやネットワーク、OS、ミドルウェア、アプリケーションなどです。特に近年では、クラウドを活用したデジタルサービスが普及し、アプリケーション中心の時代が長く続いています。そのため、近年のトレンドでは、セキュリティの観点でもアプリケーションへのセキュリティの比重が高まっており、アプリケーションの脆弱性を検査できるツールへの注目を集めています。

なぜ脆弱性診断が必要なのか、その理由とは

企業活動の多くをITによって支えられる現代において、脆弱性の発見と排除は最重要課題のひとつです。ITシステムの脆弱性を悪用されれば、情報漏洩や機密漏洩のようなサービスの安全性が脅かされたり、企業の信用やブランドイメージが損なわれたりするなどのビジネスリスクがあります。結果、ビジネス機会の損失やユーザー離れにつながってしまいます。社会的に認知度の高い企業やサービスであるほど、そのダメージは増すでしょう。ゆえに、脆弱性診断を実施し、脆弱性の特定とリスクを評価し、適切な対処を事前に実施することが求められます。これは、ユーザーに対するサービスの安全性やブランドを守ることにつながります。

また、脆弱性診断は「一度やれば終わり」ではありません。継続的に実施されるものです。継続的にセキュリティを向上するために、開発の段階から脆弱性診断を組み込み、リリース後も常にセキュリティを監視し続ける、いわゆるDevSecOpsへの取り組みが重要になります。

脆弱性診断の重要度が高い企業の事情

セキュリティの向上は多くの企業に求められるものです。一方で、どれほどのリソースを脆弱性診断に投下できるかは業種やサービスの規模によって異なります。

ここでは、特に脆弱性診断の重要度が高い企業の例を見てみましょう。

コンプライアンスを重視する企業

コンプライアンスを重視する企業は、脆弱性診断に多くの予算をかけている場合が多いでしょう。ITの高度化、情報流通の多様化等から、総務省が「地方公共団体における情報セキュリティポリシーに関するガイドライン」を提示したのは、2001年のことです。地方公共団体が遵守すべき情報セキュリティの方針として、何度も改訂を重ねられてきました。

民間企業においても、こうした公的ガイドラインをベースにセキュリティポリシーが作られ、サイバー攻撃への備えと情報保護のための指針としています。中でも、個人情報や機密情報を扱う金融や法律、ヘルスケアの分野では情報漏洩のリスクが大きいため、脆弱性診断が欠かせません。

社会的に成熟したサービスを持つ企業

社会的に成熟したサービスを持つ企業も、脆弱性診断に力を入れる傾向があります。セキュリティ対策は投資しても直接的な利益を得られないため、十分に成長していないサービスを持つ企業にとってはなかなか手が入れられません。

しかし、サービスの規模が大きくなり、顧客や取引先が増え、多岐にわたる情報を取り扱うことになると、セキュリティインシデント発生時のインパクトが非常に高まります。社会的に成熟したサービスは、その影響範囲の大きさから深刻な影響も広範囲に及ぼす可能性があるため、脆弱性診断が重要といえるでしょう。

脆弱性診断の種類

アプリケーションに対する脆弱性診断の種類は、SCA（Software Composition Analysis）、SAST（Static Application Security Testing）、DAST（Dynamic Application Security Testing)、IAST（Interactive Application Security Testing）に分けられます。この4種類の方法を組み合わせることで、総合的な脆弱性検知を目指します。

ライブラリをチェックするSCA（Software Composition Analysis）

SCAはSoftware Composition Analysisの略で、ソフトウェア構成分析と訳されます。SCAはソフトウェアを構成する部品となるライブラリを走査し、脆弱性を検知するための手法です。サポートされたライブラリやフレームワーク、パッケージなどが主な走査対象であり、特に現代的なアプリケーションでは約8割がオープンソースを含むライブラリで構成され、残り2割が各社固有のビジネスロジックで実装されます。

アプリケーションライブラリの脆弱性検知が全体の8割を占めるとなると、その重要性の高さはいうまでもありません。

静的なソースコードをチェックするSAST（静的診断）

SASTはStatic Application Security Testingの略で、静的アプリケーションセキュリティテストと呼ばれます。これはホワイトボックステストに区分され、生のソースコードを静的に分析することでセキュリティ脆弱性を特定する手法です。

前述したとおり、現代的なアプリケーションでは約8割がオープンソースを含むライブラリで構成され、残り2割が各社固有のビジネスロジックを占めます。その2割のビジネスロジックに対する脆弱性検知の手法としてSASTが活用されます。

SASTは一般的には開発中、あるいはビルドやコンパイルするよりも前の段階で走査し、ソースコードレベルで脆弱性を検知可能です。これにより脆弱性の早期発見につながり、いわゆるセキュリティのシフトレフトを実現することで、デジタルサービスの安全性向上に寄与します。

稼働中のアプリケーションの脆弱性を見つけるDAST（Dynamic Application Security Testing）

DASTはDynamic Application Security Testingの略で、動的アプリケーションセキュリティテストと呼ばれます。これはブラックボックステストに区分され、ビルド後あるいはコンパイル後のアプリケーションを動作させて、実行中のアプリケーションを外部から走査し脆弱性を検知する手法です。

DASTはソースコード単位の脆弱性検知ではなく、稼働中のアプリケーションをブラックボックスとみなし、外部からの悪意のある攻撃をシミュレーションすることで脆弱性を検知します。DASTは特定のプログラミング言語に依存することなくセキュリティテストを実行できる唯一の手段です。一方で、アプリケーションの脆弱性を発見してもソースコード単位で評価しないため、別途原因となるソースコードを調査する必要があります。また、DASTは誤検知が発生することがあり、精度の問題もあります。このため、例えばDevSecOpsのようなサイクル下では、テストプロセスに遅延が発生しえます。

稼働中のアプリケーションでもソースコード単位で脆弱性検知できるIAST（Interactive Application Security Testing）

IASTはInteractive Application Security Testingの略で、こちらも動作中のアプリケーションの脆弱性を検知する手法です。一見すると先程のDASTと似ている手法に見えます。確かに、両方とも動作中のアプリケーションに対するテストであり、結果的にどのような脆弱性があるのかを調べることが可能です。

しかし、IASTはコードレベルで脆弱性を特定できるメリットがあります。つまり、IASTは悪意のあるリクエストと実行されたコードを特定し、ある脆弱性がどのソースコードで引き起こされたのかその原因がわかるようになるのです。これにより、脆弱性を検知しつつ、テストプロセスも早く回せるようになり、DASTにはないメリットを享受できます。

IASTについてはこちらの記事でも詳細を説明しています。
 - IASTとは？開発時のセキュリティ対応を大幅に省力化する方法を解説

脆弱性診断とペネトレーションテストの違い

アプリケーションの脆弱性を検知する手法としてペネトレーションテストがありますが、脆弱性診断とペネトレーションテストは実施する目的に大きな違いがあります。

一般的に、脆弱性診断は、既知の脆弱性を検知・特定し、その重要度とともに報告するものです。一方のペネトレーションテストは、実際の攻撃に対してセキュリティが有効に機能するかどうか、セキュリティを回避・無効化される可能性がないかを検証するために行われます。

ペネトレーションテストは「侵入テスト」とも呼ばれるように、悪意を持った第三者の立場で、擬似的な攻撃を仕掛けるといった、IASTに含まれるテストです。時には対象企業の組織構成やワークフローなど、内部情報を踏まえた上で攻撃シナリオを作成し、狙った情報にタッチできるかどうかを試します。

それぞれ目的が異なるため、ニーズに合わせて脆弱性診断とペネトレーションテストを使い分けることが大切です。

誰が脆弱性診断を実施するか

ここまで脆弱性診断の種類ついて整理してきました。これらを実行に移す際には、セキュリティ専任エンジニアを配置する方法、セキュリティ専門会社にアウトソースする方法、セキュリティソリューションを活用する方法の大きく3つの選択肢があります。それぞれの特徴を見てみましょう。

セキュリティ専任のエンジニアを配置する

脆弱性診断を実施する方法のひとつに、セキュリティ専任のエンジニアを配置する方法があります。一定以上の経験とスキルを持った人材を社内に配置しておくことで、手厚い体制を構築でき、万一の際の対応も安心です。

しかし、専任を雇うコストがかかるため、大企業など資金やリソースに余裕のある会社では問題ありませんが、中小やスタートアップのような規模の会社ではなかなか雇えないといった実情があります。

セキュリティ専門会社にアウトソースする

セキュリティ専門会社にアウトソースして脆弱性診断を実施する方法もあります。この方法なら、自社でエンジニアを採用する必要はありません。セキュリティ専門会社の豊富な実績から、自社の業務内容や規模感に合ったプランを提案してもらえるでしょう。

しかし、多くのケースではDASTやペネトレーションテストをリリース前に一度実行する場合が多く、継続性に欠けるケースが散見されます。継続的に実施する場合、当然追加費用がかかるため致し方ないかもしれませんが、脆弱性診断は「一度やれば終わり」ではありません。

セキュリティソリューションを活用する

脆弱性診断を行う際に、セキュリティソリューションを活用する選択肢があります。最近では、セキュリティを自動化・効率化するソリューションが登場しており、複数の手法を組み合わせて、効率的にセキュリティテストを実行できます。また、このような自動化されたセキュリティソリューションはDevOpsのサイクルに取り込むことで脆弱性診断を継続的に実施可能です。

コストの両立、テストの継続性、セキュリティという専門領域をカバーする自動化されたセキュリティソリューションは、ファーストチョイスになりえるでしょう。

DevSecOpsを強力に推進するNew Relic

New Relicは、2023年2月にVulnerability Management（脆弱性管理）をリリースしたことを皮切りに、セキュリティ分野へオブザーバビリティの提供を開始し、DevSecOpsの支援を宣言しました。その後も2024年2月にはIAST（Interactive Application Security Testing）の正式リリースが開始し、アプリケーションを中心としたセキュリティソリューションを展開しました。New Relicはますますセキュリティ分野へ注力し、デジタルサービスを抱える組織やチームに対してDevSecOpsを実践するソリューションを提供しています。

ここでは、現在New Relicが提供している機能を整理します。

New RelicのVulnerability Management（SCA）とIASTとSecurity API

New RelicはSCAに該当するNew Relic Vulnerability Managementがあり、アプリケーションライブラリをチェックすることで、システム全体のアプリケーションライブラリの脆弱性を特定します。また、どのバージョンにアップデートすべきか、あるいは、どのアプリケーションにどのようなライブラリ脆弱性があるか、その関係性を可視化することが可能です。これにより、スタック全体から脆弱性を特定し、適切な対処に移すことができるのです。

加えて、New Relicは2024年2月からIASTを提供しています。アプリケーションに悪意のあるリクエストをシミュレートし、ソースコードレベルで脆弱性を特定することで、スムーズな改善を促し、DevSecOpsを実現します。

IASTの詳細についてはこちらの記事をご覧ください。
 - IASTとは？開発時のセキュリティ対応を大幅に省力化する方法を解説

また、New RelicはSecurity APIを公開しており、サードパーティからデータを集約することが可能です。例えば、AWS Security Hubでインフラ系の脆弱性情報やSnykのようなSASTのデータをNew Relicに集約し、セキュリティに対する総合的なオブザーバビリティを実現する仕組みを用意しています。

開発・運用の全プロセスでセキュリティを効かせるDevSecOpsの実現

開発から運用までの一連のソフトウェアサイクルの各フェーズでセキュリティ対策をすることで、セキュリティのシフトレフト、つまりDevSecOpsを実現できます。ソフトウェアの開発段階では、SCAとSASTを実行し、ステージング環境でのテスト段階ではIASTを実行しておけば、アプリケーションをより安全で安定した状態でリリースでき、アジリティを大きく損なわずに済むでしょう。

また、リリース後の運用でも、常にスタック全体から脆弱性を可視化することで、適切なアクションを取れる状態を作ることができます。開発（Dev、運用（Ops）の各フェーズでセキュリティを考慮するDevSecOpsを推進することで、トラブルの発生リスクを大きく抑えることが可能です。これにより、サービスの安全性やブランドの毀損リスクを低減し、エンドユーザーが安心してサービスを利用できるためのセキュリティ向上につながります。

DevSecOpsを強化し、さらにビジネスの成長を支援するNew Relic

ビジネスの観点では一見するとセキュリティ対策はコストがかかり、直接的な利益を生みません。しかし、そのコストは自社のビジネスの信頼やブランド、そして顧客を守るための投資でもあるのです。コストの両立という観点から自動化されたセキュリティソリューションをファーストチョイスとして採用し、専門性のカバーという観点ではSCA、SAST、IASTなど総合的に組み合わせることで、多くの企業が課題とする脆弱性に取り組める時代が来ています。

New Relicは上記のようなセキュリティも含め、アプリケーションやインフラなどデジタルサービスを構成する技術スタックをリアルタイムで可視化するオブザーバビリティを提供し、デジタルサービスを改善できる状態を提供します。

New RelicでDevSecOpsを実現し、サービスの安全性をいつでも確認できる状態にしつつ、サービス成長に必要な開発と運用に注力することで、さらなるビジネス成長を実現しましょう。