Enterprise Strategy Group (ESG) は、アプリケーションセキュリティの現状を調査したマルチクライアント開発者セキュリティ調査レポート「社会的な規範を守る: GitOps とシフト・レフト・セキュリティ」をリリースしました。 驚くべき結論と予想される結論の両方を提供するこのレポートの重要な発見は、クラウドネイティブ・アプリケーションにおけるソフトウェア・サプライチェーンのリスクの蔓延でした。
シノプシス ソフトウェア・インテグリティ・グループ ジェネラル・マネージャー Jason Schmittも次のように共感を示しました。
「組織は、ソフトウェア・サプライチェーンのセキュリティ上の脆弱性や侵害がビジネスに及ぼす潜在的な影響のレベルを、注目を集める見出しを通じて目の当たりにしているため、プロアクティブなセキュリティ戦略の優先順位付けは、現在、基本的なビジネス上の必須事項なのです」と述べ、「オープンソースのリスクを管理することは、クラウドネイティブ・アプリケーションにおけるソフトウェア サプライチェーンのリスクを管理する上で重要な要素ですが、リスクがオープンソースのコンポーネントを超えて広がることも認識しなければなりません。 コードとしてのインフラストラクチャ、コンテナ、API、コード レポジトリなど、リスト上には数え切れないほどの項目があり、ソフトウェア・サプライチェーンのセキュリティに対する全体的なアプローチを確保するには、すべてを考慮する必要があります。」
この調査には以下の目的がありました。
この調査には、北米とカナダの 350 人の参加者が含まれ、回答者の 30% が IT チームのメンバーで、40% がサイバーセキュリティの専門家、30% が意思決定権を持つアプリケーション開発者であることがわかりました。 参加者は、金融、製造、小売/卸売、テクノロジーなど、複数の業界から集まりました。
レポートによると、組織はサプライ チェーンが単なる依存関係以上のものであることを認識しています。 開発ツール/パイプライン、レポジトリ、API、コードとしてのインフラストラクチャ (IaC)、コンテナ、クラウド構成などです。
サプライチェーンの最初の懸念事項はオープンソース・ソフトウェアかもしれませんが、クラウドネイティブ・アプリケーション開発への移行により、組織はサプライチェーンの追加ノードにもたらされるリスクを懸念しています。 実際、組織の 73% が、最近のサプライチェーン攻撃に対応して、ソフトウェア サプライチェーンのセキュリティ対策を「大幅に強化した」と報告しています。
回答者は、サプライチェーン攻撃に対応して追求している主要なセキュリティイニシアチブとして、強力な多要素認証技術の採用 (33%)、アプリケーション・セキュリティ・テスト対策への投資 (32%)、組織の攻撃対象領域のインベントリ (30%) を更新するための資産検出の改善を挙げています。
また、回答者の 45% が現在の組織で最も攻撃を受けやすい領域として API を挙げています。 42% がデータストレージのレポジトリが 最も危険にさらされていると見なしており、34%はアプリケーションのコンテナイメージが最も影響を受けやすいと指摘しています。
この調査では、オープンソース管理の欠如が SBOM の編集の脅威であると指摘しています。
この調査では、組織の 99% がオープンソース・ソフトウェアを使用しているか、今後 12 か月以内に使用する予定であることがわかりました。彼らは、これらのオープンソース・プロジェクトの保守、セキュリティ、および信頼性に関して多くの懸念を抱いており、最も多く挙げられた懸念は、アプリケーション開発においてオープンソースが活用されている規模に関するものでした。オープンソースを使用している組織の 91% は、組織のコードが最大 75% のオープン ソースで構成されているか構成されると考えています。 回答者の 54% は、オープンソース・ソフトウェアに関する懸念または課題として、「アプリケーション コードに含まれるオープンソースの割合が高いこと」を挙げました。 また、私たち自身の調査では、オープンソース・ソフトウェア (OSS) の使用の規模と関連するリスクの存在との間に相関関係があることを発見しました。
OSS の利用規模が拡大すれば、アプリケーションでの存在感も自然と高まります。 ソフトウェア・サプライチェーンのリスク管理を改善する圧力により、ソフトウェア部品表(SBOM)の編集にスポットライトが当てられています。 OSS の使用が爆発的に増加し、OSS の管理が精彩を欠く中、SBOM のコンパイルは複雑な作業になっています。ESG 調査の調査回答者の 39% が OSS の使用の課題としてマークしたものです。
Source: ESG Research Survey, Walking the Line: GitOps and Shift Left Security, August 2022
OSS のリスク管理は優先事項ですが、組織には責任の明確な線引きがなされていません。
この調査は、最近の出来事 (Log4Shell や Spring4Shell の脆弱性など) に続くオープンソースのパッチ適用に焦点を当てた結果、OSS リスク軽減活動が大幅に増加した (前述の 73%) という現実を指摘しています。 これらの緩和の取り組みは不明のままです。
多くの DevOps チームは、OSS 管理を開発者の役割の一部と見なしていますが、ほとんどの IT チームはそれをセキュリティ・チームの責任と見なしています。 これは、組織が OSS に適切にパッチを当てるのに長い間苦労してきた理由を十分に説明している可能性があります。 この調査では、IT チームはセキュリティ・チームよりも (48% 対 34%) OSS コードのソースについて懸念していることがわかりました。これは、IT が OSS 脆弱性パッチを適切に維持する役割を果たしていることを反映しています。 IT と DevOps の回答者 (49% と 40%) は、展開前の脆弱性の特定はセキュリティ・チームの責任であると考えています。
IaC は、組織がクラウドネイティブ開発の要求を満たすのに役立っていますが、セキュリティを拡張するのに苦労しているため、採用が進んでいません。
開発と展開の速度に対する要求が高まるにつれて、クラウドネイティブ・アプリケーションの構成やインフラストラクチャのプロビジョニングなどのタスクは、開発者に任せられるようになりました。 このプロセスを簡素化および拡張するために、組織と開発者は IC を活用します。 96% が既に使用しているか、今後 12 か月以内に使用する予定です。
ただし、これはセキュリティ上の懸念につながる可能性があります。 IT/Ops はセキュリティのベスト プラクティスに多少精通しているかもしれませんが、開発チームにはあまり当てはまりません。 回答者の 83% が IaC の構成ミスの増加を経験しています。 これは、アプリやデータへの不正アクセス、暗号通貨をマイニングするためのクリプトジャッキング・マルウェアの導入、業界規制への違反による罰金などの問題につながります。
Source: ESG Research Survey, Walking the Line: GitOps and Shift Left Security, August 2022.
この調査では、DevOps 回答者の過半数 (50%) が、過去 1 年間に発生した API への攻撃の成功を報告しており、クラウドサービス・アカウントの資格情報の侵害、クラウドサービスの構成ミス、内部コードの既知の問題の悪用がそれほど遅れていない (41 %、36%、および 44%)とも。
開発者の能力は向上しているものの、セキュリティの専門知識の欠如が問題。
DevOps でよく使われる用語である「シフトレフト」は、セキュリティの取り組みを開発ライフ サイクルの早い段階に、より頻繁に移行することを意味します。 これは、セキュリティの責任を開発者に押し付ける主な要因となっています。 この変化には課題がなかったわけではありません。 回答者の 68% が開発者の支援を組織の最優先事項として挙げていますが、セキュリティの回答者の 34% だけが、開発チームがセキュリティテストの責任を負うことに実際に自信を持っています。
追加のツールと責任で開発チームに過大な負担をかける、イノベーションと速度を混乱させる、セキュリティの取り組みを監視するなどの懸念は、開発者主導の AppSec の取り組みに対する最大の障害のようです。 セキュリティおよび AppDev/DevOps の回答者の過半数 (65%、60%) は、開発者がセキュリティチームとやり取りすることなくコードをテストおよび修正できるようにするポリシーを設けています。一方、IT 回答者の 63% は、組織には開発者の関与を求めるポリシーがあると述べています。
開発者がセキュリティチームのメンバーになれることの価値は、大多数の回答者が感じているようですが、従来のセキュリティチームを深く関与させ続ける必要性が大幅に弱まっているわけではないことも明らかです。
セキュアなサプライチェーンというのは、開発者の書いたコード、依存関係のあるコンポーネント、コンテナなど、多岐にわたるすべてのものが安全であるということです。サプライチェーンについてのeBook「サプライチェーンのセキュリティ対策で考えるべき6つのこと」をお読みください。また、詳しくはこちらへ。