2026-05-06 05:10:27 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 该ICSE2026论文系统揭露GitHub上存在约600万颗假Star构成的黑色产业链，假Star被用于提升恶意软件仓库的可信度以诱导开发者下载。研究提出StarScout检测方法，结合低活跃账号与联动行为特征，识别出18617个主动运营假Star的仓库及30.1万参与账号，揭示假Star对开源软件供应链安全的严重威胁。 综合评分： 85 文章分类： 恶意软件,供应链安全,漏洞分析,威胁情报,安全运营

cover_image

GitHub 上藏着的六百万颗假星，背后是一条恶意软件产业链

原创

喜吾安璇喜吾安璇

攻防SRC

2026年5月5日 21:38 美国

在小说阅读器读本章

去阅读

论文基本信息

He, H., Yang, H., Burckhardt, P., Kapravelos, A., Vasilescu, B., & Kästner, C. (2026). Six million (suspected) fake stars on GitHub: A growing spiral of popularity contests, spam, and malware. In Proceedings of the 48th IEEE/ACM International Conference on Software Engineering (ICSE ’26), April 12–18, 2026, Rio de Janeiro, Brazil. ACM. https://doi.org/10.1145/3744916.3764531

这篇论文发表在 ICSE 2026，即第 48 届 IEEE/ACM 国际软件工程会议。ICSE 创办于 1975 年，由 IEEE Computer Society 和 ACM SIGSOFT 联合主办，是软件工程领域历史最悠久、影响力最大的学术会议，在 CORE 评级体系中属于最高等级 A*。历年技术研究方向的录取率通常在 20% 到 26% 之间，发表难度相当高。本届会议于 2026 年 4 月在巴西里约热内卢举行。

论文有六位作者，来自两所机构。主要作者 Hao He 和 Haoqin Yang 均为卡内基梅隆大学（CMU）博士生，研究方向涵盖实证软件工程与软件仓库挖掘。Bogdan Vasilescu 是 CMU 软件研究所（ISR）的副教授，长期从事开源软件社区的实证研究，在 GitHub 数据挖掘领域发表过大量成果。Christian Kästner 是 CMU 的教授，早年以可配置软件系统研究著称，近年关注 AI 与软件工程的交叉领域。Alexandros Kapravelos 来自北卡罗来纳州立大学（NC State），是网络安全方向的副教授，专注于恶意软件检测和浏览器安全，他为这篇论文带来了安全领域的视角与经验。Philipp Burckhardt 来自 Socket Inc，这家公司专注于开源软件供应链安全，他的参与使研究成果得以直接落地到工业产品中。这个团队的构成本身就值得注意——实证软件工程、供应链安全、工业界实践三方合力，目标从一开始就不只是记录现象，还要把研究结果真正落地到防御实践里。

从一条社会学定律说起

论文一开头引用了唐纳德·坎贝尔 1976 年的话：

“任何社会指标被用于社会决策的程度越高，它所承受的腐化压力就越大，也越容易扭曲和腐蚀它本来要监测的社会过程。”

这句话后来被称为”坎贝尔定律”（Campbell’s Law），最初是在教育测评政策的语境下提出的，但它有一种令人不安的普适性——凡是被用来做决策的量化指标，都会成为被操控的目标。把这段话放在一篇讲 GitHub Star 刷量的论文开头，是在给整篇研究定调：这个问题的根源不是 GitHub 哪里出了技术漏洞，是一旦某个数字成为被广泛依赖的决策依据，操控它就变得有利可图，这是社会系统的一般规律，跟平台无关。

GitHub 的 Star 功能走到今天，恰好印证了这条定律。Star 的设计初衷很简单：用户看到一个有意思的仓库，点一下，既是收藏，也是对作者的鼓励。这个功能轻量、无成本、无门槛，设计上类似 Twitter 的收藏键。但多项学术研究已经证实，开发者在选择开源依赖、评估项目可信度时，把 Star 数列为最重要的参考指标之一；投资人也会看 Star 数评估开源项目或相关初创公司的市场认可度。这个无害的小按钮，因为被如此广泛地用于真实的高风险决策，就成了一个有价值的数字——而有价值的数字，自然就催生了买卖。

先有需求，再有市场。在 Google 上搜索”buy GitHub stars”，会找到十几个提供这类服务的网站。这个现象存在已久，灰色文献（博客、新闻报道、开发者社区讨论）记录了不少具体案例，但从来没有人在全局层面上系统量化过它的规模和性质。这篇论文做的，正是这件事。

假 Star 的市场生态与已有研究

黑市运作方式

研究者把假 Star 的供给模式梳理为三类。第一类是直接的商业服务：专门的网站或 Telegram 频道出售 GitHub Star，通常按 50 颗或 100 颗一批报价，即时发货，用完即走。第二类是交换平台，比如 GitStar 这类网站，用户互相给对方的仓库点 Star，以积分换积分，实质是组织刷量的中间人。第三类更隐蔽，是仓库所有者在自己的营销活动中以礼品换 Star，比如 OceanBase 曾经以此方式推广，给点 Star 的用户送赠品。

这三种方式都违反 GitHub 用户协议中关于”非真实互动”（inauthentic interactions）、”排名滥用”（rank abuse）和”奖励驱动行为”（reward-incentivized activities）的禁止条款。论文把以上所有来路不正的 Star 统称为”fake stars”——不管是机器人批量点的还是真人有偿点的，只要不是用户出于真实意愿自发给出的，都在研究范围内。

买 Star 的动机，从论文归纳来看大致有四类：growth hacking（”先造声势再做大”）、吸引投资人（VC 参考 Star 数评估项目受欢迎程度）、简历造假（求职时展示高 Star 仓库）、传播恶意软件（用看起来受欢迎的仓库骗人下载恶意程序）。

数据基础：GHArchive

研究的数据来自 GHArchive，这是一个把 GitHub 所有公开事件实时同步到 Google BigQuery 的镜像数据集。截至 2025 年 1 月，它包含 6390 万用户、3.31 亿个仓库、3.26 亿个 Star 事件，以及 67 亿个其他类型的事件，五年原始数据约 20TB。

选择 GHArchive 而非 GitHub 官方 API 有明确的工程理由：GitHub API 对未认证请求每小时只允许 60 次，即便是认证用户也只有 5000 次每小时，要遍历数亿条 Star 记录根本不现实。GHArchive 存在 BigQuery 上，可以用 SQL 做分布式查询，研究者把检测逻辑写成 SQL 语句直接在 BigQuery 上执行，这是处理这个量级数据的唯一可行路线。

GHArchive 有一个根本性的局限：它只记录事件流，不存储仓库内容。一个仓库被删除后，其代码和 README 就永久消失了，只剩下事件记录表明它曾经存在。这给研究假 Star 相关的恶意软件仓库带来了很大障碍，因为这类仓库往往在被举报后迅速被 GitHub 清除。研究者为此做了专门的设计决策，在后续分析中会看到具体的应对方式。

StarScout 的检测逻辑

低活跃特征

第一种异常模式叫低活跃特征（Low Activity Signature）。定义很简单：一个账号在 GHArchive 上的全部记录只有一条 WatchEvent（即给某个仓库点了 Star），最多加上同天同仓库的一个其他事件（比如 Fork），此后再无任何活动。这种账号极有可能是用完即丢的刷量工具。

批量制造这类账号是刷量商成本最低的操作方式——注册、点 Star、完事。研究者没有在这个特征上加入更多复杂的判断条件，比如账号年龄、头像是否设置之类，这是刻意为之：越复杂的条件越容易被对抗性调整规避，也越依赖 GitHub API（因为这些信息不在 GHArchive 里）。简单反而更鲁棒。

联动特征与形式化定义

第二种模式叫联动特征（Lockstep Signature），这是论文技术贡献的核心部分。它的直觉是：如果一批账号反复在很短的时间窗口内同步给同一批仓库点 Star，这种”齐步走”的模式在正常使用行为下极难自然产生，高度指向有人在统一调度。刷量商必须在承诺的交货期内完成任务，时间压力天然导致账号行为的同步性，无论他们怎么尝试让单个账号看起来更像真实用户，这个底层的时间同步约束很难完全掩盖。

论文给出了严格的形式化定义。设 U 为全体 GitHub 账号的集合，R 为全体仓库的集合，所有 Star 关系构成一张带时间戳的二部图：

其中每条边表示账号给仓库点了 Star，是这次点 Star 的时间戳。

给定参数四元组，称账号子集与仓库子集展现联动特征，当且仅当同时满足以下条件：

逐条来解读这些条件的含义。

前两个条件和是规模门槛：参与联动的账号数至少要有个，仓库数至少要有个。设置规模门槛是为了过滤掉小范围的偶然巧合——两个朋友同一天给同一个仓库点 Star 不算联动，得是足够大的一批人才有统计意义。

第三个条件是联动特征的实质。它说的是：对于里的每一个仓库，都能在里找到一个子集（大小至少）和一个时间起点，使得中所有账号给点 Star 的时间都落在从开始、长度为的窗口内。换句话说，里至少有比例的账号，曾经在某个时间窗口内集中给点了 Star。这里并不要求同一批账号给每个仓库都点过，只要每个仓库都有足够多的账号在时间上集中到达就满足条件。

这个定义对完全二部图（biclique，即二部完全子图）既是扩展，也是放松，论文原文明确使用了”both an extension and a relaxation”这个说法。说它是放松：完全二部图要求中每个账号都给中每个仓库点过 Star，而这里只要求每个仓库被比例的账号点过——在真实数据里严格的完全二部子图极度罕见，也不符合刷量商的实际操作方式（让所有账号反复给所有仓库刷反而更容易暴露）。说它是扩展：它允许每个仓库对应不同的账号子集和不同的时间窗口起点，而不是要求所有仓库共享同一个时间窗口，这更贴近刷量商分批次、分时段服务多个客户仓库的真实行为。

论文使用的具体参数是，，，天。代入含义：寻找至少 50 个账号和至少 10 个仓库构成的群组，其中每个仓库都在某个 30 天窗口内，从这 50 个账号里至少收到了 25 个账号的 Star。

CopyCatch：规模化寻找联动群组

找满足上述条件的账号-仓库群组，在形式上等价于在带时间约束的二部图里寻找最大二部团，这是 NP 完全问题，精确求解不现实。论文采用的是 CopyCatch 算法，这是 Facebook 研究团队 2013 年发表的算法（Beutel et al., WWW 2013），已被实际部署在 Facebook 生产系统用于检测虚假点赞。

CopyCatch 的核心是带时间窗口的贪心局部搜索。算法从一批种子仓库出发，对每个种子，迭代地做两件事：根据当前账号群组的 Star 时间分布，调整最能覆盖更多账号的时间窗口；根据更新后的时间窗口，重新筛选在这个窗口内给足够多仓库点过 Star 的账号。这两步交替迭代直到收敛，最终保留满足、规模条件的群组。

由于每一步都是对单个种子仓库的局部操作，并且都可以写成 SQL 查询（利用 GROUP BY 和窗口函数），整个算法可以在 BigQuery 上并行执行。研究者把整张 Star 二部图（3.26 亿条边）切成交错的半年时间窗口分批处理——之所以交错而非简单切段，是为了避免跨窗口边界的联动行为被两段都漏掉。

CopyCatch 没有完备性保证，属于启发式搜索，不能保证找出所有联动群组。结合低活跃特征，StarScout 的整体召回率不是 100%，但足以在统计意义上描述这个现象的规模和特征。

后处理：区分主动买 Star 和被动蹭号

两种特征检测出的异常 Star，不能直接等同于”该仓库在主动买 Star”。刷量商为了让账号看起来像真实用户，会让账号顺手给一些热门仓库点 Star——Linux 内核、TensorFlow、Vue.js，什么都有。这些仓库是无辜的，只是被顺带污染了。

后处理步骤的逻辑是：只保留那些在某个月内假 Star 数超过 50 颗且假 Star 占比超过 50%、同时全时段假 Star 占比超过 10% 的仓库，视为”主动运营了假 Star 活动”的仓库。这个筛选的直觉是：顺带被点几颗假 Star 的热门仓库，其假 Star 占总 Star 的比例会被真实的大量真 Star 稀释，远低于 10%；只有真正在购买假 Star 的仓库，才会在某个月内出现假 Star 比例异常高的尖峰。

最终统计：后处理之前，StarScout 共识别出 600 万颗候选假 Star，分布在 26254 个仓库中（低活跃特征贡献 106 万颗，联动特征贡献 493 万颗）。经过后处理筛选，确认 18617 个主动运营假 Star 活动的仓库和 30.1 万个参与账号，对应 381 万颗假 Star。

评估效果

评估一个假行为检测器的准确率有天然的困难——没有公开的 ground truth，你拿不到一份”已确认买过 Star 的仓库名单”来比对。

召回率的评估利用了一个现成的已知案例：Stargazer Ghost Network，这是 Check Point Research 于 2024 年公开披露的一个真实的假 Star 推广恶意软件的网络，涉及 847 个仓库和 15672 个高度可疑账号，有完整的人工核查作为 ground truth。StarScout 识别出了其中 81.23% 的仓库和 75.95% 的账号，考虑到 CopyCatch 是随机贪心算法不保证完备，这个结果算是相当不错的。

精确率采用”删除率”作为替代指标：如果 GitHub 在积极清理欺诈和恶意账户，那么被 StarScout 标记的仓库和账号中，被 GitHub 删除的比例应该显著高于随机基准。结果是：随机抽取的 GitHub 仓库删除率为 5.03%，而 StarScout 检测出的有假 Star 活动的仓库删除率高达 **90.42%**。账号方面，基准删除率 3.54%，StarScout 标记账号的删除率 57.07%。论文将这一差距概括为约 16 倍，基本排除了大规模误报的可能性。

为什么不购买假 Star 建立蜜罐仓库来做评估？论文解释了理由：购买假 Star 意味着直接给刷量黑市付钱、资助被研究的恶意生态，同时在 GitHub 上制造垃圾内容，这涉及研究伦理问题，所以选择用已有的真实案例替代。

四个研究问题

RQ1：规模与覆盖范围

研究时间跨度是 2019 年 7 月到 2024 年 12 月。假 Star 在每月全部 Star 事件中的占比始终低于 1%，从绝对比例看不算高。但这个数字掩盖了更重要的结构性变化：有假 Star 活动的热门仓库（定义为当月收 Star ≥ 50 颗的仓库）占全体热门仓库的比例，在 2024 年 7 月达到峰值 **16.66%**，涉及 3499 个仓库。参与刷量的活跃账号数在 2024 年 3 月达到峰值 **6.59%**，共约 11.7 万个账号（117,024）。时间曲线显示，2022 年开始出现明显上升，2024 年跳跃式爆发。

在 GitHub Trending 页面上，五年内有 78 个假 Star 仓库出现过，占全部假 Star 仓库的 0.42%，峰值出现在 2024 年 3 月（25 个）。这说明 GitHub 的 Trending 算法对纯粹靠买 Star 冲榜的仓库有一定过滤作用，但并非完全免疫。研究者在这 78 个仓库里发现了”Wallet-stealer”和”blooket-hacks”这样的名字——能上 Trending 意味着被真实用户看到了。

在包注册表方面，通过 ecosyste.ms API 查询，研究者找到了 738 个来自 229 个假 Star 仓库的已发布包，分布在 PyPI（159）、npm（145）、Pub（138）、Cargo（123）、Go（118）等注册表。这些包的实际采用情况很糟糕：70.46% 的包在注册表里没有任何依赖它的其他包，77.5% 在 GitHub 上没有依赖它的仓库。高 Star 数和真实采用之间的脱节相当明显。

RQ2：行为模式

存活时间方面，83.9% 的假 Star 仓库的全部 GitHub 活动记录不超过 10 天，这些仓库的生命周期极短，典型模式是上线、买 Star、被举报或消亡。相比之下，参与刷量的账号的活跃时长分布与普通 GitHub 用户差别不大——刷量商会复用同一批账号反复接任务，不会为每次任务重新注册。

活动类型方面，把所有仓库和账号的 GHArchive 事件聚合成 Star、Push、Fork、Create、Issue、PR、Comment、Other 八类对比，假 Star 相关的仓库和账号活动严重向 Star 偏斜，几乎不存在 Issue、PR 等需要真实人工投入才能完成的活动类型。

对账号做 k-Means 聚类，时 Silhouette Coefficient 最高，三组聚类中心分别是：77.75% 的账号几乎只做 Star（Cluster 0，纯刷量号）；14.76% 的账号混有 Push 和 Create 操作，看起来更像真实用户（Cluster 1），手动查看后发现有些账号确实在创建空仓库模拟开发活跃度来规避检测，也有些真的难以判断；7.49% 的账号以 Star 和 Fork 为主（Cluster 2），研究者推测来自同时出售 Star 和 Fork 的刷量商。

RQ3：这些仓库是什么

90.42% 的假 Star 仓库已被 GitHub 删除，无法直接查看内容。研究者对仓库名做词频分析，高频词集中在三个语义域：破解软件（crack、adobe、photoshop、free、activation）、加密货币机器人（bot、solana、wallet、crypto、trading）、游戏外挂（hack、cheat、roblox）。

对于还在线的 1783 个仓库，研究者全部克隆，采用 open coding（开放编码）方法对其中三组进行人工分类：出现过 Trending 的 78 个、有包注册表发布的 229 个、以及从其余仓库随机抽取的 299 个（按 95% 置信水平、5% 误差边际确定样本量）。Open coding 是定性研究中的归纳式编码方法，不预设分类框架，直接从材料中提炼类别，并由多人独立编码后计算评分者一致性来评估可靠性。

最终得到九个类别：Spam/Phishing（22.6%）、AI/LLM（16.6%）、Blockchain（13.1%）、Tool/Application（12.6%）、Tutorial/Demo（12.1%）、Web Frameworks（9.7%）、Basic Utility（5.2%）、Database（2.4%）、Other（5.9%）。

Spam/Phishing 类的典型模式是 README 把仓库包装成一个有用的工具（区块链应用、游戏外挂、破解软件），然后提供下载链接，实际下载的是恶意程序。论文图 1 给出了一个具体案例：仓库声称是 Solana 区块链应用，代码文件 main.js 在第 12 行第 892 列藏了一个被刻意放到视野之外的 spawn() 调用，它启动了一个伪装成合法 npm 包名的脚本（@solana-web3-1.43.js），该脚本经过混淆处理，使用 axios 和 AdmZip 从远端下载并执行代码，实际功能是窃取加密货币钱包。仓库的 Issue 区有一个受害者的投诉帖，投诉自己的钱包被清空了。这个仓库有 111 颗 Star，研究者判断其中至少 109 颗是假的。

AI/LLM 类里有相当一部分是学术论文的配套代码仓库，作者通过买 Star 提高代码仓库的可见度；另一部分是 LLM 相关创业项目在做 growth hacking。这个类别的出现把假 Star 爆发与 2024 年 AI 热潮直接联系起来。

RQ4：买假 Star 到底有没有用

这是论文里方法论最复杂的部分，需要仔细理解。

问题的难点在于简单的相关性分析不够用。如果你发现某个月买了假 Star 的仓库在接下来几个月真 Star 增加了，你没办法区分这是假 Star 带来的效果，还是因为那些买了假 Star 的仓库本来就处于增长期（同时做了别的推广，有活跃的开发活动），而这些才是真 Star 增加的原因。要把假 Star 本身的效果剥离出来，需要控制这些混淆因素。

面板自回归模型（Panel Autoregression）是这里的方法论核心。面板数据指的是同时具有截面维度（多个个体，这里是多个仓库）和时间维度（多个时间点）的数据。对每个仓库在每个月，研究者收集了以下七个变量：

：仓库在第月新增的假 Star 数
：截至第月，仓库的累计假 Star 总量
：仓库在第月新增的真 Star 数
：截至第月，仓库的累计真 Star 总量
：仓库到第月时的仓龄（月数）
：仓库在第月之前是否有过 GitHub Release（布尔值）
：第月内仓库来自非 owner、非假刷量账号的 GHArchive 事件数（真实开发活跃度的代理变量）

前四个变量是检验假设的核心变量，后三个是控制变量（已有研究证实这三者与 Star 增速相关）。

模型的结构是阶自回归，即 AR()，完整形式为：

这个公式要逐项拆开来看。

是自回归项：把过去个月每月新增的真 Star 都作为预测变量放进来。这样做是因为 Star 增速有时间惯性，上个月涨得多，这个月大概率也不差；不放入这些滞后项，模型就无法把”本来就在增长的项目”和”假 Star 带来了增长”区分开来。

是真 Star 的累计存量项。一个拥有几万 Star 的老项目，其 Star 增速可能比一个刚起步的项目更稳定，这个存量效应应该被控制。之所以取而非，是为了避免与前面的流量项（）在时间上重叠——以为例，流量项覆盖和，存量项就取时刻的值，表示那之前的历史积累。

是假 Star 的流量项，用来检验”买了假 Star 之后的短期效应”——上个月买的假 Star 有没有带来这个月更多真 Star？

是假 Star 的累计存量项，用来检验”历史上假 Star 积累的越多，对后续真 Star 获取有什么影响”。这是长期效应的载体。

控制变量、、仅在随机效应模型中出现；固定效应模型不需要这些，因为固定效应本身已经通过给每个仓库引入一个专属截距，把所有仓库层面上时间不变的潜在特征（包括维护者的能力、项目所处赛道的热度等）都吸收掉了。

所有分布偏斜的变量在入模前取对数变换。对数变换之后，模型的系数具有弹性解读：如果和都做了对数变换，那么系数的含义是” 增加 1%，预期变化 %”。这比” 增加一个单位，增加个单位”的解读更有意义，因为不同仓库的 Star 数量差异巨大，用相对变化来描述更合适。

研究者对都拟合了模型，结果一致，论文主要汇报的结果。同时报告固定效应和随机效应两个版本是为了展示结果的稳健性——两种模型假设不同、估计方式不同，如果结论一致，说明结论不依赖特定的模型设定。

模型检验了两个假设。

H1：积累真 Star 有助于在未来获得更多真 Star。理论基础是社交网络里众所周知的”富者越富”效应（preferential attachment / rich-get-richer），已有大量研究在不同平台上证实这一规律：一个项目越受欢迎，在搜索和推荐中就越容易被看到，被看到就越容易继续积累关注，形成正反馈。

H2：积累假 Star 也能带来更多真 Star，但效果比真 Star 弱。推理是：普通用户浏览 GitHub 页面时看不出 Star 是真是假，假 Star 提升的数字对路过的用户有一定影响力；但一些用户会看 Issue 讨论的热度、PR 合并记录、贡献者数量等其他信号，如果这些都很空洞，就不会进一步关注，所以假 Star 的效果预期比真 Star 打折扣。

固定效应模型的结果（Table 6）：

H1 得到强支持。的系数是 0.364（p < 0.01），意味着上个月真 Star 增加 1%，本月预期真 Star 增加 0.364%；的系数是 0.148，效应在衰减但仍然显著；的系数是 0.097，说明历史累计真 Star 多的仓库持续有更高的真 Star 获取速率。总体来看，真 Star 对真 Star 的正效应是持续存在的，符合富者越富的规律。

H2 只得到部分支持。的系数是 0.074（p < 0.01），的系数是 0.029（p < 0.05），说明假 Star 在购入后的前两个月确实带来了少量真 Star 增量，但效果约为同等真 Star 效果的 1/5。这个短期正效应在统计上显著，但量级很小。

然而的系数是 −0.045（p < 0.01）——负的，并且显著。这意味着一个仓库历史上积累的假 Star 越多，此后每个月获得的真 Star 预期反而越少。研究者的解释是：假 Star 让仓库的星数字好看，短期内确实有人点进来看；但进来之后发现 Issue 区冷清、提交记录稀疏、文档粗糙，这些才是决定用户是否真正关注的信号。买假 Star 的仓库往往在这些方面都不足，来了就走，不留下真 Star。时间长了，这种不匹配积累成一种负面印象，反而比不买假 Star 更差。

研究者同时坦诚了模型的因果推断局限性。Granger 因果检验是计量经济学里用来建立更强因果证据的工具，但它要求时间序列足够长（对 AR() 模型需要个时间点），而这批短命仓库的月度活跃记录大多达不到这个要求，所以无法使用。更根本的问题是外生变量：如果一个维护者技术能力差且急于求成，这个特质可能同时导致他去买假 Star，也导致仓库内容空洞而吸引不到真 Star——这样的话，”假 Star 越多，真 Star 越少”反映的是同一个潜在因素的两个表现，而不是前者导致了后者。论文明确承认这一点，没有声称已经排除了这种可能性。

应对措施

论文的讨论部分把建议分给了三类主体来分析。

平台（GitHub）是拥有最大杠杆的一方，因为它掌握非公开信息（比如用户 IP 地址）、可以直接修改 Star 的展示逻辑和算法权重。研究者认为最根本的改进方向是重新设计仓库热度信号，而不是继续给所有 Star 平等权重。文献里有不少可以借鉴的思路：按用户的真实活跃程度给 Star 加权（活跃贡献者的 Star 算更多）；把仓库在真实依赖网络中的网络中心度纳入热度计算；对来自可疑账号的 Star 做影子屏蔽（shadowban，即这颗 Star 对账号本身可见，但不计入仓库公开显示的 Star 数）。Stack Overflow 的声誉系统和 Yelp 的评论过滤机制都是同类设计的先例。

研究者还注意到一个细节：他们手动检查仓库时，发现有些恶意仓库的 Star 被清空了，但仓库本身仍然在线。这说明 GitHub 可能已经在某些环节识别出了假 Star，但没有把这个信号与恶意内容检测联动起来。把假 Star 的检测结果作为触发恶意软件审查的输入信号，可以提升平台的防御效率。

第三方安全工具有独特的位置：他们服务于具体的工业客户，可以在客户的软件采购流程里植入针对假 Star 的告警。研究者与 Socket Inc 合作，把 StarScout 的检测结果集成进了他们的供应链安全产品——当客户的依赖清单（SBOM）里出现有假 Star 历史的包时，工具生成告警。在 200 万份客户 SBOM 中触发了 283 次告警，虽然数量不多，但这些包真实存在于工业项目的依赖树里，说明问题确实有实际影响。

开发者和从业者这一方，论文给的是实打实的数据，不是道德说教。数据说明，买假 Star 实际上没用，长期来看还有反效果——两个月内带来的真实关注增量就衰减殆尽，之后这段刷量历史反而成了包袱。

负责任披露

这篇论文有专门一节记录研究过程中的安全披露，这在大多数软件工程论文里并不常见，但对于直接涉及活跃恶意软件的研究来说是必要的。

在 RQ3 的分析中，研究者发现了一批 GitHub 上仍可访问的钓鱼仓库，立即向 GitHub 安全团队举报。他们进一步从完整数据集里筛查其他可疑仓库，条件是提供了 .zip/.rar/.exe 下载链接、VirusTotal 检测为恶意软件、或 README 内容与已确认钓鱼仓库高度相似。手动核查后，共向 GitHub 上报了 130 个钓鱼仓库和 2 个主要用于 SEO 作弊的账号（分别拥有 213 和 139 个仓库）。截至论文写作时（2025 年 8 月），所有钓鱼仓库和其中一个 SEO 账号已不可访问。

对于其余有疑似假 Star 记录的仓库，研究者选择不直接举报，理由是 StarScout 存在一定的误报率，仅凭检测结果举报仓库可能对误报中的正常仓库造成不必要的伤害。他们的选择是把整个研究告知 GitHub 安全团队，由平台方结合非公开信息（比如 IP 地址）进一步验证和处理。

这项研究的位置

这篇论文在三条研究脉络上都有实质性贡献。

在社交媒体欺诈检测领域，它把为 Facebook 点赞欺诈设计的 CopyCatch 算法迁移到软件开发平台，验证了这类方法的跨域适用性，同时系统记录了一个新型欺诈场景——刷的不是粉丝或点赞，是代码托管平台的可信度信号。这个迁移不是直接套用，需要针对 GitHub 事件数据的结构重新设计检测流程，并在规模上处理几亿条记录，工程上有其挑战。

在软件供应链安全领域，它填补了一个明显的空白。供应链攻击的各种路径——typosquatting、恶意扩展、账号劫持、xz 那类长期社会工程学攻击——在学术文献中都有研究覆盖，但用假 Star 建立恶意仓库的虚假可信度这条路，之前只有灰色文献提及，这篇论文第一次给出了全局范围的量化证据，包括规模、特征和与恶意软件的关联程度。

在实证软件工程领域，面板自回归模型在 GitHub 研究中并不常见。把它引入来估计某种行为的纵向因果效应，比通常的横截面回归或简单的时间序列相关分析更能处理个体异质性，即便作者自己也坦诚距离严格因果推断还有距离，方法论上的规范性仍然有参考价值。

论文的数据和代码开放在 Zenodo（doi:10.5281/zenodo.17009693），StarScout 源码一并公开，为后续研究提供了可以直接使用的工具基础。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：攻防SRC 喜吾安璇喜吾安璇《GitHub 上藏着的六百万颗假星，背后是一条恶意软件产业链》