このブログは、「現場からの教訓：CRAから学んだこと」シリーズの第9回です。このシリーズの目的は、製造業者、ソフトウェアベンダー、コネクテッド製品の提供企業が、CRAコンプライアンス・プログラムを実装する際の現実的な課題を理解できるよう支援することです。お客様との取り組みや業界リーダーとの対話を通じて得た知見を紹介します。  組織は、持続可能なコンプライアンスを実現するには、従来のサイバーセキュリティ活動を大きく超えたガバナンス、可視性、説明責任、ライフサイクル管理の能力が必要であることを学びつつあります。安全な製品を作るだけでは、CRAコンプライアンスは達成できません。

 

サイバーレジリエンス法がソフトウェア・サプライチェーンのリスクを経営上の優先課題へと押し上げる理由

長年にわたり、オープンソースソフトウェアの利用は、主としてエンジニアリング上の意思決定と考えられてきました。

開発者がライブラリを選定し、アーキテクトがフレームワークを承認し、セキュリティチームが脆弱性を追跡し、製品チームが機能と納期に集中してきました。経営幹部が、自社製品に組み込まれている何百ものオープンソース・コンポーネントについて考える必要が生じることはほとんどありませんでした。

しかし、その時代は終わりました。

欧州連合のサイバーレジリエンス法（CRA）は、オープンソースソフトウェアを含むソフトウェア・サプライチェーンに対する組織の考え方を変えつつあります。かつては主に技術上の問題と見なされていたものが、今ではビジネス、コンプライアンス、ガバナンスの問題へと急速に変化しています。

オープンソースが異なる理由

オープンソースソフトウェアは、事実上あらゆるコネクテッド製品を支えています。商用ソフトウェアとは異なり、製造業者は通常、それを作成・保守する開発者と契約関係を持っていません。多くのオープンソース・プロジェクトには、商用サポートも、保守の保証も、サービスレベルのコミットメントもありません。

組織には、自社製品を支えるソフトウェアを把握し、依存関係を可視化し、脆弱性に迅速に対応し、製品ライフサイクル全体を通じて継続的なガバナンスを実証することが、これまで以上に求められています。CRAの下では、これは社内で開発したソフトウェアや商用ベンダーからライセンス供与を受けたソフトウェアだけでなく、オープンソースソフトウェアにも及びます。

この現実により、オープンソースソフトウェアに関する議論は、エンジニアリングチームの中だけでは完結せず、経営幹部の会議、コンプライアンス・レビュー、監査委員会、取締役会へと移りつつあります。問題は、オープンソースソフトウェアそのものが本質的に危険であることではありません。問題は、可視性と説明責任です。

経営層への示唆

CRA対応プログラムから明らかになりつつある重要な教訓は、ソフトウェア・サプライチェーンのリスクがビジネスリスクになったということです。従来、組織はオープンソースソフトウェアが開発を加速するか、コストを削減するか、製品機能を向上させるかに注目していました。

取締役会は、自社製品でどのオープンソース・コンポーネントが使用されているかを確認するだけでなく、それらがCRAコンプライアンスに与える影響も検討しなければなりません。つまり、そのオープンソース・プロジェクトが活発に保守されているか、どの程度成熟しているか、商用の支援があるか、脆弱性報告のプロセスが整備されているか、脆弱性がどの程度迅速に修正されるか、そしてサポートが終了した、または放棄されたコンポーネントが出荷中の製品に残っていないかを判断する必要があります。  サポートに不足がある場合、企業はその不足を社内で補えるかどうかを判断しなければなりません。  場合によっては、大企業がオープンソース・プロジェクトに参加したり支援したりすることで、脆弱性の報告と軽減のための持続可能なプロセスづくりを後押ししています。

これらはエンジニアリングだけの問題ではありません。ガバナンスとマネジメントの問題です。CRAの下で、組織はソフトウェア依存関係の可視性を実証し、脆弱性管理プロセスを維持し、協調的な脆弱性開示活動を支援し、継続的なサイバーセキュリティ・ガバナンスの証拠を提示することが求められます。

その結果、多くの経営チームは、オープンソースソフトウェアの利用が規制コンプライアンス、顧客の信頼、製品セキュリティ、ブランド評価、長期的なサポート義務に直接影響することに気づき始めています。

オープンソースがCRA上の課題になった理由

オープンソースソフトウェアそのものが問題なのではありません。実際、現代のソフトウェア開発はオープンソースなしではほぼ不可能です。  課題は、多くのオープンソース・プロジェクトに商用サポート、保守保証、サービスレベルのコミットメントがないことです。

脆弱性は複数の製品に影響し得る

広く利用されているオープンソース・コンポーネントで脆弱性が発見されると、複数の事業部門にまたがる何百もの製品に影響する可能性があります。組織は、影響を受ける製品、対象バージョン、顧客への影響、利用可能な緩和策を迅速に特定できなければなりません。

可視性がなければ、対応時間は大幅に長くなります。

長期サポートが説明責任を生む

CRAはライフサイクル全体の責任を重視しています。組織は、製品のサポート期間を通じてソフトウェア依存関係を管理できるよう準備しなければなりません。これは、オープンソースソフトウェアについて難しい問いを突きつけます。たとえば、サポートが終了した、あるいは放棄されたオープンソース・プロジェクトを使用していないか、オープンソースソフトウェアの脆弱性をどのように追跡するか、発見された脆弱性をどのように軽減できるか、といった点です。  企業自身でそのオープンソースソフトウェアを更新できるでしょうか？ それとも、重要なオープンソース・コンポーネントに長期サポートを提供する請負業者や企業を見つけられるでしょうか？

オープンソースソフトウェアの広範な利用

組織は、オープンソースソフトウェアへの依存をますます強めています。  オープンソースと聞くと、多くの人はOpenSSL、Linux、PostgreSQLのような大規模プロジェクトを思い浮かべます。しかし実際には、それらは氷山の一角にすぎません。

一般的なアプリケーションには、プログラミング言語のランタイム・ライブラリ、開発フレームワーク（Spring、.NET OSSパッケージ、React、Angularなど）、暗号ライブラリ、ネットワーク・ライブラリ、ビルドツール、JSON/XMLパーサー、ロギング・フレームワークなどが含まれます。そして、それぞれがさらに数十のパッケージに依存している場合があります。

現実世界の例

社内開発ソフトウェアと同様に、オープンソースソフトウェアの利用状況を可視化することは、多くの組織にとって課題です。  広く使われているオープンソース・ライブラリで重大な脆弱性が公表されると、セキュリティチームは直ちに、そのコンポーネントが自社製品に含まれているかどうかを確認し始めます。

答えは簡単に出せるはずです。しかし、集中管理された完全なドキュメントがなければ、実際には容易ではありません。各エンジニアリングチームが、コードリポジトリ、文書管理システム、開発環境を調べて影響範囲を特定しなければならないからです。これには数日かかる場合があり、CRAの24時間以内の報告要件を考えると深刻な問題です。

さらに、オープンソース・プロジェクトの性質が問題を複雑にします。企業がソフトウェア構成や脆弱性への影響について情報提供を求められるサプライヤーとの契約関係はありません。製造業者は、多くの場合、自ら影響の程度を判断しなければなりません。

CRAの下でオープンソース・リスクを管理するためのベストプラクティス

経営チームが認識していなくても、ほぼすべての企業が製品でオープンソースソフトウェアを利用しています。  オープンソースを管理する第一歩として、CRAコンプライアンス・チームは、オープンソースソフトウェアを利用するための正式な受入基準を定めるべきです。重要な基準には、プロジェクトの成熟度、メンテナーの活動状況、リリース頻度、セキュリティ実績、ガバナンスモデル、ライセンス、テスト手法、長期的な存続可能性などがあります。

これは重要な一歩ですが、オープンソース・プロジェクトの受入基準を定義することは将来に向けた活動です。新製品開発におけるオープンソース利用の管理には有効ですが、既存のレガシー・プロジェクトでの利用には対応できません。CRAコンプライアンスを目指すオープンソース・リスク管理プログラムには、追加の取り組みが必要です。

包括的なSBOMを維持する

企業は製品のライフサイクル全体にわたってSBOMを維持・更新し、オープンソースソフトウェアの利用がすべて文書化・監視されるようにしなければなりません。使用しているオープンソース・プロジェクトを特定した後は、CRAコンプライアンスを達成するために、それらのソリューションをどのように管理・保守するかを計画する必要があります。

サポート計画と移行計画を決定する

使用中のオープンソース・ソリューションのインベントリを作成したら、それらのコンポーネントをどのようにサポートするかを決定しなければなりません。企業は、一部のオープンソース・コンポーネントから別のものへ移行したり、可能であればそのコンポーネントを支援する第三者（3rd party）企業からサポートを受けたり、自社でサポートする計画を立てたりできます。

オープンソースへの依存度が高いため、多くの企業は難しい板挟みの状況に置かれています。オープンソースからの移行は現実的でないことが多く、社内でサポートすることも同様に困難な場合があります。その代替策として、オープンソース・プロジェクトを資金面で支援する企業もあります。また、オープンソース・ライブラリのサポートを提供する企業と契約できる場合もあります。

脆弱性を継続的に監視する

組織は、新たに発生する脆弱性をソフトウェア・インベントリや展開済み製品と継続的に照合・評価する必要があります。  自動化により、対応速度を大幅に向上できます。

よくある落とし穴

CRA対応の取り組みでは、いくつかの典型的な誤りが繰り返し見られます。

すべてのオープンソースソフトウェアを同じように扱う

広く利用されているオープンソース・プロジェクトは数千あります。1人の開発者が作成したプロジェクトから、大規模で十分な資金を持つプロジェクトまで、その規模や体制は大きく異なります。たとえばLinux Foundationは年間3億ドルを超える予算を持ち、1,300を超える個別のオープンソース・プロジェクトを支援しています。

プロジェクトの数、規模、利用状況を考えれば、品質やサポートの水準に大きな差があるのは当然です。

人気が高ければ品質も高いと考える

オープンソース・プロジェクトが広く採用されているからといって、高品質である、あるいはセキュリティリスクが低いとは限りません。  場合によっては、その逆もあります。人気の高いプロジェクトにはより多くの開発者が集まるため、コーディング品質にばらつきが生じたり、すべての新機能やコード変更を適切にレビュー・テストすることが難しくなったり、新たなユースケースに対応するために機能追加を急いだりする可能性があります。  こうした要因は、コード品質の低下や予期しない脆弱性の混入につながり得ます。

大規模で複雑、かつ広く利用されているオープンソース・プロジェクトは、悪意ある攻撃者にとっても魅力的な標的です。ソフトウェアが公開され、簡単にダウンロードできるため、攻撃者はコードを分析し、稼働中のシステムで悪用できる脆弱性を探すことができます。コードの脆弱性をスキャンできる新しいAIツールの登場により、このリスクはかつてないほど高まっています。さらに、悪意ある攻撃者が正規の開発者を装い、巧妙に隠されたバックドアや脆弱性をオープンソースソフトウェアに混入させようとする可能性もあります。多くの開発者が参加する大規模プロジェクトでは、悪意あるコードが気づかれないまま追加されるリスクが高まります。

サポートされていないプロジェクトに依存する

多くのオープンソース・プロジェクトは活発に開発が続けられていますが、すべてがそうではありません。多くのプロジェクトは、特定の問題を解決するために1人の開発者または小規模チームによって作成されます。プロジェクトが完成すると、開発者が別のプロジェクトへ移り、元のコードベースの保守を継続しないこともよくあります。

こうしたプロジェクトを利用する企業にとって、これは長期的なコンプライアンス・リスクになります。特に、重要で長寿命の製品では深刻です。プロジェクトが放棄されてから長い時間が経った後に、脆弱性が見つかることがあります。  影響を受けるコンポーネントを使用している企業は、自力で問題に対処しなければなりません。  オープンソースソフトウェアの複雑さによっては、これは大きな課題になります。問題を修正するために必要なスキルを持つ開発者が社内にいないかもしれません。必要なスキルがあったとしても、慣れていないコードベースを理解し、問題をデバッグし、修正方法を設計するまでに数週間かかる可能性があります。

SBOMをコンプライアンス文書としてだけ扱う

SBOMは、脆弱性管理、製品の可視化、ライフサイクル・ガバナンスを支える運用ツールとして活用すべきです。コンプライアンス・プログラムにおける重要な文書ではありますが、あくまで出発点にすぎません。

OEMとソフトウェアベンダーのためのアクション項目

CRA対応プログラムの中でオープンソースソフトウェアの利用に対処しようとする組織は、次の行動を検討すべきです。

直ちに取り組むべき優先事項

  1. オープンソースソフトウェア利用のガイドラインを策定する。
  2. すべての製品に含まれるオープンソース・コンポーネントの完全なインベントリを作成する。
  3. 継続利用を承認するオープンソース・プロジェクトを特定する。
  4. サポート終了、放棄、または高リスクと判断されたオープンソース・プロジェクトの利用をなくすための移行計画を作成する。
  5. 自社製品で利用しているオープンソース・コンポーネントの脆弱性監視プログラムを構築する。
  6. 自社製品で利用しているオープンソース・コンポーネントの脆弱性対応計画を作成する。  これには、対象プロジェクトに商用サポートを提供する企業を探すことや、ソフトウェアを支援できる社内リソースを育成することが含まれる場合がある。
  7. 自社にとって重要なオープンソース・プロジェクトへの支援を検討する。
  8. 社内におけるオープンソースソフトウェア利用の責任者を明確にする。
  9. オープンソースソフトウェアの利用方針と脆弱性軽減計画を文書化する。

オープンソースソフトウェアがなくなることはありません。しかし組織には、自社製品に含まれるソフトウェア・コンポーネントと、それらがもたらすリスクを継続的に可視化する必要があります。製品、依存関係、脆弱性が変化すれば、その理解もそれに合わせて更新しなければなりません。

OmniTrust Certifyがどのように支援できるか

オープンソースソフトウェアがなくなることはありません。しかし組織には、自社製品に含まれるソフトウェア・コンポーネントと、それらがもたらすリスクを継続的に可視化する必要があります。製品、依存関係、脆弱性が変化すれば、その理解もそれに合わせて更新しなければなりません。

OmniTrust Certifyは、ソフトウェア構成、脆弱性、サイバーリスク、規制要件、コントロール、エビデンスを製品ライフサイクル全体で結び付ける、常に更新される製品プロファイルを作成します。

OmniTrust Certifyを利用すると、組織は次のことができます。

  • ソースコード、バイナリ、ファームウェアからSBOMを生成する、または既存のSBOMを取り込む
  • オープンソースおよび第三者製ソフトウェアのコンポーネントと依存関係を特定する
  • 新たな脆弱性インテリジェンスを継続的に監視し、新しい脆弱性を影響対象の製品と照合する
  • 特定された脆弱性が製品のサイバーセキュリティ・リスクに与える影響を評価する
  • 脆弱性のレビュー、対応、軽減、関連エビデンスを追跡する
  • CRA要件およびその他の適用される規制・標準に照らして製品を評価する
  • 製品、コンポーネント、脆弱性、要件の変化に応じて継続的に再評価する

SBOMを静的なコンプライアンス文書として扱うのではなく、CertifyはSBOMを常に更新される製品記録と結び付けます。これにより、組織は製品に何が含まれているのか、何が脆弱なのか、何がリスクにさらされているのか、そして何をすべきなのかを理解できます。

まとめ： オープンソースソフトウェアは、今もイノベーションを加速する最大の要因の一つです。CRAはその利用を妨げるものではありませんが、組織に責任ある管理を求めます。商用ソフトウェアとは異なり、組織はコントロール権を持たないまま責任を引き受けます。成功する製造業者は、自社がどのオープンソースを使用しているかだけでなく、重要な依存関係ごとの成熟度、健全性、サポート可能性、継続的なセキュリティ状況も把握するでしょう。だからこそ、オープンソースソフトウェアは経営会議の議題になったのです。

このシリーズの今後の記事（次回は「ブログ#10：評価は簡単。修復は難しい。」）について通知を受け取るには、ブログのホームページから購読してください。