Open Source Summit Japan 2024 / Japan SBOM Summit 2024 Wrap up

Cybertrust Japan Co. Ltd. / The Linux Foundation Japan Evangelist 池田 宗広氏
2024年12月12日開催 OSSセキュリティMeetup 講演資料

Transcript

1. Open Source Summit Japan 2024 Japan SBOM Summit 2024 Wrap up ~ 2024/12/12 OSS Security Meetup ~ Muuhh IKEDA Cybertrust Japan Co. Ltd. / The Linux Foundation Japan Evangelist
2. 池田 宗広 / Muuhh IKEDA • サイバートラスト（株）OSS事業本部 プリンシパルアーキテクト • The Linux Foundation Japan Evangelist • 喫茶店店員、航空宇宙電子機器生産技術 者、LCDパネル開発者、Linuxカーネル開発 者、ネットワーク機器技術サポート・ビジネス 開発を経て現職 • 担当パートはベースギター及びシャウト 2 2
3. Open Source Summit Japan 2024 3
4. Open Source Summit Japan 2024 イベント概要 4 • 2014/10/28（月）～29（火）＠ 虎ノ門ヒルズ • 言わずと知れた OSS 界（Linux界？）の中心イベント • 北米（春）、欧州（秋口）、日本（年末）の三極で毎年開催 • 参加者数は目算で700～800名程度 • 分野別の「ミニカンファレンス」の集合体という体裁 ◦ Automotive Linux Summit, CloudCon, Critical Software Summit, Embedded IoT Summit, LinuxCon, Open Source Leadership Summit, Operations Management Summit, OSPOCon, SupplyChainSecurityCon • キーノート含め100本程度のセッション ◦ 技術、動向、組織、リーダーシップ、 OSSへの参加など話題は幅広い • 参考： イベントページ
5. 全体所感 • セキュリティは変わらずホットトピック。2024年初頭に起きた XZ Utils 事件は複数の キーノートやセッションで触れられており、OSS 開発者・メンテナに対するトラストと、 OSS PJ の健全性評価・持続性確保も大きなトピックとなっていた。 • AI も引き続きホットなトピックだが、OSSJ としてはAI の技術的側面よりもライセンス や OSS としての AI モデルなど、コンプライアンス的な側面での話題が多いように感 じられた。 • 技術色が薄まり、OSPO、セキュリティ、コミュニティリードといった題材が増えている 最近の傾向は継続。 ◦ Geek の群れは今いずこ... • 来年の OSSJ は 12/8-10 での開催が決定。Linux Plumbers Conf が OSSJ のあとに 開催されるので、Linux Kernel の大物メンテナが多数来日すると思われる。 5
6. ハイライトセッション：自動車業界からの貢献促進 Panel: How to Accelerate Contribution in Automotive Industry（Masato Endo Toyota Motor Corporation, at. el） • 課題解決のために超えるべき問題 ◦ 経営層が貢献の価値を理解しておらず、「なぜ我々のコードを公開する必要があるのか？」と問われる、必要な社内 プロセスに時間がかかる、upstream-first の文化・重要性が理解されていない ◦ 社内ネットワークのプロキシが邪魔 ◦ OSS コミュニティとの協働・貢献は個人の資質を要求する部分が多い。 OSPO からの支援があると助かる • OSS・OSS活動のビジネス観点での価値 ◦ 移植性と柔軟性の高さにより、利用不可能になってしまうリスクを低減できる ◦ IP リスクを低減できる（注：特許侵害リスクの意味と推測） ◦ コスト低減 ◦ コミュニティに開発者が知られていると、採用に有利 ◦ 常に最新の技術に触れることで、技術者のスキルを維持・向上することができる • OSS コントリビューターの立場から貢献を促進するための方策提案 ◦ ノープロキシ！ ◦ OSS 活動を R＆D チームと協働で行うとよいかもしれない 6
7. ハイライトセッション： The Kernel Report 7 Keynote: The Kernel Report（Jonathan Corbet, Executive Editor, LWN.net） Rust • 6.1 で「Experiment」マージ、メンテナから「実行可能」という判断が下されている • 課題： 言語そのものの安定性、コンパイラがサポートしないアーキテクチャあり、設 計上の合意が不完全、Rust/C 間のバックポートが困難 • Rust 実装： Binder、Apple GPU ドライバ、NVIDIA GPU ドライバなど 動的に選択可能な CPU スケジューラ • sched_ext ： 6.12 でマージ予定、 eBPF を利用 • ゲーム、レスポンス重視、パーティショニングなど、ユースケースに合わせたスケ ジューラを実装し組み込むことができるようになる
8. ハイライトセッション： The Kernel Report 8 多数の CVE • Linux Kernel が CNA（CVE Numbering Authority）になった • 1,000件/年 以上の CVE が発行されている • 多すぎて追いきれないという声も聞くが、だからこそ mainline kernel を使うことが重 要 ツール • パッチ管理の b4（https://b4.docs.kernel.org/） に注目 • バグトラッキングは以前から使われている Bugzilla と、bugspray に注目 • テストに関しては Kernel 自身のテストツール拡充と、KernelCI に注目
9. ハイライトセッション： 日本と世界の SBOM 状況 9 Ayumi Watanabe, Hitachi Solutions, Ltd. 各国政府からの指令・法規 • 米国大統領令14028 • EU Cyber Resilience Act 産業界の標準 • 医療業界： IMDRF、FDA 規則 • 自動車業界： UN-R155/156・ISO/SAE 1434・NHTSA • カード決済業界： PCI SSC v4.0 各国からの SBOM 関連の文書 • ドイツ： BSI Technical Guideline TR-03183 • 米国： NSA、ODNE、CISA などからの各種文書 • インド： CERT-inTech Guidelines on SBOM • 韓国： KISA Software Supply Chain Security Guideline • 中国： TC260 Network Security Tech SBOM Data Format
10. ハイライトセッション： 日本と世界の SBOM 状況 10 日本の状況 フォーマット • 小規模な企業では SPDX/SPDX Lite がメジャーで CycloneDX が二番手 • エネルギー、エンターテイメント、メディ ア企業では CycloneDX、製造業やエン ジニアリング企業では SPDX がメ ジャー SBOM 関連の文書 • NISC サイバーセキュリティ2024 ◦ サプライチェーンセキュリティ強化のため SBOM の利用を推奨 SBOM 関連の文書（つづき） • 経産省「SBOM 導入の手引き」 ◦ Ver 2 が 2024年8月に公開 ◦ SBOM による脆弱性管理プロセス ◦ SBOM の適切な範囲・スコープ ◦ 提供企業（サプライヤー）と受領企業（コンシューマー）間の SBOM に関する契約モデル • 経産省「OSS の利活用及びそのセキュリティ確 保に向けた管理手法に関する事例集 ◦ 2021年4月に第一版、2022年5月に第二版 ◦ トヨタ、ソニー、オリンパス、日立、オムロン、東芝、デンソー、 富士通、NEC、NTT などのケーススタディを記載 グローバル課題のサプライチェーンセキュリティ強化 のためには、OpenChain を中心としたグローバルコ ミュニティとのコラボレーションで日本に多くある知見 を活かすことが必要
11. ハイライトセッション： 組込みでコンテナ 11 Running Containers on a Resource Constrained Embedded Device （Jeff Shaw, Digi International） Docker • 良い点：機能が豊富、設定が柔軟にできる、使いやすい • 悪い点：リソースを食う（RAM が 275MB 必要）、パフォー マンスが低い LXC • 良い点：少ないリソースで動作する（85MB の RAM で動 作した）、パフォーマンスが良い、シンプル • 悪い点：ほとんどの LXC コンテナは OS イメージとして提 供されており過多、自分でやらなければならないことが 多い（手間がかかる）、ユーティリティが複数コマンドに分 かれている（lxc-ls, lxc-start, lsc-stop, etc. その反面コマ ンドのサイズは小さい） 超小型コンテナ • ホストシステムのディレクトリをコンテナからマウント する LXC の機能で、システムに必要な大部分をホス ト側のものを使う • App がリンクするライブラリの位置がホストとコンテナ とで異なるため、 ld-musl-arm.so.1 –list /bin/busybox などで依存リストを出力して LD_LIBRARY_PATH を調 整し、ライブラリの場所を指定する • IMX6ULL のルーター上で、/etc/passwd, profile だけ を含むわずか 375byte のコンテナ内で RasPi の ls コ マンドを 動作させることができた 参考 • https://github.com/AcceleratedLinux/accelerated-ln ux • https://www.digi.com
12. ハイライトセッション： XZ事件と今後の対応 12 Analysis of and Lessons from the Xz-Utils Vulnerability – What Might Come Next?（Taku Shimosawa & Atsuya Kato, Hitachi, Ltd.） XZ PJ を OpenSSF Scorecard で評価 • Code-Review と Branch-Protection にリ スクあり • 実際に攻撃に利用されたリスクである Maintained と Binary-Artifacts はリスクと しては低い（スコア値は高い） → Scorecard の評価は現状では十分ではない 新たな評価指標を提案 • 過去90日間に3件以上コミットした開 発者の数 ◦ 1に近ければ、メンテナが孤軍奮闘しているこ とを示す • メンテナあたりのコミットの数 ◦ 数が大きければ、メンテナの負担が大きいこ とを示す → メンテナが多忙とみられる PJ として libcap、libxkbcommon、gperf を検出 • 今後これらの指標の取り込みを Scorecard に働きかける予定
13. ハイライトセッション： Linux Kernel CVEs 13 Linux Kernel CVEs: What Has Caused So Many to Suddenly Show Up?（Greg Kroah-Hartman, Kernel Maintainer & Linux Fellow） 脆弱性とは • 機密性、完全性、可用性に影響を及ぼす、悪用される可 能性のある弱点 • Linux Kernel では painc_on_warn が有効な場合 WARN_ON で再起動する → これを引き起こすものは脆弱性 • 逆に、データ破壊、パフォーマンス問題、外部から到達 不可能な条件で発生するバグは脆弱性に分類されない Linux Kernel の状況 • 平均して週に55件の CVE を公表 ◦ Wordpress は 112件/週、MITRE は 95件/週 の CVE を公表 • 脆弱性がどのファイルのどのバージョンに含まれるもの かを明らかにし、JSON フォーマットでも公開 システムを安全に保つ方法は２つしかない 1. 55件/週 の CVE を一つ一つ吟味して必要なものを当 てる（cherry-pick する） 2. 最新の stable/LTS カーネルにアップデートする • どちらの選択肢を取るかはあなた次第だが、お勧め は２つ目の選択肢 • アップデートによりデータ破壊が減りパフォーマンス が向上するというおまけもある。 脆弱性、 CVE を取り扱うための有用なツール • dyad：ある脆弱性が導入された・修正された Git のコ ミット範囲を特定 ◦ コミット自体が汚いのでなかなか大変だが • bippy： Git のコミットから CVE の報告情報を作成 • strak： あるバージョンに含まれる CVE や、修正され た CVE を出力
14. Japan SBOM Summit 2024 14
15. Japan SBOM Summit 2024 イベント概要 15 • 2014/11/1（金）＠ 六本木 国際文化会館 • SBOM の議論が様々なコミュニティ、業種、産業セクターで分散して行われている 現状を鑑み、それらが一同に会して情報の共有と議論を行う場が必要という課題 提起に基づいて企画・開催された • 参加者数は目算で100名程度 ◦ 現地参加のみ、リモート接続なしで開催 ◦ 早々に定員に達したとのこと ◦ OpenSSF、OpenChain といった（いつもの）LF 傘下メンバーに加え、 OWASP、経産省からも参加 • 参考： イベントページ
16. セッションリスト（リンク付きはトピックを後述） 16 • Pitfalls of Using SBOM for Open Source Compliance ▪ Oscar Valenzuela氏, Amazon, Principal Open Source Engineer • Higher Accuracy SBOM Information Using Building Tracing ▪ Armijn Hemel氏, Tjaldur Software Governance Solutions • SBOMに関する施策について ▪ 見次正樹氏 経済産業省 商務情報政策局 参事官 • OpenChainとSBOMがめざすサプライチェーンの信頼関係 ▪ 渡邊歩氏 日立ソリューションズ シニアOSSスペシャリスト • SBOM活用の現実 – SPDX Lite で解決! ▪ 小保田規生氏 ソニーグループ シニアOSSストラテジスト • 多層化しているソフトウエア脆弱性とその対応戦術 ▪ 岡田良太郎氏 OWASP Japan • SBOM x OpenSSF (Open Source Security Foundation) ▪ 池田宗広氏 サイバートラスト リードアーキテクト • OSPOが拡大する世界動向と OSS参加のビジネス価値 ▪ 桑田昌行氏 ソニーグループ 統括課長 • 自動車業界におけるコミュニティを通じた SBOM活用の推進(OpenChain Automotive WG, AGL OSPO EG) ▪ 遠藤雅人氏 トヨタ自動車 グループ長 ▪ 日下部 雄一氏 ホンダ技研工業 リードアーキテクト ▪ 伊藤義行氏 ルネサスエレクトロニクス プリンシパルスペシャリスト
17. ハイライトセッション：SBOM 生成 Higher Accuracy SBOM Information Using Building Tracing • SBOM 作成はビルド時に strace or eBPF でファイルの open をトレースしてリスト化 するのが一番正確だぜ イェーイ！というセッション • FFmpeg の脱 GPL 化で実際にやってみたら正確な結果を得た ◦ ただし脱 GPL 化は非常に大変だった • ツール開発中 ◦ https://github.com/armijnhemel/tracing_software_packages 17
18. ハイライトセッション：経産省 SBOMに関する施策について • Q：現状は任意規格である JC-STAR は必須化を目指すのか？ • A：IoT機器のサイバーセキュリティ強化は、全ての機器が対策を取ることが重要。 必須化のためには範囲と要件を明確に定義する必要があり、その範囲外の機器・ 要件への対応が取られなくなる弊害があるため、現状は任意規格のままとしたい。 ◦ EdgeTech+ で JC-STAR に関する講演を行った IPA の方は、逆に必須化によってサイバーセキュリ ティの底上げを図りたいという意見だった ◦ 法律に従う官僚と、技術的な正しさを目指す IPA の視点の違いから出る意見の相違とみられ、今後 の動向には注意する必要がある 18
19. ハイライトセッション：SPDX Lite SBOM活用の現実 – SPDX Lite で解決! • Q：SPDX Lite は元々 Excel で扱えるフォーマットというのが策定のモティベーション にあるが、データ構造が SPDX 3.0 でスキーマ化したため取り扱いが困難になって いる状況にどう対応するのか • A： コンセプトがね...崩壊かっ！？ • A： 産業界で SBOM を取り扱うためには小規模な企業が扱えなければならないの で、Excel でないにせよツール化は必須。今後の課題。 19
20. ハイライトセッション：OWASP / CycloneDX 多層化しているソフトウエア脆弱性とその対応戦術 • ENISA Threat Landscape は IPA 10大脅威よりも解像度が高く参照必須。経産省はこういっ たものを推進すべき。 • セキュリティに対する OSS 開発者へのインセンティブをどうセットするかは課題。SBOM が 義務化されることは、この課題の解決に向けた追い風になる。 • セキュリティはプロセスを実行すれば守れるものではない。ソフトウェアの脆弱性対応とし て最もポピュラーな手段はアップデートだが、意図的な侵害コード混入もあり得るのでそれ だけで脆弱性リスクはなくなるのかといえばそんなことはない。脆弱性対応は SBOM で問 題を発見してからが本番である。 • セキュリティの底上げには開発者向け・運用者向け教材の充実だけではなく、対応力を上 げるための共同訓練が必要なのではないか、そういったことを OWASP/OpenSSF/LF/その 他 が共同で行うのが良いのではないか 20
21. 全体所感 • 普段あまり接点のない方が参加されており、「SBOM 関係者が一同に会する」という 目的は達成されたと思われる ◦ OWASP の岡田さんなど： CycloneDX のお話しはほとんどなかったが • ここでの繋がりを活かし「ムーブメント」を作っていくことが必要 ◦ 他人事ではない 21
22. Thank You 22
23. Ways to Participate Join a Working Group/Project Come to a Meeting (see Public Calendar) Collaborate on Slack Contribute on GitHub Become an Organizational Member Keep up to date by subscribing to the OpenSSF Mailing List 23
24. Engage with us on social media X @openssf LinkedIn OpenSSF Mastodon social.lfx.dev/@openssf YouTube OpenSSF Facebook OpenSSF 24
25. Subscribe to our mailing list openssf.org/sign-up 25
26. Is your organization a member? Questions? Contact membership@openssf.org openssf.org/join 26
27. Legal Notice Copyright © Open Source Security Foundation®, The Linux Foundation®, & their contributors. The Linux Foundation has registered trademarks and uses trademarks. All other trademarks are those of their respective owners. Per the OpenSSF Charter, this presentation is released under the Creative Commons Attribution 4.0 International License (CC-BY-4.0), available at <https://creativecommons.org/licenses/by/4.0/>. You are free to: • Share — copy and redistribute the material in any medium or format for any purpose, even commercially. • Adapt — remix, transform, and build upon the material for any purpose, even commercially. The licensor cannot revoke these freedoms as long as you follow the license terms: • Attribution — You must give appropriate credit , provide a link to the license, and indicate if changes were made . You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. • No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits. 27