GitHub 闸门会先隔离 AI 编写 PR 里新引入的 OSS 包，直到安全团队拿到 provenance、更安全的替代项和审批。

1. 以 $1 billion 估值完成的 $60 million Series C，说明依赖安全已经从可选工具跨进了企业预算科目。
2. AI 原生软件公司已经是可点名的参考客户，这意味着第一批滩头市场客户买的不是概念，而是已经被同行验证过的东西。
3. AI 生成代码抬高了进入代码仓的第三方包数量，团队越快，人工审批流程越容易当场失效。
4. 6 分钟就能发现恶意依赖的例子说明，现在的审查窗口已经短过常规安全交接，因此审批控制必须长在 pull-request 工作流里，而不是等 merge 之后再补。

催化因素。 这组信号说明，AI 驱动开发正在加速放大依赖风险，企业买家已经在为开发者优先的供应链工具付费，而决策窗口最短只有 6 分钟——逼着团队必须把包审批前移到 PR 本身。

产品接入 GitHub、GitLab 或 Bitbucket，持续盯住整个组织里 manifest 和 lockfile 的 diff，专门抓第一次出现的依赖新增。只要 PR 引入新包，系统就会自动拼出一份给审查者看的简报：维护者历史、发布节奏异常、混淆或 install-script 风险、公司内部使用上下文，以及公司里已经存在的一个或多个获批替代项。安全团队可以一次批准全组织复用、带理由拒绝，或者把依赖先放进临时隔离分支做更深测试。整个流程就是给小平台安全团队设计的：不用每个包都从零查起，他们只需要维护策略模板和内部可信目录，而这套目录会随着每次决策持续复利。再往后，同样的简报还能回流到 Cursor、Copilot 和内部编码 Agent，让开发者在开 PR 之前就先看到更安全的包建议。

差异化。 Socket、Snyk 这类产品强在扫描和告警；这个点子做的是工作流系统，核心不是判断一个净新增包“危险不危险”，而是决定它到底该不该进代码库。它的护城河来自持续复利的内部决策数据：每次批准都会沉淀成可复用的包目录、替代图谱和组织专属的策略记忆。AI 生成代码让包的更替频率越来越高，这些资产只会越来越值钱。做成之后，它会变成编码 Agent 和第三方代码宇宙之间的控制平面，而不只是另一个红黄绿扫描器。

待完成任务

flowchart LR
  Buyer[Platform Security Lead] --> Pain[Too many AI-generated package additions]
  Pain --> Product[Dependency Intake Gate]
  Product --> Outcome[Fewer risky packages reach main]

高管要点

• 痛点正在前移：问题不再是依赖用了之后怎么修，而是新包到底该不该进仓库。
• 现有厂商已经验证了预算和紧迫性，但大多数产品强调的仍是检测与补救，而不是可复用的审批工作流记忆。
• 如果产品能成为 PR 里的策略记忆和替代引擎，而不是又一个扫描器，这个切口就站得住。

市场定义

一类面向开发者安全工作流的软件：专门在 pull-request 阶段治理首次采用开源依赖，尤其适用于 AI 辅助开发团队。

用户与买方

核心用户是 AI 原生 SaaS 公司的平台安全团队和资深平台工程团队——安全人手少，但净新增包很多。真正拍板的是已经掌管 AppSec 和 secure SDLC 预算的 VP Engineering 与产品安全负责人。

购买触发点

• 正式铺开 AI 编码后，依赖 churn 抬升，但开发者对 AI 输出质量依旧不放心，于是包审查一下就暴露成明显控制缺口。 [112][23][45][115]
• 恶意包数量上升、实时供应链攻击变多，让安全团队越来越觉得 merge 之后再审已经太晚。 [111][77][106]
• 合规和采购项目越来越常问：有没有可审计的 OSS 控制、受认可仓库，以及全生命周期的漏洞处理机制。 [46][47][48][19]

支付意愿

买家已经接受按开发者计费的安全预算：GitHub Code Security 是每个活跃 committer 每月 $30，Snyk Team 起价是每个贡献型开发者每月 $25。所以如果一个更窄的依赖引入工作流能明确减少人工审查时间，并更早拦下高风险包，它就能拿到预算。 [22][87]

品类动态

增长信号 13.2% CAGR

验证信号

• Socket 在 2026 年的融资和客户名单说明，AI 原生软件团队已经在为供应链专用工具列预算。
• 开发者使用 AI 工具已经是主流，但信任和调试痛点仍然够大，足以支撑在依赖建议外再加一层护栏。
• GitHub 和 GitLab 已经开放了 PR 阶段的依赖工作流，因此一个窄切口闸门的技术分发风险并不高。
• npm 和 PyPI 的 provenance 体系，正让自动生成审查简报这件事越来越可行，不必再全靠人工查包。

监管与技术约束

• 一个 blocking 型引入闸门，必须和 SCM 的状态检查、受保护分支或 ruleset 模型无缝衔接，不然团队一定会绕开它。
• provenance 和 attestation 能提升可追溯性，但并不能证明一个包一定无害，所以审查者仍然需要策略和判断。
• 私有 registry、传递依赖和不同包管理器的差异，会把“第一次发现新包”这件事搞得很复杂。
• 合规指引会抬高紧迫性，但不会硬性指定某个供应商品类，因此采购节奏仍可能慢于产品痛点本身。

竞争很挤，但并不均匀。GitHub 和 GitLab 占住 merge 入口，广义 AppSec 套件占住预算线，供应链专精厂商占住恶意包与可达性叙事。这个创业方向只有把自己钉在一个窄流程上才最强：第一次包引入、替代建议，以及可复用的策略记忆。

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

• SCM 平台. GitHub 和 GitLab 本来就在 pull-request 路径上，但它们现在的依赖能力主要还是可见性、状态检查和基础策略原语，而不是深入到组织专属的包采购决策。
• 广义 AppSec 套件. Snyk 靠平台广度和整合能力取胜，这对想统一 AppSec 的买家很有吸引力；但也正因为太广，第一次包审批只是它里面一个子流程，不是核心产品。
• 供应链专精厂商. Socket 和 Endor Labs 离这个威胁叙事最近，但两家主打的还是包情报、恶意包拦截、可达性或 firewall，而不是 PR 原生的审批记忆和替代指引。
• provenance 与 attestation 工具. npm provenance 和 PyPI attestations 能增强完整性证据，但它们并不回答：某个包在一家具体工程组织里到底该不该被采用。

这家公司应该从一个 GitHub 原生的依赖引入闸门切进去，服务 AI 辅助开发团队，而不是一上来就做宽口径的软件成分分析或运行时供应链平台。首个客户应是一家 Series B-D 的 AI 原生 B2B SaaS 公司：工程师规模 150-600 人，共用 monorepo，已经正式 rollout Cursor 或 Copilot，但平台安全工程师只有 1-3 人，现在还在 Slack 或 PR 评论里人工审批陌生包。购买触发点通常是 AI 编码 rollout 后的一次安全复盘、一次和陌生包有关的险情，或者高层要求在下一次采购或合规审查前拿出可审计的 OSS 控制。研究显示，这是个聚焦且可做的市场：TAM 约 $168.0M，SAM 约 $38.4M；如果公司能按模型把约 100 个滩头客户转化到按开发者计费的支出水平，第 3 年可触达的 SOM 约为 $4.8M。产品应先从 GitHub 上的 advisory mode 做起，先覆盖 npm 和 PyPI 依赖，证明它既能缩短第一次审查新包的时间，也能把开发者往已批准替代项上引；只有做到这一步，才该往 blocking 策略、更多生态和更宽的 OSS 采购控制扩。这个取舍很刻意：公司要抢的是 PR 里的第一次包审批决策，而不是正面去和 GitHub、Snyk、Socket、Endor 拼全谱系扫描广度。最可能推翻判断的风险有两个：一是目标团队每月新增包量不够，撑不起一个独立工作流产品；二是 GitHub 和供应链专精厂商在创业公司真正积累起策略数据前，就先补上了“够用”的审批记忆。现有输入没有量化目标工程团队真实的包引入量，因此在扩招或加大投入前，pilot 设计必须先把这个痛点直接测出来。

问题

• AI 编码工具提出的陌生开源包，进入 pull request 的速度，已经快过小平台安全团队能审完的速度。
• 现有扫描器和 Slack 人工审批往往要等包已经进了仓库才开始动作，因此在第一次采用的那个关口，既没有可复用的决定，也没有可审计的审批记忆。

解决方案

• 在 GitHub pull request 里识别每一个第一次出现的 npm 与 PyPI 依赖，自动生成 provenance 与行为简报，并在 merge 之前把决策路由给正确的策略负责人。
• 建立一套内部目录，记录哪些包已批准、哪些被拒绝、哪些有更安全的替代项，让后续 PR 处理得更快，也把开发者往已知安全选项上引。

为什么我们会赢

• 这个切口比宽口径 SCA 平台更窄，却正好卡在第一次采用包的决策点上——这里最有紧迫感、买家归属最清晰，也最容易量化工作流 ROI。
• 审批历史会持续复利，长成组织专属的策略记忆和替代推荐，而现有厂商看起来还没有把这套工作流放在最核心的位置。
• 从 GitHub PR 切入，正好贴住滩头客户今天审 AI 生成代码的方式，相比单独再开一个安全控制台，组织变更成本更低。

里程碑

flowchart LR
  Wedge[GitHub first-time package intake wedge] --> MVP[GitHub npm and PyPI advisory gate]
  MVP --> Proof[Faster documented package decisions and approved catalog]
  Proof --> Expansion[Blocking policies, more ecosystems, and OSS procurement controls]

创始团队

实验路线图

风险评估

必须成立的条件

• 目标客户每月必须真的会遇到足够多的首次 npm 或 PyPI 包引入，否则撑不起一条独立审批工作流。
• advisory mode 部署必须在不引发开发者反弹的情况下，把包审查中位时间压到 1 个工作日以内。
• 至少一半 pilot 必须转正，因为可复用的包记忆和替代指引，确实比 GitHub 或现有扫描器多出独立价值。
• 围绕研究基准的受保护工程师定价模型，必须能装进现有 AppSec 或工程预算，而不需要重服务投入。
• GitHub-first 的共创客户必须提供足够多的策略数据，让公司在现有厂商补齐功能前，先攒出有防守力的替代与审批记忆。

待尽调问题

• 目标客户在 rollout AI 编码后，每月到底会处理多少次净新增 npm / PyPI 包审批？
• 有多少目标买家愿意从 advisory mode 开始，又有多少会一开始就要求对未知包立即 blocking？
• 在真实评估里，GitHub dependency review、Socket、Snyk 或 Endor Labs 还解决不了哪些包审查环节？
• 产品有多大概率能推荐一个已经获批的替代项，而不是再批准一个新的外部包？
• 误报率或审查延迟高到什么程度时，工程团队会开始绕过这条工作流？

模型合理性

• 收入引擎. 基准情景的收入引擎来自两个杠杆：客户数从 Q4Y2 的 12 个涨到 Q4Y3 的 65 个，同时依靠更广仓库覆盖和自动化档位，把 ACV 从约 $54K 拉到约 $82K。
• 必须做对的事. 公司必须把 pilot 按大约 90 天的节奏转成年约，并在 Y3 开始拿到伙伴带来的 pipeline，才撑得住模型里的 logo 爬坡。
• 模型会失效，如果. 如果包引入量低到撑不起 300+ 受保护席位，或者销售周期被拉长到 120 天，现金走势就会滑向 downside 情景，Y3 的盈利也会消失。
• 下一轮融资证明点. 在 Q4Y2 前做到 10-12 个生产客户，并跑通从 advisory 到 blocking 的采用，就是最能支撑下一轮融资的里程碑。

情景

敏感性

flowchart LR
  Leads --> Pilots
  Pilots --> ProductionCustomers
  ProductionCustomers --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

警示项: 基准情景仍要求客户数从 Q4Y2 的 12 个猛拉到 Q4Y3 的 65 个，因此伙伴渠道执行是最大的预测风险。 · 模型假设客户最终覆盖的席位会超过 SOM 交叉校验里的 250 席，因为多仓库扩张和自动化档位会继续抬高 ACV；如果买家不接受这种扩张，Y3 收入就会低于模型。 · 目标工程团队真实的包引入量，在源材料里仍未被证实，因此留存和扩张最终都取决于 pilot 能否证明反复审查量确实足够高。

• 现有厂商捆绑. 现有依赖安全厂商完全可能补上一套基础 PR 审批工作流，在公司还没做出品牌前就把这个切口压扁。 缓解措施: 不要只拼扫描，而要在工作流深度、替代推荐和内部目录复利上赢；同时尽早锁定共创客户。
• 审查摩擦引发反弹. 如果这道闸门拖慢 merge，或者制造出很多噪音和误报，工程师与买家都会绕开它，甚至把策略降回只审计不拦截。 缓解措施: 先用 advisory mode 上线，提供一键批准，并把生成审查结果的 SLA 压紧；等信任建立后再逐步扩 blocking 规则。
• AI 原生团队之外紧迫性不足. 传统软件团队可能还没强烈感受到包引入的痛点，在出现一次看得见的事故前，不愿意再买一层新控制。 缓解措施: 前两年只盯正式铺开编码助手的 AI 原生软件公司，用它们的包引入量数据证明 ROI。