取り組み方が明らかになっていく Software Supply Chain Security
米国連邦政府向けシステムで要求される事柄のSoftware Supply Chain Securityに関しては前回KubeCon 2022 NA Detroitでもかなり注目されていました。
CNCFの各プロジェクトでもその対応が進行していることもあり、今回のKubeCon EU 2023でも多くのセッションで取り上げられています。
Software Supply Chain Securityのポイント
そんな中でSoftware Supply Chain Securityのポイントが見えてきました。個人的な解釈ですが、Software Supply ChainにおけるZero Trustを実現することがポイントになっていると感じます。つまり「信用するな、確認しろ」を徹底することです。
ソフトウェア開発のフローをみてくと次のようなことを考えなければなりません。
- 開発対象コードの脆弱性
- 依存ライブラリの脆弱性
- 開発成果物の正当性
- 利用時の内容の適正確認
- 実行時の脆弱性
自身が開発したコードに対して機能面テストはもちろん、脆弱性に対する確認をしなければなりません。またSBoMも生成する必要があるでしょう。さらに依存ライブラリについても添付されているであろうSBoMなどを通じ脆弱性がないかどうかを確認しなければなりません。 これらから実行用のコンテナイメージなどを作成すると思いますが、この内容が間違いなく自ら期待した内容のものか（第３者によって書き換えられていないか）を確認するためイメージ等へのサインを付与し、書き換えられていないことを証明できるようにしなければなりません。 また、そのイメージのポリシー／ライセンスが適切なものであるかも確認しなければなりません（例えば意図しないGPLライセンスのライブラリが含まれていないかどうかなど）
細かい点はまだあるのですが、大まかに 脆弱背確認、サインニング、ポリシー、といったものを、ZeroTrustですべてをチェックする必要があります。 さて、みなさんはこれらを実行する準備ができていますか？すでに実行していますか？ 今回あえてツール等の具体例は挙げていません。ぜひどういったものを利用すべきか考えてみてください。
やっぱり大変だったSoftware Supply Chain Security
今回はおもに開発成果物に対する対策の部分でした。それでも様々なことを行わなければなりません。これをそれぞれの開発チームで行っていては大変なのは明白です。昨今注目されているPlatform Engineering / Internal Developer Platformで、その組織としてやるべきことを決定し、ツールの使い方やポリシー運用を行い開発チームの認知負荷を低減しなければならないでしょう。
DevOpsカルチャーとして開発チームがすべてを責任をもって取り組むというものがありますが、やはりすべてを行うのは難しいと思います。今回紹介したSoftware Supply Chain Securityもそんな大変な項目の１つです。
以前のような機能単位での組織分割に戻ることはありませんが、やはりPlatform Teamとして役割を（再）定義することで、DevOpsのカルチャーを活かしつつ効率をあげていく必要があることを再認識しました。
あらためて、Platform Engineeringについて考えさせられるきっかけにもなりました。
今回いくつかのセッションで実際の内容を見聞きしているのでどこかのタイミングで実際に開発ライフサイクルに取り入れたいと考えています。機会がありましたらそうした内容も投稿していきたいと思いますのでご期待ください。
