打造一款工具，让它成为 Strix 的一部分。
Strix 是一套工具集，而非封闭花园。如果你打造了一款开源的隐私或安全工具，且它遵循着同样的准则——默认离线、零遥测、真正可审计——你就可以提议将它纳入。一旦它通过与每款 Strix 工具相同的安全审查与加固流程，它便会归入 Strix 旗下发布：拥有独立的仓库、在本站以 13 种语言呈现的页面，以及附带校验和与证明的版本发布。
最后更新
运作方式
从你的仓库到一款已发布的 Strix 工具，只需四步——而且自始至终，作者署名与著作权都归你所有。
- 01
打造你的工具
用任意语言编写，面向 Windows 和/或 Linux，采用与 MIT 兼容的许可证。满足下方的标准：离线、无遥测、把一件事做好。
- 02
发起一次提交
在 GitHub 上提交一个 issue，附上你的仓库链接、它的功能、面向的平台，以及它如何触及网络——如果确实会的话。你无需在我们这里注册账户，只需一个 GitHub 账户即可。
- 03
安全审查与加固
我们会执行每款 Strix 工具都经历过的同一道关卡：静态分析、依赖与供应链审计、对抗性代码审查，以及一轮加固。你会拿到全部发现，我们再一同逐条解决。
- 04
它以 Strix 的名义发布
一经接纳，你的工具便会在 Strix 组织下拥有独立的仓库、在本站拥有一个本地化的落地页，以及附带 SHA-256 校验和与构建来源证明的版本发布。
Strix 工具必须具备的特质
这些没有商量余地——它们正是整套工具集赖以立身的承诺。如果你的工具早已遵循它们，那它便会宾至如归。
开源
在 MIT 许可证（或与 MIT 兼容的宽松许可证）下公开源代码。没有任何隐藏，没有任何混淆。
默认离线
对于桌面工具，自身不发起任何网络调用。如果网络本就是这款工具的全部用途（侦察/OSINT），那它必须无需密钥、受同意确认约束，并有清晰界定的范围。
零遥测
没有分析 SDK，没有回传，没有账户。用户的数据永远不会离开他们的机器。
一件事，做到位
一款专注的实用工具，配有合理的默认设置、清晰界定的范围，并明确说明它刻意不做什么。
有文档、可测试
一份 README、一份包含威胁模型的 SECURITY.md，以及针对所有安全关键之处的回归测试。
最小权限
不调用 shell、不执行动态代码、子进程调用仅使用 argv、以绝对路径解析工具，且仅在确有必要时才提权。
每次提交都会经历的安全审查
与现有工具在发布前通过的正是同一道关卡。不通过，就绝不发布。
- 静态分析（SAST）在整个代码库上运行 semgrep、bandit、PSScriptAnalyzer、Roslyn 分析器，以及与语言相匹配的 linter。
- 依赖与供应链审计固定版本、一份 SBOM、pip-audit / Dependabot，并核查每一项第三方依赖是否确有必要。
- 对抗性代码审查由人工逐行排查注入、路径遍历、SSRF、权限提升，以及任何削弱安全控制的行为。
- 加固我们一同堵上缺口：最小权限、不调用 shell、输入校验、失败即关闭的默认行为，以及在危险路径上的纵深防御。
- 每个版本都附带来源证明CI 会构建每一个版本、生成一份 SHA-256 的 SHA256SUMS，并附上一份 SLSA 构建来源证明，因此每个下载文件都可供验证。
你保有什么——又能得到什么
为 Strix 做贡献，并不意味着把你的作品拱手让人。
你的作者身份与著作权
你始终是作者。MIT 著作权归你所有；Strix 则与你一同分发并共同维护它。
真实的受众
一个以 13 种语言呈现的本地化落地页、完善的 SEO/GEO 配置，以及在工具网格与下载页中的一席之地。
一条可信的发布流水线
校验和、来源证明、一条最终可用的代码签名路径（SignPath Foundation），以及一套安全披露流程——都为你搭建妥当。
共同维护
issue、PR 和安全报告都会走与套件其余部分相同的流程。你并非孤军奋战。
准备好提交了吗？
提交一个 issue，附上你的仓库链接和一段简短说明。我们会接手、展开审查，并从那里开始与你协作。还没准备好？不妨先阅读完整的贡献指南。
提交只需一个 GitHub 账户。没有任何费用，没有任何会剥夺你权利的贡献者协议，也没有任何义务——在发布之前，你随时可以撤回。
FAQ
我会失去对自己工具的所有权吗？
不会。你保有作者身份和 MIT 著作权。Strix 与你共同维护并分发它，而且在发布之前你可以撤回。
允许使用哪些语言或框架？
任意皆可。现有套件横跨 Python、C#、PowerShell 等等——关键在于许可证、离线/无遥测的准则，以及能否通过安全审查，而非技术栈本身。
如果我的工具需要联网怎么办？
只有当网络本就是它的实际用途时（如侦察/OSINT 工具），这才没有问题。此时它必须无需密钥、以明确的同意确认为前提、范围清晰界定，且仅限获授权使用——绝不能有任何悄无声息的或后台的流量。
审查需要多长时间？
这取决于工具的规模，以及会浮现出多少问题。规模小、已然加固的工具会推进得很快；而任何涉及破坏性操作或提权的工具，都会受到额外的审视。
如果没能通过会怎样？
你会拿到全部发现，可以逐一解决后重新提交。一次能发现问题的审查，恰恰说明这套流程在起作用——套件中现有的工具也都经历过同样的过程。