リックソフトでは、オープンソースの脆弱性管理・コンプライアンス管理ツールであるWhiteSourceを販売しています。

今やOSSライセンスを使ったソフトウェア開発は90%以上とも言われている中で、これらの管理をスプレッドシートを使い手作業で確認をしている、あるいは他のツールを使用しているが壁に当たって考えている方々に是非こちらのブログをお読みいただき、WhiteSourceのツールに興味を持っていただけたらと思っています。

本ブログはWhiteSorce社に了承を得て翻訳をしたものになります。

今回は全6回のうち4回目、「セキュリティ負債への対応：セキュリティの赤字解消法」というブログをご紹介します。

ここ数年、報告されるセキュリティ脆弱性の件数は急増し、企業アプリケーションを狙った悪質な攻撃も非常に多く発生しています。
こうしたことへの対抗措置として、組織はアプリケーションセキュリティやDevSecOpsへの投資を増やしており、たとえば、AST（アプリケーションセキュリティテスト）ツールの広範な導入などを行っています。

ASTツールはDevSecOpsを完成させる重要なステップの1つですが、セキュリティ脆弱性の検出に力を入れることは、多くの組織において、セキュリティ負債を膨らませる要因にもなっています。

■セキュリティ負債とは何か、なぜセキュリティ負債に注意すべきなのか

セキュリティ負債とは、技術的負債の1つであり、組織のソフトウェアやインフラストラクチャに蓄積されている既知のセキュリティ脆弱性のことを指します。

組織はアプリケーションセキュリティへの投資を増やしていますが、開発者とセキュリティチームは膨大な量のアラートに苦しめられ、多くの脆弱性に手を着けられません。
結果的に、未対応の脆弱性が山積みになり、悪質な攻撃に対して無防備になります。

2016年、Gartnerによると、2020年には、侵害に悪用される脆弱性の99%は、セキュリティやITの担当者が1年以上前から知っていたものになるだろうと予測されていました。

現在、組織のアプリケーションレイヤーに既知のセキュリティ脆弱性が解消されず蓄積していることは、組織にとって大きな懸念事項となっています。
2017年にEquifaxの情報流出事件を引き起こしたような攻撃を見れば、既知の脆弱性を黙殺したり、修正を後回しにしたりすることが、セキュリティ負債への正しい対処法でないことは明らかです。

■セキュリティ負債の原因

当然ですが、誰かがセキュリティ負債の積み上げを始めたわけではありません。

システム内で検出されるセキュリティ脆弱性が日々増え続け、セキュリティチームや開発チームは対応に懸命に努力していたにもかかわらず、いつの間にか、対処するセキュリティ負債が膨らんでいたというケースがほとんどです。

残念ながら、最近のPonemon Instituteのレポートでは、現在多くの企業組織にセキュリティ負債が重くのしかかっていることが明らかにされています。

この数年、アプリケーションセキュリティのリスクに対する意識の高まりから、セキュリティ研究コミュニティはコードの解析やセキュリティ脆弱性の検出、公開にいっそうの力を入れています。

正義のハッカーたちの活動は、オープンソースと商用ソフトウェアのどちらの開発コミュニティにおいても急激に活発化しています。
その結果、発見される脆弱性が増えています。
実際に、オープンソースの脆弱性件数はこの数年で急激な増加を見せています。

これは、オープンソースコミュニティでもソフトウェア開発業界でも研究が盛んになっていることが要因です。

公開されるセキュリティ脆弱性の件数が増えていることに加えて、アプリケーションセキュリティツールの使用効果からセキュリティアラートの件数も増えており、チームは毎日アラートを処理する必要があります。

残念ながら、ほとんどのアプリケーションセキュリティツールは自社独自コンポーネントやオープンソースコンポーネントからセキュリティ脆弱性を検出することには力を入れていますが、優先順位付けや修正の機能は通常ありません。

このため、チームはさまざまなセキュリティアラートを受け取れても、スピーディーに修正する手段がほとんどありません。

急激に短期化が進むリリースサイクルのペースに合わせて、セキュリティチームや開発チームがコード内で検出されるセキュリティ脆弱性のすべてに対処することはほとんど不可能です。
脆弱性の優先順位付けと修正の方針が明確に定義されていなければ、セキュリティ負債は簡単に膨らんでしまいます。

■セキュリティ負債の削減

開発者やセキュリティ担当者が対処しなければならないセキュリティアラートの数が急増していることを見ても、検出だけでは十分な対策でないことは明らかです。

セキュリティ負債を減らすには、セキュリティのプロセスとツールの「シフトレフト（前倒し）」を進め、それらをSDLC（ソフトウェア開発ライフサイクル）全体に導入する必要があります。

■脆弱性の優先順位付けと修正

セキュリティ担当者と開発者に対する最近の調査では、セキュリティ担当者はこの問題を認識し、「セキュリティの優先順位付け」をアプリケーションセキュリティ計画を推進するうえでの最大の課題ととらえていることがわかりました。

セキュリティ負債の増大に対処するには、セキュリティチームと開発チームが協力して、検出から修正までの間にある溝を埋めなければなりません。
このためには、最も重大なリスクがあるセキュリティ脆弱性に注力し、深刻な脆弱性の数を抑えることが必要です。

しかしながら、データが示すように、脆弱性の優先順位付けについて業界としての標準や手法は現在存在しません。
さまざまなチームが数多くの考慮事項に基づいてセキュリティアラートの優先順位を決めているため、結局、何を最初に修正するかを決めることに多くの貴重な時間を費やしています。

セキュリティ脆弱性の優先順位付けと修正は複雑な作業です。

セキュリティ脆弱性を分析して何を最初に修正するかを決めるには、「重要」なデータに着目する手法を確立しておくことが大切です。
「重要」なデータは、アクセスや解決が簡単あるいは低コストだという基準で選ぶものではありません。

システムに直接的に影響する脆弱性に対応するような脆弱性優先順位付け戦略を導入できれば、対処が必要な大量のセキュリティ問題を絞り込み、最も深刻なリスクを最初に取り除くことが可能になります。
何を修正するかを決めるために時間を無駄にしたり、対処が簡単な順に修正を行ったりすることはなくなります。

【＃自働化】

現在、AST（アプリケーションセキュリティテスト）ツールの市場には、セキュリティ脆弱性を継続的に検出する自動化ソリューションが数多くあります。
その一方で、残念なことに、そのようなソリューションのほとんどが優先順位付けや修正を効果的に自動では行ってくれません。

現在組織は、脆弱性の詳細や依存関係、影響を手動で分析し、深刻度を評価しようとしていますが、こうした重要で緊急性の高いプロセスを自動化できれば大幅な時間短縮につながります。
何を最初に修正するかの論争をやめて、貴重な時間をセキュアコードの開発に生かせます。

【#セキュアコーディング】

予防に勝る治療なし -- これはDevSecOpsパイプラインにも当てはまります。

セキュリティ負債を減らそうとする場合、セキュアコーディングによる予防を無視することはできなくなっています。
セキュリティのシフトレフトが進み、開発者がアプリケーションセキュリティに積極的にかかわるようになっていることから、高度な脆弱性検出/修正ツールを開発者のネイティブ環境に統合することが必要となります。

これにより、脅威とセキュリティリスクに、できるだけ早く、修正が比較的容易でコストもかからないうちに、対処することが可能になります。

■セキュリティ負債の削減：検出から修正までの溝を埋める

セキュリティ負債の削減には、全員が総力を挙げてDevSecOpsに取り組むというアプローチが必要です。
つまり、セキュリティ脆弱性管理に対応する責任を全チームが共同で担うことが必要になります。

現在の組織が日々直面している脆弱性アラートの件数を考えると、分断したセキュリティアプローチではまったく太刀打ちできません。

セキュリティ負債を切り抜けるためには、組織の全チームに脆弱性管理方針を徹底することが必要です。
セキュリティはDevSecOpsパイプライン全体で継続的に取り組むものであり、セキュリティチームと開発チームが協力して重大な脆弱性にできるだけ早く対処することを目指す必要があります。