SRE Kaigi 2026
クラウドネイティブ基幹系のサプライチェーン防御：Renovate×GitHub×OpenChainで“運用に効く”仕組み化
Kengo TODA
Kengo_TODA
■ 発表カテゴリ
募集要項（https://srekaigi.notion.site/SRE-Kaigi-2026-CfP-25a6f7392c108187a9e6e47c346396b2） にある6つの発表カテゴリからお選びください
・Practices: SREの実践例と得られた教訓
■ 発表概要（400字程度）
近年のサプライチェーン攻撃増加を受け、クラウドネイティブな業務基幹システムの開発で実施した「攻めの依存管理と運用ガバナンス」を共有します。依存をSBOMで管理してSBOMをTrivyに食わせることで、言語問わず汎用的なワークフローを構築。RenovateのminimumReleaseAgeとGitHub Actionsのハッシュ固定で更新経路を堅牢化し、PRではdependency-review-actionで既知CVEを即時検知、リポジトリ横断ではDependabot Alertsで継続監視します。さらにSECURITY.mdで受け皿（VDP/連絡経路/優先度基準）を公開し、OpenChain（ISO/IEC 5230・18974）セルフ認証でプロセスを標準化。SRE視点で「セキュリティを信頼性へ翻訳」する実践と効果を具体的にお話しします。
■ 発表の詳細（1000字程度）
OSS依存と自動化はSREの武器である一方、更新経路・CI/CD・レジストリ・アクションを狙う攻撃で信頼性が毀損し得ます。クラウドネイティブな基幹システムを開発する株式会社ヘンリーでは、技術対策×組織プロセスを両輪に以下を整備しました。
① 依存更新の安全化（入口対策）
- RenovateにminimumReleaseAgeを設定し、公開直後のリリースを一時保留。
- GitHub Actionsはタグ禁止・コミットハッシュ固定を徹底、再利用ワークフローでもpin必須。
- ブランチ保護／必須レビュー／強制署名を運用標準化。
② PRで止める（シフトレフト）
- dependency-review-actionで差分依存のCVEやライセンス変化をPR上に即時可視化。
- SBOM生成は言語ごとに最小限（例：npmはCycloneDX、GradleはCycloneDXプラグイン、RustはCargoメタデータ等）。
- 生成したSBOMをアーティファクト化し、Trivyに入力してCVE検査（PRでfail条件を定義）。
- Dependabot Alertsでリポジトリ横断の追随・バックログ管理を実施。
③ 言語横断の“扱い”に統一軸（SBOM中心）
- 各言語は“SBOMを出すところまで”。以降はTrivyによるスキャンを共通の検査レイヤに寄せ、結果を一元集計（メトリクス化・SLO化）。
- コンテナ単位でもSBOMを併用し、ビルド後スキャン／ランタイム再検査の両輪を確保。
④ 組織プロセス（OpenChain準拠）
- SECURITY.mdで受付け窓口・優先度基準・開示方針（VDP）を公開、外部からの報告〜トリアージ〜修正までを明文化。
- OpenChain ISO/IEC 5230（ライセンス遵守）＋ISO/IEC 18974（OSSセキュリティ保証）に合致する形で、役割分担、記録保持、対応SLA、教育を制度化しセルフ認証を取得。
- これにより、属人化しがちな依存セキュリティ対応を“監査可能な運用プロセス”へ昇華。
⑤ 成果と学び
- PR段階での検知率向上／誤更新の抑止／修正TTR短縮。
- 一方でminimumReleaseAgeによる適用遅延や誤検知の運用コスト、pin更新の手間などトレードオフも顕在化。これらに対し、例外基準・エスカレーション・自動ローテーションを設けて改善。
⑥ 挑戦（Challenge SRE!）
- SREが“供給網の安全性”をSLO/SLIの設計言語に翻訳し、信頼性工学の一部として継続運用する。
- 言語やスタックが変わっても、「SBOM→共通スキャン→運用ガバナンス」で再現可能にする設計が鍵。
本セッションでは、設定例・ゲート条件・失敗談も交え、他組織が今すぐ持ち帰れる実装と運用の勘所を共有します。
■ 対象聴衆とその人たちが得られるもの
- 対象：SRE／セキュリティエンジニア／アプリ開発リード／プラットフォームエンジニア
- 得られるもの：
- Renovate×ハッシュ固定×dependency-review-action×Dependabotの実運用レシピ
- 「言語はSBOM生成まで、以降は共通処理」という拡張しやすいアーキテクチャ
- SBOMをTrivyに食わせる具体的フローとゲート条件の考え方
- SECURITY.mdとOpenChain ISO/IEC 18974で“仕組み化”する手順と落とし穴
■ なぜこのトピックについて話したいのか（モチベーション）
サプライチェーン攻撃は、可用性・保全性・変更容易性に直結する運用リスクです。SREは障害対応だけでなく、供給網の安全性を継続的に担保する設計と運用を担う段階に来ています。私たちは、GitHubのネイティブ機能とSBOM中心のアプローチ、そしてOpenChain ISO/IEC 18974の枠組みで“仕組み化”することにより、言語・スタックが変わっても再現できる方策を得ました。この知見をコミュニティと共有し、SREの境界を一歩押し広げたいと考えています。