はじめに
New Relicは2023年2月にVulnerability Management(脆弱性管理)をリリースしたことを皮切りに、セキュリティ分野へのオブザーバビリティを提供を開始し、DevSecOpsの支援を宣言しました。その後も2023年8月にはIAST(Interactive Application Security Testing)をパブリックプレビューを開始し、アプリケーションを中心としたセキュリティソリューションを展開しております。しかし、一般的なDevSecOpsにおけるセキュリティへの理解はまだまだこれからです。本ブログでは、はじめてプロダクトのセキュリティに取り組む開発や運用に携わるエンジニアの方々に向けてDevSecOpsに必要なセキュリティの知識を整理し、解説を行います。
DevSecOpsとは?
DevSecOpsは、開発(Dev)、セキュリティ(Sec)、運用(Ops)の統合を目指す一連の思想です。DevSecOpsでは、セキュリティが開発の初期段階から考慮され、継続的なデリバリーと迅速なフィードバックを通じて、セキュアなソフトウェアを提供することを目指します。これによりアジリティを犠牲にせず、セキュアなプロダクトを提供することで、サービスに対するコンプライアンス、信頼性を順守します。
アプリケーションセキュリティに取り組む意義
ビジネスの観点では、セキュリティへ取り組むことはユーザーの信頼とビジネスの継続性に直結します。データ漏洩やセキュリティ侵害は、企業やサービスの評判を損ない、法的な責任を負う可能性があります。社会的な認知度が高くなった誰もが知るようなサービスの場合はなおさら重要です。また、業界の特性によっては遵守すべき法的なコンプライアンスを守るためにセキュリティを重視する場合もあるでしょう。また、ソフトウェア開発においては、企業が多くのソフトウェアや機能を迅速に、そしてより複雑な環境でリリースするについて、セキュリティ上の欠陥が発生する可能性が高まります。特にアプリケーションのセキュリティの現状として、致命的な脆弱性がある商用アプリケーションの割合が85%、既知の脆弱性のあるコードを本番稼働させた組織の割合が48%である調査報告もあり、リリースが早いほど、パイプライン上で脆弱性が増加しビジネス上のリスクが増加します。そのため、セキュリティは開発プロセスの初期段階から組み込み早い段階で対処できる仕組みづくりを導入し、開発者と運用者に適切なコラボレーションを促進することで、ソフトウェアの品質とセキュリティを向上させることができます。
セキュリティを自動化し、DevOpsのパイプライン上に実装する
たとえDevOpsのパイプラインにおけるセキュリティに限定して考えても、セキュリティの範囲は広いです。そのため、手動で運用を行うには工数の肥大化を招きやすく、また人材のスキル面では属人化の懸念あるいはそもそも対応可能かどうかなどの現実的な課題があります。そこで、DevOpsで実現したアジリティを大きく犠牲にせず、適切にセキュリティへ対応するためには、セキュリティソリューションを導入し自動化することが重要です。自動化をDevOpsのパイプラインに組み込むことで工数を最適化しアジリティを損なわずに対処でき、かつソリューションを採用することで属人化やスキル面の不安を解消でき、両立した適切な仕組みを作ることができます。これがDevSecOpsへの取り組みの第一歩です。
さらにセキュリティを実装する場合は一般的に検知と防御の2つの観点で分けて、それぞれで自動化を検討します。脆弱性を検知し、対処あるいは、本番環境であれば防御することでセキュリティのリスク範囲を抑え込み対処します。このブログでは、特に検知に焦点を当て整理します。
セキュリティ検知手段
脆弱性を検知する、特にクラウドの時代ではアプリケーション中心の時代であることから、アプリケーションに対するセキュリティの意識が高まっています。このような現代的なアプリケーションは一般的にアプリケーション全体のコードのうち8割はオープンソースをはじめとるするライブラリを中心に構成されており、残りの2割は独自のビジネスロジックで開発され保守されています。つまり、セキュリティの観点では8割のライブラリに対する検知と2割のビジネスロジックに対する検知を両立することで、アプリケーション全体のセキュリティを高めることができます。これがDevSecOpsにおける基本戦略の一つになります。そして、具体的にはアプリケーションライブラリにはSCA、そしてビジネスロジックにはSASTやIASTのアプローチで脆弱性を検知することで、アプリケーション全体のセキュリティを向上できます。以下にあるようにSCA、SAST、IASTを整理しましょう。
SCA(Software Composition Analysis)
SCAはSoftware Composition Analysisの略で、ソフトウェア構成分析と訳されます。一言で言えば、ソフトウェアを構成するライブラリの脆弱性検知のことです。先の通り一般的なアプリケーションのうち8割はライブラリが占めており、たかがアプリケーションライブラリ脆弱性の検知と言えど、されど8割を占める検知であることは言うまでもなく重要と言えるでしょう。また、New Relic Vulnerabilility ManagementはSCAに該当し、アプリケーションライブラリの脆弱性を検知します。また、New RelicはAmazon Security Hubなどのその他サードパティと統合するためのAPIを公開しており、アプリケーション以外のライブラリもNew Relicプラットフォーム上に集約できます。
SAST(Static Application Security Testing)
SASTはStatic Application Security Testingの略であり、これは生のソースコードを静的に分析するこでセキュリティ脆弱性を特定する手法です。一般的には開発中あるいはビルドしてコンパイルするよりも前の段階でSASTを実行します。このテストを実行することで脆弱性の早期発見につながり、いわゆるセキュリティのシフトレフトを実現します。 Snykなどの次世代脆弱性管理ツールはこのようなSASTを提供しており、かつNew Relicのパートナーでもあります。Snykで収集した脆弱性のデータをNew Relicに統合でき、セキュリティの共通プラットフォームとして利用できます。
IAST(Interactive Application Security Testing)
IASTはInteractive Application Security Testingの略であり、先ほどのSASTが静的なテストであるのに対してIASTは動的なセキュリティテストの手法になります。あまり聞き慣れない用語かもしれませんが、実際にビルド後のアプリケーションを稼働させたときに実施する脆弱性テストであり、実際に侵害の可能性のあるパラメータやリクエストを送ることでアプリケーションコードの脆弱性を炙り出す手法です。特にNew Relic IASTは、New Relic APMと統合されており、SQLインジェクションやOWASP Top10に代表されるような脆弱性をコードレベルで特定し、脆弱性の修正方法の提示まで行います。商用環境でアプリケーションを動かし初めてわかるような脆弱性を、IASTのような手段でステージング環境やテスト環境で検知でき、さらなるセキュリティリスクを軽減できます。
まとめ: DevSecOpsにおけるSCA及びSASTとIASTの統合
SCAやSAST、IASTは、それぞれ異なる強みを持っています。SCAでライブラリの脆弱性をカバーし、SASTで開発の初期段階でコードの問題を特定し、IASTは実行時の問題を発見します。これらを組み合わせることで、ソフトウェアのセキュリティをより包括的に強化できます。DevSecOpsではセキュリティは継続的なプロセスとして扱われます。SCAやSAST、IASTを統合することで、パイプライン全体にわたってセキュリティを確保し、リスクを最小限に抑えることができます。New RelicではNew Relic Vulnerability Managementやパートナーとの協業及びサードパーティ連携、またIASTのサポートなどDevSecOpsのためのオブザーバビリティプラットフォームを提供しており、これからアプリケーションセキュリティに取り組む方々へいっそう支援してまいります。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。