内部信息审核需知

一句话结论

涉及内部信息的软件，禁止走此审核流程。

为什么不能走

这套审核流程只收 公开仓库（public repo）：项目得上传到 GitHub 的 secure-artifacts 组织，对全互联网可见。

为什么卡死公开仓库这一种形态？GitHub 的 Code Scanning、Secret Scanning 等扫描能力对公开仓库免费开放，对私有仓库要付费订阅 GitHub Advanced Security。为了让每个项目都跑得上审核，平台就只接这一种。

所以：把软件提交进来 = 把它公开到互联网。里面有内部信息，就是主动泄露。

哪些算"涉及内部信息"

提交前请自查，只要命中任一条，就不要走此流程：

• 代码里有内部业务逻辑、内部系统的 API 地址、数据结构、表结构
• 代码里硬编码了内部服务的账号、数据库连接串、密钥（哪怕你打算稍后移除）
• 文档 / README / 注释里提到客户、内部人员、内部项目代号
• 训练数据、样例数据、测试用例里带着真实业务数据
• 软件本身是给内部系统用的，离开内部环境跑不起来

不分审核类型，约束都一样

当前流程只处理"软件"，网站 / 插件 / 脚本的审核上线之后，下面这几条依然适用：

• 不准上传内部网站的地址、截图、后台路径
• 不准把内部资料（设计稿、文档、数据、配置）带进仓库
• 代码、README、注释里，都别留内部敏感内容——注释一样会公开，一样能被搜到

造成泄露的，一样由提交者自己承担。

风险与责任

无视本需知、把涉及内部信息的软件公开上传之后：

• 任何人都能 clone、fork、引用这个仓库
• 就算你事后删除，GitHub 缓存、第三方镜像、搜索引擎可能已经留了副本
• 由此造成的信息泄露、法律、合规后果，由提交者本人承担

内部软件不走此流程

内部软件走别的渠道，具体怎么走不在这里讨论，自己确认清楚。

自查清单

提交前逐条过一遍：

• [ ] 代码里的内部服务地址、账号、密钥都搜过了
• [ ] README / 注释里没有客户、内部项目代号
• [ ] 训练 / 测试数据里没有真实业务数据
• [ ] 离开内部网络也能独立运行
• [ ] 以上任何一条不确定 → 先别提交，去问清楚

全部过关，走 项目提交流程。