皆さんこんにちは、ACS事業部亀崎です。 2025年6月18日、KubeCon + CloudNativeCon Japan 2025の併催イベントの１つ、OpenSSF Community Day 2025に参加してきました。
この分野にすごい詳しいというわけではありませんが、これまでも何度か取り上げてきたSoftware Supply Chain Securityに関するものなのでやはり注目しないわけにはいきません。
こちらのような内容でした。
実は KubeCon Japanのほうでも Your SBOM Is Lying To You – Let’s Make It Honest というセッションがあり、こちらも大変参考になりました。
Log4Jの脆弱性あたりから大きく取り上げられてきたSoftware Supply Chain Security 。このブログでも2022年から取り上げてきていましたね。
2022年以降、海外では法律でその作成・公開が義務付けられはじめているSBoMですが、日本ではまだそこまで定着していない印象です。セッション等で行われるQuick Surveyでも実際に取り組んでいる方は欧米系の方が多かった印象です。
しかし、最近でも OSS Packagesに脆弱性が仕込まれるなど、その対応の重要性はどんどん高まっているように思います。
今日のセッションの中でも、 Ozzie & Nova - Supply Chain Shenanigans: A Kubernetes Security Play About OpenSSF Standards で寸劇風にこんなところを攻撃してくるんだよ、だからこういう対応が必要だよと解説してくれていましたが、従来の実行環境の防御だけではなく、開発環境の防御の重要性がわかりやすかったです。（もしビデオが公開されたらぜひご覧になっていただくとよいと思います）
さらにSBoMって複数あるんだ、ということを今回あらためてはっきりと認識できました。一般的にイメージできるのは Code SBoMですが、それ以外にもContainer ImageレベルでのSBoMなど（全部メモしきれなかったのですが）4種類ぐらいあったように記憶しています。
さらにKubeConの最終日のセッションのタイトルの通り、実はSBoMだけでは防御としては不完全で、それ以外にもビルドやテスト、パッケージングで使ったツールやその実行内容などもちゃんと記録にとっておかないといけないというのもなかなか大変です。
開発者がどこかのタイミングで実際に導入していかないとと思っても、さまざまなツールを組み合わせてその環境を作り上げなければならないということや、実際に公開するアプリケーション機能とは直接関係ない内容のものでもあり、導入するにはまさに「認知負荷」が高いものになっていると感じます。
開発者の認知負荷を下げる、と聞くとまさにPlatform Engineeringの世界だなと思うのですが、実行環境を提供するものではないため従来のインフラチームの役割からも外れ、あまり積極的にこの分野を対応しようとする人がおらず、導入組織が増えていかないのかなと推測しています。
これからますます必要性がます領域だと思いますので、なんとか自分から取り組みたいと思ってはいるんですが・・・・。なんとかキャッチアップしていきたいと思います。
また、もう１つとても興味深いものがありました。それが今日の最後にあった Tabletop Exercise（TTX）です。仮想的なIncidentを想定して対応内容を検討してみようというものです。それをトレースしていくと、技術的なものももちろん必要なのですが、組織的な対応（役割分担）やディシジョンプロセス、外部への情報公開のやり方など、事前にさまざまなことを決めていないと実際に発生したときに対応が難しいなと感じました。 組織でなにかしらの事故があったときに、誰が・どのように・どういった基準で情報公開するか、誰がディシジョンしなければならないのか、といったことがIncident発生時にも求められるという感じです。
今日扱った内容を全部一気に導入するのは難しいとは思いますが、ぜひ皆さんもこの領域に興味をもっていただき、少しずつでも実現していただければと思います。
（自分の知識不足で中身までご紹介できない点はご容赦ください）
ということで私のKubeCon Japan 関連のイベントもこれですべて終了です。 機会があれば、そのエッセンスを少しずつこのブログで紹介できればと思っています。ぜひご期待いただければと思います。
それでは。
