![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
しかし、SBOMを利用することで全体像を把握できるようになる。これは、米国商務省電気通信情報局（NTIA）のSBOMによるソフトウェアエコシステムを示したチャートをご覧いただくのがよいと思う。
最終回となる第3回は、SBOMの流通によってどんな「良いこと」と「悪いこと」が起こるかを整理しつつ、品質保証の枠組みへの取り込みについても考察する。
今回のOSSRAレポートでは、オープンソースを含むコードベースの割合が96％、全コードベースに占めるオープンソースの割合が76％となった
「SBOMはもはや選択肢ではない。今回の調査によると、2022年には78％の組織がSBOMを作成または利用する予定だ」
FDAは、同草案の「V．サイバーセキュリティリスクを管理するための SPDF（セキュア製品開発フレームワーク）利用」の「A．セキュリティリスクマネジメント」において、「2．サードパーティー製ソフトウェアコンポーネント」のサプライチェーンリスクマネジメント支援ツールとして、SBOMを取り上げている。
Jarvis 2.0は、ソースコードではなく、バイナリコードを用いてソフトウェア構成解析とセキュリティテストを行えるツールである。ブラックベリー社内での開発に用いられていたツールを外販したもので、組み込みシステム向けに特化していることが特徴となっている。
企業におけるSBOMの準備・採用の度合いと、オープンソースエコシステム全体のサイバーセキュリティの改善に向けたSBOMの重要性について述べているという。
マイクロソフトは、ビルド時にそのソフトウェアがどのようなソフトウェア部品から構成されているかを示すデータ「SBOM」を生成してくれるツール「SBOM Tool」を、オープンソースで公開しました。
サプライチェーン攻撃に関してはMicrosoft以外も取り組んでいて、そのうちのひとつであるGithubのブログを読んでみる。
ここでは、OSSのサプライチェーン管理に関する連載の3回目として、SBOMを解説する。
SBOM を正しく理解していただけるよう、本書ではシノプシスの顧客の間に見られる懸念や混乱についての情報を整理し、その内容をふまえて いくつかの重要な提言をまとめました。SBOM に対する今後の取り組みの軌道修正にご活用ください。
この記事は Google オープンソース セキュリティ チーム、Brandon Lum、Oliver Chang による Google Security Blog の記事 "SBOM in Action: finding vulnerabilities with a Software Bill of Materials" を元に翻訳・加筆したものです。
テーマはSBOM。最近ではカンファレンスのキーワードで扱われる機会が増えてきている。
本セミナーは、2021年5月に開催された回の再放送となります。
本稿では、＠ITが開催した「＠IT ソフトウェア品質向上セミナー」の基調講演「SBOMによるサプライチェーン攻撃対策 ～自社ソフトウェアのリスク、把握していますか？～」で語られた、OSSの使用に潜むリスクへの対処法について、要約してお届けする。
今回の記事では、SBOMを利用した脆弱性管理の取り組みについてご紹介します。
ここへ来て、2020年12月にSBOMの仕様が国際標準「ISO／IEC 5230」として固まり、普及への期待が高まっている。
Black Duckとの違いについて、「組み込みシステムに最適化している点がJarvis 2.0の大きな特徴だ」（同氏）と説明した
Build Security In BSIはセキュリティに関する知識を形式知化することを目的としている。 SBOM （Software bill of materials：ソフトウェア部品表） SBOMはコードベースに存在するすべてのオープンソースおよびサードパーティ・コンポーネントの一覧のことだ。
興味深い内容です。。。政府は重要なソフトウェアを取得する場合は、サプライヤから SBOM を要求すべきという方向に行きますかね。。。
ソフトウェア部品表（ソフトウェアBOM）を使用すると、オープンソースの使用に伴うセキュリティ、ライセンス、および運用上のリスクにすばやく対応できます。
