オペレーションの近代化への動きにより、ソフトウェア サプライ チェーンのセキュリティの必要性が高まります
最近、ソフトウェア サプライ チェーンのセキュリティ面が脅かされているのは驚くことではありません。 まずlog4j がニュースで取り上げられ、ソフトウェア サプライ チェーンに広く蔓延し問題となっている脆弱性を軽減するために全員が慌てて取り組みました。
さらに最近では、 Spring4Shell が私たちのレーダー上に現れました。これは、脅威に対処する必要のある企業に混乱を引き起こす、フレームワークによって導入されたもう 1 つの脆弱性です。
そのため、 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 の実践でも同じ技術的負債とセキュリティ上の課題が数多く発生するということです。
良いニュースは、DevOps やビルド プロセスとは異なり、SRE 運用は組織にとって新しい実践となるということです。 そして、新しい慣行を確立するということは、最初からセキュリティを組み込むことを含め、新しい運用方法を確立することを意味します。