今回のテーマは最近よく耳にするサプライチェーン。
後半では、Cloud Native Security Conference 2022で知ったCIS Software Supply Chain Security Guideを紹介。
サプライチェーンセキュリティの背景
サプライチェーンという用語は、一般的に何らかの製品の生産、物流、販売などの一連のフロー全体を意味します。
一方、サプライチェーンは様々なコンテキストで語られるため、具体的な定義は対象やスコープによって大きく異なります。
例えば、小麦の生産→購買、工業製品の生産→購買では、前者の生産が天候に大きく影響を受けるの対して、後者への影響は限定的と言えます。
このように対象が異なればサプライチェーンの特性やリスクも異なります。
さて、IT業界の製品やサービスを構成する要素には主に以下のようなものが挙げられます。
比重自体はアーキテクチャ(IoT、モバイルアプリ、webアプリ)や業種(SIベンダ、ソフトウェアベンダ、サービスベンダ、通信事業者)によって様々かと思いますが、大雑把にはこれらに属すると思われます。
・自社開発ハードウェア
・自社開発ソフトウェア
・OSS(オープンソースソフトウェア)
・他社調達製品(ハードウェア、ソフトウェア)
・他社クラウドサービス
ここでIT製品のサプライチェーンでは、自社製品から他社製品、それらの生産に関わるモノやヒトまで、保護対象(脅威)領域には際限がありません。
例えば、他社製品の調達と言っても、供給元におけるソフトウェアの脆弱性診断、サーバルームの監視カメラ、従業員のソーシャルエンジニアリング対策など、技術、物理、運用の観点から様々な対策が求められます。その上、調達元が複数となればアタックサーフェスは増加していきます。
このようにサプライチェーンの範囲は挙げればキリがなく、議論の際はスコープ絞りが必要になります。
Cloud Native Security Conference 2022の講演にもあるとおり、サイバーセキュリティの分野では下記のようなコンテキストで語られることが多いようです。
一つは委託先や関連会社などの「社外」対策、もう一つは社内でのソフトウェア開発やシステム開発などの「社内」対策といえます。
前者は後者よりもガバナンスを利かせにくいため、特に対策が難しいとされています。ただ、万事休すというわけでなく、NIST SP 800 171への対応といったアプローチが取られています。
NIST SP 800 171については詳しく言及しませんが、概要としては米国連邦政府や関連組織にシステムを納品する供給組織が守るべきセキュリティ基準になります。
サプライチェーンに関わる組織が遵守することで「一次受けは対策をしているが二次受け以降はガバガバという状況」を緩和できるとされています。防衛省でもこちらを採用していたはずです。
さて、「社外」対策と「社内」対策では、まずは組織内で実施できる範囲からになると思います。
初歩的なアプローチとしてはISMS(情報セキュリティマネジメントシステム)準拠のように、メジャーなガイドラインに沿って組織のセキュリティ体制を強化することになるでしょう。
ただし、ソフトウェア成果物が依存する外部ライブラリや有償製品の対策では、脆弱性対策のように手が回らないところが出てきます。
このような課題を解決するために、ソフトウェアの開発プロセスをよりセキュアにする(より安全なソフトウェアをデリバリする)「Software Supply Chain Security」という分野が提唱されています。
整理すると、まず広義の「Supply Chain Security」があり、脆弱な関連組織自体を狙う「Island Hopping Attack」や自社ソフトウェアが依存するコンポーネントを狙う「Software Supply Chain Attack」に対してそれぞれ対策アプローチがあることになります。
今回テーマのCIS Software Supply Chain Security Guideは主に後者のガイドラインになります。
CIS Software Supply Chain Security Guide
「Software Supply Chain Security」の先駆的な取り組みとしてSLSA(SLSA • Supply-chain Levels for Software Artifacts)やSoftware Supply Chain Best Practices(tag-security/CNCF_SSCP_v1.pdf at main · cncf/tag-security · GitHub)がありますが、最近CIS Software Supply Chain Security Guide(chain-bench/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf at main · aquasecurity/chain-bench · GitHub)なるものが登場したようです。
確認したところ、100 を超える推奨事項がありそれなりのボリュームです。
ただ、SLSAやCNCFのガイドラインと比較してそれほど目新しいものはないように感じました。(見たことある内容もちらほら)
下記は推奨事項の一例です。
カテゴリ | 対策例 |
---|---|
Source Code | バージョン管理プラットフォームでコードの変更を追跡する |
Source Code | コードへの変更が 2 ⼈の強力に認証されたユーザーの承認を確実に受けるようにする |
Source Code | マージ前に新しい変更の署名済みコミットを確認する |
Source Code | IP アドレスに基づいて Git アクセスが制限されていることを確認する |
Source Code | ブランチ保護ルールが管理者に適⽤されていることを確認する |
Source Code | コード内の機密データを識別して防⽌するためのスキャナーが配置されていることを確認する |
Source Code | 継続的インテグレーション (CI) パイプライン命令を保護するためにスキャナーが配置されていることを確認する |
Source Code | Infrastructure as Code (IaC) 命令を保護するためにスキャナが配置されていることを確認する |
Source Code | コードの脆弱性を検出するスキャナーが配置されていることを確認する |
Source Code | 使⽤されているパッケージのオープンソースの脆弱性に対してスキャナーが配置されていることを確認する |
Source Code | 使⽤済みパッケージのオープンソース ライセンスの問題に対してスキャナーが配置されていることを確認する |
Build Pipelines | 各パイプラインに単⼀の責任があることを確認する |
Build Pipelines | パイプライン インフラストラクチャと構成のすべての側⾯が不変であることを確認する |
Build Pipelines | ビルド環境の作成が⾃動化されていることを確認する |
Build Pipelines | ビルド環境へのアクセスを制限する |
Build Pipelines | ビルド ワーカー環境とコマンドが渡され、プルされていないことを確認する |
Build Pipelines | 各ビルド ワーカーの職務が分離されていることを確認する |
Build Pipelines | ビルド ステージの⼊力と出力がステップで明確に定義されていることを確認する |
Build Pipelines | 出力が別の安全なストレージ リポジトリに書き込まれるようにする |
Build Pipelines | すべてのリリースのすべての成果物が署名されていることを確認する |
Build Pipelines | パイプラインのすべての依存関係を検証する |
Build Pipelines | ビルド パイプラインが再現可能なアーティファクトを作成することを確認する |
Build Pipelines | パイプラインのステップでソフトウェア部品表 (SBOM) が確実に作成されるようにする |
Build Pipelines | ⽣成された SBOM にパイプライン ステップが署名することを確認する |
Dependencies | サードパーティのアーティファクトとオープンソース ライブラリが検証されていることを確認する |
Dependencies | すべてのサードパーティ サプライヤから SBOM が要求されていることを確認する |
Dependencies | オープンソース コンポーネント間の依存関係を確実に監視する |
Dependencies | コードの署名済み SBOM が提供されていることを確認する |
Dependencies | 既知の脆弱性についてパッケージが⾃動的にスキャンされるようにする |
Artifacts | すべてのアーティファクトがビルド パイプライン⾃体によって署名されていることを確認する |
Artifacts | アーティファクトが配布前に暗号化されていることを確認する |
Artifacts | 許可されたプラットフォームのみがアーティファクトの復号化機能を備えていることを確認する |
Artifacts | パッケージ レジストリのアップロード時に、すべての署名済みアーティファクトが検証されていることを確認する |
Artifacts | 既存のアーティファクトのすべてのバージョンの署名が検証されていることを確認する |
Artifacts | 成果物にその起源に関する情報が含まれていることを確認する |
Artifacts | プライベート アーティファクトを外部レジストリから取得できないようにする |
Deployment | デプロイメント構成ファイルがソース コードから分離されていることを確認する |
Deployment | デプロイメント構成の変更が確実に追跡されるようにする |
Deployment | デプロイ中の機密データを特定して防⽌するためのスキャナーが配置されていることを確認する |
Deployment | デプロイ構成へのアクセスが特定のメンバーに制限されていることを確認する |
Deployment | デプロイ構成マニフェストが検証されていることを確認する |
Deployment | デプロイが⾃動化されていることを確認する |
Deployment | デプロイ環境が再現可能であることを確認する |
自組織の開発者に責任のあるソースコードの対策としては、ソースコード管理ツールのアクセス制限や署名、脆弱性診断などが挙げられています。
サプライチェーン固有というよりは一般的な内容が多い気がします。その他は、依存ライブラリ、サードパーティ製品の対策に加えて、CI(Continuous integration)技術やIaC(Infrastructure as Code)技術まで意識された内容になっています。
ここで特に注目されるべきは、「署名」や「脆弱性診断」といったキーワードに対応するAttestations技術やSBOM技術になります。
Attestations技術
開発フロー上で成果物の改ざんが行われると開発環境にとどまらず本番環境まで侵害リスクが及びます。
そこで、ソースコードから成果物、果ては「だれがどこで何をしたかそれらを証明する」に至るまで、あらゆる箇所で証明書や暗号ハッシュを用いて、真正性を確保することが推奨されます。
極限までこれらをサポートする実装例がCNCFのin-totoになります。実装は下記で紹介されていますが、正直ここまでやるか。。というような内容です。
SBOM技術
依存ライブラリ、サードパーティ製品のような他組織で開発されたパッケージは内部構成を把握しきれないことに起因して、脆弱性を見落とすことがあります。
例として、「Apache Log4j」のように開発者が何らかのjavaパッケージをインストールした際に意識せずに取り込まれたコンポーネントに脆弱性が見つかるケースがあります。
運用中システムの脆弱性検出は、大前提として構成管理されたパッケージ名やバージョン情報を脆弱性データベースと照合して行われます。
そのため、従来は構成管理の粒度が荒く、記録されていない内部コンポーネントの脆弱性までは見落とされやすかったということになります。
そこで登場したのがSBOM(Software Bill of Materials)です。
SBOMはパッケージ単位で依存パッケージやコードスニペットを管理するため、うまく活用することで前述のようなリスクを軽減することが期待されています。
具体的な内容は触れませんが、実装例のSPDXフォーマットについてはこちらで詳しく解説されています。
chain-bench
CIS Software Supply Chain Security Guideのチェックツールであるchain-benchもあるようですが、まだ対応項目が少なそうな印象を持ちました。