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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© NTT Communications Corporation All Rights Reserved. 4 ソフトウェアサプライチェーンのリスク https://slsa.dev/spec/v1.0/threats-overview • 攻撃可能な脆弱なコード • 保存されたソースコードが改変される • 依存関係に悪性コードが含まれる • ビルドプロセスが攻撃され、情報流出やバックドアが混⼊される • ビルドした成果物 (バイナリ・コンテナイメージなど) が改竄される多様なリスクが存在

Slide 6

Slide 6 text

© NTT Communications Corporation All Rights Reserved. 5 なぜソフトウェアサプライチェーンが重要か本番環境より攻撃しやすい • 本番環境はアクセスできるユーザの制限や、認証が強⼒になっているなど⼀定のセキュリティが担保されていることが多い • ⼀⽅で開発環境やビルド環境はセキュリティ要件が厳しくないことが多い • サプライチェーンを攻撃できれば、本番環境まで影響を及ぼせる

Slide 7

Slide 7 text

© NTT Communications Corporation All Rights Reserved. 6 なぜソフトウェアサプライチェーンが重要か依存関係の増加ソフトウェア本体やCI/CDプロセスなど、外部のソフトウェアへの依存が増加脆弱性や悪意あるコードの混⼊の影響を受けやすくなっている Codecovの事例: テストのカバレッジを計測するツールとして利⽤されているCodecovに対する攻撃 Codecovに保存された利⽤者のgitクレデンシャルが悪⽤され、コードリポジトリにアクセスされ情報流出 https://blog.gitguardian.com/codecov-supply-chain-breach/

Slide 8

Slide 8 text

© NTT Communications Corporation All Rights Reserved. 7 サプライチェーンセキュリティは解決が難しい考慮する要素が多いサプライチェーンを構成する要素が多様で脅威も複雑 (CI/CDパイプライン、リポジトリなど) 開発現場の主導が必要 CI/CDパイプラインや開発プロセスの変更が求められるため、現場の参画が必須 (セキュリティ組織が⼀括して導⼊することが難しい) z z 採⽤している⾔語・フレームワーク・ CI/CDツールによって異なる対策が必要に

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© NTT Communications Corporation All Rights Reserved. 10 フレームワークのメリットソフトウェアサプライチェーンを安全にするための要件と具体的な⼿段を定めたガイドライン基本的に想定される脅威とその対策がセットになっており「なんとなく」ではなく具体的なリスクを明確にして対策を導⼊できるソフトウェア開発のプラクティス (CI/CD、IaCなど) を前提としているため、開発速度を⼤きく損なうことなく適⽤できる (セキュリティ対策の意味でも⾃動化されたビルドを推奨している)

Slide 12

Slide 12 text

© NTT Communications Corporation All Rights Reserved. 11 フレームワークの要件の具体例 c コードリポジトリ: レビュワーが確認しない変更が紛れ込むリスクレビュー後にコードが変更されたら再度レビューを必要とする c コードリポジトリ: 開発者になりすましてコードがpushされる強固な認証 signed commitを必須にする c 依存関係: 依存しているOSSに脆弱性が混⼊する脆弱性スキャンツールを⽤いるリスク対策

Slide 13

Slide 13 text

© 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の利⽤に焦点を当てたフレームワーク

Slide 14

Slide 14 text

© NTT Communications Corporation All Rights Reserved. 13 SLSA Linux FoundationのプロジェクトであるOpen Source Security Foundation が開発するフレームワークオープンソースの開発者向けに⽐重が置かれている https://slsa.dev/ 特徴 • サプライチェーンにおいて満たすべき要件をレベル別に定義 • v1.0 では来歴 (ビルド成果物がどのように⽣成されたかの証跡) に焦点 • v0.1 ではプロセス全体に焦点を当てているためサプライチェーン全体の保護をするならv0.1を参照した⽅が有⽤

Slide 15

Slide 15 text

© 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

Slide 16

Slide 16 text

© 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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© 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

Slide 22

Slide 22 text

© NTT Communications Corporation All Rights Reserved. 21 Visual Studio Codeの設定 Visual Studio Codeの設定を利⽤し、ソースコードのリスクを低減 • trivyの拡張機能を設定し、機密情報などのスキャンを可能に { "recommendations": [ "AquaSecurityOfficial.trivy-vulnerability-scanner" ] } settings.json Source Code

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 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

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 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

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 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

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© NTT Communications Corporation All Rights Reserved. 30 ⼤変だった点導⼊は楽でも、運⽤にコストがかかる対策もある • 依存パッケージの脆弱性のチェック • 導⼊は容易で、DependabotやGitHub Actionsでのスキャンを設定するだけで設定可能 • Webフレームワークで使⽤していない機能の依存パッケージで脆弱性が検知されるなど、運⽤にコスト

Slide 32

Slide 32 text

© NTT Communications Corporation All Rights Reserved. 31 フレームワークを活⽤して良かった点効果とコストを考慮した対応ができるという安⼼感「なぜその対策を採⽤したか」を根拠込みで⼈に説明できる • 客観性を持った対策の選定 • なんとなく知っていたセキュリティのためのプラクティスをフレームワークを活⽤して補強 + 優先づけできた優先度をつけて対応できる • 様々な既知のセキュリティプラクティスを優先度をつけながら徐々に対応していくことが可能

Slide 33

Slide 33 text

© NTT Communications Corporation All Rights Reserved. 32 まとめ • ソフトウェアの開発プロセスの⾼度化と依存関係の増加を背景にソフトウェアサプライチェーンの保護が重要になっている • 開発現場へ適⽤できる、ソフトウェアサプライチェーンのセキュリティフレームワークが開発されている o SLSA o CIS Software Supply chain Security Guide o S2C2F • これらのセキュリティフレームワークを⽤いることで、開発速度を維持しながらサプライチェーンのセキュリティを向上できる