経済安全保障推進法でサプライチェーンのリスク可視化が必須に
経済安全保障推進法とは、経済活動において国家や国民の安全を維持するために、リスク管理の基本方針策定や、必要な制度の創設を定めた法律である。2021年、Apache Log4jライブラリに関する複数の脆弱性が報告されたことなどを皮切りに、日本でもサイバーセキュリティ確保への対策が急務だという動きが起こり誕生した。
同法律が最初に交付されたのは2022年。そこからは段階的な施行が行われ、2024年5月からは、「重要インフラ事業者は、重要設備の導入時にリスク管理施策の導入計画を届出し、審査を受ける」義務が生じる。また、サプライチェーンの導入計画書の届出時に、リスク対策状況を確認できる資料などの提出が求められるなど、より具体的な行動が要求されるようになった。
NRIセキュアテクノロジーズの御舩愛輔氏は、本講演でソフトウェアサプライチェーンのリスク管理施策に焦点を当てた解説を行った。ソフトウェアの開発には、そのプロセスの中で多くの事業者が関わる。そのため、オープンソースソフトウェア（OSS）の使用を含め、リスク混入の可能性が様々な局面で存在する。
講演の冒頭、御舩氏は「リスクが混入する箇所を特定することが困難であるのは間違いない」としながらも、この責務から逃れることは不可能であり、特定と整理に必要な知識をつけなければならないと強調した。
［画像クリックで拡大表示］
リスク管理施策に活用できる国内外のガイドライン
リスク管理施策の作成に向けて、御舩氏は安全な開発を促進するガイドラインの利活用を推奨した。一般的に、多くのガイドラインではセキュアな開発のための要求事項が定められている。活用するガイドラインとしては、NISTの「Supply Chain Risk Management Practices for Federal Information Systems and Organizations」や米政府が資金提供するMITRE（マイター）社の「System of Trust」など、それぞれの目的に応じて国際的に多くのガイドラインがある。また、経済安全保障推進法においても「経済安全保障推進法の特定社会基盤役務の安定的な提供の確保に関する制度について」にて「リスク管理措置の一覧」が提供されている。
たとえば「リスク管理措置の一覧」では、特定社会基盤役務者に向けたリスク管理施策として、「特定重要設備に、悪意のあるコード等の混入を確認する受入検査、その他の検証体制を構築すべき。脆弱性テストを導入までに実施すべき」といった概要が記載されており、実際のリスク管理措置の参考にできる。
また、ソフトウェアのライフサイクルにおける工程ごとにリスクや要求事項を分類して整理することで、抜け漏れを防ぐことが可能だ。次図のように一覧化して整理すれば、工程ごとに考慮すべきリスクの有無を確認しやすくなる。
さらに、組織のITプラクティス戦略策定などで用いられるPPT（People、Process、Technologies）フレームワークを使用し、「人員・プロセス・技術」の観点から領域ごとに顕在化するリスクを検討すれば、より網羅的にリスクの主体や対する要求事項の整理ができるようになると御舩氏は説明する。
ソフトウェアサプライチェーンの各工程でとるべき施策
次に御舩氏は、ソフトウェアサプライチェーンのリスク管理に関する具体的な施策を紹介した。施策は、「調達→製造・開発→リリース・デプロイ→運用」の各工程に沿って構築する必要がある。
はじめに、全工程に共通する施策として、システムの構成や資産の管理、脅威分析、セキュリティ要件の明確化を実施し、組織全体に浸透させなければならない。これには、各種操作のログ取得と定期的な監査体制の確立、技術進化に適応できる開発者を育成するための教育体制の整備などが含まれる。
では、それぞれの工程におけるリスクや施策の例を見ていこう。まずは調達工程、システム開発時に使用するライブラリやソフトウェアの調達、業務委託先の選定を行う工程だ。ここでのリスクとしては、サードパーティー製コンポーネントへの悪意あるコードの注入や、委託先従業員による不正な改造が考えられる。これに対処するためには、製造組織がコード検査を行い、調達した人材のリスト管理を徹底するなどの施策が必要となる。
次に、製造・開発工程。ここでは、システムの設計や実装、テストが行われる。想定されるリスクとしては、ソースコードへの悪意ある変更が加えられることや、CI/CDパイプライン上の秘密情報の漏洩などが挙げられる。対策として、ソースコードへの変更をコミットログから確認し、開発ソースコードやパイプライン上に秘密情報を表示しないことが有効だ。
続いてはリリース・デプロイ工程、ソフトウェアの配布を行う工程だ。配布時に正規でない悪性のソフトウェアが利用されるリスクが想定されるため、ソフトウェアのバージョン管理と構成管理を適切に行い、リリース時にはデジタル署名を付与して提供することが対策として重要だと御舩氏は述べる。
そして最後の運用工程では、システムの稼動中に、運用担当者による不適切な変更が行われるリスクが存在する。対策としては、運用環境で不正な変更が行えないようにアクセス制御を設けることや、システムを安全に管理するために監視や不正検知を行うことが挙げられる。また、インシデント発生時に迅速かつ適切に対応できるよう、インシデント対応プロセスを文書化し、運用担当者が十分な訓練を受けておくことも必要である。
事例で解説、第三者視点によるセキュリティ対策評価
各工程でのリスク管理施策を紹介した後、御舩氏は、NRIセキュアテクノロジーズがある顧客向けにリスクや要求事項を分類・整理して評価した事例を紹介した。その顧客は経済安全保障推進法への対応を目指し、セキュリティ対策を第三者の視点で確認したいが、現状そのような仕組みがなかったため、同社がこれに対応した。
まずは、MITREのSystem of Trustや経済安全保障推進法に関するリスク管理措置などのソフトウェアサプライチェーンに関係する4つのガイドラインを基に、これに記載された要求事項を集約して、顧客のセキュリティ対策の一覧を作成。この一覧に記載された要求事項は、ビジネスオーナーがビジネスの重要度や影響を考慮し、どの対策を優先的に実施するか柔軟に選択できるよう、3つのレベルに分類された。
レベル1「Basic」には、必ず対策すべき要求事項が振り分けられた。直ちに対応されない場合は、検証の報告レポートで必ず対応が求められるような事項だ。レベル2「Advanced」には、個人情報を扱うなど重要度が高い場合に対応すべき事項が当てはまる。検証の報告レポートでは、対応されていない箇所が重要部分であれば対応が求められる。そしてレベル3「Extreme」に該当する事項は、対応は任意であり、ビジネスオーナーの判断に委ねられる。対応の難易度や費用対効果を踏まえて対応可否を検討する。
セキュリティ対策をこうした一覧に則って実施してもらった後、同社は顧客の開発部門や運用部門などにヒアリングを実施し、要求事項の実施状況を調査して評価を行った。評価の結果、御舩氏は「実際に稼働しているシステムでも、ソフトウェアサプライチェーン対策が十分に進んでいない」との所感を得たと述べ、サービスリスク分析の不十分さ、開発環境でのログ取得の未実施、人員管理や不正コード混入の確認の不定期実施、SBOM（Software Bill of Materials）の未導入などの課題を挙げた。
SBOMとは、製品に含まれるソフトウェアのコンポーネントや依存関係、ライセンスデータなどを記した一覧表である。経済安全保障推進法におけるリスク管理措置として含まれる、悪意のあるコード等の混入の検査のためにも、今後対応が求められていく技術であると考えられる。
そして最後に、評価への対応には、開発部門だけでなく組織全体での取り組みが必要である。技術的な対策においては、共通基盤へのソリューションの埋め込みを含め、開発現場の導入負担を低減したり、対応コストの最適化を図ることも大切だ。対策を標準化し、全社的な取り組みとして具体化することが必要だと御舩氏は強調し、講演を締めくくった。
