イントロダクション：なぜ今、可視化と監査が必須なのか
クラウドサービスの導入が加速する一方で、企業のITスタックは“SaaSスプロール”と複雑な依存関係を生んでいます。ソフトウェアサプライチェーン（コンポーネント、CI/CD、配布経路）への攻撃は増加しており、SBOM（Software Bill of Materials）、SLSA、署名と透明性ログ（例：Sigstore）が実務で重要になっています。SLSAはビルドやプロビナンスを段階的に評価する指標を提供し、SBOMや署名は実際の検証と監査に使われます。
この記事は二つの観点で構成されています：1) SaaS資産の発見・ガバナンス（SaaS管理プラットフォーム）と、2) ソフトウェアサプライチェーンの技術的可視化・監査（SBOM生成・スキャン、署名、SLSA準拠）。各セクションで主要ツールの長短・導入例・CI統合テンプレを示します。
1. SaaS資産（人・契約・アプリ）可視化ツールの概要と比較
目的：社内で使われているSaaSの発見、ライセンス／支出管理、アカウントのライフサイクル管理、シャドーIT検出、およびリスク評価を実現します。代表的なプラットフォームにはTorii、BetterCloud、Zylo、Zluri、G2 Trackなどがあり、Discovery（発見）・Spend（支出）・Governance（運用自動化）という3つの柱で評価されることが多いです。SaaS管理ツールはSSOログ、課金データ、ネットワークログ、ブラウザ拡張の情報などを突合して継続的に資産をマッピングします。
主要ツールの短評（選定基準別）
- Torii：ミッド〜大規模向け。自動発見とワークフロー連携が強み。SSO以外のソースも結合してリアルタイム発見が可能。
- BetterCloud：ユーザープロビジョニングやオンボーディング自動化に強い。IT運用寄りのコントロールを重視する組織に適合。
- Zylo / Zluri：大企業向けの費用分析や大量のインテグレーションで強み。財務・調達と連携して契約最適化が可能。
導入時の注意点：SaaS管理は“データソースの幅”が鍵です。SSOだけでなく経費・請求・ネットワークトラフィック・エンドポイント情報を接続できるかを評価してください。自動化ルールでオフボーディングを確実に実行できると、リスクと無駄な支出を同時に削減できます。
2. ソフトウェアサプライチェーン可視化／監査のための主要ツールとワークフロー
ここではSBOM生成・SCA（Software Composition Analysis）・署名・透明性ログ・SLSA準拠という観点でツールを整理します。
SBOM生成と脆弱性スキャン
Syft（SBOM生成）とGrype（脆弱性スキャン）はオープンソースで広く使われています。Syftはコンテナ・ファイルシステム・ディレクトリからSBOMを生成し、CycloneDX/SPDXなど標準形式で出力できます。GrypeはSyftの出力を利用し脆弱性検出を行います。これらはCIに組み込んでビルドごとにSBOMとスキャンを自動化する用途に適しています。
署名と透明性ログ（Sigstoreエコシステム）
Cosign/Fulcio/Rekorを中心とするSigstoreは、アイデンティティに基づく署名（keyless signing）と公開透明性ログを提供します。これによりアーティファクトに対する署名・証跡が取得でき、オフライン検証や証跡監査がしやすくなります。組織はビルドアーティファクトに署名してRekorへ記録することで改ざんの検出と追跡を容易にできます。
SLSA準拠とプロビナンス
SLSAはビルドトラックでレベル（L0–L3）を定義し、段階的に信頼性を高めるための要件を示します。まずはプロビナンス（誰がいつどの環境でビルドしたか）の取得をオンラampにし、次に署名・ハードニングへ進めるのが一般的です。企業はSLSAのチェックリストに基づいて段階的に強化するロードマップを作るとよいでしょう。
選定ポイント（実務）
- 標準形式の採用（CycloneDX / SPDX）とツール互換性の確認。
- CIでの自動SBOM生成→署名→レジストリ/透明性ログ登録を確保すること。
- SBOMツールの精度と整合性に注意。最新の研究ではツール間の検出一致率やフィールド精度に課題が指摘されています（導入前にサンプルで検証を）。
3. 実践テンプレ：CIに組み込むSBOM生成・署名・スキャンの簡易フロー
以下は代表的なLinuxベースCI（GitHub Actions / GitLab CI / Jenkins等）で使える簡易テンプレです。要点は「SBOM生成 → 脆弱性スキャン → アーティファクト署名 → 透明性ログへの記録（および保存）」です。
例：Syft + Grype + Cosign（簡易コマンド）
# SBOM生成
syft packages dir:./app -o cyclonedx-json > sbom.json
# 脆弱性スキャン（SBOMを流用）
grype sbom:sbom.json -o table > grype-report.txt
# ビルドアーティファクト（例：container image）に署名
cosign sign --key cosign.key registry.example.com/myimage:tag
# または keyless
cosign sign --identity-token $OIDC_TOKEN registry.example.com/myimage:tag
# 署名の検証
cosign verify registry.example.com/myimage:tag
※CosignはFulcio/Rekorと連携してキー管理や透明性ログ記録を行えます。CIではOIDCベースの短期証明書を使うkeyless署名が運用負荷低減に有効です。常時オフラインで検証する場合に備え、Rekorから必要な公開キーやタイムスタンプを保存しておく運用を推奨します。
4. 監査チェックリスト（短縮版）と採用ロードマップ
導入初期チェック（1〜2ヶ月）
- 全SaaSアプリのインベントリ作成（SaaS管理ツールで自動発見）。
- 主要ビルドパイプラインでSBOMの自動生成を有効化（Syft推奨）。
- 署名ポリシーを決定（keyless運用 or KMSベース）。
中期（3〜6ヶ月）
- SLSAレベル到達目標を定め、プロビナンスと署名の自動化を拡張。
- SBOM出力のフォーマット整備とVEX（Vulnerability Exploitability eXchange）連携を検討。
監査時の確認ポイント
- ビルドごとにSBOMと署名が生成・保存されているか。
- 透明性ログ（Rekor）や署名検証がCI外でも再現可能か。
- SaaSのアクセス権限・未使用アカウント・支出の異常が監視されているか。
また、SBOMツールの出力品質と相互運用性に関する外部研究は、実務での検証（サンプルリポジトリでの比較テスト）を推奨しています。ツールが出力するフィールドや依存関係の検出漏れは監査での齟齬要因になり得ます。
結論と推奨アクション
短期的には「SaaS管理プラットフォームで資産・契約・アカウントを一元化」し、「主要ビルドでSBOM生成と脆弱性スキャンを自動化」することが費用対効果とリスク低減の両面で有効です。中期的にはSLSAに準拠したプロビナンスと署名の自動化（Sigstore等）を導入し、外部監査で再現できる証跡を残してください。これらを段階的に進めることで、サプライチェーンリスクを実務レベルで管理可能になります。
最後に：ツール選定は“組織のデータソース（SSO・経費・ネットワーク）”と“CIの実行フロー”に合うかが最重要です。導入前に小規模なPoCを回し、SBOMの互換性や署名検証の再現性、SaaS発見のカバレッジを必ず確認してください。