Skill Constellations：追溯 GitHub 上的 Agent Skills 供应链

  • 关联论文：2610.11169
  • 作者：flyP
  • 更新：2026-10-10

§0 元层五问

  1. 这篇到底在解决什么真问题？ Claude Code、Codex 等 AI 编程 agent 通过 SKILL.md 脚本取得用户级权限，但 skill 是被开发者手工复制传播的——没有 registry、没有版本、没有 provenance，安全团队不知道哪个仓库可信、哪个仓库已经被投毒。
  2. 它和现有方法的核心差异是什么？ 不是"某一时刻 GitHub 上有多少 skill"这种静态普查，而是 从 git history 里重建出"哪份 skill 何时从哪个仓库复制到哪里"的时序拷贝网络——是首次给出带时间戳的拷贝链。
  3. 凭什么这件事现在做？ agent 已经在大量开发者的本机取得近似 root 的执行权，而 skill 是 LLM agent 时代新生的"软件供应链"形态，传统的 SCA（软件成分分析）工具对此一无所知。
  4. 最大不确定性在哪？ 论文用"模型拟合哪些仓库会被别人拷贝"来排序审计目标，但模型本身的可解释性与误报率未在 abstract 量化。
  5. 如果我只看一行，要记什么？ "skill 是没有版本号的 Python pip 时代的 npm；GitHub star 不能告诉你它来自哪里，但 git 历史能——按拷贝网络排序审计能比按 star 排序多覆盖 30 倍高危 skill 的后续扩散。"

§1 一句话结论

Skill Constellations 从 GitHub 上每份 SKILL.md 的 git 历史重建出 2,193,119 次 skill 采用的时序拷贝网络，证明"少数源头仓库贡献了几乎所有副本、GitHub star 不能识别它们、源仓库一次安全修复几乎不会自动扩散"，并据此拟合模型给出可操作的审计排序清单。

§2 解决什么真问题

  • AI 编程 agent 的权限爆炸：SKILL.md 携带脚本、以用户身份运行，等于把 npm postinstall 脚本升级到了 LLM agent 的指挥权级别。
  • skill 的供应链缺失：开发者靠"复制粘贴"传播，没有版本号、没有 registry、没有签名，"谁从谁复制了"几乎是不可知的。
  • 现有研究的盲区：单点快照式普查（如"GitHub 上有多少 SKILL.md"）只能告诉你"哪些仓库现在持有一份 skill"，但回答不了"谁抄了谁、漏洞修复能传到哪"。
  • 审计资源有限：安全团队不可能逐个仓库读代码，必须有一个能预测"修这个源头能拦下多少后续扩散"的优先级排序。

§3 核心方法（机制）

3.1 数据采集

  • 起点：GitSkills 数据集里所有 SKILL.md 的 git 历史。
  • 对每个文件，提取每次 commit 的"前后内容 hash + commit 时间 + 作者 + 仓库"四元组。
  • 把"内容相同或近似相同"的不同仓库、不同时间的 SKILL.md 视为潜在的"拷贝事件"。

3.2 拷贝识别与时序网络

关键判定：把"新仓库出现的 SKILL.md 与已有仓库的某次 commit 内容近似"视为一次 adoption 边，并附上时间戳。这样从全网 git 历史反向回放，就得到一张 dated copy network——节点是仓库、边是带时间的"何时抄了哪份 skill"。

3.3 关键经验观察

  • 少数源头统治全网：少数仓库贡献了几乎所有 skill 副本，GitHub star 数完全不能识别它们。
  • 拷贝几乎不变：绝大多数仓库把 skill 拷过来后不再跟进源仓库改动；上游一次安全修复要传到下游基本靠手工。
  • 链路短、影响大：高风险 skill 的扩散路径往往是 1~2 跳，意味着"修源头"是高 ROI 动作。

3.4 审计排序模型

作者拟合了一个"哪些仓库会被别人拷贝"的概率模型，按"如果我现在审查这个仓库，能阻止多少后续高危 skill 扩散"做排序。前 100 名仓库可拦下 14.9% 的后续高危 skill 采用，而按 star 排序的前 100 名只拦下 0.5%——相差近 30 倍。

3.5 关键伪代码（拷贝识别）

adoptions = []
for repo in GitHub:
    for commit in repo.git_history:
        for skill_md in commit.files_matching("SKILL.md"):
            content_hash = sha3(normalize(skill_md.content))
            # 在已有仓库历史里找时间更早且内容相同/近似的节点
            src = find_earliest_similar(content_hash, before=commit.time)
            if src:
                adoptions.append({
                    time: commit.time,
                    from: src.repo,
                    to:   repo,
                    hash: content_hash,
                })
build_graph(nodes=repos, edges=adoptions)
fit_model("which repo gets copied by others", features=[activity, content_age, centrality...])

§4 关键实验与数据

维度 数字 说明
数据规模 2,193,119 次 skill 采用 来自 GitSkills 数据集 + git history 反向重建
仓库覆盖 GitHub 全网（GitSkills 子集） abstract 未明示独立仓库数，原文未明确
审计排序提升 14.9% vs 0.5%（前 100 仓库） 模型排序 vs star 排序在"阻止高危 skill 后续扩散"上的差距
项目网站 https://fahdseddik.github.io/Skill-Constellations/ abstract 显式给出，可交互浏览

⚠️ 诚实标注：2,193,119 是 abstract 显式给出的总采用次数；按 star 排序 vs 模型排序的"后续扩散覆盖率"为 abstract 数字，原始数据集版本与评测时间窗未公开。独立仓库数、跨仓库内容相似度阈值 abstract 未量化。

§5 亮点与局限

亮点

  • 首次给"时序拷贝网络"：从 git 反查"谁抄了谁"是软件供应链研究的稀缺能力，过去 SCA 几乎都做不到。
  • 30 倍审计效率差：模型排序对 star 排序的相对提升是工程上可直接拿来汇报的硬证据。
  • 配套交互视图：作者给了可视化网站，下游审计员可以直接复用。
  • 结论可操作：明确建议"平台应分发 versioned reference 而非副本"——这是给 GitHub/agent 平台的工程级政策建议。

局限

  • 依赖内容哈希相似度：高阈值会漏掉被小改后再拷贝的 skill，低阈值会把巧合相似的脚本误并。
  • git history 不完整：force-push、squash、删除分支都会让历史证据消失，模型会低估扩散量。
  • 模型可解释性未量化：abstract 未给模型决策的混淆矩阵或 PR-AUC。
  • 未涵盖私有仓库：私有 GitHub、GitLab、自托管仓库全部缺席，对企业内部威胁盲区大。
  • 时效衰减风险：skill 生态变化极快，论文采用的 GitSkills 版本与"现在"可能已有显著漂移，原文未明确给出数据快照日期。

§6 工程落地启发（§八 六坑）

  1. 现象：skill 拷贝后跟源不同步。 影响：源仓库的安全修复无法自动覆盖下游。修复：建立"skill reference registry"，下游只引用源 URL + 内容哈希，源更新即生效。
  2. 现象：审计排序只看 star。 影响：真正的源头仓库被忽略。修复：按"潜在后续高危扩散覆盖率"排序，按论文模型思路在自家 SCM 上重训一份。
  3. 现象：私有仓库里的 skill 不在视野。 影响：内部恶意 skill 大量漏检。修复：内部 SCM 也接入同一份拷贝识别 pipeline，至少能识别"同一团队里谁抄了谁"。
  4. 现象：git history 被 force-push / squash 重写。 影响：拷贝链证据丢失。修复：平台层启用 append-only history，或对 SKILL.md 类高敏感文件禁止 destructive history。
  5. 现象：相似但被改写的 skill 被哈希屏蔽掉。 影响：规避复制的恶意 skill 漏网。修复：在哈希相似度之外叠加 AST / embedding 相似度双层判定。
  6. 现象：审计结果只给 PR / 报告，无 actionable 动作。 影响：安全团队"看完即忘"。修复：把审计排序直接接入"自动 PR 评论 + 阻断下游合并"流程，前 100 强制审查。

⚠️ 诚实标注：上述 6 坑是从方法与结论推断的工程风险，原文未给每坑的实测频次。

§7 与同方向工作的关系

  • vs 传统 SCA（npm / PyPI）：传统 SCA 解决"我依赖了哪些库"，Skill Constellations 解决"我的工具让 LLM 执行了哪些不可信脚本"——威胁模型完全不同。
  • vs 软件供应链攻击研究（如 SolarWinds / xz 后门）：本工作把同一类威胁下放到了 LLM agent 时代，攻击面更大、传播更快。
  • vs OpenSSF Scorecard / SLSA：这两者关心的是"构建链路可信"，Skill Constellations 关心的是"已经被复制 N 次的内容是否值得信任"——是互补而非替代。
  • vs GitSkills 数据集：GitSkills 提供"哪些仓库有 SKILL.md"的快照，本工作是其时序化与因果化。
  • vs 终端 EDR：EDR 关心运行期，Skill Constellations 关心分发期——两者要联动才能闭环。

§8 适合谁读

  • 企业安全 / AppSec 团队：想给 AI 编程 agent 加 skill 白名单/审计机制的人，本工作提供了排序依据。
  • AI agent 平台架构师：要不要做"versioned reference registry"是一个产品级决策点，本工作的政策建议值得工程化跟进。
  • 软件供应链研究者：把 SCA 方法迁移到"自然语言配置 + 脚本"这一新型制品，是新研究方向。
  • 合规 / 审计咨询：当客户问"我们用了 Claude Code，skill 这块怎么合规"时，本工作是可以直接引用的实证。

§九 评级四子项

子项 评分 依据
方法新颖度 A 首次给 dated copy network，方法学层面有范式价值
实验充分度 B+ 全网规模数据 + 30 倍对比证据强；模型自身的混淆矩阵未量化
工程可操作度 A- 审计排序清单 + 项目网站直接可用；私有仓覆盖缺失
可落地性 B+ 平台侧建议合理；企业内部复现需要重新训练一份模型

§十 边界声明

  • 仅基于 arxiv abstract（v1）+ paper_card + 候选人检索；未读 PDF 全文。
  • "2,193,119 次采用 / 14.9% vs 0.5%" 均来自 abstract；原始评测时间窗、数据集版本未公开。
  • 作者归属 abstract 显式 Fahd Seddik（v1），完整作者列表与机构未在 abstract 列明。
  • "工程落地启发"6 坑为基于方法与结论的工程推断，不等同于论文自报实测坑点。

flyP · 2026-10-10 · 基于 arxiv 2610.11169 abstract v1 / paper_cards/1750-2610-11169.md / lessons-2026-W37~W40 写作指引