Open Source Summit North America 2025 参加 Report

Muuhh IKEDA氏 (Cybertrust Japan Co. Ltd. / The Linux Foundation Japan Evangelist)
2025年7月30日開催 OSSセキュリティMeetup 講演資料

Transcript

1. Open Source Summit North America 2025
 参加 Report
 ~ 2025/07/30 OSS Security Meetup ~
 Muuhh IKEDA
 Cybertrust Japan Co. Ltd. / The Linux Foundation Japan Evangelist

2. 池田 宗広 / Muuhh IKEDA
 • サイバートラスト（株）
 オープンプラットフォーム事業本部
 • The Linux Foundation Japan Evangelist
 • 喫茶店店員、航空宇宙電子機器生産技術 者、LCDパネル開発者、Linuxカーネル開発 者、ネットワーク機器技術サポート・ビジネス 開発を経て現職
 • 担当パートはドラム、ベースギター及びシャウ ト
 2 2

3. Open Source Summit North America 2025 イベント概要
 3
 • 2025/06/23～25 @ Denver Convention Center, Denver, CO, USA • 言わずと知れた OSS 界（Linux界？）の中心イベント • 北米（春）、欧州（秋口）、日本（年末）の三極で毎年開催するうちの北米回 ◦ EU : 2025/08/25～27 @ Amsterdam ◦ JP : 2025/12/08～10 @ 虎ノ門 • 参加者数は目算で 800名程度 • AM はキーノート、11:00 くらいからテーマごとのブレークアウトセッション、パネルディスカッション • キーノート： 18 ◦ LF の全体概要、新規・既存 OSS PJ の状況、スポンサーの OSS 参画状況など • セッション、パネルディスカッション ： > 250 ◦ 1～3人のスピーカがプレゼンテーション、または壇上～ 5人のディスカッション ◦ AI、サイバーセキュリティ、コミュニティ参画支援・活性化・評価、 OSPO など • 今回は並列度が高すぎて（ >10）聞きたいセッションがかなり重複していたのが残念 • 参考： イベントページ ◦ セッション資料・動画は View the schedule から各セッションのページに行くと（上がっていれば）参照可能
4. 全体トピック・所感
 • AI がここ数年のホットトピック ◦ 今年はエージェント型 AI （Agentic AI）がホット ◦ Agent2Agent (A2A) Protocol PJ が始動 ▪ Google 主導、MS, AWS, etc. 参加の、AI エージェント同士の情報共有通信プロトコル • トラスト/セキュリティはもはや定番ネタ ◦ OSS の署名は sigstore が完全にデファクト化（sigstore 以外は全く聞かない） • オープン維持も静かなトレンド ◦ AWS, Valkey, OpenSearch と3つ個別にプラチナスポンサー ◦ WordPress の PlugIn Mgmnt “FAIR” • 技術イベント色は以前と比べると大分薄まり、情報収集とコネクションの構築・再確認の場になりつ つある ◦ セッションで進行中 PJ の状況や未知の OSS PJ を情報として仕入れる ◦ 個別 Mtg でコネクションの確認・拡大と今後の方向性議論を行う ◦ → 継続的な参加には引き続き意義あり • 中国人がほとんどいない ◦ ビザの関係で米国への入国が難しくなっている？ ◦ OSS の基本姿勢はあくまでオープンだが、政治的分断からは逃れられない 4

5. ハイライトセッション紹介 
 5

6. OSPS Baseline : OSS PJ が満たすべき要件
 6
 OSPS: All Your Base Are Belong To Us Christopher Robinson, OpenSSF & Eddie Knight, Sonatype • OpenSSF Open Source Project Security Baseline (OSPS) ◦ OSS PJ がセキュリティ、規制・法令観点で満たすべき要件の定義、フレームワーク、ツール • Level 1 ： 最低限満たすレベル • Level 2 ： 2～６人のメンテナの OSS PJ が満たすべきレベル • Level 3： 高度なセキュリティを備える OSS PJ が満たすべきレベル • 標準・規制への対応は、以下を考慮している ◦ NIST SSDF, CSF, 800-161/53, etc. ◦ CISA Software Acquisition Guide ◦ EU CRA ◦ OpenSSF BestPracti Bades、 Scorecard、 Minder、 SLSA, その他ツール , etc. ◦ などなど • ユースケース ◦ OSS 開発者向け：セキュリティ対応・準備の観点 ◦ OSS 利用者向け： OSS 選択の観点 • Baseline を読んでフィードバックしてほしい ※ OpenSSF Community Day NA のセッションはこちら ※ 以下は Version: 2025-02-25 の一部抜粋です。 < Level 1 > • 多要素認証 • CI/CD 入力のサニタイズ • 通信の暗号化 • 不具合・セキュリティ報告の窓口定義 • コントリビューションプロセスの定義 • レポジトリへの実行バイナリ格納を禁止 < Level 2 > • 最小権限によるCI/CDタスクの実行 • ユニークなバージョン名の付与 • 成果物への署名 • 自動テスト • セキュリティアセスメントの実施 • 対応期限を含む脆弱性対応ポリシーの定義 < Level 3 > • 完全性・真正性検証手段の提供 • サポート範囲と期間の定義 • SBOM の提供 • 依存レポジトリへのセキュリティレベル強制 • コードマージはコミッタ以外の Approval 必須 • 脅威分析とアタックサーフェス分析 • 影響を与えない脆弱性を VEX に明記 • 全ての変更において依存先を含む既知脆弱性を 自動で検査
7. Linux カーネルメンテナンスへの AI 活用 
 AI for Kernel Engineers Sasha Levin, NVIDIA • LLM は、コードのひな形（ boilerplate）作成、リファクタリング、デバッグに有用。コンパイラの進化形と捉え てよい段階に達している • 小さな漸近的な変更であり、明確に定義されたタスクであり、テスト可能であり、クリエイティブというよりも テクニカルな変更・修正は LLM に適している • 実際の例： あるハッシュのサイズを定義するマクロを数値（ 128）からビット数（7）への変更 → うまく機能した • LLM 活用事例(1) : AUTOSEL ◦ 10年間以上の Stable カーネルへのバックポートの実績を学習 → 100コミット/日 以上の処理が一貫性を持って可能になった ◦ 判断は複数の LLM で行い、多数決で要否を決定 ▪ Claude、GPT-4、Llama に NW ドライバの修正要否を聞いたところ、 2/3 が「賛成」、1/3 が「反対」（リスクが高い）という結果 だったため実行した例がある ◦ AUTOSEL と同じテクノロジは、コミットに脆弱性が含まれるかどうかの判断にも使うことができる • LLM 活用事例(2) ◦ Bash スクリプトの Rust への変換 7

8. SBOM の品質を高めるためのツールとレッスン (1/2)
 8
 Enhancing SBOM Generation: Filling the Gaps To Make Actionable SBOMs Ian Dunbar-Hall, Lockheed Martin; Gary O'Neall, Source Auditor Inc. ～ ツール ～ • 生成（Generation） ◦ このフェーズは慣れたツールを使えばよい（例えば trivy など） ◦ ここでは以下の情報が入っていないことが多いので 注意 ▪ author、supplier、repository location、 license、copyright • 改善その１（Augmentation） ◦ ツール：sbomasm ◦ 生成時に入っていない情報を補う • 改善その２（Enrichment） ◦ ツール：parlay ◦ ライセンスなどの必須フィールドを補完する ◦ このフェーズは必要に応じて行う • 確認・検証（Verification） ◦ ツール：sbomqs ◦ フォーマットが要求する最低限の要求が満たされて いることを確認する ◦ SPDX は形式（JSON, Key-Value, etc.）に応じたファイ ル名規則を定めているため、これに従う • 署名（Signing） ◦ ツール： cosign
9. SBOM の品質を高めるためのツールとレッスン (2/2)
 9
 ～ レッスン ～ • 不正な SBOM のよくある誤り ◦ ライセンス情報の誤り、フィールドを誤って 使っている、ID が重複している、Supplier 情報がない、など ◦ バージョンの誤りはパッケージマネージャ から情報を取得することで、正しいバージョ ンを得ることができる • 単一のツールに頼っていると SPoF になりがちな ので、複数のツールを組み合わせて使うのがよい • SPDX と CycloneDX とでフィールドの対応をきちん と整合させる必要がある。CISA が対応についてド キュメントを発行しているが、全てのフィールドに ついて書かれてはいない。bomctl が相互の変換 の助けになる ～ レッスン （続き）～ • Identifier の不整合はよくあるケース。pURL が一 般的になりつつあるが、pURL は必ず一意ではな いという問題がある。Software Heritage IDs, GITOID といった Content Identifier を使うことも検 討するとよい • エコシステムが持つ問題として、 C/C++ は依存の 追跡が困難 ～ まとめ ～ • 色々と困難な点もあるが、既存のツールによって 実用的な SBOM は作成可能 • 特にメタデータはパッケージマネージャの情報を 活用することが重要
10. 組込み領域における SBOM
 The State of SBoMs in Embedded Joshua Watt, Garmin SBOM に対する組込み領域の優位性 • 組込み開発は結果をあらかじめ指定・設定して行 うため、SBOM に必要な情報を全て含んでいる （例：Yocto のレシピ） → リバースエンジニアリングの逆 == Forward engineering • 組込みソフトウェアは実行環境が開発環境と完全 に分離しており、SBOM のようなサプライチェーン のためのメタデータにホストの情報が流出してしま う恐れがない • サプライチェーンセキュリティの強化という意味で は、SBOM と同じく再現可能ビルド（Reproducible build）も重要 組込み向けの主要プロジェクトにおける SBOM と再現 可能ビルドのサポート状況 • Yocto ◦ 5.1(Styhead) で SPDX 3.0 をサポート ◦ コアのレシピで再現可能ビルドのテスト中 • buildroot ◦ 再現可能ビルドが可能 ◦ CycrloneDX SBOM に対応 • Zephyr ◦ SPDX 2.3(JSON) に対応 • Apache NuttX RTOS ◦ SPDX 2.4(JSON) に対応 Q&A • 100MB の rootfs の SBOM が 500MB 出力され る ◦ データのパックに関していまだ課題がある 10

11. おまけコーナー： Denver, Colorado, USA
 標高 1,600m のコロラド州都 • “One mile high city” • タイムゾーンは MST/MDT （山岳部標準時間/山岳部夏時間） • 涼しくて快適 11
 遠くに見えるロッキーの山並み 会場が馬鹿でかい ... 入口から会場の部屋まで徒歩 10分 入口の巨大な青いクマ（？） 若干治安が不安な通りもある • Denver に限らずアメリカ中の都市でこ こ数年治安悪化の傾向がみられる
12. Thank You
 12
13. 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
 13
14. Engage with
 us on social media
 X
 @openssf 
 LinkedIn
 OpenSSF
 Mastodon
 social.lfx.dev/@openssf
 YouTube
 OpenSSF 
 Facebook
 OpenSSF
 14
15. Subscribe to our mailing list
 openssf.org/sign-up
 15
16. Is your organization a member?
 Questions? Contact membership@openssf.org 
 openssf.org/join
 16

17. 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. 17