求められるSBOM対応、ソフトウェアのリスク管理は「待ったなし」、さあどうする？：OSS活用の際に直面する“3つの課題”と自社システムの脆弱性にどう立ち向かうか

各国政府や国際機関が、SBOMなどを通じたサイバーセキュリティやソフトウェアのサプライチェーンへの取り組みを急速に進めている。これは人ごとではない。各国政府や、業界団体は、制度化や国際標準化により企業への対応を強く求めている。今後、企業にはどういうアクションが求められるのだろうか。

[PR／＠IT]

高まるSBOM導入の機運、継続的な監視／運用の体制作りが重要に

　ここ数年で、オープンソースソフトウェア（OSS）の利用リスクに大きな注目が集まるようになった。「Apache Log4j」で明らかになった脆弱（ぜいじゃく）性の問題は、今やOSSがあらゆるところで使われており、セキュリティ上の問題がもたらす社会的インパクトが大きいという事実を浮き彫りにした。

　とはいえ、OSSのサプライチェーンや脆弱性の管理については、把握が難しく、これまで対応が遅々として進まない現状があった。それが昨今では、「SBOM」（Software Bill of Materials：ソフトウェア部品表）への取り組みが政府機関や標準団体、業界レベルで進められるなど、状況は大きく変わりつつある。

　例えば、2021年5月のサイバーセキュリティに関する米国大統領令（EO 14028）に端を発して、米国や欧州などの各政府機関や産業向けの標準規格などにソフトウェアサプライチェーンやSBOMに関する項目が含まれるようになった。また、2023年5月に広島で開催された日米豪印「クアッド」首脳会合では、SBOM管理が明記された。そして、2023年7月には経済産業省がSBOMの導入に関するガイドラインを公開した。このように、SBOMの導入機運は急速に高まっているのだ。

　こうした状況について、「OSSからプロプライエタリソフトウェアまでの脆弱性やサプライチェーンに関するソフトウェアのリスク管理を、SBOMを活用して適切に対応することは必須になりつつあります。企業はビジネス継続のため、いかに効果的にソフトウェアのリスクに対応していくかが問われています」と、SRAの山口大介氏（産業第1事業部 営業部 部長）は指摘する。

　「2021年の米国大統領令を受け、NIST（米国立標準技術研究所）がSBOM活用のガイドラインを策定しました。SBOMは米政府調達の要件に加わりつつあり、IoT向けの欧州標準規格『ETSI EN 303 645』や、自動車向けのサイバーセキュリティに関する国際標準規格『ISO/SAE 21434』、UNECEが採択した『UN-R155』『UN-R156』などにも必要となってくる手段です。OSSが組み込まれたIoT機器、自動車、産業機器に問題があると場合によっては人命にも関わります。

　既に当社のお客さまにも、サプライチェーンでSBOM提出を要件として明記するところが出てきています。Synopsys, Inc.が毎年公開している調査レポート（2023 オープンソース・セキュリティ＆リスク分析レポート）によると、調査対象のソフトウェア1703本中、OSSを含む割合は96％におよび、その調査対象となったソフトウェアのコード総量の76％はOSSが占めているとのことです」（山口氏）

OSS利用において直面する“3つの課題”とは

　OSSを利用する上でのリスク対応は、決して簡単な取り組みではない。山口氏によると、企業が直面する課題は大きく3つあるという。

［課題1］脆弱性管理

　1つ目の課題は「利用しているOSSの把握（脆弱性管理）」だ。

　「OSSはさまざまな経路で企業の中に入ってきます。きちんと管理された状態で入ってくればよいですが、開発者が承認を得ずダウンロードして直接入ってくるもの、既存製品のコードを再利用する際に含まれるもの、開発パートナーから提供されるコードに含まれているものなどがあります。多くの企業は、このように混入してくるOSSをきちんと管理できていません。どんなOSSが、どういった経路で入ってくるかを把握し管理する必要がありますが、可視化ができていないためにどんな脆弱性があるかも分からないのです」（山口氏）

［課題2］ライセンスコンプライアンス

　2つ目の課題は「ライセンス把握の難しさ（ライセンスコンプライアンス）」だ。

　「OSSはライセンスの種類が2000以上もあり、大別しても数十におよび、派生やバージョンアップ、ライセンス変更なども頻繁に発生します。自社での利用に当たって考慮が必要なコピーレフト性の強いライセンス、例えば、GPL（GNU General Public License）は、二次的著作物に関してもGPLでライセンスしなければなりません。また、他のOSSライセンスでもGPLとはライセンスが両立しないケースなども発生します。自社のポリシーに合ったライセンスを利用し、ライセンス条件にきちんと対応していくことが求められます」（山口氏）

［課題3］能動的な継続的監視と修正

　3つ目の課題は「メンテナンスの難しさ（能動的な継続的監視と修正）」だ。

　「OSSは使うことが当たり前になっています。先ほど取り上げたSynopsys, Inc.の調査では、対象のコードベースの96％にOSSが含まれるほどです。OSSはコミュニティーで開発されるものなので、開発の活発度や脆弱性対応はまちまちです。自社で利用していくに当たって、セキュリティアップデートを含め、メンテナンスがきちんとされているかどうか、開発を維持できる体制になっているかどうかなどをしっかり把握する必要があります。また、新たに脆弱性が発見されたら、自社で利用しているものについて適切に追随してアップデートしていく必要があります」（山口氏）

　これらの課題は、SBOM作成の難しさに直接的に関わってくる。

　「SBOMの項目は多岐にわたり、脆弱性管理、ライセンスコンプライアンス、コミュニティーの維持・運用性を考慮して作成していく必要があります。フォーマットにはISO/IEC 5962:2021として標準化されたSPDX（Software Package Data Exchange）やCycloneDXなどがありますが、対象となるOSSの数も膨大になるため、手動で作成し、手動で監視していくことは現実的ではありません。フォーマットの違いを吸収し、項目数の多さに効率良く対応していくためにツール活用は必須です」（山口氏）

SBOM／OSS管理ツール「Black Duck」で継続的な監視体制の構築を

　SRAがこうしたSBOMを中心としたOSS管理におけるリスク対応のためのツールとして提供しているのが、シノプシスのSCA（ソフトウェアコンポジション解析）ソリューション「Black Duck」だ。

OSSのコードから生じるセキュリティや品質、ライセンス、コンプライアンス上のリスク管理を支援する「Black Duck」（提供：SRA）《クリックで拡大》

　1つ目の課題である脆弱性管理については、SBOM作成後にソフトウェアがどうバージョンアップされ、どのバージョンで脆弱性が発生しているかなどを継続的に監視していくことが可能になる。

　「シノプシスは専任のセキュリティのリサーチャーチームを独自に持っています。公式に提供されるNVD（National Vulnerability Database）やCWE（Common Weakness Enumeration）などの脆弱性情報とは別に、堅牢（けんろう）な独自のナレッジベースを持っているのが強みの一つです。CSIRT（Computer Security Incident Response Team）やIEC62434などの対応でPSIRT（Product Security Incident Response Team）を運用しているような組織では、管理すべき脆弱性の項目は膨大になりますが、Black Duckはそれらに対して網羅的に人手を介さずに対応することを可能にします」（山口氏）

　2つ目のライセンスコンプライアンスについては、ライセンスのバージョンアップや新しいライセンスの追加などをナレッジベースにより把握できるようにし、ライセンスの条件を順守しているか否かを確認できる。

　「新たなOSSライセンスや、ライセンスのバージョンアップ、変更をそのたびに調査するのは大きな負担です。Black Duckを利用すると、ユーザー側でポリシーを決めておくことで、ライセンスを適切に利用できるようになり、バージョンアップやアップデートの際にも、手動で調査する必要がなくなります」（山口氏）

　3つ目のメンテナンスの難しさについても、ナレッジベースにより、OSSコミュニティーの活発度やその継続的な監視が可能となる。

　「脆弱性管理やライセンスコンプライアンスを含め、さまざまな情報源から情報を収集して、継続的に監視できる体制を構築する必要があります。継続的な監視体制の確立は、ソフトウェアのコンプライアンス／リスク対応において最も重要な取り組みです。特に、SBOM作成後は、ソフトウェアサプライチェーンにわたって膨大な情報を継続的に監視し、運営していくことはツールを使わなければ不可能です。Black Duckは、OSSを使用した場合に発生するセキュリティ、ライセンスコンプライアンス、運用リスクを最小化し、SBOM作成までを包括的に提供し、継続的な管理・監視を可能にします。また、ソフトウェア開発プロセス全体にわたってそれらを自動化することができるため、迅速なソフトウェア開発や品質改善、各種ガイドラインや標準規格に沿った運用を可能にします」（山口氏）

　SBOMは、OSSに特化したものだと思われがちだが、実際にはプロプライエタリなコードも含めてソフトウェアがどのような部品で構成されていくかを管理していくための仕組みだ。そのため、OSSだけでなく独自コードの脆弱性にも対応していくことが重要になる。

「Coverity」で「残り24％」のプロプライエタリコードの脆弱性をチェック

　SRAはOSS以外のプロプライエタリコードの脆弱性管理ツールとして、シノプシスが開発する「Coverity」を提供している。Coverityは、アプリケーションのソースコードを静的に解析し、脆弱性や問題を特定するための静的解析（SAST：Static Application Security Testing）ツールだ。

　「OSSの脆弱性はBlack Duckで管理できますが、OSSではない『残りの24％』のプロプライエタリコードの脆弱性は別の手法で見つける必要があります。そこで、SRAではBlack DuckとセットでCoverityを利用することを提案しています。Coverityを利用すると、脆弱性を含むようなセキュリティに問題があるコードの書き方をしていないかどうかをチェックできます。米OWASP（Open Web Application Security Project）が公表している脆弱性情報『OWASP Top 10』やCWEなどに基づいたチェックが可能です。自動車業界における機能安全規格『ISO 26262』やMISRA（Motor Industry Software Reliability Association）、AUTOSARなどの団体の規格、クレジットカード業界の『PCI DSS』、医療業界の『FDA（米国食品医薬品局）』が規定するガイダンスなどに対応したチェックも可能です。また人間では難しい処理をまたぐプロシージャ間の解析なども可能です」（山口氏）

　現代の社会においてソフトウェアの重要性は増すばかりだ。例えば、自動車業界では、自動運転や電動化、コネクティッドなどのトレンドが進展する中、車載ECUやエッジコンピュータが扱うコードは数千万行にも達する。それらコードの脆弱性を人手のみで管理するのは不可能であり、Coverityのようなツールは不可欠な状況だ。また、車載デバイスでは複数のメーカーやサプライヤーがソフトウェアを開発していく。つまり、ソフトウェアサプライチェーン全体にわたってSBOMを管理することが不可欠になりつつある。

ツールだけでは対応できないことも……その際の支援もSRAが提供

　その一方で、ツールだけでは対応できないシーンも増えてきているという。

　「まずは、SBOMを中心に、ツールを使ってOSSとプロプライエタリコードを管理し、サイバーセキュリティやサイバーレジリエンスに向けたコンプライアンス／リスク対応を包括的に実施することが重要です。ただし、ツールを導入すれば解決できるというわけではありません。例えば、ポリシーやガイドラインをどう作るか、開発プロセスやライフサイクルにどうツールやポリシーを適用していくかなどは、ツールでは及ばないところです。SRAでは、そのようなツールでは埋められないところも含めて支援しています」（山口氏）

　この他、SRAでは、既知の脆弱性管理や静的解析、SBOM管理などだけでなく、ゼロデイ脆弱性のような未知の脆弱性に対応するためのファジングテストツールやアプリケーションの振る舞いをチェックするIAST（Interactive Application Security Testing）ツール、ハッキングサービスなども提供する。

ツールだけでは対応できない部分は、SRAの各種ソリューションで対応、支援していく（提供：SRA）《クリックで拡大》

　SBOM対応をはじめとして、ソフトウェアの脆弱性やサイバーセキュリティに対応し、ビジネスのレジリエンスを高めていく上で、SRAが提供するソリューションは大きく役立つはずだ。