这一点值得说清楚，因为它正是让大多数关于安全扫描器的对话谈不下去的那个反对意见。
201 个检测器的引擎被下载到你的 runner 上，并在那里执行。回传给 SaferICO 的是各严重级别的数量，以及带文件名和行号的规则编号列表——从不包含代码，也从不包含证据字符串，因为那些会引用你的源码。测试套件会扫描出站请求体，确认里面没有它刚扫过的源码片段。
对于一个仓库私有、尚未审计的团队来说，「把你还没发布的合约贴到别人的 API 里」就是对话结束的地方。在你自己的 runner 里跑，是把这个反对意见消除掉，而不是跟它争辩。
在一个真实代码库上，引擎需要的远不止这些。GitHub runner 有一整个核心且没有时间上限，所以在你提交上跑的那次扫描是完整的扫描，不是一个缩水版本。
runner 每次运行都会取当前版本的引擎。一年前钉住的工作流，今天拿到的仍然是今天的检测器。
可选的最后一步会上传 SARIF，于是发现会出现在 GitHub 的 Security 标签页里，并内联显示在 diff 上——那才是开发者真正会读到它们的地方。
.github/workflows/ 下的一个文件，runner 不会拉进任何依赖树。一个把自己的依赖拖进你流水线的安全工具，是在跟自己的主张作对。
工具本身（扫描器、控制台、SAFI 工作区）目前仍是英文界面。这些页面用中文把一切讲清楚，方便你进去之前先看明白。
引擎报告的严重级别有：严重、高、中、低、提示。默认是「高及以上则失败」。
在清理存量问题的阶段把阈值调低，等干净了再调高。
一个谁都过不去的门槛，一周之内就会被人关掉——而一个被关掉的检查，什么也保护不了。
检测器本身已经公开在 /sfi-engine.js，这一点没什么好遮掩的。
这里出售的是许可、历史记录、决定构建是否失败的那条策略，以及组织范围内的整体视图。
.github/workflows/ 下的一个文件：checkout，取回 sfi-ci.mjs 并执行它，可选地再把 SARIF 上传上去。
在账户的 API 密钥标签页创建密钥，加到仓库的 secrets 里。runner 本身是一个你可以先读完再运行的单文件：https://saferico.com/sfi-ci.mjs。
任何达到或超过所设严重级别的发现都会让构建失败，这通过进程退出码实现——不需要额外解析什么。
同一个 runner 也可以在本地用 npx saferico scan ./contracts 直接跑，用来在推送之前先看一眼。
