Introduction Supply Chain Security

Recent trends in supply chain security.

Transcript

1. はじめに 僕が興味の赴くままに勉強したことを共有します。 今日のお話 Supply Chain Security のお話 なぜ Supply Chain Security を考えるのか? 世の中ではどのように議論されているのか? 大きな課題に対する取り組み方も勉強になる 今日のゴール 雰囲気を持ち帰って欲しい（僕も雰囲気しか理解できてないから） 1
2. なぜ Supply Chain Security が必要なのか すでに脅威として世の中で騒がれている IPAが出している 情報セキュリティの10大脅威 にもランクインしている 2
3. Sonatype からも攻撃が増加しているとのレポートが出ている 3
4. Supply Chain Security とは ソフトウェアの供給プロセス全体で整合性を保護し、各プロセスへの攻撃からプロダクトを 守ること → サプライチェーン攻撃から守ること 4
5. サプライチェーン攻撃とは 大きく分けて2種類の攻撃が存在 取引先や関連会社、グループ会社を経由した攻撃 ターゲット企業とやり取りがある比較的セキュリティレベルが低い取引先や関連会社、 グループ会社を経由し、攻撃を行う方法。 ソフトウェアが依存しているモジュールなどを標的とした攻撃 広く利用されるソフトウェアや、ターゲット企業が利用するであろうソフトウェアやソ フトウェアの更新プログラムに攻撃を行う方法。 今日は ソフトウェアが依存しているモジュールなどを標的とした攻撃 への対策としてのサプ ライチェーンセキュリティの話 5
6. 具体的にどのような攻撃が行われているのか Node.jsの event-streamライブラリにマイニングスクリプトを埋め込まれた事件 https://arstechnica.com/information-technology/2018/11/hacker-backdoors-widely- used-open-source-software-to-steal-bitcoin/ SolarWinds事件 ネットワーク監視機器にマルウェアを混入 https://orangematter.solarwinds.com/2021/01/11/new-findings-from-our- investigation-of-sunburst/ Codecov CI/CD上で動作するツール上経由でGitHubのクレデンシャルなどが漏洩 https://blog.gitguardian.com/codecov-supply-chain-breach/ そのほかの事例についてはCNCFが纏めてたりする https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises 6
7. これらの脅威に対しての取り組みについて 様々な団体がこれらの問題に対して取り組んでいる. OpenSourceSecurity Foundation(OSSF) が主導して取り組んでいる LinuxFoundation 配下の WG OpenSourceSecurity Foundation の GitHub 業界関係者と政府関係者を集めて今後の計画を発表している CNCFでもTAG-SecurityというWGが立ってる https://github.com/cncf/tag-security 7
8. OSSF について OSSF が目指す世界 OSSの開発者 サプライチェーンの各プロセスにおいて、ソフトウェアの作成者、作成、コンポーネント、 健全性、セキュリティ、ライセンス、アイデンティティ、その他の側面に関する暗号的に検 証可能な情報をシームレスに収集し公開できるようにする。 OSSの利用者 この情報をシームレスに比較し、セキュリティとコンプライアンスの必要性に応じて、ソフ トウェアの受け入れ、拒否、軽減のポリシーを適用できる状態にする。 8
9. OSSF の進め方 (少し脱線) アプローチ 1. スコープの合意 2. サプライチェーンにおける脅威モデルを定義する 3. いくつかのコミュニティと協力して、脅威の対策を検討する 4. これらの解決策を一般化する ※ 合意したスコープを探したけど見つからなかった... 9
10. 本題 10
11. 現在取り組まれていること 脅威モデル の作成と検討 SLSA の制定 サプライチェーンを保護するためのガイドライン Digital Identity Attestation の検討 OSS開発者とOSS利用者が、作成、使用するコードの出所を理解し、決定できるように することを目的 SLSA を元に脅威モデルやDigital Identity Attestationについて触れていく 11
12. ここからの話 脅威モデルについて SLSA について Digital Identity Attestation について 12
13. 脅威モデルについて SLSA について Digital Identity Attestation について 13
14. 脅威モデルについて 読んでください https://docs.google.com/document/d/1xVQowaPQ_x_yaMu2GY59iP74I54lbizmUuDFIrax 3OQ/edit# 14
15. 脅威モデルについて SLSA について Digital Identity Attestation について 15
16. SLSA について SLSAは（Supply-chain Levels for Software Artifacts）の略でサプライチェーンの保護レベ ルを定義するセキュリティフレームワーク。 具体的には、4つのレベルとそれらの Requirements を定義している。 現在は SLSA Level 2 までを対応するために必要なツールを提供している。 16
17. SLSA におけるソフトウェアサプライチェーンの定義 Source GitHubにcommitされたソースコード Build Travis CIやJenkinsなどのCI/CD もしくは ローカル環境かもしれない Package Buildプロセスの出力 （例: docker image, zip, jar, なんでも） Dependencies Buildプロセスへの入力だが、ソースではないアーティファクト。 17
18. ソフトウェアサプライチェーンにおける脅威の定義 具体的な脅威については以下に記載されている。 https://slsa.dev/spec/v0.1/threats 18
19. SLSA Level と Requirements SLSA は Build, Source, Deps の3つの環境へのセキュリティ対策の達成度ごとにレベルを定 義している。 Levelごとに Requirements を定めている。 https://slsa.dev/spec/v0.1/requirements 19
20. セキュリティレベルについて (1) SLSA 1. Documentation of the build process ビルドプロセスの Provenance（来歴）を作成すること。 ビルドプロセスが自動化され、Provenanceを生成する必要がある。 Provenance は、ビルドプロセス、ソースコード、依存関係など、アーティファクトがどのよ うにビルドされたかに関するメタデータ Provenance を用いることで、ソフトウェアの利用者はリスクに基づいたセキュリティ上の決 定を下すことができる。SLSA 1は Provenance の改ざんには対応できないが、コードソース を識別し、脆弱性管理することが可能。 20
21. セキュリティレベルについて (2) SLSA 2. Tamper resistance of the build service バージョン管理と、署名された Provenance を生成すCI/CDの環境を利用する必要がある。 SLSA 2 では、Provenance により、ビルドサービスが信頼できる範囲での改ざんが防止でき る。 SLSA 3. Extra resistance to specific threats SLSA 2に対してより強固なBuild環境の提供 SLSA 4. Highest levels of confidence and trust SLSA 3に対してより強固なBuild環境の提供とソースコードの管理 https://slsa.dev/spec/v0.1/levels 21
22. セキュリティレベルについて (まとめ) 各レベルに対する要件 基本的には以下の3つに対して要件が定められている。 Build環境 ソースコードの管理 Provenance https://slsa.dev/spec/v0.1/requirements セキュリティモデルと脅威モデル 各レベルに対して対策される脅威がマッピングされている https://slsa.dev/spec/v0.1/threats 22
23. Provenance 目的 アーティファクトまたはアーティファクトのセットがどのように生成されたかを示すための もの Prerequisite Understanding of SLSA Software Attestations and the larger in-toto attestation framework. Software Attestation と in-toto attestation を知らないとダメのようなのでその話をします。 実質これが Digital Identity Attestationです。 23
24. 脅威モデルについて SLSA について Digital Identity Attestation について 24
25. Digital Identity Attestation とは OSS開発者/貢献者/利用者が、保守/開発/利用するコードが どこから どのように 供給されて いるかを理解し、利用判断できるようにすること https://github.com/ossf/wg-supply-chain-integrity/tree/main#readme Digital Identity Attestation の一種である Software Attestation を紹介する。 要約 25
26. Software Attestation 「何が(Subject)、どのように作成(Predicate)、誰が署名(Signature)」などのメタデータをモ デル化したもの。 以下のモデルを満たしていれば ソフトウェアアテステーション とみなせ る。 26
27. in-toto Attestation Software Attestation の一つの形式として in-toto attestation が推奨されている。 Software attestationを実体化した仕様 ソフトウェアアーティファクトのメタデータ向けの署名方法とデータ形式を定義 メタデータはデータ型を指定し、Provenance や SBOM などのデータ型があり、ま た独自定義も可能 署名方法は cosign が推奨されている 27
28. in-toto Attestation (例) シナリオ masahiro331 が自作の Docker Image に masahiro331 が作ったことを署名したい 方法は以下 Artifact は Docker Image Predicate(メタデータ) の型を http://my.example.com/author とする メタデータ は {"author": "masaihro331"} Subject は Docker Image の sha256 Digest 49193a2310dbad4c02382da87ac624a80a92387a4f7536235f9ba590e5bcd7b5 署名はcosignで生成した鍵を使用 28
29. Statement の作成 Subject と Predicate を用いて 「Docker Image」を「masahiro331によって作成」を表現し ている { "_type": "https://in-toto.io/Statement/v0.1", "predicateType": "http://my.example.com/author", "subject": [ { "name": "masahiro331/maven-test-project", "digest": { "sha256": "49193a2310dbad4c02382da87ac624a80a92387a4f7536235f9ba590e5bcd7b5" } } ], "predicate": { "author": "masahiro331" } } 29
30. Attestation の作成 Statement を base64 encode し、 payload に詰め込んでから 署名している。 { "payloadType": "application/vnd.in-toto+json", "payload": "eyJfdHlwZSI6Imh0dHBzOi8vaW4tdG90by5pby9TdGF0ZW1lbnQvdjAuMSIsInByZ...", "signatures": [ { "keyid": "", "sig": "MEQCIG+na8kNMK4u9j2jc2Db94aR0rglNqbHZcscHH9QqP..." } ] } 30
31. デモ 31
32. in-toto で表現できることまとめ Subject なにが (アーティファクトのDigest) Predicate なにに依存して (SBOM) どのように作られたか (Provenance) 誰が (author) その他自由 Signature 署名 (cosign) 32
33. まとめ Supply Chain Security が 流行っていてそれらに対処する仕様が作られつつある。 業界の中で先頭を走っているのは SLSA Framework かもしれない（多分） in-toto attestation format が Software Attestation の中でも有力 33