OpenSSF Community Day Japan イベントレポート

後藤健太氏・竹村太一氏 (サイボウズ株式会社)
2025年7月30日開催 OSSセキュリティMeetup 講演資料

1. OpenSSF Community Day Japan イベントレポート 2025.07.30 サイボウズ株式会社 後藤、竹村 1
2. 自己紹介 • 後藤健太 • 所属 • サイボウズ株式会社 • Platform Developer eXperience (PDX) • 経歴 • 2019.04 – 2025.01 • プライベートクラウド基盤の開発 • パブリッククラウド (AWS) 基盤の運用 • 2025.02 - サイボウズ株式会社 • Security, OpenSSF • Platform Engineering • Kubernetes 2 @gokken-roko
3. • 竹村太一 • 所属 • サイボウズ株式会社 • 仕事内容 • Kubernetesをベースとしたインフラ基盤の開発・運用に従事 • コンテナレジストリミラーの運用 • 最近はKuberetesのコントローラを開発しています https://github.com/cybozu-go/ofen • 好きな技術 • containerd • Linux Audit 自己紹介 3
4. 4 01 02 03 04 OpenSSF とサイボウズの関係 Ozzie & Nova - Supply Chain Shenanigans: A Kubernetes Security Play About OpenSSF Standards レポート Tabletop Exercise (TTX) Panel Session レポート まとめ 目 次
5. OpenSSF と サイボウズの関係 • サイボウズでは自社の基盤からアプリケーションまで幅広くOSSを活用している • 基盤開発の成果物の一部をOSSとして公開している https://github.com/cybozu-neco • サイボウズはOpenSSFにGeneralメンバーとして加盟 • OSSのセキュリティ問題への貢献 • OpenSSFの推進するセキュリティ対策の自社への導入 5 https://topics.cybozu.co.jp/news/2022/08/31-18229.html
6. OpenSSF Community Day Japan 2025 • 日程: 2025 年 6 月 18 日 • 場所: ヒルトン東京お台場 • 内容 • OSSのセキュリティに特化したカンファレンス • 60名以上の世界各国からの参加者 • KubeConに合わせて、開催されていた 6 https://events.linuxfoundation.org/openssf-community-day-japan/
7. Ozzie & Nova - Supply Chain Shenanigans: A Kubernetes Security Play About OpenSSF Standards レポート 7
8. • Ozzie & Nova - Supply Chain Shenanigans: A Kubernetes Security Play About OpenSSF Standards - Whitney Lee, Datadog & Puja Abbassi, Giant Swarm 紹介するセッション 8
9. • 寸劇形式でKuberetesクラスタに対して 攻撃者がどうやってソフトウェアサプライチェーン経由で攻撃するかが実演された • 3種類のソフトウェアサプライチェーン経由での攻撃シナリオが紹介された • 攻撃シナリオ1: 物理アクセスと不正なイメージのdeploy • 攻撃シナリオ2: Dockerfile改ざんによる攻撃 • 攻撃シナリオ3: 依存関係へのBackdoor混入 • それぞれの攻撃シナリオの対策として、sigstore cosign、SLSA、SBOM、OpenVEXといった ツールの紹介が行われた Ozzie & Nova - Supply Chain Shenanigans: A Kubernetes Security Play About OpenSSF Standards 9
10. • 登場人物 • Ozzie: セキュリティに自信を持つプラットフォームエンジニア • Nova: 攻撃者 • セッションの内容 • OpenSSFで開発されているツールでどういった対策ができるかを紹介するセッション • ツールの技術的な詳細に関しては触れられず、ツールがどういった場面で使えるかがテーマのように感じた 10 Ozzie & Nova - Supply Chain Shenanigans: A Kubernetes Security Play About OpenSSF Standards
11. • OzzieはBig Corpという企業でKubernetesクラスタを管理する • Kubernetesクラスタには、様々なセキュリティ対策がされている • service meshとmTLSによりpod間の通信を保護 • Kyverno(Kubernetes向けのポリシーエンジン)によるポリシー制御 • Falco(脅威検出システム)による侵入検知 11 Ozzie & Nova - Supply Chain Shenanigans: A Kubernetes Security Play About OpenSSF Standards
12. • KuberetesクラスタではBig Corpと呼ばれるWebアプリケーションがデプロイされている • ネットショッピングのサービスを提供 • WebアプリケーションのマニフェストはGiOpsコンフィグで管理される 12 Ozzie & Nova - Supply Chain Shenanigans: A Kubernetes Security Play About OpenSSF Standards
13. • NovaはOzzieがPCをロックせずに離席した隙に、USB Rubber Duckyを使用 • Rubber Duckyはキーボードになりすまして、予めプログラムされたキー操作を行うツール • Rubber Duckyを使うことでOzzieのPCから以下の情報を窃取して、 Kubernetesクラスタへのアクセスを確立 • kubeconfig • Kubernetesクラスタへアクセスするための設定ファイル • private SSH key • SSH configファイル • Git configファイル 攻撃シナリオ1: 物理アクセスと不正なイメージのDeploy 13
14. • NovaはBig Corpのdeploymentのマニフェストを変更し、 Novaが作成した悪意があるコンテナイメージを実行するように変更 • Novaは窃取した認証情報を用いて、OzzieになりすましGitOpsコンフィグを改ざんする 攻撃シナリオ1: 物理アクセスと不正なイメージのDeploy 14
15. • Argo CDがGitOpsコンフィグの変更を検知して、syncを行う • Novaの悪意があるイメージが実行される • OzzieはKubernetesのイベントを確認し、不正なイメージが実行されていることを発見し気がついた 攻撃シナリオ1: 物理アクセスと不正なイメージのDeploy 15
16. • 再発防止策 • Sigstore cosignを使用して、Big Corpによってビルドされたコンテナイメージであることを示す署名を行う • Kyvernoに新しいpolicyを導入し、Big Corpによって署名・検証されたイメージのみ実行を許可するように設定 対策1: イメージの署名と検証 16
17. • Novaは窃取した認証情報を使いOzzieになりすまし、ソースコード内のDockerfileを改ざん • DockerfileにCOPYコマンドを追加し、悪意のあるshell scriptをコンテナイメージに含めるように変更 攻撃シナリオ2: Dockerfile改ざんによる攻撃 17
18. • Big Corpの公式CI/CD pipelineが、この悪意のある変更を検知せずイメージをビルドした • ビルドされたイメージは公式のpipelineによってビルドされたため、 Sigstoreによって自動的に署名され、Kyvernoのチェックも通過してしまった • OzzieはGitのcommit履歴を確認し、自分自身がDockerfileのcommitを行っていることを発見し、 なりすましを発見した 攻撃シナリオ2: Dockerfile改ざんによる攻撃 18
19. • 再発防止策 • Git commitへの署名を必須にするGit signsを導入 対策2: Git commit署名とBuild Provenance 19
20. • 再発防止策 • Dockerfileのようなソースコード経由で悪意のあるコード混入を防ぐため、Build Provenanceの概念を導入 • 「どのように、どこで、どの入力を用いてビルドされたか」を記録・検証する • Kyverno policyを更新し、イメージが有効なSLSA attestationを持つことを必須とする • attestationは、ビルドがtrusted build stepsに従ったこと、承認されたbase イメージからビルドされたこと、 承認されたDockerfileを使用したことを検証する 対策2: Git commit署名とBuild Provenance 20
21. • Novaは以前Ozzyのパソコンにアクセスした際に保存した、SBOM(Software Bill of Materials) を調査 • SBOMはソフトウェアに含まれるコンポーネントや依存関係の情報を含めた一覧のリスト • SBOMの中から古いversionのLog4j (0.9.2) を発見した • NovaはLog4jをforkし、いくつかのbug fixと同時に、 backdoorを追加した新しいversionを公開する • Log4j 0.9.3として公開 • NovaはBig Corpが誤って、forkしたパッケージを使われるのを待つ 攻撃シナリオ3: 依存関係へのBackdoor混入 21
22. • Big CorpのCI/CD pipelineは、このsecurity updateを問題ないと判断し、 自動的に取り込んでイメージを再ビルド、署名、deployした • Backdoorが仕込まれたイメージが作成され、NovaがBackdoor経由でクラスタへアクセスできるようになる 攻撃シナリオ3: 依存関係へのBackdoor混入 22
23. • Big CorpのCI/CD pipelineは、このsecurity updateを問題ないと判断し、 自動的に取り込んでイメージを再ビルド、署名、deployした • Backdoorが仕込まれたイメージが作成され、NovaがBackdoor経由でクラスタへアクセスできるようになる 攻撃シナリオ3: 依存関係へのBackdoor混入 23
24. • Falcoが不審な通信を検知し、Ozzieにアラートを通知した • Ozzieは内部サービスから不審な外部IPへの接続を発見 • Ozzieは外部IPへの接続を行っているPodのコンテナイメージをTrivyでスキャンして、 悪用された脆弱性を特定 • Trivyでスキャンしただけでは、多くの脆弱性が検出されてしまう • OpenVEX (Open Vulnerability Exploitability eXchange) を使用し、 特定の環境で実際に悪用可能な脆弱性に絞り込んだ • Big Corpのsecurity teamが介入し、旧clusterを隔離し、新clusterを構築した 攻撃シナリオ3: 依存関係へのBackdoor混入 24
25. • 新clusterでの再発防止策: • SBOM policyを導入し、applicationの全コンポーネントを追跡 対策3: 脆弱性管理とSource Attestation 25
26. • 新clusterでの再発防止策: • SLSA source attestationを必須とし、オープンソースの依存関係のcommitがレビューされ、 検証済みのコントリビュータによるものであることを証明する • VSA (Verification Summary Attestations) を使用し、機械可読な形式でこれを実現 • Kyverno policyを導入し、有効なVSAを持つ依存関係のみを許可 対策3: 脆弱性管理とSource Attestation 26
27. Tabletop Exercise (TTX) Panel Session レポート 27
28. Tabletop Exercise (TTX) Panel Session Tabletop Exercise とは？ > A Tabletop Exercise (TTX) is where an organization assembles subject matter experts to role-play through a mock incident that tests out the organization’s incident response plan (IRP) and gauges the ability of the org to react to plausible threats. - OpenSSF Tabletop Exercise Framework TTX とは、組織が専門家を集め、模擬インシデントを通してロールプレイを行い、 インシデント対応計画（IRP）を検証し、脅威への対応能力を評価するものです。 TTX は “Mock Disaster” とも呼ばれ、 インシデントの復旧計画 (BCP/DR) を検証する場になる 28
29. Tabletop Exercise (TTX) Panel Session セキュリティインシデント対応の必要性 • データ侵害(情報流出)に被害額は 2024 年は前年より 10% 増加した $4.88 million となった • [IBM: Cost of a Data Breach Report 2024] • CVE の件数は 2013-2023 で 463% 増加 • [Sonatype: State of The Software Supply Chain 2024] • 攻撃者は侵入後、平均 48 分、最短 51 秒という短時間で、システム内部で移動をする • [Crowdstrike: CrowdStrike 2025 Global Threat Report] セキュリティインシデントは迫っており、 顧客情報の保護、企業ブランドの維持、ビジネスの継続の観点から、対応準備が必要 29
30. 今回の Tabletop Exercise (TTX) の概要 • OSS プロジェクトの CI/CD パイプラインに侵害があり、脆弱性のあるコードがリリースされた • OSS を利用している企業のプロダクトに、その脆弱性が混入したかもしれない それぞれのロールが、各ステージごとに議論する ロール • Moderator : 各ロールに話題を振り、 議論の方向性のアドバイス • CISO: 企業の最高セキュリティ責任者 • OSPO: 企業の OSS 推進チーム責任者 • Developer: OSS メンテナー, 開発者 • Researcher: セキュリティ調査・専門家 • Customer: プロダクトの顧客 30
31. Day1 – 脆弱性の認識 (Identify) 議論 • Developer は、SNS などで脆弱性に関する議論を発見するだろうが、 SNS で騒がれるのは信頼があるものではないかもしれない • Researcher としては、きちんとした GitHub からの脆弱性報告フローが整備されていると良さそう • OSPO では、SBOM や OpenSSF Score Card など活用し状況把握に活用できると良さそう • Customer は、内部の事情に詳しくないので、影響がわかるような情報提供の検討が必要 Day1 まとめ / アドバイス • 早期の問題検知や、利用する Package の信頼性を担保する仕組みがあると良いでしょう • SLSA によるパッケージの来歴の検証 • SBOM を利用した依存性の把握 31
32. Day3 – 問題が公開され対応が始まる (Containment, Eradicate) 議論 • 各ロールは、ステークホルダーと適切にコミュニケーションを取りながら対応する必要がある • Developer はレポートを提出し透明性のあるやりとりをしたほうが良さそう • 透明性のあるやり取りが、企業価値を向上させるという認識が重要 • レポートなどの問題は政府からの指摘も考えられるので、CISO は法律、規制要件の対応の準備が大事 • Customer が簡単に安全なバージョンの製品を使えるような対応を考える必要がある • 不正な挙動をモニタリングできるようにすることも必要 Day3 まとめ / アドバイス • 脆弱性開示、ステークホルダーとのコミュニケーション手順は重要 • OSS を利用する側も、脆弱性範囲を特定し、顧客に情報提供できるようにしておく体制が必要 32
33. Day7 – OSS のパッチがリリースされた (Recover) 議論 • パッチの分析をするほか、顧客にどのような影響がありサポートできるかの検討が必要 • OSPO としては、今回のような脆弱性混入から守るための改善をしたほうが良さそう • OpenSSF Best Practice の活用 • Developer は、単にコードを書くだけでなく、セキュアにしておくための取り組みが必要になりそう • セキュアな CI/CD, MFA 有効化, シークレットローテーション • 完全に再発防止は難しいが、顧客との透明性のあるコミュニケーションが必要 Day7 まとめ / アドバイス • 多層防御 (CI/CD、認証認可など) について検討し、より回復力のある体制を目指す必要がある 33
34. Tabletop Exercise (TTX) - 学べること 今回の Tabletop Exercise から学べる Incident Response への対応 • 責任者の割当、問題の分類、解決プロセスのドキュメント整備の重要性 • SLA を決めたうえでの、ステークホルダーとのコミュニケーション • きちんと準備、練習して問題に対応することの重要性 OpenSSF では Tabletop Exercise のリソースを提供・整備予定 https://github.com/ossf/wg-vulnerability-disclosures/tree/main/docs/TTX 34
35. まとめ 35
36. まとめ・感想 Supply Chain Shenanigans: A Kubernetes Security Play About OpenSSF Standards • 寸劇形式でサプライチェーン攻撃についてわかりやすく講演されていた • サプライチェーンの各段階で対策が必要になる • 複数のツールを用いることで、多層防御を実現する必要がある • サプライチェーン攻撃の全体像を把握することができた Tabletop Exercise (TTX) Panel Session • 脆弱性のある OSS のパッケージがリリースされるという身近な話題がテーマだった • 最近では eslint-config-prettier で悪意のあるパッケージが公開されることがあった • 各ステージ、でそれぞれのロール・立場で多様な考え方がわかる • 経営層、技術者や顧客では意識することも違う • 多層防御の実現、日頃の準備・練習をして、将来のインシデントに対応が必要 36
37. ©️ Cybozu, Inc. 37