OpenSSF Community Day EU / Open Source Summit EU 2026 参加レポート

ルネサスエレクトロニクス 余保束氏
日立製作所 川名のん氏
日立製作所 下沢拓氏
サイバートラスト 池田宗広氏
2026年10月26日開催 OSSセキュリティMeetup 講演資料

Transcript

1. OpenSSF Community Day EU Open Source Summit EU 2026 参加レポート Oct 26, 2026 Copyright © 2024 The Linux Foundation®. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks.
2. この資料の概要 チェコ共和国、プラハで開催された、OpenSSF Community Day EU 2026 および Open Source Summit EU 2026 の参加レポートをお届けします。 上記イベントに参加した OpenSSF Japan Working Group メンバーのうち、以下の４人から お送りいたします。 • • • • ルネサスエレクトロニクス 日立製作所 日立製作所 サイバートラスト 余保 束 川名 のん 下沢 拓 池田 宗広 2
3. イベント概要 OpenSSF Community Day EU 2026 • • • 日時：2026/10/06 主催：Open Software Secure Foundation (OpenSSF) 会場：チェコ共和国プラハ、Prague Congress Center Open Source Summit EU 2026 • • • 日時：2026/10/07 - 09 主催：The Linux Foundation 会場：チェコ共和国プラハ、Prague Congress Center 3
4. 全体所感 • OpenSSF Com Day はいつも通り100人前後で開 催。OSSEU は 2,000人以上が参加。日本からも 30人超が参加。 ◦ • 最大のトピックはソブリニティ ◦ • • • • OSSNA を超えて一番多く人が集まる Open Source Summit になった ソブリニティ = US 独占からの脱却？ EU だけあって CRA の話題はホット。セキュリティ は単体ではなく、全ての領域にしみこんだ基礎・ 基盤の文脈で語られる AI からの防御・AI による防御がセキュリティの ホットトピック SBOMの作成は当たり前で、脆弱性管理にどう使 うかの議論が中心 2026年はSecurity Advisoryの発行数が前年比 42 倍（Keynoteから) 4
5. 興味深いセッション紹介 5
6. Operationalizing the EU CRA 余保 Bridging Policy, Practice, and Community @OpenSSF Community Day Global Cyber Policy Working Groupの活動紹介 Global Cyber Policy Working Groupは、EU CRAについて、どう捉えるべきか、どんな準備が必要かを議論しガイド ラインやホワイトペーパーなどを作成・提供 2026 CRA Awareness and Readiness Report 英文・和文 LF Reserchが2025年に引き続き2026年のレポートを発行 CRAの認知度や準備状況のサーベイ結果：認知度は横這いで4割程度 CRAのタイムライン 2026.9.11 Manufacturerの報告義務開始 2027.12.11 FOSS Stewardの報告義務開始 2027.12.11 CRAフル適用 Global Cyber Policy WG Bi-weekly meeting 隔週月曜日 日本時間22時～ 議事録 参加登録 6
7. Beyond the 10-Year Promise 余保 How CIP’s Industrial-Grade Foundations Anchor the AI Era @OSSEU2026 CIP (Civil Infrastructure Platform) プロジェクトの活動紹介 公共インフラシステム（鉄道・発電所など）向けのソフトウェア構成要素（ビルディングブロック）の利用および導入を可 能にするため、産業グレードのオープンソースの基盤レイヤー (OSBL)を確立 OSBLの10年超の超長期メンテ（ SLTS:Super Long Term Support)実施を約束 今年 (2026年) CIPプロジェクトは 10周年 10年超のSLTSの約束を達成 CRAの登場により公共インフラ以外でも注目 CIP Security Working GroupではOSBL導入によって どのようにCRA準拠が容易に出来るかガイドを作成中 OSSEU2026 Beyond the 10-Year Promise slide CIP CRA Compliance Readiness sile 7
8. OpenSSF CRA workshop 余保 @OSSEU2026 Global Cyber Policy WGが主催のCRA Workshop OSSEUのランチタイムに開催 3つのグループに分かれてモデレータの元で議論 Vulnerability Management + Reporting Maintainer Due Diligence 余保はDue Diligenceのチームに参加 Manufacturerの義務 ・具体的に何をどうすれば良い？ ・エビデンスの残し方は？ ・サプライチェーンにおける責任分担は？ 8
9. Proofs of Personhood: Managing Identity in the Age of AI 川名 Hart Montgomery, The Linux Foundation; Drummond Reed, First Person Cooperative; Glenn Gore, Affinidi 従来のTrustの課題 ▪ XZ Utils攻撃のように、本当に信頼できる人か分からない。そもそも実在している人かどうかも怪しいし、 AIか もしれない ▪ 1対1であれば信頼できる関係であっても、 2次、3次と関係が広がるにつれて急速に信頼性が下がる ▪ 手動での認証・検証には限界があり、誰が誰を信頼しているかが分かると攻撃の標的にもなる DTG（Decentralized Trust Graph） ▪ 中央集権のリポジトリはなく、個人のデバイスや エージェントで P2Pの信頼関係を築く ▪ コミュニティの概念も導入することで、個人間の繋 がりだけでない信頼グラフを構築 9
10. Proofs of Personhood: Managing Identity in the Age of AI 川名 Hart Montgomery, The Linux Foundation; Drummond Reed, First Person Cooperative; Glenn Gore, Affinidi DTG（Decentralized Trust Graph）の構成要素 ▪ VTA（Verifiable Trust Agent） 個人、デバイス、 AIエージェントにそれぞれエージェントを 作成し、W3C基準のDIDやVCを管理 エージェントというよりウォレット・管理システムのイメージ ▪ VTC（Verifiable Trust Community） 「信頼するルート」となるコミュニティや組織のこと 参加ポリシーやアクセス制御などを管理する ▪ VMC（Verifiable Membership Credential） VTCのメンバーであることの証明書 ▪ VDC（Verifiable Delegation Credential） 人間からAIへ権限を委任する証明書 10
11. Proofs of Personhood: Managing Identity in the Age of AI 川名 Hart Montgomery, The Linux Foundation; Drummond Reed, First Person Cooperative; Glenn Gore, Affinidi 主な機能 ▪ ZKP（ゼロ知識証明）を活用し、推薦者の名前や識別子を公開せず必要な推薦数を満たしていることだけを 証明 ▪ 多重アカウント攻撃（シビル攻撃）の防止のため、 1回限りのタグ生成により同一人物の重複推薦を検知・排 除 ▪ 過去の活動ログや関係グラフを追跡不可能にすることで、 Unlikabilityを確保 3つのコンポーネント ▪ OpenVTC：ユーザー側クライアントで、資格情報を格納するウォレット ▪ VTC：コミュニティ側で、名簿管理やポリシー定義 ▪ VTA：信頼ルートで、暗号鍵生成やアクセス制御 11
12. Proofs of Personhood: Managing Identity in the Age of AI 川名 Hart Montgomery, The Linux Foundation; Drummond Reed, First Person Cooperative; Glenn Gore, Affinidi デモ公開 ▪ https://firstperson.dev/ ▪ 現地で実演有 ▪ ①Aさんが運転免許証やパスポートを使って VTAを作成 ②Aさんがコミュニティの QRコードを読んで加入申請 ③コミュニティ管理者が Aさんを1次承認 ④推薦人とAさんがお互いの IDを読み取って認証・承認 12
13. SCORED • 下沢 https://scored.dev/ Conference on Software Supply Chain Offensive Research and Ecosystem Defenses (SCORED ’26) ◦ ◦ ◦ ACM + LF, OpenSSFがスポンサーの学会 (2025までACM単体のWorkshop?) 今年は、アカデミアと OpenSSFコミュニティとのシナジーをねらって OpenSSF Community Day Europeと併催 来年もバンクーバーで OSSNA (5月)との併催予定 The SCORED conference invites academia, industry, and governmental entities to submit original research papers or security-in-practice talks concerning the security of software supply chains from both technical and policy perspectives. Particular focus areas of interest to the committee in 2026: • AI supply chain • Reproducible builds • Privacy-enhancing technologies in the context of supply chain security • Datasets and benchmarking (e.g., SBOM datasets, datasets for ML models) 13
14. 下沢 Hurry Up and Wait: Malware Detection Timelines and Minimum Release Age for npm Dominic Tassio (U of Kansas) et al. • 常に最新のバージョンを利用していると、ソフトウェアサプライチェーン攻撃によって悪意ある パッケージをインストールしてしまう可能性がある 悪意ある アップデート 発覚 対処 • npmコマンドにはv11.10.0 (2026/02/11)から”min-release-age”オプションが追加 ◦ リリースされてから指定された時間が経過したパッケージのみをインストールする • では、どれだけ待つのが正しいのか ？ 14
15. 下沢 Hurry Up and Wait: Malware Detection Timelines and Minimum Release Age for npm • 過去の脆弱性を解析して、妥当な期間を探索 ◦ ◦ 対象: GitHub Advisory Databaseから、CWE-506 (埋め込まれた悪意あるコード , Embedded Malicious Code) であるnpmで公開されているパッケージの脆弱性 (403件、520パッケージ) 悪意あるアップデートが行われてからセキュリティアドバイザリが発行されるまでの期間を調査 ▪ npmでの公開時刻 (226件のみ判明) とセキュリティアドバイザリの公開時刻 の期間 • (例) color 5.0.1 (CVE-2025-59143)の場合 npm公開時刻: 2025/09/08 13:16:24 UTC アドバイザリ公開時刻 : 2025/09/15 18:50:02 UTC 7日5.5時間 15
16. 下沢 Hurry Up and Wait: Malware Detection Timelines and Minimum Release Age for npm 192時間 = 8日 • 結果 ◦ ◦ ◦ いくつかジャンプがある 7年待てば100% 8日で69% • 70%はちょっと少ない、けど… ◦ ◦ 実際にはnpmのパッケージの ダウンロードには偏りがある ほとんどのパッケージは全く ダウンロードされない 340万個は 週10ダウンロード未満 16
17. 下沢 Hurry Up and Wait: Malware Detection Timelines and Minimum Release Age for npm 192時間 = 8日 • パッケージの人気で重みづけ ◦ ◦ 7年待てば100% 8日で94.2% Hurry up s y a D 8 for t i a W And 17
18. 下沢 Hurry Up and Wait: Malware Detection Timelines and Minimum Release Age for npm • 当日のQ&A ◦ ◦ ◦ 「8日間」という期間は、 GitHubやnpmのセキュリティチームが、報告されてからアドバイザリを公開す るまでの対応時間が入っているのでは？ ▪ Yes。実際のアタックウィンドウよりは保守的な値となっている可能性がある 脆弱性によっては、修正パッチが公開されてから数分や数時間で脆弱性が悪用されるケースもある。 8日間待つということのリスクについてどう考えるか？ ▪ Minimum Release AgeはSilver Bulletではなく、防御の一つである。緊急セキュリティパッチに は、この設定をバイパスして適用する必要がある パッケージマネージャーや他ツールで 8日間をデフォルトとするよう働きかける予定はあるか？ ▪ 機会があればしたい。既存の他のツール (SonatypeやDependabot)では3日間としていることも あるが、これにはデータ的な根拠がなく、今回データ分析によって示したことに意義がある 18
19. Keynote: Linus & Dirk 対談 池田 Linux 誕生35周年を記念して、Linux、Git を振り返り AI 時代の未来を見通す、みんな大好きLinus & Dirk 対談。今回は歴史の振り返りがメイ ン。 数年前までは AI に否定的な発言も目立っていたLinus だが、最近は「使えるところには使っていこう」という姿勢を打ち出している。 Linux は誕生から35周年。振り返って初期と変わったこと ▪ ▪ コードをオープンにして多くを学んだ。パッチが送られてきて、人々がなにを望んでいるか分かった。 中には私よりよく OS/カーネルを知っている人もいた。 Git 以降(2006年以降)の Linux 開発モデル ▪ ▪ 最初は10週間ごとにリリースするなんて正気じゃないとも思った。ただ、開発ブランチで 2年間あちこち壊し続けてそのあとにリリース する、みたいな形にはしたくなかった。20年続けてきて、いまはちゃんと動いている。 カーネルは退屈であるべき。変更が暫時的・インクリメンタルでも、長い年月でみると変わっている。 AI について ▪ ▪ 現在はプログラマにとってのハードルが上がっている。 AI の支援でなにかができるところまですぐ到達できることは、プログラマの参 入ハードルを下げる意味では良いこと。あらゆる技術領域で、参入ハードルは低い方がよい。 自分で作ったものはUI が 1980年代のものになっちゃう。それはまあ、僕は男らしいカーネル技術者であって UI は分からな いから当然なんだけど（会場拍手）、AI に頼めば21世紀の UI にしてくれる。 19
20. Keynote: Linus & Dirk 対談 池田 20
21. Ask for Help like a Pro! Jakub Scholz, Cloudera 池田 OSS への貢献の仕方を基本に立ち返って説く。 今一度大事なことを思い返させてくれる大変面白いセッションなので紹介。 質問も貢献の一種 Win-win を目指そう ドキュメントに書かれていない部分かもしれない。知りたい人が他にもいるかもしれない。 プロセスをできるだけ効率的にするとユーザーにもメンテナにも win-win。それには正しい方法で質問することが必要。 正しい場所で質問しよう ML, Github, Slack, Discord…etc.Web サイトに質問場所へのリンクを載せておくのもよい。 ユーザーはこれらや、 README.md をチェックするとよい。 同じ質問を複数の場所でする場合は、それが本当に必要なのか考えよう。１チャネルで質問するのが本当は良い。 重複を避けよう 以前の質問を検索する。見つからなければ、問題をよく確認して、設定などを添付して状況を明確に質問すること。 共有しよう 自分は何を読んで理解しているか。なにをしたか。 Issue template があれば利用する。トラブルシューティングツールがあれば使う。 可読性のあるコードを書く（特に YAML）。ログはスクリーンショットではなくテキストで提出する。 秘密情報は公開しない 会社によっては IP アドレスやホストネームも社外に出してはいけない。これらは匿名化すること。 異なるマシンのログの時計は合わせるように。 ショートカットや略語は なるべく使わない Be patient WDYM: What Do You Mean? IMO, AFAIK…etc. ログ、コマンド、コンフィグは確定的語句。 分からない語句は遠慮なく聞く。 AI を使うなら書くより translation の方が有用。 お返ししよう 人は知らない人より友人の方が助けてあげたくなる。コミュニティの一員になろう。 すごいコントリビュータになる必要はない。他の人を助けて、あなたの会社を参加者リストに載せよう。 人は 24/7 で動けない。コミュニティも答えを知らない場合がある。 AI があってもコミュニティは重要。リアルな人と関わろう。 21
22. 紹介しきれなかった分 Meetup 内では時間が足りなかっ たので、せめて資料だけは付ける ので後日ご確認ください 22
23. ORBIT Launchpad: Building the Due Diligence Bridge Between Manufacturers and Open Source Sarah Evans, Dell Technologies & Rao Lakkakula, Microsoft 資料リンク 川名 CRAB-FOSC v1の公開 ▪ CRA Baseline for Open Source Consumption ▪ 製造業者がOSSで評価すべき事項を、 3カテゴリ・12項目に分類 評価ツールとモデル ▪ Privateer：自動判定用スキャナープラグインで 証跡集め ▪ Gemera：ツール間で評価メタデータを共有す るための標準フォーマット ▪ これらのツールで、リスクベースの意思決定を 支援し、CRA対応へのコストを削減 23
24. Digital Sovereignty, Institutionalisation and International Momentum: 2026 OSOR Report on Progress and Trends - Éléonore Daxhelet, OpenForum Europe 資料リンク 川名 Open Source Observatory (OSOR) ▪ 欧州委員会が運営する公共部門の OSS推進・情報共有するプラットフォームのこと ▪ 行政における OSS導入のベストプラクティス共有、国別レポート、トレーニングの提供など 2026年レポートのトレンド ▪ ▪ OSS採用の拡大： 安全保障の理由や自立性確保のためにOSSが選ば れている 透明性と監査がOSSのセキュリティ上の強みとして、ド イツやオランダなどで長期的な運用継続性のために OSSを組み込む動きが加速 制度の強化： 中央政府が主導する流れ。ポーランドやフランスでは 国防省や行政内にOSPOを設置 ▪ ▪ 資金調達： 重要OSSの維持とセキュリティ確保に向けた政府レベルの 公的資金調達スキーム 米国大手テック企業依存を避けるための欧州共同開発が 活発化 EU外の事例： スイス：連邦政府が開発したツールのオープンソース化が 義務付けられ、標準化が推進 ウクライナ：電子政府アプリをオープンソースとして展開 24
25. Open Source Security as the Foundation of European Sovereignty - Madalin Neag & Mirko Boehm, The Linux Foundation 資料リンク 川名 デジタル主権と OSS ▪ OSSに国境はない。自国でコントロールすることがデジタル主権の鍵になる ▪ 欧州のデジタル主権・技術主権を強化するための「 European Technological Sovereignty Package」 主権レベル SEAL ▪ SEAL（Sovereignty Effectiveness Assurance Levels）でデジタル主権の度合いを 5段階で分類 レベル 説明 SEAL-0 No Sovereignty サービス、技術、運営が、 EU外の管理下にあり、 EU外で完全に統治される SEAL-1 Jurisdictional Sovereignty EU法は形式的には適用されるものの、実際の執行力は限定的 SEAL-2 Data Sovereignty EU法が適用され執行可能であるが、 EU外の重要な依存関係が残っている SEAL-3 Digital Resilience EU法が適用され、執行可能であり、 EUの主体が実質的な影響力を行使しているものの、完全な影響力を行使しているわけ ではない SEAL-4 Full Digital Sovereignty 技術および事業運営は完全に EUの管理下にあり、 EU法のみに準拠し、 EU域外の重要な依存関係は一切存在しない 25
26. Open Quantum Safe: Post-Quantum Software Research in the Era of the First PQC Standards - Rodrigo Martín, Indra 資料リンク 川名 背景 ▪ NISTによって最初の標準アルゴリズムが決定し、 OpenSSLなどに組み込みが開始 ▪ 標準化後のOpen Quantum Safe（OQS）プロジェクトの方向性について課題感があった OQSの今後の方針 ▪ 標準化前の実験的アルゴリズムへの再注力 ▪ 暗号研究・評価プラットフォームの継続支援 ▪ オープンソースコミュニティとの連携強化 →商用ライブラリと競合するのではなく、 OSSと連携しながら研究の基盤を提供することで貢献をする 26
27. Open Source Maintainers VS The CVE Tsunami 下沢 Harkrishn Patro (Apple), Madelyn Olson (AWS) Valkeyプロジェクトでの課題 ◦ AIの普及による脆弱性発見が容易になり、GitHubで のセキュリティアドバイザリのリクエストが急増 ▪ 2026年の現時点で2024年+2025年合わせ たよりも多い ◦ 脆弱性を見つけるコストは下がったが、その後のプロ セス (再現、トリアージ、パッチ作成、テスト、リリース、 バックポート) は変わらない ▪ “Finding got cheap; everything after it didn’t” ◦ 重複レポートが多発 ▪ 3人の別々のセキュリティ研究者が、同じ脆弱 性を2週間の間にそれぞれ報告するということ もあった メンテナ側での対策・取り組み ◦ CVEはもはや特別なものではない (CVE becomes nothing special) ▪ Embargo (公開猶予期間) の短縮: 30日→14 日 ◦ バグを先に見つける (Find bugs before they go) ▪ プロジェクト側でも敵対的テスト (Adversarial Testing)を導入し、バグを積極的に発見する ▪ 34件の実際のバグを発見 ◦ 素早く対応する (React fast) ▪ トリアージの最初の対応者としてAIを導入 ▪ 脆弱性の再現性を自動で評価 ▪ バックポートの作業も自動化し、実際に5つのブ ランチへのバックポートを72分で実施 27
28. Open Source Maintainers VS The CVE Tsunami 下沢 Harkrishn Patro (Apple), Madelyn Olson (AWS) 見つかった課題 ◦ 脆弱性調査にLLMを利用すると、「サイバー攻撃の懸念 がある」として、回答拒否されてしまうことがある ▪ AnthropicやOpenAIが、セキュリティチーム向け プログラムを立ち上げており、それに登録する ▪ オープンウェイトモデルを利用する ◦ 人が発見が困難だったバグを AIで実際に発見できた ▪ Use-After-Freeのバグの発見 • Linked Listのtraversal中での、別スレッド でのLinked Listの操作(削除) ◦ メモリ安全言語(Rust)は万能ではない ▪ 上記のバグはRustで防げる ▪ オーバーフローやロジックの不具合は Rustでも防 げない Q&A ◦ バックポートの自動化に AIを使っているというこ とだが、コスト削減でローカルやオープンウェイト モデルを使っているか？ ▪ Valkeyは、AWSからトークン寄付をもらっ ているため、それを利用している。ローカ ルモデルも評価しているがまだ劣ってい る。ただし、将来的には実用的になると考 えている ◦ 敵対的テストでどれだけの数がバグ候補として 出たのか？ ▪ 最初は1200件で、コードレビューで 200-300件、トリアージで 150件に絞り込 み、再現テストで 34件となった 28
29. (SCORED) 下沢 Canary in the Code Mine: Predictive Risk Scoring for Open-Source Supply Chain Security Timothy E. Brennan (George Washington U) 背景 ◦ OSSに対するソフトウェアサプライチェーン攻撃 が増える中、既存のツールは受動的 (reactive) ▪ CVE, CVSS, EPSS, Scorecard ◦ CANARY: Component Analytics & Near-Term Advisory Risk Yardstick ▪ 各プロジェクトのリスクを予測する ▪ 対象 • Jenkins プラグイン (2,053) • 各プラグインで、今後 6カ月以内に セキュリティアドバイザリが発行され る可能性を判定する 過去の評価の課題と再評価 ◦ 7月にROC-AUCを0.96, 精度を0.77として報告 ◦ しかし、時分割の失敗による結果 ▪ 未来のデータ(ラベル)を含んで学習してしまっ た結果で、プロジェクトの内容ではなくラベルか ら学んでしまった結果 ▪ ラベルしなおした結果、ROC-AUCが0.482まで 低下 ◦ ラベルを正しくし、最良のモデルで行った結果、 ROC-AUCは0.670 ◦ PyPIでも評価したが、シグナルはエコシステムで大き く異なる ▪ Jenkins: 最新のアクティビティ・コントリビュータ の動き ▪ PyPI: 過去のアドバイザリ履歴 29
30. How Git Clone Took Down Our CI for 20 Days 下沢 Yathartha Goenka (Mercari) 対処 背景 ◦ ある日、Mercariの1800リポジトリを対象とするGKEで構 築されたCIシステム全体で、HTTPエラー(401, 403, 429)が頻発するようになり、20日間CIがほぼ停止状態と なった 原因 ◦ 2.47より前のGitのデフォルト動作 ▪ 認証トークンが設定されていても最初は未認証の 状態でHTTPリクエストを行う ◦ Goモジュール解決の仕様 ▪ プライベートモジュール解決の際、 Gitで失敗する と、追加情報のためにリポジトリの Webページに 認証なしでアクセスしようとする • 結果、404や409を大量発生 ▪ (しかも一部のスクリプトで大量に並列実行をして いた) ◦ Gitの設定変更 ▪ http.proactiveAuthの設定 (Git 2.47+) ◦ これを各リポジトリに適用するために sourcegraphを用い て979件のPRを一括発行 ◦ DinDで動いているものなど、CIホストのGit変更が適用さ れないものに対して、ミラーレジストリ (イメージキャッシュ) を利用して、Golden imageの強制適用 ◦ モジュールプロキシを経由した Goのモジュール解決 ◦ 並列実行していたスクリプトの修正 教訓 ◦ Gitのデフォルト設定の見直し ◦ Goモジュール解決挙動の見直し ◦ コンテナ環境のガバナンス (Golden imageの運用が不可 欠) 30
31. How Git Clone Took Down Our CI for 20 Days 下沢 Yathartha Goenka (Mercari) Q&A ◦ 今後、個別のDockerイメージにパッチ適用を続けるのか？それと も別の解決策を取るのか？ ▪ 2000以上の個別Dockerfile・175個のコンテナイメージ が乱立していたが、プラットフォームチームが管理する 15-17個の標準イメージに統一した ◦ 979件のPRをどのように作成・マージしたのか？ ▪ Sourcegraphでリポジトリのワークフローをスキャンして 作成した。多数のプロダクトチームがあるため、管理者権 限を用いて強制的にマージした ◦ 今回得た教訓は、今後参加するエンジニアにどのように共有して いるか？ ▪ コードコメントやWikiに残すだけでなく、”Golden Path”と いう全社の共通フレームワークとして体系化した ◦ アップストリームへのフィードバックはしたのか？ ▪ proactiveAuthやGo Proxyなどの解決策は既にあったた め連絡はしなかった。自分たちの運用の問題。 Q&A ◦ インシデント管理にはどのようなツールをもちいてた か？ ▪ インシデント管理には、FireHydrantを使用して いる ◦ 顧客への影響はあったか？ ▪ 外部顧客へのサービス障害はなく、社内インシ デント。ただしCIに伴いCDも停止したため、機 能リリースの遅延は発生した。 ◦ 今回の障害で最も重要な教訓は何か？ ▪ プラットフォームを単なる運用のサービスでは なく、社内エンジニアによるプロダクトとして定 義すること ▪ 好き勝手にDockerfileなどで構築するのを防 ぎ、プラットフォームチームがGolden Pathを提 供して管理することが不可欠 31
32. おまけ： チェコ共和国 プラハ ▪ プラハはボヘミアの中心都市。旧 王家の城が建つ丘の下をモルダ ウ川が流れる美しい街 ▪ 朝は 6～8℃、晴れると昼間は 20℃ を超える寒暖差 ▪ 治安が悪いような路地は見られ ず。比較的安全な街？ ▪ 通貨はチェコ・コルナ。ユーロでは ありません • ボヘミアの川よ、モルダウよ～ 昔はクローネって言いませんでし た？ 王城。チケットトラブルで中に入れませんでした 32
33. おまけ： 写真集 国立博物館の素晴らしい階段 Linux 35周年イラスト 謎の日本語風Tシャツ レセプションパーティ会場は宮殿 恒例の朝活5kmラン Congress Hall (メインホール） 世界最古のマルシェ(西暦1232年） OSSEU会場のLunch 33
34. Thank You For Listening! 34
35. 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. 35