組織間の業務上の繋がりを悪用してセキュリティ対策に弱点がある組織に攻撃を仕掛け、この企業を踏み台としてターゲット企業に不正侵入を行うことや、Webアプリケーション等が利用しているOSSライブラリに不正なコードを混入させ、標的に侵入し攻撃が行われることを「サプライチェーン攻撃」と言います。後者のサプライチェーン攻撃については、ソフトウェアサプライチェーン内のソフトウェアの依存関係において、どこか一箇所でも脆弱なところがあれば、そこから侵入され、ビジネスに大きな被害が出てしまうこともあります。
実際に、アップデート等の更新プログラム配布の際に不正なコードを混入され、マルウェア拡散に悪用されてしまったり、バックドア等が埋め込まれているOSSを利用し攻撃可能な状態になったことで組織全体に広範囲に影響が及んでしまったりしたケースも少なくありません。
本記事では、ソフトウェアサプライチェーンにおけるリスクに対する有効策として注目され、昨今利用が進んでいるSBOM（エスボム）についてご紹介します。
ソフトウェアサプライチェーンへの攻撃事例
ソフトウェアサプライチェーン攻撃にはどのようなものがあり、攻撃を受けるとどのような被害に繋がるのでしょうか？
まずは、実際にあったいくつかの攻撃事例を見ていきましょう。
1. AWS認証情報が盗まれるライブラリの改ざん
2022年5月、PyPI で公開されている「ctx」、Packagistで公開されている「PHPass」の2つのライブラリにAWS認証情報等を収集するコードが含まれていることが発覚しました。元々のパッケージ所有者のメールアドレスドメインが無効となっていたため、攻撃者は当該ドメインを取得し、元の所有者と同じメールアカウントを作成、提供元の本人性を証明したことで所有者アカウントを掌握し、パッケージの改ざんを行うことが可能となりました。最近はこのように“能動的な攻撃”ではなく、“罠を張る”タイプの攻撃も増えています。
2. Kaseya社のケース
2021年7月、米IT大手Kaseya社が提供するRMM（Remote Monitoring and Management）製品「Kaseya VSA」がゼロデイ攻撃を受けたことにより、「Kaseya VSA」の利用企業はランサムウェアによって端末を暗号化され、高額な身代金を要求される被害が発生しました。利用企業は数万社に及び、中には複数のMSP（マネージドサービスプロバイダ）企業もあったため、サービス提供されていた最大1500組織に影響が及びました。
3. 台湾政府を含む複数組織の侵害
2020年8月、台湾政府がサービス事業者に払い出していたVPNアカウントが盗用され、政府ネットワークが侵害されました。侵入者はActive Directoryの管理者権限を悪用して痕跡を削除していたため、被害や影響範囲は不明とされています。
4. SolarWinds社製品悪用による米政府機関等を含む1万8000組織での攻撃被害
2020年12月、米IT大手SolarWinds社のネットワーク監視ソフトウェア「Orion Platform」を利用していたアメリカの財務省、国務省、国家核安全保障局などの省庁やMicrosoft、Ciscoなどの大企業を含む1万8000の組織がサイバー攻撃の被害を受けました。攻撃者により「Orion Platform」のアップデートにマルウェアが埋め込まれていましたが、半年以上も攻撃が発覚しなかったため、影響範囲は非常に拡大しました。
このように、製品アップデートやパッチの更新プログラム配布を利用され、マルウェアの拡散等に利用されてしまう“アップデートハイジャック”や、提供元を保証するための“コード署名の脆弱性を悪用”して悪意のあるプログラムを配布されてしまうケース、“攻撃者が侵害したOSSの利用”により意図せず攻撃可能な状態になってしまうケースなど、さまざまな攻撃手法があります。
では、攻撃者に侵害されないためには、どのような対策を取ればよいのでしょうか？
その一つとして、SBOMの活用が効果的です。
SBOMとは？
SBOMとはSoftware Bill Of Materialsの略称で、ソフトウェア部品表を意味します。
コンポーネントやライブラリ、モジュール、ライセンスなど、ソフトウェアを構成する部品のリストです。
下左図はOSの上に、Java、Tomcat、OSS、アプリケーションが載っているJavaアプリケーションのシンプルな構成ですが、コンテナ技術を利用すると、下右図のように多種多様なアプリケーション環境を容易に構築することが可能になります。
しかし、利用されるライブラリやモジュールも増えるため、ソフトウェアサプライチェーンにおける管理は難しくなります。
万が一、特定のライブラリの、特定のバージョンに脆弱性が見つかった場合、影響を受ける環境やアプリケーションを特定するのは非常に大変です。
例えば、工業製品の場合、製品にはネジやボルト、基盤等さまざまな部品が使用されています。
そのうちのネジ1つに問題があって、そのネジを使用している製品をリコールすることになった場合、自社製品の中からそのネジが使用されている製品をすべて特定しなければなりません。一つ一つ確認するには大変な作業になりますが、全製品の全使用部品を網羅しているリストがあれば簡単に特定することができるはずです。
その考え方をソフトウェアで活用するのがSBOMです。
ソフトウェアの構成要素のリストであるSBOMはプロプライエタリソフトウェア、OSSを問わず、合わせて作成・提供し、一般公開することが推奨されています。もしいずれかの構成要素に問題があった場合は、このリストにより該当箇所を特定することができます。
アプリケーション開発者は、効率的かつスピード感を持って開発するために、多数のライブラリを使用します。そして、それらのライブラリは他のライブラリにも依存していることが多いため、各アプリケーションが依存するライブラリは何千にも及びます。
そのため、ある開発者がアプリケーション開発において、ライブラリAを使用しましたが、ライブラリAはライブラリBを読み込んでいて、ライブラリBは脆弱性のあるライブラリCを読み込んでいる…といったケースでは、開発者はライブラリCを使用している認識がないこともあります。
実際、2021年にApache Log4jの脆弱性「Log4Shell」が話題になった際も、経営者やクライアントから「当社のアプリケーションのうち、『Log4Shell』の影響を受けるものがあるか？」と質問された開発者の中には、すぐに特定できなかった方も少なくないかもしれません。
もしこの時にSBOMを導入できていたら、どうだったでしょうか？
開発者は自組織のSBOMファイルの集積ディレクトリ等に対して検索を行うだけで、これまでに開発したアプリケーションがLog4jを使用していないか確認できるため、対応が必要なアプリケーションを洗い出すことが容易だったかもしれません。
以下の画像はサンプルアプリケーションのSBOMを生成し、「log4j」というキーワード検索を行ったものとなります。OSSとしてLog4jライブラリの利用有無が即座に確認でき（log4j-over-slf4j）、かつ利用しているバージョンが「1.7.22」であることを確認できます。このサンプルアプリケーションの場合は、Log4Shell（CVE-2021-44228）の影響を受けないものであることがわかります。
※参照：https://www.slf4j.org/log4shell.html
またSBOMが有益なのはアプリケーションの提供を行うソフトウェア開発者だけではありません。アプリケーション利用者にとっても大変有益です。
SBOMの公開が行われている場合、例えば企業の情報セキュリティ部門は、自社環境におけるサードパーティ製品の管理やセキュリティソフト、VPNクライアント、チャットツールなどに含まれるソフトウェアの把握が可能となるため、影響度の高い脆弱性が報告された際に、提供元の発表を待たずに影響範囲の特定等に利用することもできます。
SBOMの作成
SBOMの作成にあたっては、企業間を跨いでSBOMを利用するすべての人への提供を前提に、なるべく詳細に記載することが推奨されています。
NTIA（米国商務省電気通信情報局）では、「データフィールド」、「自動化対応」、「慣行およびプロセス」ごとに次の事項を最小構成要素として記すよう定義しています。
| データフィールド ※青字は推奨される要素 |
サプライヤー（提供者） コンポーネント名 コンポーネントバージョン その他一意の識別子 依存関係 SBOM作成者 タイムスタンプ コンポーネントハッシュ値 ライフサイクルフェーズ（どの時点で生成されたSBOMなのか） その他の依存関係（あるライブラリに手を加え「派生」であることを示す等） ライセンス情報 |
| 自動化対応 | 組織の境界を超えた相互運用のための自動生成機械判読対応 データフォーマット形式情報（SPDX、CycloneDX、SWIDなど） |
| 慣行およびプロセス | 頻度（アップデートに合わせてSBOM を作成） 深さ（トップレベルコンポーネント、 および下位コンポーネントを再帰的に特定可能な情報） 既知の未知（依存関係に関する未知を明示） 共有方法（告知／発見、 送信／取得、 アクセス権限） アクセス管理（利用規約を明示） ミスの許容（記載漏れや誤りを許容し 継続的な改善を促進） |
フォーマットについては多く作成されていますが、各組織固有の形式で管理してしまうと、組織を跨いでの共有や活用が非常に難しくなるため、なるべく代表的なものを使用します。米国大統領令では「SPDX」、「CycloneDX」、「SWID」の3つが推奨されています。
SBOMの管理・運用について
SBOMの作成に関するガイドラインやフォーマットはおおむね整備されている一方で、SBOMの管理・運用面については、まだ統一的なガイドラインはなく組織ごとに委ねられているのが現状です。しかし、SBOMはすべての人が活用できることが望ましいため、自社独自の管理方法にはならないよう意識して管理・運用しましょう。
推奨されているSBOMの一般公開についても、利用者にとって有益であると同時に、攻撃者にとっても大変有益な情報となるため注意が必要です。公開するリスクが非常に高いため、公開するのであれば企業として万全な対策を行わなければなりません。
ユービーセキュアでは、SBOMの管理・運用について、SBOMを単体で作成～使用するのではなく、SCA（Software Composition Analysis）ツールを利用されることをオススメしています。
ソフトウェアに変更があるたびにSBOM作成が必要になりますが、リリースの度にSBOMを作成するのは大変です。しかしDevOpsパイプラインに組み込んでしまえば、ビルド時にSCAツールからSBOMを自動生成できるようになるため、楽に管理・運用することができます。
ユービーセキュアでもSBOMを自動生成できるIASTツール「Contrast」や「JFrog」を提供していますので、SBOM活用をご検討される際は、ぜひご相談ください。
