ソフトウェアならではの対策の難しさ
ソフトウェアサプライチェーン攻撃は、ソフトウェア開発のライフサイクルに関与する全てのモノ（コード、ライブラリ、プラグイン、各種ツール等）や人（開発者、運用者等）のつながりを狙った攻撃である。モノの観点ではソフトウェアの構成の複雑さ、人の観点では関係する人の多さが対策を難しくしている。
ソフトウェアにおけるプラグインやアドオンの脆弱性は、これまでもWebブラウザやWebアプリケーションで問題となっていた。本体となるソフトウェアは正しくアップデートしていても、プラグインやアドオンに未修正の脆弱性があり、そこを攻撃されてしまうケースが多い。ソフトウェアサプライチェーン攻撃も、感覚としてこれに近いものがある。
ソフトウェア開発では、すべての機能を一から開発するわけではない。ソフトウェアを差別化する独自の機能は、もちろん一から開発するが、それ以外の一般的な機能は汎用のライブラリを使用する。そうしたライブラリは、OSS（オープンソースソフトウェア）としてGitHubやGitLabなどで無償で公開されている。これらのライブラリに意図せず、あるいは故意に脆弱性が存在することがある。
汎用のOSSライブラリを使用するリスクは、「Log4j」の脆弱性により顕在化した。Log4jはApacheが提供するオープンソースのログ出力機能で、多くの汎用ライブラリに採用されている。2021年12月に、このLog4jにリモート（遠隔）から任意のコードを実行できる脆弱性が発見された。あらかじめシステムに不正アクセスすることが条件となるが、悪用されると最悪の場合はシステムを乗っ取られる可能性があった。
Log4jは、多くのアプリケーションが採用している汎用のOSSライブラリに含まれている可能性があり、しかも階層の深いところに存在しているため、そもそも自社で使用しているソフトウェアにLog4jが採用されているかどうかを確認するだけでも負荷の高い作業となる。このことは、ソフトウェアサプライチェーン攻撃への対応の難しさを端的に表している。
ソフトウェアサプライチェーン攻撃への対策
ソフトウェアサプライチェーン攻撃に対策するには、システムが侵害されるという前提に立ち、リスクを最小限に抑えることが重要となる。一方で、アプリケーションやサービスが機能するために、重要なアクセス権と通信権限が必要になる。このため、これらをブロックできないことが多く、対策を困難にしていることも事実である。
ただし、対策はいくつか存在する。企業がソフトウェアを開発している場合には、信頼できないツールやライブラリへの依存を可能な限り最小限に抑えることが効果的な対策となる。ソフトウェア開発で使用するツールやライブラリに対し、安全性を確認した上で「自社の公式ライブラリ」などに指定する方法だ。ただし、常に構成要素のアップデートを行い、脆弱性を排除する必要がある。
また、DevSecOpsの採用も効果が高い。ソフトウェア開発の初期の段階からセキュリティの観点を盛り込む手法で、シフトレフトとも呼ばれる。これまでのDevOpsはソフトウェア開発期間を短縮し、市場の要求により早く対応できるが、セキュリティの問題が発覚した際の対応に時間がかかってしまう。開発の後期になるほどセキュリティへの対応は難しくなる。
電子証明書による管理も注目されている。コードサイニング（コード署名）とも呼ばれ、WebサーバーとWebブラウザ間におけるSSL/TLS証明書と同様のもので、コードが改ざんされていないことをコードの持ち主とともに証明する仕組みだ。これにより、不正な改ざんを防ぐことができる。
最近では、SBOM（Software Bill of Materials：ソフトウェア部品表）も広がりつつある。SBOMは、ソフトウェアを構成するコンポーネントや相互の依存関係、ライセンスデータなどをリスト化した一覧表のことを指す。特に、OSSのライセンス管理や脆弱性の管理、ソフトウェアサプライチェーンのリスク管理等の用途で期待されている。
NDR（ネットワークの検知と対応）も、ソフトウェアサプライチェーン攻撃の検知に有効である。ネットワークを監視することで、疑わしいアクティビティを検知する。アプリケーションは境界防御を通り抜ける可能性はあるが、例えばC2（コマンド＆コントロール）サーバーとの通信といったコア アクティビティは常に目立つ。
強力なNDRツールを使用することで、行動分析やパケットレベルのフォレンジック、および復号などの高度なテクノロジを使用して、これらのパターンを簡単に検出できる。
