Questions #188
Description
z0scan的开发者您好，非常感谢您对404星链计划的持续关注与认可，接连四次提交申请，这份对开源安全领域的热情和执着，我们由衷地表示肯定与敬佩。经过团队再次对 z0scan 项目的全面评估，我们很遗憾本次仍暂无法同意该项目加入，此前提及的核心问题“创新点不足”未得到实质性解决。另外我们也有一些小建议，希望对您能有所帮助：
1、目前项目将所有规则直接嵌入代码中，而正常的代码应仅负责核心逻辑，规则类内容本质上属于数据范畴。这种混编的方式会导致后续规则扩充、修改时成本极高，且易引发代码逻辑混乱。建议梳理项目中的规则模块，将规则抽离为独立的配置文件/数据库存储，让代码专注于逻辑执行，以此提升项目的可扩展性和维护性。
2、在安全类开源项目中融入二进制文件是行业内的一大忌讳 —— 二进制文件无法直观审查代码逻辑，无法确认是否暗藏后门、恶意逻辑或未公开的漏洞，这不仅会降低项目的可信度，也不符合404星链计划对开源项目透明性、安全性的核心要求。
3、开源项目的竞争力往往源于对真实问题的解决能力，建议优先围绕在使用过程中遇到的、行业内尚未被很好解决的具体安全检测/扫描问题展开迭代。这些从实际场景中提炼的问题，若能被针对性解决，既可以保证项目的实用性，也能自然形成区别于同类工具的核心亮点，而非单纯追求功能堆砌。我们理解多次申请被拒可能带来的失落，也始终认可z0scan在安全开源领域的投入。如果后续项目完成优化，或在创新方向、核心能力上有了显著突破，我们非常欢迎再次提交申请！
Originally posted by @Knownsec404team in #185
尊敬的404项目工作者们好，很感谢能够收到你们对我的答复与认可。但对于建议，我想要提出质疑与表达疑惑：
- 将规则抽离为独立的配置文件/数据库存储是否真正意味着能够提升项目的可扩展性和维护性？
在您描述中有提及"规则类内容本质上属于数据范畴"，那么同样属于数据范畴的payload列表是否也应该抽离为独立的配置文件/数据库存储呢？
在早期的 z0scan 中规则被整理并存放在 config 中，但我在10.11日做出了这样的决策：
**2025.10.11**
1. core/helper -> 外置helper, 内置core/helper 为插件外部动态更新做铺垫
2. config/* -> config.py, others/*被包含到插件代码中
这里的包含并不意味着"嵌入"，而是将其置顶于代码中。插件外部动态导入是 z0scan 自项目起建就具有的重要优势，这一优势与nuitka打包相结合共同为用户带来的极大的自定义价值：这允许用户既能享用打包后nuitka+python所带来的高性能表现又能够将poc开发予用户调整。在xray中有这样一个议题，这本质上反应了用户对更直观的检测与实现路径的探求，那规则与payload列表又何尝不是检测与实现路径的一部分呢？倘若将他们抽离为配置文件/数据库存储，这不将违背"直观"的初心吗？相反，用户能够在 z0 清晰的分类结构中轻易地定位到 poc 并进行对应的修改，这将保证最整洁的结构与最直观的自定义优势。
不妨设想一下，我将随机的一条规则抛之与用户，用户真的就能懂得规则的前置触发逻辑吗？用户就真的知道它的实现是为何而服务的吗？
在维护上，随着 poc 开发的逐步推进与功能的拓展，规则逐步增加，这使得我在有时的开发推进过程中为对应部分规则的服务对象而犯难。
2. 二进制融入
首先我承认我在仓促的开发中一时疏忽了404星链计划对开源项目透明性、安全性的核心要求。但 crawlergo 作为全球知名开源爬虫程序，并不存在"无法直观审查代码逻辑，无法确认是否暗藏后门、恶意逻辑或未公开的漏洞"的问题。
crawlergo 二进制用的：https://github.com/Qianlitp/crawlergo/releases/tag/v0.4.4
sha256校对：
darwin_arm64: dae5936070c215996b949881cb8123b8c0817229c2a1f47916085a97c9869a9c
linux_amd64:
cdf072120615104423a9827dc4134953133a9113626286ab38e9de1e6160dd3b
linux_arm64:
6d861785060f713ef550fccbaff8200353192733cfe7c4c0740bd5a4b5f06373
win_amd64:
2f9d9abd2b3dae7c1a362736db7bf3b55f1d24b2af7a7a4a665108f8b1cbfd71
或许我可以以GithubAction为平台通过源码构建crawlergo二进制文件到bin中存放以实现间接性内嵌？
3. 解决能力
这是我对您要求的理解：
- 使用过程中遇到的
- 被动扫描过程中用户&扫描器间的流量竞争问题
- 端口导入注册以减少端口开放性检测数
- 在xray与ez中缺乏PerHost级POC组
- 行业内尚未被很好解决的
- 用户对打包文件下开放插件代码的需求
- 分布式与本地式的共存问题
未来 z0scan 所计划实现的是： - 依托用户form输入触发的插件组
- AI深度集成
最后，诚挚地感谢404项目工作者们对 z0scan 项目的支持、鼓励与关注，你们能够在百忙之中指点 z0scan 项目的开发便是对其进步与发展的最大鼓舞！