今日のソフトウェアサプライチェーンセキュリティを形作る3つのトレンド

著者

2024年8月22日

0 分で読めます

ソフトウェア開発は今も組み立てラインのようなもので、開発者はウェブ上のさまざまなリソースを取り入れてアプリケーションを作成しています。サードパーティのリソースは長年にわたりソフトウェア開発に不可欠な役割を果たしてきましたが、開発チームによる外部コンポーネントの活用方法は変化しています。開発者はより幅広い種類のサードパーティリソースをプロジェクトに取り入れており、AIコーディングアシスタントのおかげで、自社開発コードに直接、以前よりはるかに速いペースで組み込めるようになっています。

ソフトウェア開発の世界でこうした変化が起きるなか、規制当局と企業の双方が、多くのソフトウェアサプライチェーンの慣行に潜むリスクを認識し、サードパーティソフトウェアに関する規制を引き続き推進しています。

こうした現状を受け、ソフトウェア開発組織には何が求められるのでしょうか。アプリケーションを開発する企業はこれまで以上に、テスト可能なソフトウェア部品表（SBOM）の作成、AI生成コードを考慮したコードセキュリティのさらなるシフトレフト、セキュアなサードパーティコンポーネントの選定を支援する実用的なツールの開発者への提供、そしてビジネスコンテキストを活用したサプライチェーンリスクの適切な優先順位付けなど、プロアクティブなセキュリティ対策に注力する必要があります。

こうしたプロアクティブな対策の具体例を掘り下げるため、サプライチェーンに関する3つの重要なトレンドと、ソフトウェア開発への影響を見ていきましょう。

SBOMをめぐる規制の拡大

SBOMは、近年の多くのコンプライアンス要件やベンダー契約に共通して盛り込まれています。セキュリティが不十分なコンポーネントや悪意のあるコンポーネント、依存関係への懸念が高まるなか、官民の組織はSBOMに関する基準を引き上げています。こうした規制の多くは、新たなサードパーティリソースがソフトウェアエコシステムに加わるたびに、SBOMを定期的に更新する重要性を強調しています。

こうした規制が今のチームに意味すること

最新のSBOMを維持できるかどうかが、今後、ビジネスの成否を左右するようになります。政府や民間企業との契約でSBOMが求められるケースが増えるにつれ、自社のビジネスについて再テスト可能なSBOMを作成し、時間の経過とともにエコシステム内で生じる新たな脅威や変化を把握できるようにする必要があります。また、SBOMは<a href="">ソフトウェアの利用</a>という観点からも重要で、利用するサービスの透明性を確保します。

AI生成コード

AIコーディングアシスタントは、今やソフトウェア開発チームにとって当たり前の存在になりつつあります。しかし、自社開発コードにAI生成コードを取り入れることは、ソフトウェアサプライチェーンのセキュリティにいくつかの影響を及ぼします。セキュリティチームは、基本的なコードセキュリティ対策（静的アプリケーションセキュリティテストなど）を強化し、AI生成コードがリポジトリに取り込まれるペースに合わせて、既存のプラクティスやツールを調整する必要があります。

AIコーディングアシスタントの普及がチームに意味すること

AIコーディングアシスタントの普及により、開発チームにはスピードと効率性への期待が高まっています。開発者は一般に、人が書いたコードよりもAI生成コードを信頼し、以前にも増して速く開発を進めようとします。そのため、時間や労力を要するセキュリティ対策に割ける余地はほとんどありません。結果として、SDLCの後工程で自社開発コードをテストしたり、コードのテストや保護のためにツールを切り替えるよう開発者に求めたりする従来型のコードセキュリティ対策では、もはや対応できません。セキュリティチームは、開発ワークフローにセキュリティツールを組み込むことで、さらにシフトレフトする方法を検討する必要があります。

進化する脅威の状況

こうした要因に加え、この数年で脅威の状況は大きく変化しており、とりわけAI関連の脅威が今日の企業に新たなリスクをもたらしています。実際、OWASP Machine Learning Security Top Tenプロジェクトでは、AIサプライチェーン攻撃がLLMに対する重大な脅威として挙げられています。機械学習プロジェクト全体を侵害することで、攻撃者は攻撃の効果を拡大し、静的ライブラリを侵害した場合よりも多くの資産にアクセスできる可能性があります。

進化する脅威の状況がチームに意味すること

チームはまず、安全性の高いサードパーティリソースを選ぶ方法を見つける必要があります。その後、既存のライブラリを定期的に確認し、侵害されていないことを確かめなければなりません。また、サードパーティの脆弱性はビジネス上の重要度に基づいて優先順位を付けることが重要です。そうすることで、まずビジネスクリティカルな資産に関わるセキュリティ上の問題の修正に注力し、その後、他の問題に取り組めます。

サプライチェーンセキュリティのトレンドへの対応

こうしたサプライチェーンのトレンドに対応し続ける鍵は、プロアクティブな取り組みです。ビジネスやセキュリティプロセスに潜むリスクを予測し、できるだけ早い段階で対処することが重要です。プロアクティブなアプローチに切り替えるため、まず次の質問を考えてみましょう。

悪意のある攻撃者がアプリケーションに侵入した場合、ビジネス、アプリケーション、ライブラリのうち、アクセスされると最も困るのはどこでしょうか。反対に、アクセスされても大きな問題にならないのはどこでしょうか。こうしたコンテキストに関する質問を通じて、最初に保護すべきビジネスクリティカルな領域と、優先順位を下げられる低リスクの領域を把握できます。リスクの全体像を詳細に把握するには、単にCVSSや到達可能性に基づいて脆弱性をトリアージするだけでは不十分です。
自社開発コードやサードパーティコンポーネントを保護する際、開発チームにどれだけのコンテキスト切り替えを求めていますか。修正作業のためにコーディング画面を離れる必要がありますか。もしそうなら、AIコーディングアシスタントの支援で開発スピードが上がっているチームに、負担をかけすぎている可能性があります。
安全でないサードパーティコンポーネントやライセンス上の問題がリポジトリに入り込むのを未然に防ぐため、どのような自動化されたガードレールを設けていますか。開発者が利用できる安全なサードパーティリソースのリストを整備することをおすすめします。たとえば、ベースイメージの推奨リストを用意したり、特定のニーズに合う高品質なパッケージを選ぶ方法を示したりできます。また、ソフトウェアのビルド、デリバリーのプロセスやパイプラインにガイドラインの適用を組み込むことも重要です。

今日のサプライチェーンセキュリティの課題をさらに深く理解し、実践的なヒントを知るには、eBook『Securing today’s software supply chains』をご覧ください。