Sighttrue

Sighttrue

sighttrue.com · 你的技术栈 · 比较 · 方法 · 动态

在 CI 中检查依赖项

permissions:
  pull-requests: write   # only needed for the comment

steps:
  - uses: actions/checkout@v4
  - uses: sighttrue/sighttrue@v1
    with:
      manifest: package.json
      fail-on: withdrawn,archived,relicensed

当依赖项自身的发布者撤回了该依赖项时，构建会失败——npm 称之为弃用，PyPI 和 crates.io 称之为撤回，RubyGems 称之为撤回，Packagist 称之为弃用，NuGet 称之为弃用；当其代码库已归档或改用仅提供源代码的许可证时，构建也会失败，并且无论哪种情况都会报告安全公告。读取 package.json、requirements.txt、pyproject.toml、Cargo.toml、 composer.json 和 Gemfile。无需密钥、无需账户、无需注册服务——它读取已发布的测量数据，并与 OSV 通信。网络问题绝不会被判定为问题：如果无法获取数据，这一步会说明情况并通过，因为构建若会因他人的网站宕机而失败，最终只会被删除。

在拉取请求中，它还会以表格形式发表评论，列出检查结果，并在每次推送时更新同一条评论，而不是另发一条。构建失败会告诉审核者有问题，却不会说明是哪个依赖项，也不会说明它发生了什么变化，除非打开日志。设置 comment: false 可仅在步骤摘要中报告。来自派生仓库的拉取请求会获得只读令牌，因此会跳过评论，但该步骤仍会通过。

也适用于 requirements.txt 和 Cargo.toml。

或安装应用，无需做任何改动

Action 需要在每个想使用它的仓库中添加工作流文件。GitHub App 只需安装一次，之后便会监视授权给它的所有仓库，无需工作流、密钥或配置：当拉取请求添加了监视列表中的运行时依赖项时，它会发表评论，列出已记录的信息——下载量、OpenSSF 记分卡、安全公告数量、许可证、上次推送时间——并在之后的每次推送时更新同一条评论。

当拉取请求没有修改清单、没有添加依赖项，或没有添加任何受监视项时，它完全不会发言。这才是常见情况，也是设计初衷：一个评论说自己什么都没发现的机器人，最终会被卸载。它绝不会把任何东西称为安全、不安全或值得推荐，因为这些都不是本项目测量的内容。

Action 会让构建失败；App 只负责报告。两者读取相同的已发布数据包，因此结果不会相互矛盾。

一份可以交付的 SBOM

/stack 会将检查结果导出为 CycloneDX 1.6 文档，并将每个依赖项的安全公告数量、记分卡、许可证、发布日期和公交因子作为属性附上。与该页面上的其他功能一样，它在浏览器中根据粘贴的清单生成——不会上传任何内容，也没有用于发送清单的端点。

它不会声明版本。清单声明的是 ^1.6.0，并未说明实际安装了什么，也没有说明其下的传递依赖树。文档会在自己的元数据中明确说明这两点，而不是让读者自行察觉，因为一份妄自猜测的 SBOM 比没有 SBOM 更糟：它会成为一份合规文件，声称某些实际上无人解析过的内容。

建议添加监视项

监视列表经过人工整理，但并不完整；它是凭判断手工选出的，没有其他方法可言——这是它最薄弱的地方。提交议题，说明你认为哪些仓库值得纳入。列表的每次变更都会以经过审核的提交进行，因此议题就是审核发生的地方。

面向编码 Agent

一个基于相同读数的 MCP 服务，让 Agent 能根据今天的测量结果回答“这个依赖健康吗”，而不是依赖一年前的训练数据。

{ "mcpServers": { "readout": { "url": "https://sighttrue.com/api/mcp" } } }

九个工具免费，二十二个付费。编写代码时，可以使用 check_before_install：给定一个软件包，它只返回审查者事后发现时会感到恼火的情况——已撤回该软件包的发布者、它在安装机器上运行的脚本、已归档的仓库、安全公告、仅提供源代码的许可证、长期沉寂——并附上发布相关信息的机构的网址。它不会告诉你是否应该安装，只会列出已有记录，让你在了解情况后作出决定；如果结果为空，它会明确说明这表示没有发现任何信息，而不是说该软件包安全。

接下来是 check_package、check_stack、search_repositories、compare_repositories、find_model、check_eol、check_provider、list_readings。它们都是只读的，无需密钥或账户。每项结果都会说明它能够支持的结论范围，因为 Agent 会把这些数据粘贴到代码审查中；如果引用分数卡时没有注明“衡量的是已声明的实践，而非项目是否安全”，那就是本项目不会作出的断言。

不使用 MCP 时，一个 GET 请求就能返回相同内容：

curl 'https://sighttrue.com/api/verdict?pkg=npm:axios'
curl 'https://sighttrue.com/api/verdict?pkg=pypi:django&version=4.2'

安全公告、许可证、注册表最近一次发布该软件包的时间、公交系数，以及该版本是否仍受支持——每项都附上发布相关信息的机构的网址，方便审查中引用的数据一键核查。 尽管名称如此，它并不会给出结论：没有分数、排名或建议。那些会让本项目对他人的工作作出判断，并把判断伪装成测量结果。

一个 Agent 监控 417 个开源仓库，并采集 11 项读数，其中大多数并不涉及 GitHub：保留了 807 条已从各自状态页面移除的服务商事件、522 条正在生命周期终止倒计时中的发布版本线、382 项模型价格、182 个按实际发布日期记录的软件包，以及 416 段用于计算公交系数的提交历史。它每四小时在 GitHub Actions 上运行一次，将读取的数据提交到此仓库，并发布静态站点。

每个页面和每个资源包都是一个文件。共有五个动态路由，且没有页面依赖它们：/api/ask、/api/mcp、/api/chain、 /api/github/webhook（供 App 使用），以及 /api/auth 和 /api/watchlist 下的登录与关注列表端点。使用 GitHub 登录只会保存关注列表，不会保存其他内容——已登录页面上的读数与任何人都能下载的已发布资源包相同。

data/ 的提交历史正是重点。它是一条审计轨迹：每项读数都有时间戳，只追加、不修改，并且可以直接通过 GitHub 核查。

它报告什么

11 项读数，每项都以其回答的问题命名，而不是以生成它的采集器命名。网站导航也由同一份列表驱动，因此两者不会出现偏差——在这份列表被记录下来之前，它们已经偏差过 3 次。

读数	回答的问题	涉及 GitHub
实时	过去几小时发生了什么变化？	是
发布	哪些项目发布了新版本？	是
分叉	哪些项目的复制速度超过了自身的基线？	是
需求	开发者对哪些内容有需求，且这些需求跨越多个项目？	是
依赖项	哪些依赖项被添加、移除或升级了主版本？	是
谱系	哪些模型声称自己基于哪些模型构建？	否
模型价格	100 万个 token 的成本是多少，这一成本何时发生变化？	否
服务中断	我依赖的服务会宕机吗？频率如何？	否
生态系统	注册表、安全公告和论坛都在说些什么？	否
被依赖项	其他所有东西都在悄悄依赖什么？	否
本周	如果每周只看一次，我会错过什么？	—

这 6 项完全不涉及 GitHub，它们回应了一个合理的质疑：GitHub 摘要器的价值仅限于 GitHub 已经展示给你的内容。

每个检测器的阈值是否根本有可能达到，也会在索引页的“我们的记录”栏目中公布。如果某个检测器从未有任何对象接近过其阈值，那它就不是安静的检测器，而是配置错误的检测器；网站也会如实说明这一点。

如何阅读

每项比较都是相对于仓库自身的历史数据，而非与其他仓库比较。“基线的 27 倍”表示该项目的表现是其通常水平的 27 倍；图表上也绘出了基线，方便你了解什么是正常水平。

置信度会明确标注，绝不暗示。

状态	含义
forming	历史数据不足 14 天。仅显示原始计数。不计算倍数，也不暗示存在倍数。
detected	曾有一次越过阈值。采用中性处理。
confirmed	连续两个每日快照中均持续存在。

只有 confirmed 信号才会作为发现呈现。这会牺牲最多一天的速度，换来无法挽回的东西。

生成的文字会使用与测量值不同的字体。 如果某句话解释了某个数字，那么该句中的每个数字都会在发布前与源记录核对；如果其中任何数字不在记录中，就会弃用该句，改用模板生成的句子。

本项目不作何种承诺

• 监测列表经过人工筛选，且并不完整。它由人工选出，并非对开源项目的全面调查。依赖项和需求相关发现描述的是正在监测的仓库，而非整个生态系统。
• 数据不是实时的。数据更新间隔至少为 4 小时，定时运行也经常延迟。
• 这里的内容不预测任何事情，也不表示任何仓库是好是坏、安全还是不安全。
• 出现在监测列表中只代表一种观察结果，并不意味着存在合作关系。此处列出的项目均未认可本项目。

如果已发布的发现后来被证明有误，就会以醒目程度相同的更正事件取代。事件永不删除，历史记录永不改写。

数据

网站读取的每个数据包都以 JSON 格式提供，因此任何声明都可以通过页面所用的同一文件进行核验。

data/
├── live/state.jsonl          Latest reading per repository. Sorted, rewritten each pulse.
├── live/window.jsonl         Timestamped fork samples, for the rolling 24h delta.
├── live/manifests.jsonl      Last-seen dependency set, diffed daily.
├── history/YYYY-MM-DD.jsonl  One immutable snapshot per day.
├── events/YYYY-MM.jsonl      Append-only. Never rewritten, never pruned.
├── summaries.jsonl           Generated prose, keyed by event id.
├── watchlist.jsonl           What is watched, and since when.
└── meta.json                 Last run status.

文件按固定键顺序排序，因此未发生变化的仓库不会产生差异。这也让一天提交 6 次的仓库不会无限增长。

运行

Node 24。类型会原生剥离，因此无需构建步骤，也没有运行时依赖项。

在 D1 模式到来之前，文档一直写着 22.18+。测试会将 migrations/ 加载到 node:sqlite；该模块在 24 中已稳定，在 22 中则需要启用标志。因此在 22 上，测试套件会因导入失败而非断言失败，这种了解版本要求的方式很让人困惑。

npm install          # dev dependencies only: typescript, vitest, fonts
npm test
npm run typecheck

node scripts/pulse.ts --limit=20   # needs GITHUB_PAT
node scripts/daily.ts
node scripts/build.ts              # emits dist/

维护观察列表

观察列表由人工策划。我们曾尝试通过搜索查询生成列表，但结果更差——主题搜索只能找到自行添加标签的仓库，而按星标数排序会把教程和链接合集排在基础设施项目前面。保留 derive-watchlist.ts，是为了提出策划者可能遗漏的候选项，也为了让这个失败的结果可以复现。

node scripts/verify-watchlist.ts   # check every entry against the API
node scripts/retire-watchlist.ts   # mark archived and deleted ones inactive
node scripts/derive-watchlist.ts   # propose candidates, writes nothing
node scripts/derive-packages.ts    # map repositories to packages, writes nothing

derive-packages.ts 会填充 packages 字段，借此 Agent 可以查询项目的下载量变化，而不只是仓库的变化。它绝不会仅凭名称匹配：先提出候选项，再获取注册表中该名称对应的记录，只有当注册表指向此仓库时，才保留映射。这个规则可不是摆设——第一个版本按子字符串匹配，把 angular/angular 映射到了 npm 包 angular，但该包属于已归档的 angular/angular.js，这样就会把一个已停更项目的下载量记到一个仍在运行的项目上。

绝不会删除任何内容。已退役的条目会继续留在列表中，并标记为 active: false，因为删除条目会抹去它曾被观察过的记录，也会抹去它仍链接到该项目期间收集的发现。

剩下的工作由两个定时工作流完成。pulse.yml 每四小时运行一次，获取仓库基线和发布信息；daily.yml 写入规范快照、识别激增情况，并收集问题和清单。两者每次运行都会提交更改，即使没有任何变化——仓库 60 天没有活动后，定时工作流就会被禁用，而这个提交正是防止这种情况的关键。

配置

密钥	用途
SIGNAL_GITHUB_PAT	细粒度令牌，仅用于读取公开仓库。密钥名称不能以 GITHUB_ 开头。
CLOUDFLARE_API_TOKEN	Cloudflare Pages：编辑权限
CLOUDFLARE_ACCOUNT_ID
GROQ_API_KEY	可选。未设置时，每份分析结果仍会发布，只包含数字，不包含文字。

两组可选配置都是真正可选的：未设置时，相应步骤会跳过并说明原因。不会将运行标记为失败，因为选择不配置某项并非错误，而始终显示的警告只会让人视而不见。

许可证

MIT。请参阅 LICENSE。

费用

Cloudflare Pages、公开仓库上的 GitHub Actions，以及 Groq 免费套餐。Pages 上的静态资源和带宽没有上限，因此访客流量不受限制。其余所有限制都适用于构建端，而构建端的用量有界且可预测。