検索
Japan
SBOMに関する質問と回答まとめ（OSSマネジメントフォーラム2022 Day1）
先日開催された「OSSマネジメントフォーラム2022」にて、経済産業省の三田様にSBOM関連の内容についてご講演いただきました。また講演を終えた後には聴講者の皆様からの質問にもお答えいただきました。本ブログではその際にいただいた質問と、それに対する回答のサマリーを掲載します。核心に触れる質問を数多く頂戴しましたので、参考にしていただければ幸いです。
質問と回答
Q：OSSの中でも、脆弱性の対応の頻度の高いものは、SBOMでトレースする意義が高いと思うのですが、そのようなOSSごとの更新頻度、脆弱性対応頻度などの情報はお持ちではありませんか？
A：
脆弱性が発見される頻度が高いものはSBOMでトレースしておく意義が高いというのは、そのとおりと考えます。脆弱性が発見された際にもその影響度の大小はありますので、関連情報含め、脆弱性に関する情報を積極的に日頃から収集しておくことは大切だと思います。また、コミュニティ活動が沈下しているようなプロジェクトは脆弱性が出やすい、または脆弱性情報が出た場合に狙われやすいという傾向があるので、使用を控える、または管理と情報収集を徹底して使用する、などの工夫があるとよいと考えます。
（精力的に活動しているコミュニティ、脆弱性への対応が早い・きちんとおこなわれるコミュニティのOSSを選定して使用することもポイントになります。）
Q：SBOMの作り方のフロー・作成のときの注意点を現在把握している限りで教えていただきたいです。
A：
現時点で把握しているものとして、SBOMを作る際には、対象範囲や作成の単位などを検討するため、対象となるシステムの構成を理解しておくことが重要です。また、どのような目的でSBOMを作ろうとしているのかを視野に入れて、適切なツールを選択したりすることも、作成する際の注意点として挙げられます。
Q：SBOMの対象はFOSSのみという理解で正しいでしょうか？米国、欧州の法令に準拠する場合、有償やサードパーティのソフトウェアについてもSBOMとして報告が必要となるのでしょうか？
A：
SBOM作成の目的にもよりますが、ソフトウェアの構成要素を可視化して適切に管理するという観点からすると、FOSS（OSS）だけではなく自社製品などもSBOMの要素として管理しておくことが重要と考えます。
Q：SBOMとして表現されるのはOSSが中心でありそれにより脆弱性・ライセンスコンプライアンスへの対応迅速化を達成しようという動きがある認識です。OSSだけではなく、OSS以外のソフトウェアコンポーネントをSBOMとして表現し、OSSをSBOMとして表現したときに達成できるであろう目的以外の目的を達成しようという動きはあるのでしょうか？
A：
海外における調査結果では、ライセンス管理や脆弱性管理以外に、ソフトウェアの構成情報の共有により開発自体への理解が深まるという効果も期待されています。OSSだけではなく自社製品やサードパーティ製品などを可視化することにより、開発効率化や品質保証などに繋がってくるのではないかと考えます。
Q：本日見せていただいたSBOM実証の一部結果についての資料は公開されていますでしょうか？
A：
ソフトウェアタスクフォースの資料として実証実験の結果や今後の取り組みについての公開情報がありますので、そちらをご参考いただきたいです。
Q：SBOM の入り口である、各ソフトウェアを識別するもの、ID や名称、バージョン表記方法などに関して、業界や標準化団体、国家機関、国際機関として、何らかの活動が進められているのでしょうか？
A：
ソフトウェアの識別については、ソフトウェアタスクフォースにおいても検討を行っておりますので、当該タスクフォースの資料も参照いただければ幸いです。
Q：SBOMは社外に展開しても問題ないのか？（セキュリティ的に）
A：
展開の仕方にもよるところですが、SBOMを展開することがサイバー攻撃に必ずしも直結するものではないと考えられ、また、サプライチェーン上で共有することにより、ソフトウェアの透明性を高めることで、攻撃の影響の有無や範囲など、攻撃に対する防御を高めることが可能と考えられます。
関連メニュー
