プロダクト開発における ソフトウェアサプライチェーンセキュリティ: 実践的フレームワークとその活用 / Software Supply Chain Security in Product Development: Practical Framework and their applications

2024年3月29日に開催された 「NIKKEI Tech Talk コミュニティが生み出すプロダクトセキュリティ資料の活用術」の講演資料です。 講演詳細についてはこちらをご覧ください https://nikkei.connpass.com/event/311714/

Transcript

1. © NTT Communications Corporation All Rights Reserved. プロダクト開発における ソフトウェアサプライチェーンセキュリティ︓ 実践的フレームワークとその活⽤ 2024年03⽉28⽇ NTTコミュニケーションズ株式会社 イノベーションセンター 志村正樹
2. © NTT Communications Corporation All Rights Reserved. 1 ⾃⼰紹介 NTTコミュニケーションズ イノベーションセンターテクノロジー部⾨ 志村 正樹 ( @mshim03 ) 業務内容 : • 脅威インテリジェンスの分析・活⽤業務 • SBOM関連のソフトウェア開発 • 社内の技術検証NWのセキュリティ運⽤
3. © NTT Communications Corporation All Rights Reserved. 2 本⽇のテーマ ソフトウェア開発における サプライチェーンセキュリティフレームワークとその活⽤
4. © NTT Communications Corporation All Rights Reserved. 3 ソフトウェアサプライチェーン ソフトウェアの開発から提供に⾄るまでの⼀連のプロセス・関与する要素 開発者・コード・コードリポジトリ・ビルド環境・依存関係・ビルド成果物など https://slsa.dev/spec/v1.0/threats-overview
5. © NTT Communications Corporation All Rights Reserved. 4 ソフトウェアサプライチェーンのリスク https://slsa.dev/spec/v1.0/threats-overview • 攻撃可能な脆弱なコード • 保存されたソースコードが改変される • 依存関係に悪性コードが含まれる • ビルドプロセスが攻撃され、 情報流出やバックドアが混⼊される • ビルドした成果物 (バイナリ・コンテナ イメージなど) が改竄される 多様なリスクが存在
6. © NTT Communications Corporation All Rights Reserved. 5 なぜソフトウェアサプライチェーンが重要か 本番環境より攻撃しやすい • 本番環境はアクセスできるユーザの制限や、認証が強⼒になっているなど ⼀定のセキュリティが担保されていることが多い • ⼀⽅で開発環境やビルド環境はセキュリティ要件が厳しくないことが多い • サプライチェーンを攻撃できれば、本番環境まで影響を及ぼせる
7. © NTT Communications Corporation All Rights Reserved. 6 なぜソフトウェアサプライチェーンが重要か 依存関係の増加 ソフトウェア本体やCI/CDプロセスなど、外部のソフトウェアへの依存が増加 脆弱性や悪意あるコードの混⼊の影響を受けやすくなっている Codecovの事例: テストのカバレッジを計測するツールとして 利⽤されているCodecovに対する攻撃 Codecovに保存された利⽤者のgitクレデン シャルが悪⽤され、コードリポジトリにアク セスされ情報流出 https://blog.gitguardian.com/codecov-supply-chain-breach/
8. © NTT Communications Corporation All Rights Reserved. 7 サプライチェーンセキュリティは解決が難しい 考慮する要素が多い サプライチェーンを構成する要素が多様で 脅威も複雑 (CI/CDパイプライン、リポジトリなど) 開発現場の主導が必要 CI/CDパイプラインや開発プロセスの 変更が求められるため、現場の参画が必須 (セキュリティ組織が⼀括して導⼊することが難しい) z z 採⽤している⾔語・フレームワーク・ CI/CDツールによって異なる対策が必要に
9. © NTT Communications Corporation All Rights Reserved. 8 専⾨家のサポートが欲しいが・・ セキュリティエンジニアの⼈数は開発現場に⽐べると少ない 開発プロセスをセキュア化できるエンジニアは貴重 > プロダクト開発エンジニア セキュリティエンジニア
10. © NTT Communications Corporation All Rights Reserved. 9 フレームワークの活⽤ セキュリティフレームワークを利⽤することで サプライチェーンの堅牢化を進めることができる プロダクト開発エンジニア フレームワーク
11. © NTT Communications Corporation All Rights Reserved. 10 フレームワークのメリット ソフトウェアサプライチェーンを安全にするための要件と具体的な⼿段を 定めたガイドライン 基本的に想定される脅威とその対策がセットになっており 「なんとなく」ではなく具体的なリスクを明確にして対策を導⼊できる ソフトウェア開発のプラクティス (CI/CD、IaCなど) を前提としているため、 開発速度を⼤きく損なうことなく適⽤できる (セキュリティ対策の意味でも⾃動化されたビルドを推奨している)
12. © NTT Communications Corporation All Rights Reserved. 11 フレームワークの要件の具体例 c コードリポジトリ: レビュワーが確認しない変更が紛れ込むリスク レビュー後にコードが変更されたら 再度レビューを必要とする c コードリポジトリ: 開発者になりすましてコードがpushされる 強固な認証 signed commitを必須にする c 依存関係: 依存しているOSSに脆弱性が混⼊する 脆弱性スキャンツールを⽤いる リスク 対策
13. © NTT Communications Corporation All Rights Reserved. 12 フレームワークの例 SLSA CIS Software Supply Chain Security Guide S2C2F 元々はgoogleが主導したフレームワーク OSSのセキュリティに主眼を置いているが、⼀般的なCI/CDに適⽤できる概念も多い CISとAqua Security (Trivyで知られる企業) が共同で作成したフレームワーク 元々はMicrosoft が開発した、OSSの利⽤に焦点を当てたフレームワーク
14. © NTT Communications Corporation All Rights Reserved. 13 SLSA Linux FoundationのプロジェクトであるOpen Source Security Foundation が 開発するフレームワーク オープンソースの開発者向けに⽐重が置かれている https://slsa.dev/ 特徴 • サプライチェーンにおいて満たすべき要件をレベル別に定義 • v1.0 では来歴 (ビルド成果物がどのように⽣成されたかの証跡) に焦点 • v0.1 ではプロセス全体に焦点を当てているため サプライチェーン全体の保護をするならv0.1を参照した⽅が有⽤
15. © NTT Communications Corporation All Rights Reserved. 14 CIS Software Supply Chain Security Guide CISとAqua Securityが共同で開発したガイドライン https://www.cisecurity.org/insights/white-papers/cis-software-supply-chain-security-guide 対象とするソフトウェアサプライチェーンの全体像はSLSAとほぼ同⼀ 対策が以下のカテゴリに分類されている 1. Source Code 2. Build Pipelines 3. Dependencies 4. Artifacts 5. Deployments
16. © NTT Communications Corporation All Rights Reserved. 15 S2C2F Microsoftが開発・公開したフレームワーク SLSAとは対照的に、開発者がOSSを安全に使う⽅法を取り扱っている https://github.com/ossf/s2c2f フレームワークの３つのコンセプトと、3つのゴールが規定されている https://github.com/ossf/s2c2f/blob/main/images/Diagram-white-bkg.png
17. © NTT Communications Corporation All Rights Reserved. 16 事例共有: フレームワークの導⼊体験
18. © NTT Communications Corporation All Rights Reserved. 17 導⼊の進め⽅ CIS Software Supply Chain Security Guideをベースに対策を進める • エンタープライズを想定した内容になっていること • ソースコード・ビルドパイプラインなど、多様な領域をカバーしていること
19. © NTT Communications Corporation All Rights Reserved. 18 サプライチェーンの各ステップへの導⼊ フレームワークの推奨事項をもとに、サプライチェーンの各ステップに対策を導⼊ Source Code Build Dependency Artifact Deployment
20. © NTT Communications Corporation All Rights Reserved. 19 サプライチェーンの各ステップへの導⼊ フレームワークの推奨事項をもとに、サプライチェーンの各ステップに対策を導⼊ Source Code Build Dependency Artifact Deployment
21. © NTT Communications Corporation All Rights Reserved. 20 GitHubの設定 ソースコードを保護するためのGitHubの設定 • branch protectionルールを導⼊し、mainブランチを保護 • レビューの厳格化 • PRのapprove後にコードに変更があった場合、再度レビューを必須にする • 「マージに2⼈以上のレビューを必要とする」というルールは⾒送り 参考: GitHub Docs 「ソフトウェアサプライチェーンの保護」 https://docs.github.com/ja/code-security/supply-chain-security Source Code
22. © NTT Communications Corporation All Rights Reserved. 21 Visual Studio Codeの設定 Visual Studio Codeの設定を利⽤し、ソースコードのリスクを低減 • trivyの拡張機能を設定し、機密情報などのスキャンを可能に { "recommendations": [ "AquaSecurityOfficial.trivy-vulnerability-scanner" ] } settings.json Source Code
23. © NTT Communications Corporation All Rights Reserved. 22 サプライチェーンの各ステップへの導⼊ フレームワークの推奨事項をもとに、サプライチェーンの各ステップに対策を導⼊ Source Code Build Dependency Artifact Deployment
24. © NTT Communications Corporation All Rights Reserved. 23 GitHub Actionsの設定 CI/CD プロセスに利⽤しているGitHub Actionsの設定変更 • 各workflowは単⼀の責任を持つようにする • テストのworkflow・ビルド⽤のworkflowなどを混在させない • workflowごとに最⼩のsecretの権限を与え、流出範囲を最⼩限に • actionlint • actionlintによるworkflowファイルのチェック https://github.com/rhysd/actionlint • run: ステップにscript injectionのリスクがないかのチェックも実⾏される Build 参考: GitHub Docs 「GitHub Actionsのセキュリティ強化」 https://docs.github.com/ja/actions/security-guides/security- hardening-for-github-actions
25. © NTT Communications Corporation All Rights Reserved. 24 サプライチェーンの各ステップへの導⼊ フレームワークの推奨事項をもとに、サプライチェーンの各ステップに対策を導⼊ Source Code Build Dependency Artifact Deployment
26. © NTT Communications Corporation All Rights Reserved. 25 依存関係に関する対策 • パッケージマネージャーのロックファイルを⽤いた依存関係の固定 • ビルドタイミングによって、依存バージョンが変化しないようにする • trivyを利⽤し、Pull Request の依存パッケージの脆弱性チェック • 脆弱性を無視できる、対応できない場合は .trivyignore を利⽤して無視する脆弱性を明⽰ • 定常的な監視にはDependabotを利⽤ steps: - name: Run Trivy vulnerability scanner in fs mode uses: aquasecurity/trivy-action@master with: scan-type: "fs" trivy-config: trivy.yaml Dependency
27. © NTT Communications Corporation All Rights Reserved. 26 サプライチェーンの各ステップへの導⼊ フレームワークの推奨事項をもとに、サプライチェーンの各ステップに対策を導⼊ Source Code Build Dependency Artifact Deployment
28. © NTT Communications Corporation All Rights Reserved. 27 ビルド成果物の保護 ビルドステップで作成されたコンテナイメージなどを保護する • コンテナレジストリへのアクセス権限の最⼩化 • コンテナレジストリへのアクセスをデプロイ⽤アカウントに制限 • GitHub Actions でのビルドをキーレスで実⾏ Artifact https://cloud.google.com/blog/ja/products/id entity-security/enabling-keyless- authentication-from-github-actions
29. © NTT Communications Corporation All Rights Reserved. 28 サプライチェーンの各ステップへの導⼊ フレームワークの推奨事項をもとに、サプライチェーンの各ステップに対策を導⼊ Source Code Build Dependency Artifact Deployment
30. © NTT Communications Corporation All Rights Reserved. 29 デプロイメントの保護 デプロイメントの設定や環境を保護 • デプロイメントを実施しているソースコードとデプロイ⽤のRepository を分離 専⽤のGitHub Actionsで⾃動化されたデプロイを実⾏ • デプロイに必要な情報をGitHub Secretsで保護 Deployment
31. © NTT Communications Corporation All Rights Reserved. 30 ⼤変だった点 導⼊は楽でも、運⽤にコストがかかる対策もある • 依存パッケージの脆弱性のチェック • 導⼊は容易で、DependabotやGitHub Actionsでのスキャンを設定するだけで設定可能 • Webフレームワークで使⽤していない機能の依存パッケージで脆弱性が検知されるなど、運⽤にコスト
32. © NTT Communications Corporation All Rights Reserved. 31 フレームワークを活⽤して良かった点 効果とコストを考慮した対応ができるという安⼼感 「なぜその対策を採⽤したか」を根拠込みで⼈に説明できる • 客観性を持った対策の選定 • なんとなく知っていたセキュリティのためのプラクティスを フレームワークを活⽤して補強 + 優先づけできた 優先度をつけて対応できる • 様々な既知のセキュリティプラクティスを優先度をつけながら 徐々に対応していくことが可能
33. © NTT Communications Corporation All Rights Reserved. 32 まとめ • ソフトウェアの開発プロセスの⾼度化と依存関係の増加を背景に ソフトウェアサプライチェーンの保護が重要になっている • 開発現場へ適⽤できる、ソフトウェアサプライチェーンの セキュリティフレームワークが開発されている o SLSA o CIS Software Supply chain Security Guide o S2C2F • これらのセキュリティフレームワークを⽤いることで、 開発速度を維持しながらサプライチェーンのセキュリティを向上できる
34. © NTT Communications Corporation All Rights Reserved. 33 終わりに ⼀緒にセキュリティに取り組む仲間を募集しています https://hrmos.co/pages/nttcom0033/jobs/176854905583 8539780 ご清聴ありがとうございました︕