给 AppSec 团队用的 code-to-cloud 图谱——告诉他们哪些发现真能打到生产数据、哪些修复可以安全自动执行。

1. 一线 SOC 平台刚刚买下上下文图谱技术，说明这层能力已经从实验性的 增强功能，跨进了迫切要上的操作基础设施。
2. 买方现在要的是一套能把代码、权限、身份和运行时行为连成一体的模型——因为只有这点上下文，才够让代理安全地调查或采取动作。
3. Jit 不再把自己停留在纯 DevSecOps 工作流产品，说明静态工作流自动化已经不够；客户要的是会随着系统变化而持续更新的动态图谱上下文。
4. 自主安全运营越往前走，内部上下文缺失的代价就越高——每一个缺口，不是卡住安全修复，就是埋下错误自动动作的风险。

催化因素。 Torq 收购 Jit 说明，自主安全运营现在必须吃到横跨代码、身份、权限和运行时行为的图谱化上下文。

产品先从 GitHub、CI、IaC、云控制面、Kubernetes、身份提供商和工单元数据里，持续构建每个面向互联网服务的图谱。入口产品把每条新的扫描器发现，直接转成 修复包：受影响的服务、负责团队、可达的权限链、客户数据暴露面、部署依赖，以及安全修复 操作手册，一次给全。AppSec 不用再转发 5 条原始告警，只需推送一条排好优先级的 Jira 或 Slack 工作流。等信任建立起来，这个平台就能变成自主修复的护栏：低风险修复自动执行，模糊案例则连同完整推理链一起升级给人。

差异化。 现有扫描器、CNAPP 和 SIEM 厂商各自掌握了画面的一部分，但很少有人能拿出一个真正可执行的 可直接执行的图谱，把服务 owner、权限可达性、运行时暴露面和修复安全性塞进同一个决策对象。这家创业公司赢的，是“发现”和“动作”之间的那一刻：团队得决定是 压掉、建票，还是自动修。因为这张图谱从一开始就为安全执行而不是泛分析而建，它最后有机会长成整条技术栈上自主安全工具的授权层。

待完成任务

flowchart LR
  Scanner[Scanner finding] --> Graph[Code to cloud context graph]
  Graph --> Fix[Fix packet with owner and safe action]
  Fix --> Outcome[Faster remediation and safer automation]

高管要点

• Torq 收购 Jit，验证了上下文图谱已经成了一层真实的控制面；但这个空间也早就被 ASPM、CNAPP 和资产图谱厂商挤满。
• 真正没被满足的切口，比泛 ASPM 更窄：把一条面向互联网的发现，直接变成带 owner、权限路径、运行时可达性和安全动作建议的 修复包。
• 第一款可信产品，赢点不在检测器有多全，而在信任和 见效速度；只有当图谱覆盖和审批逻辑经得起审计，买方才会放开自动化。

市场定义

这个市场，是给 AppSec 和平台团队用的工作流软件：把代码、云、身份和运行时上下文关联起来，优先级排序并安全修复面向互联网的软件风险。它贴着 ASPM、CNAPP 和 CTEM，但真正的切口是“发现”和“动作”之间那个决策对象。

用户与买方

主要用户，是云原生 B2B SaaS 公司里的产品安全和平台安全工程师。真正拍板预算的，多半是产品安全负责人、VP Engineering 或 CISO；他们想把修复速度提上去，又不想让自主工具不受控制地碰到生产环境。

购买触发点

• 最近的事故、审计或客户评审，暴露出一个软件或云发现的真实爆炸半径，至今还要靠多个工具手工拼好几个小时。 [61][62]
• AI 辅助开发和更快的部署节奏，把代码量和变更速度抬得比 AppSec 人头增长还快，积压分诊开始让人无法忍受。 [59][60]
• 管理层想上 agentic 或自主安全运营，但在允许自动修复前，他们需要组织专属上下文和审批护栏。 [5][64][1]

支付意愿

相邻平台品类里已经存在预算。公开定价覆盖了按开发者收费的计划（Snyk）、分层 AppSec 套餐（Endor Labs）、按资产和集成收费的模式（JupiterOne），以及按工作负载模块报价的方式（Wiz）。这说明，只要产品真能把分诊工作收拢起来、并可量化地减少修复人力或 数据泄露风险，买方就会为独立产品买单。 [16][18][31][35][62]

品类动态

增长信号 GitHub 项目总量同比增长 25%（生态代理指标）

验证信号

• Torq 收购 Jit，明确就是为了把 AI 上下文图谱接进安全运营；这说明上下文已经从 增强元数据，变成一线控制层。
• Jit 称其已在近 100 家企业客户里部署了数千个 AI 安全代理，说明建立在贴地上下文上的自主安全工作流确实有真实需求。
• 相邻厂商现在都把 exploitability 优先级和 code-to-cloud 上下文当成核心产品价值来卖，而不是可选的报表功能。
• Snyk、Endor Labs、JupiterOne 和 Wiz 的公开打包方式表明，企业预算已经存在于相邻的优先级和图谱型安全平台里。

监管与技术约束

• 自主修复决策必须带可解释控制和治理，因为 AI 风险框架已经明确要求关键工作流里的 AI 使用要可信、可管理。
• 安全软件开发的要求越来越偏向“可举证的修复实践”和采购时可共享的话语体系。
• 面向欧洲的软件供应商，在 NIS2 和 Cyber Resilience Act 下，会承受更强的风险管理、secure-by-design 和报告压力。
• 从技术上看，权限和可达性事实分散在 IAM 策略、网络路径、Kubernetes 授权和身份日志里，因此图谱准确度本身就是核心产品风险。

竞争从三个方向同时收拢：想把优先级做得更好的 开发者优先的 AppSec 平台、已经在建 exploitability 模型的 code-to-cloud CNAPP 厂商，以及能跨环境画关系图的 网络资产/CTEM 平台。新进入者必须站在宽平台之下、原始扫描器之上：不是再做一个 仪表盘，而是把单条发现变成安全、可交付修复决策的动作层。

为什么现有厂商不会默认胜出

• 云平台. GitHub、AWS、Kubernetes 和 Okta 已经把 ownership、IAM、事件和策略这些原始信号露出来了，但每个平台只看得到问题的一片，没有谁会默认产出跨域的修复决策包。
• CNAPP 与 code-to-cloud 平台. Wiz 和 Prisma Cloud 证明了“按可利用性排序优先级”这件事有市场，但它们优化的是整栈的宽暴露面管理，而不是 AppSec 在下次发版前必须派出一个安全变更的那个窄时刻。
• 开发者优先的 AppSec 扫描器. Snyk 和 Jit 证明买方要的是和业务上下文绑在一起的优先级判断，但扫描器中心的产品，仍得依赖外部的运行时、身份和 ownership 数据，才能证明一个发现到底重不重要。
• 资产图谱与 CTEM 平台. JupiterOne 证明了关系图谱和攻击路径上下文确实有价值，但修复 owner、发版约束和安全动作策略，今天仍是客户下游自己扛的工作。
• SOAR 与 AI SOC 厂商. Torq 证明执行层本身很值钱，但 AppSec 修复还需要 repo 级 owner 和发版上下文；一个 SOC-first 平台并不会天然拿下这件事。

这家公司一开始应该做成一层“爆炸半径决策层”，专门服务云原生 B2B SaaS 公司里、面向互联网服务的安全修复，而不是一上来就做宽泛的 ASPM、CNAPP，或自主 SOC 平台。第一个客户，是一家 Series B–D 的 SaaS 公司：75–300 名工程师、每周发版、用 GitHub、AWS、Kubernetes、Okta，只有一个小型产品安全团队，却仍要花几个小时证明一个发现能不能打到生产数据、到底该谁修。最直接的购买触发点，通常是最近的事故、审计、企业安全评审，或董事会推动自主安全运营，把缓慢而手工的爆炸半径分析彻底暴露出来。研究支持这是一个聚焦但可信的市场：如果公司能以六位数 ACV 拿下一小批共创客户，模型里可以对应 $700.0M 的 TAM、$156.0M 的 SAM，以及第 3 年 $2.7M 的 SOM。产品应该先把一条扫描器发现转成 可直接派给负责人的修复包，里面带上服务 owner、权限路径、运行时可达性、客户数据暴露面，以及带审批闸的修复建议；等图谱置信度被证明后，再加低风险自动化。这里的刻意取舍是：先比宽平台厂商更快地赢下单一服务组合里“发现交接到动作”的那一段，即便代价是把 SOC、合规和身份治理的扩张先往后放。最大的反证风险有两个：一是买方会觉得 Wiz、Snyk、Prisma Cloud 或 JupiterOne 已经够用；二是图谱完整度太弱，导致 30 天内还撑不起可信建议。独立预算到底能不能单独批出来、自动批准最低需要多高的图谱置信度，这两件事都还是必须尽早验证的假设。

问题

• AppSec 团队会从代码、云、身份和运行时工具里收到发现，但在把修复票派给一个靠谱 owner 之前，仍得手工重建爆炸半径。
• 每周发版节奏加上 AI 辅助开发，把变更量抬得比安全人头增长还快，结果积压分诊成了生产风险瓶颈。
• 宽泛的扫描器和暴露面平台会把风险标出来，却很难稳定产出一个 可直接执行的决策对象，明确告诉团队：下次发版前到底能安全改什么。

解决方案

• 先围绕一个面向互联网的服务组合，在 GitHub、CI、IaC、AWS、Kubernetes、Okta 和工单元数据之间，搭起一张持续刷新的 code-to-cloud 图谱。
• 把每一条新的高优先级发现，转成一个 修复包：owner、权限路径、运行时可达性、生产数据暴露面、发版依赖、置信度分数和建议动作，一次说清。
• 只有当产品已经证明图谱准确、知道怎么回滚、并且能在建议型工作流里留下可审计推理时，才对低风险修复开放带审批闸的自动化。

为什么我们会赢

• 这个切口卡的正是“发现”和“动作”之间那一刻。比起再做一个宽泛安全仪表盘，这里的买方痛点更尖、预算更急、ROI 也更好量。
• 跨 repo、云资产、身份和运行时上下文做实体对齐，技术上比在扫描器里再加一个优先级视图更难复制。
• 审批历史和修复结果会慢慢滚成一层专有策略库：哪些修复可以自动跑，哪些必须保留人工审批。

里程碑

flowchart LR
  Wedge[Internet-facing remediation wedge] --> MVP[Blast-radius graph MVP]
  MVP --> Proof[Owner-ready fix packets and trust signals]
  Proof --> Expansion[Policy-gated automation and adjacent control workflows]

创始团队

实验路线图

风险评估

必须成立的条件

• 至少一半合格买方，必须把“证明面向互联网发现的爆炸半径并分配 owner”看成一个已有预算的痛点，且预算来自现有 AppSec 或平台安全盘子。
• GitHub、AWS、Kubernetes 和 Okta 这套核心栈，必须在至少 3 个早期试点里都能在 30 天内产出有用的 修复包。
• 客户必须愿意直接在 Jira 或 Slack 里接收 可直接派给负责人的修复包，而不是大多数发现都逼着分析师重新打开多个外部工具。
• 至少有一批目标买方要明确说，Wiz、Snyk、Prisma Cloud 和 JupiterOne 还没有把最后一步修复决策工作流做够。
• 在自主修复成为重要扩张驱动力之前，低风险修复必须能被审批规则清楚定义，而且不会引发回滚事故。

待尽调问题

• 哪一种上下文来源最能最快拉高买方信任：服务 owner、运行时暴露面、IAM 权限，还是客户数据敏感度？
• 预算被打开，更常见是因为事故或审计，还是更宽的自主安全项目？
• VP Engineering 或 CISO 愿意放开低风险自动修复前，最低会要求多高的图谱置信度？
• 在真实评估里，Wiz、Snyk、Prisma Cloud 和 JupiterOne 还卡在哪一步，导致它们做不好 可直接派给负责人的修复工作流？
• 如果客户偏离标准的 GitHub、AWS、Kubernetes、Okta 栈，部署工作量会增加多少？

模型合理性

• 收入引擎. 基准情景的收入，来自 Q4Y2 做到 12 个正式客户、Q4Y3 做到 18 个，同时把单账户混合 ARR 扩到 180K。
• 必须跑通. 模型要成立，关键是试点转正式的转化率不能掉出计划区间，而且标准的 GitHub + AWS + Kubernetes + Okta 部署必须压在 30 天内。
• 模型失效条件. 如果销售周期拉长，或 ARPU 扩张偏弱，现金压力会最快冒头；因为哪怕没有严重招聘失误，Y3 现金也已经转负。
• 下一轮融资证明点. 公司拿下一轮融资的依据，应该是做到约 8–12 个正式客户、部署时间压到 21 天以下，并在标准栈上跑通一条获批的低风险自动化策略。

情景

敏感性

flowchart LR
  Leads[Founder-led outbound] --> Pilots[Paid pilots]
  Pilots --> Customers[Production customers]
  Customers --> Revenue[Subscription revenue]
  Revenue --> GrossProfit[75 percent gross profit]
  GrossProfit --> Cash[Runway and financing need]

警示项: 即便是基准情景，Y3 结束前仍然需要一轮后续融资，因为模型里的现金会降到 -$732.7K。 · 收入集中度依然很高：模型假设 Y3 只有 18 个客户，却要靠六位数合同支撑一个竞争拥挤的安全品类。 · 尽管图谱型工作负载很重，毛利率仍按商业计划的 75% 目标来算，因此只要云成本或支持成本超预期，现金跑道就会很快受压。

• 图谱不完整. 如果边缺失、owner 数据过期，产品就可能给团队制造错误信心，把真实爆炸半径说小了。 缓解措施: 先只支持一套收得很紧的标准栈；每条建议都露出置信度分数；在图谱覆盖率过线前，自动化一律要过审批闸。
• 现有厂商打包. CNAPP、SIEM 或 AppSec 厂商可能补上基础的上下文图谱视图，削弱客户为独立工具买单的意愿。 缓解措施: 把修复决策工作流和自主动作策略层吃下来——在这里，跨工具执行和可审计性比图谱可视化本身更重要。
• 集成疲劳. 如果部署前得先做几个月连接器工程，安全团队可能根本不愿意再上一个新平台。 缓解措施: 先为常见的 GitHub、AWS、Kubernetes、Okta 栈打包 30 天部署方案，先在一个面向互联网的服务组合上把 ROI 跑出来。