オペレーションのモダナイズにより、ソフトウェアサプライチェーンセキュリティの必要性が高まる
近頃、ソフトウェア サプライ チェーンのセキュリティ面が脅かされていることには何の驚きもありません。最初にlog4jの件がニュースになり、ソフトウェア サプライ チェーンで非常に広範囲にわたって蔓延し、問題となっている脆弱性を緩和するために、誰もが奔走する事態になりました。
最近では、Spring4Shellが現れ、またしてもフレームワーク導入による別の脆弱性が、脅威への対処を必要としていた企業を混乱に陥れました。
ですから、GitHubが新しい機能を導入し、その新機能がソフトウェア サプライ チェーンのセキュリティを対象としていることは喜ばしいことでした。セキュリティに関心のある技術者であれば、その役割に関係なく恐怖心を抱くはずの統計情報が示されたSonatypeによるソフトウェア サプライ チェーンの状況に関する最新レポートを読んだ後は、格別な喜びがありました。特に注目したのは次の点です。
- 現在、3,700万バージョンのOSSコンポーネントを利用できる
- 一般的なプロジェクトの29％には、既知のセキュリティ脆弱性が1つ以上ある
- オープン ソース サプライヤを狙ったサイバー攻撃が前年比で650％増加している
このレポートでは、「標準的な最新のアプリケーションには128のオープンソースとの依存関係が含まれている」と断定しているため、これらの見解は特に問題視されています。
私は計算が苦手なのですが、少しやってみましょう。
2022年版アプリケーション戦略状況には、次のような注目に値する統計情報があります。
- 最新のアプリケーション（コンテナネイティブおよびモバイル）は、エンタープライズ アプリケーション ポートフォリオの平均33％を占めている
- あらゆる業種の企業が、平均すると約200のアプリケーション ポートフォリオを維持している
200の内の33％ということは、一般的な企業は平均66の最新のアプリケーションを自社のポートフォリオに保有していることになります。Sonatypeによるオープン ソースとの依存関係の平均値によれば、標準的な企業が8448種類のオープン ソースとの依存関係を保護するという負担を担っている可能性があるということです。現在、アプリケーション同士が重複していることはほぼ確実です。コンテナネイティブのアプリケーションは、たいてい同じコンテナ オーケストレーション環境（現在ではKubernetesがCOEの王者）を共有しているため、特定の依存関係については実際に負担が減ってはいるものの、脆弱性が生じれば、これらのインスタンスをすべて更新しなければならず、負担が軽減されるわけではありません。
これ以上計算するまでもなく、今日のソフトウェア サプライチェーンの安全生を確保することは、アプリケーション ポートフォリオの規模やオープン ソースとの依存関係を考慮すると、非常に大きな仕事であることは誰もが認めるところでしょう。
GitHubの新機能は、「現在はプル要求のリッチdiffでしか表示されない脆弱性を発見してブロックする」ことで、その解決を支援します。つまり、CI/CDパイプラインに統合し、既知の脆弱性をリアルタイムでスキャンするのです。
素晴らしいですね。珍しい機能ではありませんが。DevSecOpsは、もう何年もの間、この種の「シフトレフト」のセキュリティ動向を推進しています。ほとんどのCI/CDパイプラインは、ツールに関係なく、コードに対してセキュリティ スキャンを実行できます。しかし、そのすべてに、依存関係の奥深くに隠れていたり、検出が難しいロジック エラーから生じる可能性のある既知の脆弱性をスキャンできる機能が統合されているわけではありません。
もちろん、CI/CDパイプラインにできるだけ多くのセキュリティを組み込み、後から背後に噛みついてくるかもしれない脆弱性やエラーを根絶する必要があります。しかし、私たちがこの演習を行ったのは、そのためではありません。
SRE、ソフトウェア、サプライ チェーン セキュリティ
私が既存のソフトウェア サプライ チェーンの問題を指摘する理由は、組織がSREのアプローチを用いてオペレーションをモダナイズするにつれ、状況は悪化の一途をたどっているからです。SREの実践は、根本的には自動化に依存しており、ご存知のように、ソフトウェアとスクリプトに依存していますが、その多くはオープン ソースです。
実際、DevOpsで使用されているそれらのオープン ソース ツールの多くがSREでも使用されることを知ったからといって、驚くことはありません。役割と関係をシンプルにしたいのであれば、SREは生産向けのDevOpsになります。通常、DevOpsを実践している企業は、ソフトウェアのビルドとリリースのパイプラインに焦点を当てるのに対し、SREはソフトウェアオペレーションのパイプラインに焦点を当てます。つまり、アプリケーションだけでなく、アプリケーションのセキュリティとデリバリ サービスや、プラットフォームと環境（コア、クラウド、エッジなど）も含まれるということです。SRE担当者が対象とする範囲はITスタックに及ぶため、ソフトウェア サプライ チェーンの安全生の確保に関しては、そのタスクは著しく困難なものになります。
あえて言うならば、ソフトウェア サプライ チェーンのセキュリティは、開発から構築、リリース、導入、運用に至るまで、アプリケーション ライフサイクル全体に影響を及ぼすため、すべての組織にとっての懸案事項なのです。
そしてこれは、デジタル トランスフォーメーションの取り組みを成し遂げたい組織にとっての懸案事項にもなるはずです。どこの企業でも重大な変化が起きており、その変化は、組織のまさに心臓部にあたるエンタープライズ アーキテクチャに影響を及ぼしています。
多くのエンタープライズ アーキテクチャは数十年前に確立されたもので、リソースは固定されて柔軟性がなく、データ センタがビジネスの中心であるという前提で開発されたフレームワークをベースにしていました。
そのようなことはもうありませんし、仮にそうであったとしても、ビジネスも変化しています。ビジネスはますますデジタルなものになっており、データ主導のプロセスを活用するデジタル ビジネスは、人間主導のプロセスを活用する物理的なビジネスを代表するように設計されたアーキテクチャでは適切に表現することができません。エンタープライズ アーキテクチャをモダナイズし、SREのオペレーションなど、新たな分野を取り入れる必要があります。
そして実際にそうなっています。今年の調査では、37％の組織がすでにSREのオペレーションを導入してアプリケーションと運用をモダナイズしており、さらに40％が今後12か月以内に導入する予定であることが明らかになりました。つまり、ツールとスクリプト、ソフトウェアとデータなど、組織でこの新しい役割をサポートするためのテクノロジ スタック全体です。
また、ソフトウェアや、スクリプトとスタックには、サプライ チェーンとセキュリティがつきものです。DevOpsから学んだことの中で、オペレーションをモダナイズする際に無視できないことは、SREを実践することで、同様の技術的負債とセキュリティ上の課題が発生することです。
幸いなことに、SREのオペレーションは、DevOpsプロセスや構築プロセスとは異なり、企業にとって新しい取り組みになります。そして、新しい取り組みを確立するということは、セキュリティを最初から組み込むことも含めて、新しいオペレーション方法を確立することになるのです。