オープンソースコミュニティの隆盛により、かつてないほど多くのプロジェクト、ソリューション、オープンソースコードが生み出されています。そして開発に携わるものは、オープンソースソリューションがとても役立つと実感していますが、コードの質は大きく変化します。同様なことが商用ソフトウェアについても言えます。
共通脆弱性識別子 (CVE) データベースにより、何千ものソフトウェアの脆弱性が報告され、追跡されています。ソフトウェアの普及が進むにつれて、CVEデータベースに登録される脆弱性の数も増えています。実際、2021年には史上最多の2万件を超えるCVEが報告されました。このような状況を放置すると、組込み機器の開発者は、重大なセキュリティ脆弱性を含むソフトウェアをコードベースで活用してしまい、そのことに全く気づかない可能性があります。これがもたらすセキュリティリスクは大きく、Forrester社の報告によると、外部からのセキュリティ侵害の約3分の1がソフトウェア脆弱性によって引き起こされています（Forrester - The State of Application Security, 2021）。
組込みソフトウェア開発チームは、ソリューションのセキュリティ脆弱性がもたらすリスクの増大に対応するための戦略と方法を必要としています。ウインドリバーは、ソフトウェアソリューションと専門的なプロフェッショナルサービスを通じて、長年にわたり組込み開発者をサポートしています。また、セキュリティ脆弱性が組込みシステムに与える影響に対応するために必要な、セキュリティエンジニアリングに関する幅広い専門知識を有しています。
長年の経験に基づいて、CVEスキャンとセキュリティ脆弱性への対応に必要な10の必須要件をご紹介します。
1. 脆弱性管理ライフサイクルの策定
開発チームが製品を継続的にアップデートしている中、コードは常に変化しています。新規追加、リファクタリング、インポートパッケージ、サードパーティのコード、その他無数の変更が、常にコードベースに影響を及ぼします。このような現実を踏まえると、脆弱性スキャンは決して「1回で終わり」という訳にはいきません。
図：脆弱性ライフサイクル管理-Gartner
開発チームは、脆弱性の検出をライフサイクルを通して管理する必要があります。このライフサイクルには、絶え間ない評価、効果的な優先順位付け、スキャンと検出、そして最後に既知の脆弱性のライブラリを増やして、時間の経過とともに検出を向上させる方法が含まれます。最終的には、脆弱性管理のライフサイクルを適用することで、プラットフォームとアプリケーションのコードのリスクと、潜在的なセキュリティ侵害のリスクを劇的に低下させることができます。
2. 精度
CVEデータベースはかつてないほど急速に増加しており、既知の脆弱性の数は過去最高となっています。残念ながら、この傾向が弱まる兆しはありません。脅威や攻撃者の数は増加しており、セキュリティ攻撃の巧妙さは厄介になっています。
しかし、これらの既知のCVEの大部分は、組込み開発者には無関係です。効果的な脆弱性管理の成功につながる重要な要因は、広範なCVEの認識と、組込み開発チームに最も影響を与える脆弱性の精選されたデータベースとの連携です。
図：キュレーションデータベースを構築するために必要なCVEソース
複数のソースからのCVEトリアージを通じて、ウインドリバーは組込み開発向けに調整された脆弱性データベースを構築しました。ソフトウェア開発チームは、このCVEデータベースを脆弱性管理のライフサイクルの中で使用することで、ターゲットを絞った適切なスキャンを継続することができます。これにより、脆弱性解析に必要な時間とリソースを削減できるだけでなく、ウインドリバーが培ってきたセキュリティ脆弱性の豊富な経験を活用することができます。
3. 常に更新された情報
しかし、脆弱性スキャンはソースがあってこそのものです。セキュリティリスクにうまく対応するためには、最新の脆弱性データベースを維持することが重要になります。新しい脆弱性は、National Vulnerability Database、Mitre、その他のリポジトリなど、さまざまなソースに日々報告されています。これらの多数のソースからのCVE関連の情報を、常に最新の状態に保つことは大変なことです。
ウインドリバーのCVEデータベースのように、組込み開発チーム向けに特別に作成されたソースを使用することで、最も関連性の高いCVEの最新の情報を得ることが出来、それは重要な成功要因となります。このようなソースを使用することで、チームは常に最新の既知の脆弱性をスキャンしていることを認識することができます。
4. 脆弱性診断の自動化
ウインドリバーが推奨する構造的なアプローチは、自動化を活用して脆弱性の検出を支援することです。これは、Linux OSプラットフォームやアプリケーションで使用されているすべてのソフトウェアパッケージの正確なリストであるソフトウェア部品表（SBOM）を作成することから始まります。ウインドリバーのソリューションにより、このコンポーネント一覧の作成を支援し、使用中のパッケージのインベントリを常に把握することができます。
SBOM は SPDX (Software Package Data Exchange) フォーマットを使用しており、記述子情報だけでなく、バージョン、名前、ライセンス、製造元など、ソフトウェアパッケージに関連するメタデータを含んでいます。この情報を利用することで、Linux OSやアプリケーションを構成するソフトウェアの強力なインベントリを作成することができます。
そして、使用するソフトウェアに合わせたインテリジェントな脆弱性スキャンの基盤となります。
5. 効率的なトリアージ
脆弱性評価プロセスを開始したばかりの多くの組織がそうであるように、最初のスキャンは圧倒的で、時には大規模なコードベースから何百、何千もの脆弱性を発見する可能性があります。
しかし、どこから手をつければいいのかが難しいところです。Common Vulnerabilities Scoring Systemは、追跡されたすべてのCVEに対して深刻度スコアを提供します。ウインドリバーの脆弱性スキャナは、このスコアを使用して、コードに最も大きな影響を与えるCVEの優先順位付きリストを提供します。CVSSスコアを使用することで、開発者はソリューションに最大のリスクをもたらす脆弱性に焦点を当てることができます。
図：CVEの深刻度
しかし、前述したように、既知のリスクがソフトウェアコードに再導入されないようにするためには、繰り返し評価を行うことが重要です。古いパッケージやソフトウェアコンポーネントがアプリケーションにリンクまたはコンパイルされることはよくあります。特にそれを必要とする他のソフトウェアやハードウェアの依存関係がある場合です。ウインドリバーの脆弱性スキャンは、優先度の高いCVEのリストを保存し、継続的に評価されるようにすることができます。Linuxプラットフォームやアプリケーションのリスクを適切に評価するためには、このレベルの可視化は不可欠です。
6. ライセンスと IP コンプライアンスの自動識別
すべてのリスクがソフトウェアの脆弱性という形で現れるわけではありません。現代のソフトウェアアプリケーションには、推定80%のオープンソースやサードパーティのソフトウェアコンポーネントが含まれており（出典：Synopsys、2021年）、それに伴うセキュリティリスクは明らかです。しかし、それらのオープンソースパッケージには、ライセンス制限や使用ガイドラインがあり、それが守られないと大きな罰則や影響を受ける可能性があります。
IPとライセンスのスキャンは、自動化されていない場合、時間がかかることがあります。幸い、パッケージの記述にSPDXのようなフォーマットを標準化し、統制のとれたソフトウェア部品表を維持することで、開発者はライセンスの使用とコンプライアンスのために自動スキャンを実行することができます。
7. DevOpsインテグレーション
次のようなシナリオを想像してみてください。従来のウォータフォール型開発モデルでは、開発チームはプラットフォームやアプリケーションの開発を完了させ、市場投入や製造への出荷に先立ち、いくつかの検証を行うためにリリースチームに引き渡されます。リリースチームは脆弱性スキャンを行い、ソフトウェアスタックで使用されているいくつかのオープンソースパッケージに根本的なセキュリティリスクがあることを特定します。彼らは、脆弱性を解決するためにアプリケーションを開発に戻すしかなく、手戻りのためにプロジェクトは予定より遅れてしまいます。
このシナリオは珍しいことではなく、セキュリティの脆弱性に対応するには高価な方法です。 DevOpsと「シフトレフト」のメリットの多くは、脆弱性スキャンなどの自動化を導入することで、開発サイクルの早い段階でリスクを特定し、修正プログラムのデプロイがより合理的で安価にできるようになることです。
図：Wind River Studioパイプライン機能としてのCVEスキャン
自動化された脆弱性スキャンとCVEスキャンをビルドプロセスの早い段階で実装することにより、開発者は、開発の早い段階で既知のセキュリティリスクを修正する責任を負うことになります。これにより、製品ライフサイクル全体において、より高度なセキュリティ体制と、特定されたセキュリティ問題により迅速に対応するためのモデルなど、いくつかの利点がもたらされます。
8. ダッシュボードとヘルスモニタ
アプリケーションがますますインターネットに対応するようになり、統合された世界に移行するにつれ、サイロ化した情報やオフラインのコンテンツから、健全性、ステータス、セキュリティ監視の統合ビューに移行する必要性が高まっています。検索エンジンやさまざまな脆弱性データベースは有用ですが、開発チームやエンジニアリングリーダー達は、さまざまなソースから情報を探し、収集するのではなく、プラットフォームやアプリケーションの状態を統合的かつ合理的に表示する必要があります。
図：CVEスキャナダッシュボード
ダッシュボードは、この統合ビューを見るための重要な手段です。優れたダッシュボードは、ステータスのハイレベルな表示を提供し、一目で理解でき、必要に応じてドリルダウンや詳細なレポートが入手可能である必要があります。また、ダッシュボードは、古くなったりすることがなく、常に自動でアップデートされる必要があります。
9. レポート
ソフトウェアやハードウェアのサプライチェーンリスクが顧客の関心の的になるにつれ、多くのエンドユーザが、サプライヤに対して自社のセキュリティ検証方法の可視化とレポートの提出を要求するようになっています。顧客はサプライヤに対して、セキュリティ保証に関する追加情報を要求することがあり、脆弱性評価ほどそれが顕著なものはないでしょう。顧客は、自社が提供するデバイスが安全であることを証明する必要があるのと同様に、サプライヤがシステムコンポーネントを既知の脆弱性に対して検証していることを期待しています。
セキュリティレポートは時間のかかる作業ですが、その多くは、強化されたCVEスキャンの自動化と統合データの集約によって作成することができます。開発チームは、CVE の検出と修復に要する時間の自動的な表示に投資する必要性を感じています。また、特にシステム内で影響力の大きいパッケージについて、検出された CVE の重要度を示すことが必要になることもあります。
10. セキュリティとプライバシー
成熟した CVE スキャン機能を実装することは、大きなメリットをもたらしますが、同時にセキュリ ティリスクも生み出します。Linuxプラットフォームやアプリケーションの既知の脆弱性に関する情報を格納するいかなるツールの未解決のCVEを、攻撃者はソフトウェアスタックの弱点（または特定された脆弱性）として狙って悪用することが可能です。使用するCVEスキャンツールは、信頼できるベンダーの安全なものである必要があります。
CVEスキャンの安全なソリューションを評価する際に、3つの特性を念頭に置く必要があります。
1）アクセス制御：機密情報への不正アクセスを防ぐために、ツールは厳密なアクセス制御を行う必要があります。
2）マニフェストの保護：ツールプロバイダは、CVEをスキャンする資産（通常はソースコード/またはソフトウェアパッケージ）を保護する必要があります。これらのマニフェストは、Linuxプラットフォームやアプリケーションのコンポーネントに関するSBOMやその他の機密情報が悪意ある攻撃者の手に渡らないように保護されなければなりません。
3）カスタマプライバシーと保護：ツールは、サプライヤと顧客との間の関係を損なってはなりません。暗号化、アクセス制御、または他の難読化手段など、様々なメカニズムを通じて非公開のままであるべきです。
ウインドリバーのエキスパートによる支援
CVEスキャンを自動化することは、開発チームが脆弱性を発見するための強力な方法ですが、最も困難なのは、脆弱性を発見することではなく、それを修正することです。どのパッチがどのバージョンに適用されるのか、推奨されるアップグレードパスや脆弱性に適切に対処するためのセキュリティエンジニアリング技術などを知ることは、難しいことなのです。
Wind River Studio Linux Servicesチームは、数多くのプロジェクトを通じて、セキュリティエンジニアリングのベストプラクティスをお客様に提供します。また、専門知識をお客様のLinuxプラットフォーム、アプリケーション、システムにも活用することができます。ウインドリバーは、Yocto LinuxおよびWind River Linuxの推奨パッチを維持しており、お客様がオペレーティングシステムを常に最新で既知の脆弱性を修正するパッチを適用することを支援します。
Wind River Studio Linux Servicesは、お客様の脆弱性管理のあらゆる段階をサポートします。ウインドリバーの組込みシステム向けCVEデータベースによるCVEの特定から、Wind River Studio Linux Servicesチームとの連携による製品のセキュリティリスク解決まで、ウインドリバーはお客様のセキュリティパートナーです。CVEの発見から緩和・修復までの対応策については、ウェビナー「Path to Secure Linux Platforms」で詳しくご紹介していますのでぜひご覧ください。