AI時代のOSS サイバーセキュリティ最新動向

2026年7月24日開催セミナー講演資料
Linux Foundation / 一般社団法人組込みシステム技術協会 (JASA) 主催 EdgeTech+ West 特別企画

【第2部】AI時代のOSS サイバーセキュリティ最新動向
Linux Foundation Japan Evangelist / サイバートラスト株式会社 池田 宗広氏

Transcript

1. AI 時代の OSS サイバーセキュリティ最新動向 2026/07/24 Linux Foundation Ｘ JASA 組込みLinuxエンジニア認定 発表記念共同セミナー LF Japan Evangelist / サイバートラスト（株） 池田 宗広 Copyright © 2024 The Linux Foundation®. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks.
2. AI x OSS：課題 AI による脆弱性の発見 • 潜在していた脆弱性が AI により発見される • 脆弱性発見のスピードは人間をはるかに凌駕している ◦ Dirty Frag (CVE-2026-43284, CVE-2026-43500), Copy Fail (CVE-2026-31431) 重複報告・誤った報告の増加 • AI は誰でも使える → 重複した報告の増加 ◦ ただし AI の不確定性により完全に同じ報告とはならないため、メンテナが調査・選別する必要あり ◦ 本当に脆弱性といえるかどうかの確認が必要 • 報告者が内容を理解していないケースも多数 → メンテナの負荷が増大 貢献数も AI により増加 • 直近の2回のリリース（7.0, 7.1）では、以前に比べコミット数が約 20% 増加している 2
3. AI x OSS：対応 対応は OSS PJ ごとに異なる • Linux カーネル (coding-assitants.rst) ◦ Assisted-by で使用したモデル、エージェント、ツール情報を付与 ◦ AI による Signed-off-by 付与を禁止 • Kubernates (AI Guidance) ◦ PR に生成 AI 支援を明示すること ◦ AI を共著者、共同署名者とすることを禁止、assisted-by, co-developed 禁止 • Curl (Contributing to the curl project: On AI use in curl) ◦ クリーンなコード、ドキュメント、テスト済みなど、通常の貢献と同じルールを適用 ◦ ※ Curl は AI による低品質レポートの増加により脆弱性バグ懸賞金制度を廃止した経緯がある • SQLite(AGENTS.md), QEMU (code-provenance.rst: Use of AI-generated content) ◦ AI 生成パッチは受け取らない 3
4. AI x OSS： AI の活用 OSS メンテナも AI を活用し始めている • Linux カーネル ◦ ◦ • 安定版へのパッチ適用には AI が活用されている（Sasha Levin, OSSNA 2025） Sashiko： AI による Linux カーネルパッチレビュー Project GlassWing ◦ ◦ ◦ Anthropic Claude Mythos Preview による OSS 脆弱性の発見・修正 4M USD の資金、100M USD 相当の Claude 利用クレジットを提供 参加企業： AWS、Anthropic、Apple、Cisco Systems、Google、Linux Foundation、Microsoft、Nvidia、etc. OSS コミュニティからの発言 • Linus Torvalds 氏「AI が発見したバグは全部公開でよいのでは？」(OSSNA 2026) • Jim Zemlin 氏「防御側は攻撃側と同じツールを使えるが、フラグメントが問題。(1) 防御スタックに参加すること、(2) AI を SDLC（ソフトウェア開発ライフサイクル） に接続すること、(3) メンテナーへの資金援助を行うこと、(4) AAIF, x402, OpenSSF, CNCF SIG に参加すること、(5) 組織的な行動により、脆弱性の発見と共有を行うこと をお願いしたい」（OSSNA 2026) Linus Torvalds 氏「AI は有用なツール。やり方に問題があるというならフォークすればよい」(LKML, 2026/07/14) ◦ • 脆弱性ハンドリング標準 (CVD: Coordinated Vulnerability Disclosure) も変わらざるを得ない（かもしれない） 4
5. AI x The Linux Foundation の動き AAIF (Agentic AI Foundation) の設立 • Open source AI を推進するための団体 • AWS, Google, Anthropic, OpenAI, 日立 製作所など200社以上 Akrites プロジェクト 発足 • 「OSS の SIRT」として重複排除、検証 、修正、情報公開をコーディネートしメ ンテナの負担を軽減 • 新しい CVD プロセス確立へ OpenSSF (Open Source Security Foundation) • OSS セキュリティのセントラルポイント • 活動の四本柱 ◦ ◦ ◦ ◦ プログラムとプロジェクト これらをコミュニティとして実行すること 教育 ポリシー Project Glasswing への参加 5
6. AI x OpenSSF の取り組み SAFE-MCP • MCP / Agentic AI の脅威を SAF-Txxxx としてカタログ整備、Github に公開 Gemara • AI ガバナンスフレームワーク・論理モデル • OpenSSF Japan Chapter による翻訳版 whitepaper が公開されました！ OSS-CRS • AI x CC から派生またはインスピレーションを受けた脆弱性検出・対応のためのオーケストレータおよび ツール Secure Coding Guide for Python 日本では「OpenSSF Japan Chapter」として、不定期（２～３ヶ月に一度）Meetup 開催中（次回は10月を予 定） 6
7. AI セキュリティ ≒ サプライチェーンセキュリティ サプライチェーンセキュリティを確保するために必要なこと １．それは何か・何が入っているかが分かる (SBOM / AIBOM) • SPDX • CycloneDX ２．どうやって作られたものか分かる (Provenance / Attestation) • SLSA / in-toto ３．情報/ソフトウェア/AI 自身が改ざんされていないことが分かる • OpenSSF Model Signing • sigstore • SBOMit 7
8. 参考：OpenSSF 傘下のプロジェクト Bomctl SBOMit S2C2F SLSA OpenVEX sigstore GUAC Protobom 機能 プロセス・ポリシー サプライチェーン Best Practices Badge Repository Service for TUF OpenSSF Scorecard OSPS Baseline Minder OpenBao ソフトウェア開発 8
9. サイバー/サプライチェーンセキュリティ関連規制・法令 国、地域 法令・制度 主な対象製品 開始時期 評価方法 参考規格 (Product Security and Telecommunication Infrastructure Act) 消費者向けIoT機器 2024年4月〜 自己適合宣言 ETSI EN 303 645 ※ JC-STAR ★1 簡略 化 CRA 「デジタル要素を備えた製品」 (サイバーレジリエンス法) ※医療機器など別のEU法規がある場合は対象外 Cyber Trust Mark 消費者向け無線IoT機器 イギリス PSTI EU 米国 日本 報告義務：2026年9月〜 クリティカル / 重要製品: 全ての規定：2027年12月 第三者認証 〜 その他製品: 自己適合宣言 2025年1月 開始 2025年6月 一時停止 2026年中に再開？ prEN 40000 ETSI EN 303 645 IEC 62443-4 第三者認証 NIST IR 8425 IoT機器 2025年3月 ★1開始 JC-STAR (セキュリティ要件適合評 （消費者機器から重要インフラ 2026年内 ★3申請開始予定 まで） 2026年以降 ★2開始予定 価及びラベリング制度) ★1★2: 自己適合宣言 ★3以上: 第三者認証 ETSI EN 303 645 ※ ★1：PSTI 相互承認 2027年3月: ★3★4、 2027年以降 ★5開始予定 ★1★2: 自己宣言 ★3: 自己評価 ★4★5: 第三者評価 IPA Security Action 自工会・部工会GL ISO/IEC 27001 SCS評価制度 企業ITインフラ、外部NW境界 2026年7月現在 参考 • • 経済産業省. IoT製品に対するセキュリティ適合性評価制度 （JC-STAR制度）の紹介 (2024/11/15)： https://www.jnsa.org/seminar/std/2024/data/std_20241115_1.pdf 経済産業省/国家サイバー統括室 サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針(令和8年3月)： /https://www.meti.go.jp/policy/netsecurity/docs/scs/scs_2.pdf 9
10. サプライチェーンセキュリティの課題 セキュリティとトラストの接続が重要 • 誰が（または何が）そのコードを書いたのか？ • その人は信頼できるのか？ XZ Utils 事件 (CVE-2024-3094) 事象 • メジャーな圧縮・展開ツール xz に、root 権限の奪取 、リモートコードの実行が可能なバックドアが混入 • 配布はベータ版ディストリビューションまでで、広い 実害はなかった • 攻撃者は数年の活動で信頼を獲得し、健康上の理由で 活動を制限していた旧メンテナからメンテナ権限を正 規に取得した上で攻撃コードを混入させた 課題・教訓 • • • 重要な OSS でもメンテナが１人で奮闘しているケ ースは多い → Alpha-Omega PJ, PJ Akrites, OpenSSF Scorecard ソフトウェアが経た工程を検証する術が必要 → SLSA, SBOMit メンテナの「信頼」をどう担保するか → ？？？ 10
11. AI 時代のエンジニア テスト レビュー 実装 テスト 設計 実装 AI 実装 設計 エンジニア エンジニア 設計 エンジニア 機械化・自動化する部分は増えていく テスト レビュー レビュー コンパイラ・リンカ コンパイラ・リンカ アセンブラ アセンブラ アセンブラ ～1970 ～2025 2026～ ※ さすがに Cobol や Fortlan はあったので、全てのエンジニアが アセンブラで書いていたわけではありません 11
12. AI 時代のエンジニア PM Arch エンジニア エンジニア 機械化・自動化する部分がプロセスの上流に上がっていく PM Arch PG AI OS/Lib OS/Lib HW HW ～2025 2026～ 12
13. IT ゼネコン体制が（意図的に）生んだ誤解 上流 ＝ 高価値、下流＝低価値 ではない • OSS モデルに明示的な設計工程は存在しない • OSS は実際に動くものを前に議論・実装を進めることで、世界を席巻する価 値を生み出した プロセスやツールよりも 個人と対話を、 包括的なドキュメントよりも 動くソフトウェアを、 契約交渉よりも 顧客との協調を、 計画に従うことよりも 変化への対応を、 アジャイルソフトウェア開発宣言 より 13
14. AI 時代のエンジニア 「プログラムが書けなくても AI があれば良いソフトウェアは作れる」 • 書けなければ、AI に正しく指示できない（良い設計はできない） • 書けなければ、AI が生成したコードが正しいかどうか（安全かどうか）判断 できない • 職人芸的なスキルが求められる局面は減っていくが、良い実装が価値をもた らすことは AI 時代でも変わらない 14
15. AI 時代のエンジニア AI は、仕事は早いがちょっと調子に乗っている新人と考えるとちょうどよい 我々エンジニア（人間）のすべきこと • 新人くんに適切な指示を与えること • 新人くんのアウトプットを正しく評価し、誤りがあれば正すこと • 結果に責任を負うこと → 現在のエースエンジニアと同じ役割、同じ知識・技術が求められる 「コーディングなんてレベルの低い仕事」として停滞を招いた I T ゼネコン体制 の失敗を繰り返してはならない 15
16. エースエンジニアになろう OSS は「良い実装」の宝庫 • 先人の英知が無料で学べる ◦ 「職人芸」の宝庫でもあるが • 試して・壊して・直す ことには大きな学びがある LF / OpenSSF のトレーニングマテリアル • OpenSSF Education ◦ ◦ ◦ ◦ ◦ LFD121-JP セキュアソフトウェア開発 LFEL1001 Understanding the EU Cyber Resilience Act (CRA) LFEL1007 Automating Supply Chain Security: SBOMs and Signatures Securing Open Source in the Age of AI etc. • OpenSSF Guides [日本語版ページ] ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ CおよびC++のコンパイラ・オプション強化ガイド ソースコード管理プラットフォーム設定のベストプラクティス より安全なソフトウェア設計のための簡潔なガイド オープンソースソフトウェアを評価するための簡潔なガイド セキュリティ研究者のためのオープンソースソフトウェアプロ ジェクトと脆弱性の公表を調整するためのガイダンス npm ベストプラクティスガイド オープンソースプロジェクト向けに協調的脆弱性開示プロセス を実装するためのガイド Cyber Resilience Act (CRA) Brief Guide for Open Source Software (OSS) Developers Correctly Using Regular Expressions for Secure Input Validation 16
17. Thank You 17
18. Join a Working Group/Project Come to a Meeting (see Public Calendar) Ways to Participate Collaborate on Slack Contribute on GitHub Become an Organizational Member Keep up to date by subscribing to the OpenSSF Mailing List 18
19. X @openssf Engage with us on social media LinkedIn OpenSSF Mastodon social.lfx.dev/@openssf YouTube OpenSSF Facebook OpenSSF 19
20. 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. 20