gists

q

記事

本当に必要だった「台帳」 へ ― 事業の Asset-driven な再設計

世の中には管理のための様々な「台帳」があります。物理的な物品は台帳的に管理されやすい対象です。広範な情報セキュリティ領域で言えば、ISMS においても情報資産管理台帳の重要性が強調されています。何かを守る上で、そもそも守るべきものを明らかにすることは、もっとも基本的な営みです。

ことプロダクトセキュリティ領域においても、どこにどんなデータがあるのか、それを取り巻くソフトウェアはどのようなものか、を把握して管理することなく、脅威を洗い出すことはできません。脅威を意識することなしに施策は生まれません。プロダクトセキュリティも例に漏れず、まず己が有する資産・システム・関与する人を把握することからしか始められません。

我々がプロダクトカテゴリ的には CSPM と呼ばれる領域からマーケットに参入したのもこれが理由です。昨年夏に投入したプロダクト「Shisho Cloud」は、これから「そもそもうちが持っている情報資産・システムとは、これと、これである」を直ちに引く・理解することのできるプラットフォームへ仕上げていきます。その上で、把握できた（プロダクトに関わる）情報資産・システムに対するセキュリティ業務を次々にバンドルしていくことで、Asset-driven/Asset-centric な体験/価値を作り込んでいきます。

視点を変えてビジネス的な整理をするなら、この再設計は、プロダクトセキュリティ領域におけるコンパウンド・スタートアップを作る上での第一歩として位置づけて考えています。コンパウンドスタートアップのキモが「どのようなデータを中心として、複数ステークホルダー・複数種別業務をバンドルするか」だと考えると、ここは避けては通れない道でしょう。

事実 18 ヶ月で $100M ARR を達成したWizは、その GTM の中で Wiz Security Graph = 資産やシステム構成を起点として、複数のリスクアセスメント業務をリバンドするような構造でマーケットを蹂躙していきました。M&A ベースで、マルチプロダクト的にケイパビリティを拡大してきた他セキュリティプレイヤーとは一線を画する戦略です。我々が目指すものは、およそ Wiz の思想に近い部分があります。

問い

asset driven って何？

「セキュリティ考慮対象」となる資産を明示的に管理する、という理解で合ってる？

a

asset-driven（Asset-driven / Asset-centric）をこの文脈で言うと、

• 「守る／運用する／意思決定する起点を “資産（asset）” に置く」
• つまり 資産の棚卸し・関係性・状態（設定/リスク/責任者など）を中心データモデルにして、その上にセキュリティ業務を載せる という意味です。
  単に「台帳を作る」より一段踏み込んで、台帳（資産のインベントリ）がプロダクト/業務の“主語”になる感じです。

---

「セキュリティ考慮対象となる資産を明示的に管理する」という理解は合ってる？

合っています。加えて、asset-driven のニュアンスとしては次の要素まで含むことが多いです。

1) まず資産を確定する（Coverageを作る）

「何が存在するか分からないと守れない」ので、

• クラウドアカウント/サブスク
• VM / コンテナ / Kubernetes
• DB / ストレージ
• IAM（ユーザ、ロール、権限）
• SaaS、Secrets、CI/CD など
  を 発見し、正規化して一覧化します（ここが台帳）。

2) 資産を“関係グラフ”として持つ（Contextを作る）

単体の台帳ではなく、

• 「このS3はこのアプリからアクセスされる」
• 「このIAMロールがこの権限を持ち、このCIが引き受けている」
• 「このDBには個人情報があり、このネットワーク経路で到達可能」
  のように、資産同士の依存関係・到達可能性・データ流通まで含めて扱う（Wizの “Security Graph” がまさにこれ）。

3) その資産に“業務”をバンドルする（Workflowを載せる）

資産を起点に、

• リスク検知（設定不備、脆弱性、過剰権限、露出）
• 重要度付け（データ種別、外部公開、到達可能性）
• 担当割当（owner / team）
• 修正提案、チケット化、SLA管理
  みたいな複数のセキュリティ業務を同じ資産ID/同じ画面/同じ文脈で回す、というのが「driven」の部分です。

---

逆に「台帳がある」だけだと asset-driven とは言い切れないことがある

• 資産一覧はあるが、関係性や重要度が薄い
• 資産とセキュリティ検知が紐づかない（別システムでバラバラ）
• “資産→課題→担当→対応→再発防止” のループが回らない
  この場合は「インベントリ管理はしている」止まりになりがちです。

---

ひとことで

あなたの理解（「考慮対象資産を明示的に管理する」）は正しくて、さらに asset-driven は
「資産を中心に、リスク評価や対応などのセキュリティ業務全体を組み立て直す」
まで含む概念だと思うとしっくりきます。

q

たとえば SBOM はソフトウェアを asset driven 化する手段といえると思う。私は SBOM について一時期調査していた時期があり、SBOM の概念を応用できないかと思った。要するに asset ってリストだと思うので。

SBOM として重要なことは、シームレスにリストをつくれることと、machine readable なフォーマットによりプログラムで処理できるようにすること。従来、いや今も人手で時間かけてつくる思想が大きいんだけど、それじゃ人手コストかかりすぎて運用的に腰が上がらないと思ってる。SBOM が自動で生成されるように、asset driven もやりたい。

a

そういう捉え方はかなり筋が良くて、SBOM はまさに「ソフトウェアという資産のインベントリを、継続的に・機械可読に・配布可能な形で持つ」ための仕組みなので、asset-driven の“実装例”として参考にできます。

ただ、asset-driven を「リスト＝台帳」だけに閉じずに SBOM 的にやろうとすると、ポイントは (1) 自動生成 (2) 正規化されたID (3) 関係性（グラフ）(4) 継続更新 (5) 利用（下流業務に直結） の5つになります。

SBOM の学びを asset-driven に持ち込むと何が起きるか

1) 「資産の型」と「最小フィールド」を決めて、まず“生成できる”状態にする

SBOM でいう component/package に相当するものを、クラウド/プロダクト領域では例えば：

• Cloud account / subscription / project
• VPC/VNet, subnet, SG/NSG, firewall rule
• Compute（VM/Container/Pod/Function）
• Data store（DB, object storage, queue）
• Identity（user/role/service account, permission）
• SaaS（GitHub, Slack, Google Workspace…）
• App（リポジトリ、CI/CD パイプライン、deploy unit）

みたいに「資産タイプ」を切って、各タイプで最低限必要なフィールド（例：asset_id, type, provider, name, env, region, owner, tags, last_seen）を揃える。
SBOM で “まずCycloneDX/SPDXで吐ける” を作るのと同じ発想です。

2) 「資産ID」を安定させる（SBOMでいうPURL/座標問題）

asset-driven が運用に乗るかはここが肝で、資産を毎回違う名前で扱うと全部崩れます。

• クラウド資産なら provider のリソースID（ARN等）を正にしつつ、マルチクラウドやSaaSまで含めるなら 内部の正規化ID を持つ
• rename/再作成/移動があっても「同一資産として追える」戦略（first_seen, last_seen, fingerprint）を持つ
• owner/team などの“属性”は変わる前提で履歴管理

SBOM でも「同じライブラリをどう一意に表すか」が超重要なのと同型です。

3) リストから一段進めて「関係性」を第一級にする（SBOMのdependency graph）

SBOM の価値が “依存関係” で跳ねるのと同じで、asset-driven も 関係性（エッジ） が本体になりがちです。

例：

• workload -> datastore（このアプリはこのDBへ接続）
• principal -> permission -> resource（このロールはこの資産にこの権限）
• internet -> endpoint -> workload -> datastore（到達可能性チェーン）
• repo -> build -> artifact -> runtime（ソフトウェアサプライチェーン）

これがあると「何が危険か」を機械的に計算できる（優先度付けができる）ようになります。

4) “手で作る台帳”を捨て、観測と統合で自動生成する

SBOM の “ビルド時に自動生成” に相当するのは、クラウドやSaaSだと：

• API 連携（AWS/Azure/GCP, GitHub, Okta等）で定期ディスカバリ
• イベント駆動（CloudTrail等）で変更検知
• CI/CD からメタデータ注入（deploy 時に owner/env/system を付与）
• IaC（Terraform等）から期待状態を吸い上げ（あるべき資産）と実態（存在する資産）を突合

「作る」より「勝手に増える・勝手に更新される」形に寄せるのがSBOM的です。

5) 機械可読にして“下流業務”へ配る（ここが driven）

SBOMが「脆弱性照合、ポリシーチェック、調達/監査」へ流れるように、資産台帳も：

• ポリシー評価（設定不備、過剰権限、露出）
• リスクスコアリング（重要度×到達可能性×既知脅威）
• チケット起票（ownerへ自動ルーティング）
• 例外管理（期限付き承認）
• 監査証跡（いつ誰がどう直した）

まで“同じ資産ID”で繋げる。ここまで行くと「asset-driven」として強いです。

---

まとめると：SBOMを一般化したものが「AssetBOM」みたいな発想

あなたの言う「assetってリスト」という直感は合っていて、運用に乗せるには

• シームレスに生成され
• 機械可読で
• IDが安定し
• 関係性（グラフ）を持ち
• セキュリティ業務がその上に“自動で”流れる

が必要、という点まで含めると SBOM の教訓を綺麗に移植できます。

必要なら、あなたが想定している対象（クラウド資産中心？プロダクト/社内SaaSも含む？）に合わせて、「最初に定義すべき資産タイプ」と「最小スキーマ」「自動生成のデータソース（API/IaC/CI/CD）」の叩き台を一緒に作れます。

This site is open source. Improve this page.