ゼロトラストをアプリ開発にも適用、オープンソース脆弱性管理はどうする？：シフトレフトやSCA、SAST、SBOMが役立つ

アプリケーションセキュリティベンダーのMendが、アプリケーションセキュリティをゼロトラストで実現する6つのステップを解説した。セキュリティのシフトレフトを最初に進めるべきだが、ソフトウェア構成分析と静的アプリケーションセキュリティテストの組み合わせやソフトウェア部品表なども役立つという。

[＠IT]

　アプリケーションセキュリティベンダーのMendは2022年6月23日（米国時間）、「アプリケーションセキュリティ」をゼロトラストで実現する6つのステップを解説した。

　Mendは「大企業に対するサイバー攻撃の激化とデジタルトランスフォーメーション（DX）の加速により、企業はセキュリティ戦略とインフラの再評価を迫られている。こうした中でゼロトラストアプリケーションセキュリティとコンプライアンスの導入が進んでいる」との認識を示す。

　ゼロトラストアプローチについては、「デバイスやソフトウェアが権限を取得している場合や、以前に検証されている場合でも、それらを無条件に信頼してはならないということだ。全てのコンポーネントについて、脆弱（ぜいじゃく）性のスキャン、分析、テストを行う必要がある」と説明している。

　そこで、Mendはアプリケーションセキュリティ戦略に絞って、ゼロトラストを成功させる6つの重要な方法を示した。

ステップ1　オープンソースセキュリティとコンプライアンスを「シフトレフト」する

　アプリケーションコードの70〜80％がオープンソースであることは広く知られている。膨大な量のソフトウェアやライブラリが作成済みであり、すぐに使える状態にあるからだ。だが、従来の「無条件に信頼する」モデルは、セキュリティ上のリスクをもたらす。警戒が甘くなり、危険なパッケージや脆弱なコードが見落とされ、アプリケーションの脆弱性に至る恐れがある。

　解決策はある。セキュリティのシフトレフトにより、ソフトウェア開発ライフサイクル（SDLC）のできるだけ早い段階で、理想的には、コードを書くときや新しいコンポーネントを調査するときに、これらの問題を防止することだ。SDLCの早い段階で脆弱性を検出し、直ちに修正することで、開発チームが脆弱性の検出と修正を別々に行わなければならないといった効率の悪いワークフローを克服できる。

ステップ2　オープンソース用のSCAとカスタムコード用のSASTを組み合わせる

　ソフトウェア構成分析（SCA）は、ソフトウェアの70〜80％を占めるオープンソースソフトウェアを分析、修正するのに適しているが、それでは20〜30％のプロプライエタリコードは保護されないままになる。

　カスタムコードを脆弱性から保護する主要な方法が、静的アプリケーションセキュリティテスト（SAST）だ。だが、コードの種類ごとに別々のツールを使用することは、開発の妨げになる。時には、そのせいで開発者が脆弱性や更新を無視してしまい、将来的にコードベースが弱点を抱える恐れもある。

　SDLC全体と統合された手法があれば、状況が改善される。SCAとSASTという2つの手法の統合が、セキュリティ上の恩恵を最大化する。これにより、開発ライフサイクル全体をコントロールし、既存プロセスに支障が出ないようにできる。

ステップ3　新しいゼロデイ脆弱性やCVE/NVD以前の脆弱性を発見する

　堅牢（けんろう）なセキュリティ手法を導入していても、CVE（Common Vulnerability and Exposure）やNVD（National Vulnerability Database）に登録されていない未知の脆弱性が発生することがある。

　脆弱性が増加する中、これらを迅速に検出し、修正することがますます重要になっている。

ステップ4　プロプライエタリコードにありがちなセキュリティ脆弱性を回避する

　新世代のSASTでは、統合開発環境（IDE）内で、通常は開発者がコードを書いているときに、問題を解決できるようになった。こうしたSASTを使用すれば、従来よりも統合が容易になり、スピードが向上する。

　さらに、教育や啓発を改善してセキュリティプロセスを強化し、それによってセキュリティツールの採用拡大を促進することができる。ソフトウェアが使いやすく、開発者にとって、開発効率を低下させる心配がなければ、採用が加速する。

　IDEにおいて、オープンソースの脆弱性とプロプライエタリコードの弱点をスキャンできる統合機能を持つことは、非常に重要だ。これによってスキャンが簡単かつ迅速に実行できるようになる。そして修正済みのコード提供を、第一の目標に設定することが可能になる。

ステップ5　脆弱性に優先順位を付ける

　これまでほとんどの企業はCVSスコアを使用して、深刻度によって脆弱性の優先順位を決定してきた。その過程では、「特権の昇格が必要かどうか」「どんな種類のネットワーク攻撃なのか」といった要素を確定するための指標を調べている。

　論理的には、重大な脆弱性に注目することは正しいように思えるが、より重要な問題は、脆弱性が「悪用可能かどうか」ということだ。

　効果的な優先順位付けを進めるには、コードを分析し、脆弱性を含む関数やプロシージャがある場合に、それらを特定するだけでなく、そのライブラリがインポートされているかどうか、それが使用されているかどうか、従って、各脆弱性を本当に優先すべきなのかを識別する必要がある。

　インポートされていないもの、使われていないものは、他の文脈では脅威であっても、自社の文脈では脅威ではなく、優先順位を下げることができる。そうすれば、自社のコードベースにとってほとんど、あるいはまったく脅威とならない脆弱性を見つけて修正するために、時間とリソースを浪費せずに済む。

ステップ6　SBOMを活用する

　脆弱性を突く攻撃を軽減する最良の方法は、SBOM（Software Bill of Materials：ソフトウェア部品表）を用意し、活用することだ。SBOMは基本的に、製品に含まれる全てのソフトウェアコンポーネントのリストだ。

　SBOMが重要なのは、使用されている個々のコンポーネントのバージョンとセキュリティ状態が分かるからだ。これらが分かれば、プロジェクトにゼロデイエクスプロイト（攻撃コード）や脆弱性が含まれるかどうかを特定できる。そうなれば、それらを含むコンポーネントをできるだけ早くアップグレードし、リスクを軽減することが可能だ。

　SCAの手法を導入することで、コンテナとDockerレジストリをスキャンして、アプリケーションのSBOMを作成できる。

　SBOMの効果は、リポジトリやパイプラインに限定されるわけではない。多くのベンダーや組み込み技術によってアプリケーションがパッケージ化され、Linuxなどの組み込みディストリビューションが使用されるかもしれないが、そのコンテナもスキャンして、SBOMを作成することが可能だ。SBOMがあれば、そのプロジェクトにどんな脅威があり、どんなセキュリティ上の弱点があるのかを正確に理解できる。

　市販のサプライチェーンセキュリティ製品の中には、堅牢なゼロトラストセキュリティアプローチを導入できるものがある。こうした製品を利用すれば、悪意あるオープンソースソフトウェアがコードベースに入り込むことを検知してブロックしたり、悪意あるパッケージをレジストリから迅速に削除したりできる。

　これにより、ユーザーが誤って悪意あるコードをインストールして、ソフトウェアサプライチェーン攻撃につながることを防止できる。