目次
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
本稿では、これまで多くの組織では別々に対策が進められていることが多い、“OSS利用によるサイバーセキュリティへの対応”と“OSSコンプライアンス管理”の共通性に着目して、双方への効率的で実効性のある対策方法を考察して行きたいと考えています。
1． ソフトウェアのサイバーセキュリティ問題とは
2． OSSコンプライアンスにおけるSBOMとは
I. ISO/IEC 5230:2020
II. ISO/IEC JTC15962:2021とは
III. 上流からSPDXが入手できない場合のソースコードスキャン
3． サイバーセキュリティ対策とのSBOM共有
4． まとめ
1.ソフトウェアのサイバーセキュリティ問題とは
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
最初にサイバーセキュリティの問題についての考察から始めます。近年、この問題はランサムウェア攻撃あるいは個人データの流出・売買というネット上の脅威に対するリスクマネジメントとして広く認識されています。有名な攻撃手法は、マルウェアの利用、ソフトウェアの脆弱性を突いての外部からのネットワークへの侵入が挙げられ、怪しい添付ファイルを開かないなどの啓発活動はもちろん、日常からのソフトウェアのセキュリティ管理が求められています。また、攻撃対象は企業やインフラ、公的機関などの基幹システムだけでなく、ネットワークに繋がる製品も含まれます。製品については、自動車などの工業製品だけでなく、病院のネットワークや患者の自宅のインターネットサービスにも接続される医療機器が、生命の危険に直結する（薬機法の分類が“高度医療機器”の場合）、分野として注目されています。
国内外での対応例としては、2021年5月の米国EXECUTIVE ORDER 14028, IMPROVING THE NATION’S CYBERSECURITY（国家のサイバーセキュリティ向上に関する大統領令）を受けた、NISTやOpenSSF（Open Source Software Security Foundation ) などが有名です。また、2022年3月に経済産業省・商務情報政策局・サイバーセキュリティ課から発表された、「サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォースの検討の方向性」によると、先の医療機器については、IMDRF（International Medical Device Regulators Forum = 国際医療機器規制当局フォーラム）および、AMED（Japan Agency for Medical Research and Development = 国立研究開発法人日本医療研究開発機構）における対応に言及があります。
各種情報を当たってみると、SBOM（Software Bill of Materials = ソフトウェア部品表）の管理が各所で強調されていることがわかります。これが、本稿の表題を選んだ理由でもあります。
例えば医療分野において言われていることは、次のように、OSS管理においてもなじみの深い事項になっています：
- SBOMにより、脆弱性が潜んでいる可能性があるソフトウェアの特定、要件の更新及び適切なセキュリティリスクマネジメントの実施を医療機器製造業者と協力して促進することができる。
- アプリケーションで使用されているコンポーネントを可視化して顧客に提示できると共に、潜在的セキュリティリスクを特定できるため、購入決定に必要な情報を提供することが可能となる。
- 製造業者はSBOM の展開で使用される形式、構文、マークアップに関する業界のベストプラクティスを活用することが望ましい。
さて、議題をOSSのSBOM作成にフォーカスすると、今ではツールを使って作成しているという方法が一般的と思われます。この際、①コンプライアンス対策のためのソースコードスキャンツール（SBOMで出力）と、②セキュリティ対策のための情報管理システムを一つのトータルシステムで行うか、それぞれ専用のものを利用するかは注目点です。前者の場合は、セキュリティ情報を管理するオプションを持つOSSスキャンツールとOSSスキャンオプションを持つセキュリティ管理システムはどちらがいいのかという問題があり、後者ではSBOMを二重に作るのか、何らかの方法で共有できるようにするのかという問題があります。この辺りはユーザーごとのニーズ次第ではあるのですが、前者について現時点ではオプション機能は専用機能に敵わないという声を聞きますし、後者の場合でもSBOMの二重登録は手間としてもスキャン性能の違いからも現実的でないようです。
そうなると残る選択肢は、専用システムを用意する場合において、ソースコードスキャンツールで出力したSBOMをそのままセキュリティ管理システムで取り込めるようにする方法です。いずれにしても、重視すべき点は、脆弱性があることが判明したソフトウェア（OSSを含む）に対するセキュリティパッチ適用または他のソフトウェアへの置きえのリードタイムを如何に短くするかという点ですね。
2.OSSコンプライアンスにおけるSBOMとは
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
コンプライアンス視点でのSBOM管理と言うと、「既に知っている」、「何度も読んだ（聞いた）」という方が多いと思いますので、ここでは業務の効率化やツールの活用という視点を取り入れながら再確認します。
なお、関連する国際標準は、コンプライアンス要件を定義するものが2020年発効のISO/IEC 5230:2020で、SBOMの形式を標準化したSPDX（Software Package Data Exchange）に関する2021年発効の国際標準が、ISO/IEC JTC15962:2021となります。
I. ISO/IEC 5230:2020
組織がOSSのコンプライアンスを遵守し、ソフトウェア開発やその組み込みを適切に行うための要件を定義する国際標準です。本稿は適合要件の解説が趣旨ではありませんので、実務として理解しやすいように、皆様がOSSを手に入れてから次工程（お客様や、社内次工程あるいはサプライチェーンの次工程）に手渡すまでの一連の流れの中で、当事者は何をするべきかという視点で図示します。図の左から右に向かって、サプライチェーン上流から下流に進むイメージです。
こうして全体の流れを描きおろしてみると、OSS利用の起点が必ずしも自分自身だけではなく、サプライチェーン上流でOSSを組み込まれたモジュールの形もあることがはっきりすると思います。コンプライアンス遵守、すなわち的確にライセンス条件に従うためには、これら両ルートから取り入れることになったOSS全てを正確に把握する必要があるわけです。
一般的に自主的に選んだOSSは一定の信用度があり、OSSスキャンツールを利用することで、裏付けが取りやすくなり、業務効率化が進みます。具体的には、スキャン結果からSBOMを自動生成し、後段の出口監査では再スキャンで差分を見れば監査の負荷が減ります。更には、取扱説明書等へのライセンス情報掲載についても、自動的にライセンスファイルから抽出してくれるようなOSSスキャンツールが存在しています。
ところが、サプライチェーン上流に一社または複数社のOSS利用者がある場合、正確に全てのOSSのSBOMが入手できるかには一定の配慮が必要です。サプライヤー様から的確なSBOMがいただける場合は良いのですが、ある程度の頻度でSBOMがなかったり明らかに不正確だったりする事象が起き得ます。OpenChain Japanが問題提起する、次の図2のように、サプライチェーン経由でライセンス違反状態のOSSが混入したとして、自社がそれを製品化して上市すれば、自社もライセンス違反を侵す事になってしまうため、細心の注意が必要な問題です。
このようなとき、自らがライセンスを受けているOSSスキャンツールを第三者であるサプライヤー様に貸与することはできません（一般的にはライセンス違反）ので、サプライヤー様のソースコードを自らスキャンし、自ら使用するものと同形式のSBOMで結果を出力することが解になります。とは言え、相手のある話ですのでうまく合意ができるかは未知数です。後段の2.3節でや3節で引き続き考察してみることにします。
Ⅱ. ISO/IEC JTC1 5962:2021とは
前章のように、サプライチェーン間のOSS情報の授受を標準化する手段の一つがSBOMの共通化です。古くからOSSコンプライアンスに取り組んでいる会社になると、自社が使いやすい独自のExcel帳票により情報管理されているかもしれません。実際、筆者もサプライヤー様から、当社のためだけに、当社様式のOSSリストを作成することに難色を示された経験は少なくありません。
このため、OSSコンプライアンスがサプライチェーン全体の問題と認知された現在、SBOMの書式を標準化することに、まずは合意しやすさの点で価値があると考えています。また、SBOMの書式がSPDXに統一されたことで、 OSSスキャンツールからSPDX形式で自動出力できる点も、業務効率化に寄与します。他方では、標準化の過程で落とされた項目もあるわけで、自らの組織内から一部不満の声が挙がる覚悟も必要になり、そこはオープンな活動で仕様を検討しているSBOMの検討会（日本国内では、OpenChain Japan）への意見提案などの形式で、全体でメンテナンスして行くことが良いと思います。なお、現時点のSPDXの仕様は、ISO/IEC JTC1 5962:2021を参照して下さい。
Ⅲ. 上流からSPDXが入手できない場合のソースコードスキャン
前述した、上流のサプライヤー様のソースコードを自らスキャンする方法について補足します。一般的には秘密保持契約などに基づいて相手先からソースコードをお借りしてスキャンすることになります。ただ、この案には反発を受けることも少なくないのが現実で、「たとえ秘密保持契約を締結しても、ソースコードは門外不出だ」と断られることは想定しておかなければなりません。このとき、次善の策としては次のような機能を持つツールを導入する方法があります：
- バイナリからOSSスキャンできるツール
- ツールが提供する機能で相手先においてソースコードを暗号化していただき、暗号化されたソースコードを借り受けてOSSスキャンできるツール
これからOSSスキャンツールを導入しようという皆様は、ぜひこのような観点にも着目されることを推奨します。
更に、最近のOSSスキャンツールは、OSSとそのバージョンがわかるだけではなく、業務効率化に貢献してくれる機能を持つものが珍しくありません。
- 抽出した情報をSPDX形式で出力できる
- 使用するOSSの著作権情報・ライセンス全文を、ライセンスファイル等を検出して自動抽出できる
これらが目視チェック不要なレベルで正確に出力できるとすれば、OSSコンプライアンス業務の作業負荷は、劇的に下がるのではないでしょうか。
3. サイバーセキュリティ対策とのSBOM共有
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
セキュリティとコンプライアンスの双方の話が終わったところで、図1で見たOSSコンプライアンスの体制図に、セキュリティ対応体制を重ねたものを、次に図3として示します。
セキュリティアラートは、決して上市されてからのサービスのためだけに必要なものではなく、上流から入ってくるOSSや、まさに開発工程においても、即座に対応が必要なものです。理想を言えばOSSコンプライアンスで使うツール類とセキュリティシステムが統一されていることですが、先ほど見たように必ずしも理想はまだ実現されたとまでは言えません。そこで、上流と下流でシステムが分かれていたとしても、現場の負荷をミニマムにしながらデータの受け渡しができることが重要です。
このとき、セキュリティ管理システムでは、OSSについてコンプライアンス上で必要な情報が全て必要になることはなく、主にOSSの身元が特定できれば良いため、OSSスキャンツールが出力したSBOMを起点に、必要な領域だけをセキュリティ管理システムに取り込むためのインターフェースを作成する手段が現実的と思われます。
一方で、ツール類の供給元となるベンダー各位に対しては、自社で全ての機能を用意する方向だけでなく、SBOMを介してシームレスにシステム間連携できる機能をご用意いただけることを望んでいます。
まとめ
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
以上見て来たように、“OSS利用によるサイバーセキュリティへの対応”と“OSSコンプライアンス管理”は、SBOMの標準化を経て、ツールの力も借りながら効率的で実効性を持った一括管理が実現できる可能性が見えています。
ここに至るまでに、サプライチェーンに含まれる各企業・組織内でのコンプライアンス活動への取り組みから始まって、異なる組織間のOSSと必要な付加情報の授受において失敗が起きにくい方法をOpenChainなどのオープンな場での議論を経て実務に応用し、そして今は上市された後の脆弱性発覚時の対応も一連の流れに取り込まれようとしています。
その一方で、これらを効率的に行うための自動化を実現する上では発展経緯が異なるそれぞれのシステムがうまく連携できるかが当面の壁になっているため、システムベンダー各社のこれからの動きにも注目したいと思います。
※本文中記載の会社名、商品名、ロゴは各社の商標、または登録商標です。
Tips集のご案内
テクマトリックスでは、開発企業としてOSSと上手につきあうための「OSS活用Tips集 – シーズン2」を提供しています。
「資料ダウンロードはこちら」から、ホワイトペーパーを一括でダウンロードできます。
1.「OSS最新動向-コロナに負けないオープンソース」
2.「オープンソースSBOMが必要な理由とは！」
3.「ソフトウェアイノベーションはOSSから、コンテナ・AI技術がイノベーションを牽引」
4.「OSSと上手に付き合う方法～攻めは最大の防御なり～」
5.「OSSと上手に付き合う方法～サプライチェーンを安全に～」
6.「ISO/IEC 5230で変わる？OSSコンプライアンス対策」
7.「著作権トロールとは？」
