この記事は NTTコミュニケーションズ Advent Calendar 2023 の14日目の記事です。
こんにちは、イノベーションセンター所属の志村です。 Metemcyberプロジェクトで脅威インテリジェンスに関する内製開発や、Network Analytics for Security (以下、NA4Sec)プロジェクトで攻撃インフラの解明・撲滅に関する技術開発を担当しています。
ソフトウェア開発プロセスにおけるセキュリティに関心が高まりつつあり、サプライチェーンセキュリティという言葉も広く使われるようになってきました。 またMetemcyberプロジェクトではSBOMに関する取り組みを行っていますが、SBOMもサプライチェーンセキュリティの分野での活用が期待されている概念となります。 そこで本記事ではサプライチェーンセキュリティとはそもそも何か、具体的にどのような対策が存在するのかについて紹介し、サプライチェーンセキュリティへの取り組み方について考察します。
目次
- 目次
- 本記事で扱う「サプライチェーン」について
- なぜサプライチェーンセキュリティが重要なのか
- サプライチェーンセキュリティのフレームワーク
- サプライチェーンセキュリティの具体的な対策
- サプライチェーンセキュリティの導入の難しさ
- 最後に
- 宣伝
本記事で扱う「サプライチェーン」について
「サプライチェーンセキュリティ」は、「サプライチェーン」に対する攻撃への対策を意味します。 ではサプライチェーンに対する攻撃とはどのようなものなのかと言いますと、現時点では複数の意味で使われているようです1。
- 標的とする組織の取引先の企業などに攻撃し、そこを踏み台として標的に侵入する攻撃手法
- ここでのサプライチェーンは「下請け・取引先を含めた企業などのつながり」を意味する
- Island Hopping 攻撃とも呼ばれる
- ソフトウェア開発の一連のプロセス (開発者・ソースコードリポジトリ、ビルド環境、デプロイ環境など) に対する攻撃
- ソフトウェアの開発から提供までの一連のプロセス (CICDパイプライン) をサプライチェーンと呼んでいる
本記事では2番の意味のサプライチェーン、すなわちソフトウェア開発のプロセスをどのように保護するか、という観点を取り扱います。
ソフトウェア開発のプロセスに関与する要素としては以下のようなものが挙げられます。
- 開発者
- ソースコード、およびソースコードを管理するSCM (gitなど)
- ソフトウェアのビルド・テストに用いる環境・ソフトウェア
- 外部の依存コンポーネント
- ビルド成果物
上記のようなソフトウェアを開発に関与する要素への攻撃がサプライチェーン攻撃であり、それに対する防御手法がサプライチェーンセキュリティといえます。
なぜサプライチェーンセキュリティが重要なのか
近年、ソフトウェア開発プロセスの高度化に伴い、開発プロセスを構成する要素が増加しています。 つまり攻撃を受けやすい状態に変化してきていることから、その結果としてサプライチェーンセキュリティへの関心が高まっています。 以降でこのことについて詳しく説明します。
近年のソフトウェア開発では、OSSをはじめとする外部ソフトウェアをコンポーネントとして組み合わせる開発方式が一般的となりました。 またソフトウェアのテスト・ビルド・デプロイにおいても、GitHub Actionsなどのサービスインフラを利用して自動化したプロセスを構築し、その上でサードパーティーのツール (テストカバレッジの可視化など)を利用することが増えています。 このような技術によって、ソフトウェア開発の高速化・高機能化が進んできました。
一方で利用・依存するプラットフォームやソフトウェアが増えるということは、攻撃可能な対象が増えることを意味します。 そのうち1つでも侵害できれば、ソースコードやクレデンシャルを取得したり、ソフトウェアに悪意ある挙動を挿入できる可能性があるのです。
代表的な攻撃事例として、2020年に発生したSolarWinds社に対する攻撃があります。 SolarWinds社は自社のビルドプラットフォームを侵害されたことにより、製品にバックドアを仕込まれてしまいました。 これによりSolarWinds社の製品を利用していた組織がバックドア経由で侵入される被害を受けました。 また2021年には、著名なコードカバレッジ測定ツールCodecovのbashスクリプトが改竄された結果、Codecov利用者のソースコードなどの情報が流出するという事件も発覚しています。
このように、開発プロセスに対する攻撃が成功してしまうと、システムへの侵入や情報漏えいといった重大な問題が発生するというリスクがあります。 サプライチェーンセキュリティの実践により、ソフトウェア開発プロセスの各要素に対する攻撃を防いだり、攻撃を受けても被害範囲を限定するといったことが可能になるので、ソフトウェア開発のリスクを低減できます。 上記のような理由のため、サプライチェーンセキュリティが重要であるとして関心度が高まっています。
サプライチェーンセキュリティのフレームワーク
サプライチェーンセキュリティのために、どのような対策を採用すれば良いでしょうか。 サプライチェーンセキュリティをどのように実現すべきかという方法論をまとめたフレームワークがいくつか存在しています。
- SLSA
- OSS開発者に向けたフレームワーク
- S2C2F
- OSSを安全に利用することを目的としたフレームワーク
- CIS Software Supply Chain Security Guide
- 企業内部での開発に焦点を当てたガイド
各フレームワークの概要について簡単に紹介します。
SLSA
SLSA(Supply-chain Levels for Software Artifacts) はLinux FoundationのプロジェクトであるOpenSSFが開発・公開しているフレームワークです。 SLSAはオープンソースをどのようにセキュアに開発・提供するかという内容が中心となっています。 SLSAは2023年12月現在バージョン1.0 がリリースされています。
SLSAでは、サプライチェーンの要素を以下のように定義しています。
- 開発者
- コードリポジトリ (GitHub, GitLabなど)
- ビルドプロセス
- Dependencies (外部の依存コンポーネント)
- 成果物のパッケージ
- ソフトウェアの消費者
サプライチェーンの各要素と、要素間をつなぐ経路の間に攻撃が存在します。
( 出典: https://slsa.dev/spec/v1.0/threats-overview )
SLSAはサプライチェーンにおいて満たすべき要件をレベルごとに定義しています。 SLSAのバージョン0.1 の段階ではソースコードの安全性などの幅広い分野の要件を定めていましたが、2023年4月のバージョン1.0のリリースにおいてはソフトウェアのビルド環境や来歴 (ビルド成果物がどのように生成されたかの証跡) の作成に焦点を当てたフレームワークとなっています。 そのためサプライチェーン全体の保護の参考にしたい場合、バージョン0.1を参考にした方が良いかもしれません。
S2C2F
S2C2F(Secure Supply Chain Consumption Framework) はSLSAと対照的に、開発者がOSSを安全に使う方法を取り扱ったフレームワークです。
SLSAと同様に、セキュリティレベルごとに満たすべき要件を定めており、Level1 ではパッケージマネージャーを利用することや、既知の脆弱性をスキャンして発見することなどが含まれています。
CIS Software Supply Chain Security Guide
CIS Controls などで知られる、インターネットセキュリティ標準化を目的とした団体であるCISが、Trivyなどで知られるAqua Security と共同で作成したガイドラインです。 公式サイトからPDFをダウンロードできます。
CIS Software Supply Chain Guideで想定しているソフトウェア開発サイクルはSLSAとほぼ同一です。 このガイドラインにはサプライチェーンを保護する100以上の推奨事項が含まれていて、以下のカテゴリに分類されています。
- Source Code
- Build Pipelines
- Dependencies
- Artifacts
- Deployments
CIS Software Supply Chain Guideでは、プラットフォームなどの詳細には踏み込まずに、一般的なガイドラインとして作成されています。 その手法をプラットフォームの詳細を踏まえて具体的な内容に落とし込んだ個別のガイダンス (CIS GitHub Benchmark など) が別途存在しています。
サプライチェーンセキュリティの具体的な対策
各フレームワークでは共通している対策が多くあります。いくつか代表的なものをピックアップして紹介いたします。
依存関係に関する対策
OSSなどの外部コンポーネントへの依存を適切に管理し、脆弱性を早期に発見・対処することが重要になります。 主な対策としては以下のようなものがあります。
- ソフトウェアに組み込む依存関係は、パッケージマネージャーなどを利用して明示的に依存する
- ソースコードをコピーするなど、暗黙的な依存を発生させない
- 利用するバージョンを固定することで、意図しないバージョンへの依存が発生することを防ぐ
- バージョンを固定しないとビルドした時期によって依存バージョンが変わり、脆弱性の判断などが困難になる
- SBOMなどを利用して依存関係の把握と脆弱性の追跡する
SBOMは含まれるソフトウェア部品の一覧を可視化したリストで、脆弱性対応やライセンス管理などの文脈での活用が進められています。 パッケージマネージャーなどを利用して明示的に依存関係を管理することは、SBOMの作成という観点においても重要なプラクティスとなります。 SBOMに関しては昨年のアドベントカレンダーの記事 もご覧いただければと思います。
ビルドプロセスに関する対策
ビルドプロセスへの攻撃は、ソフトウェアに意図しない挙動を挿入されたり、認証情報を盗まれるなどの被害を招きます。 具体的な対策は以下のようなものがあります。
- ビルドは自動化されたスクリプトで行う
- ビルド環境が複数回利用されないようにする
- 使い捨てのコンテナやVMを活用してビルドする
- テスト・デプロイなどの工程ごとにCICDプロセスを分け、各フェーズでは最小権限の認証情報を付与する
- 他のフェーズに攻撃の及ぶことを防ぐ
- 侵害された場合の認証情報の流出を最小限にする
- 依存するソフトウェアの信頼性を確認する
- GitHub Actionsの場合、そのソフトウェアの信頼性を確認する (よく似た名前の偽パッケージでないか、利用者数など)。可能であればActionのコミットハッシュを指定し、固定されたバージョンが利用されるようにする (参考)
ビルド成果物に関する対策
生成したソフトウェアやDockerイメージなどのビルド成果物はパッケージレジストリに保存され、そこから環境にデプロイされることが一般的です。 保存されたビルド成果物を改ざんなどの脅威から守ることが重要となります。
- パッケージレジストリにアクセスできるユーザを制限し、多要素認証などを導入する
- ビルド成果物に対して署名し、改ざんを検知できるようにする
サプライチェーンセキュリティの導入の難しさ
ここまで各フレームワークの概要と、共通する要素について紹介してきました。 具体的に導入すべき対策については、各フレームワークが規定している内容を参考にできます。 一方でサプライチェーンセキュリティの対策を組織に導入する際には、セキュリティとソフトウェア開発それぞれの立場から実施すべき内容があるため、通常のセキュリティ対策とは異なるアプローチが必要になります。 サプライチェーンセキュリティにどのように取り組むべきか、という観点についてセキュリティ担当者と開発者のそれぞれ立場について考察してみます。
セキュリティ担当の立場から
大前提として、サプライチェーンセキュリティの手法はソフトウェア開発の手法の上に成り立っています。 そのためサプライチェーンセキュリティの推進はセキュリティの知識だけでは完結せず、ソフトウェア開発の知識も必要となります。 組織のソフトウェア開発のプロセスを理解したうえで、フレームワークで推奨されているセキュリティ対策をどのように既存のプロセスに組み込むかを決定したり、必要に応じて開発プロセス自体の見直しを進めていくことになるでしょう。
またサプライチェーンセキュリティの対策は、依存ソフトウェアの選定やCICDプロセスの構築など、現場のソフトウェア開発者が意思決定の主体となるものが数多くあります。 そのため、現場のソフトウェア開発者に向けて、ソフトウェア観点でのセキュリティ知識向上のトレーニング実施なども重要です。
開発者の立場から
サプライチェーンセキュリティの実現には開発者の貢献が必要です。 ただサプライチェーンセキュリティを構成する要素は広範囲に及ぶため、全ての要素に対する脅威とその対策を把握するのは困難でしょう。 セキュリティ専門家のサポートを受けることが望ましいですが、開発の初期段階から十分な支援を受けることが難しい場合も多いでしょう。
そのため開発の初期段階で意思決定され、後の変更が難しい要素については開発者自身が一定の知識を有することが望ましいと考えられます。 例えば使用する言語・フレームワークなどは開発の初期段階で意思決定が行われ、変更するには多大なコストがかかります。 これらはセキュリティも念頭においた意思決定をしておくと将来的のリスクを軽減できます。
- 言語の選定
- 可能であればパッケージマネージャーが利用可能で、依存関係を明示できる言語を選定する
- 依存ソフトウェアの選定
- 開発コミュニティは機能しているか、定期的な更新や脆弱性の修正がされているか
また依存しているサービスやプラットフォームがセキュリティのガイドラインを発行していることも多いです。 このようなガイドラインを参考にして設定することも重要になります。
- GitHub Securing your software supply chain
- GitLab Secure your application
最後に
サプライチェーンセキュリティの概要やフレームワークを紹介し、サプライチェーンセキュリティへの取り組み方について考察しました。 サプライチェーンセキュリティはソフトウェア開発のプラクティスと相互に影響して成立するため、ソフトウェア開発の進化に伴い対策の内容も変化していくことが予想されます。 最新の動向は各種フレームワークなどを参考にしていただければと思います。
宣伝
最後に宣伝ですが、Metemcyberでは今回紹介したSBOMに関する取り組みや、NA4Secと連携した情報配信を行なっております。興味ある方は公式アカウント(@Metemcyber)をフォローしていただけると幸いです。
またMetemcyber/ NA4Sec プロジェクトでは一緒に働く仲間を募集しています。 興味を持たれた方はぜひ応募してみてください。
