感谢你帮助 Project Hazelita 及其用户保持安全。🌌

如果你在 Project Hazelita 的项目中发现了安全漏洞，请优先通过私密渠道报告，并避免在维护者有机会了解和处理问题之前，通过公开 Issue、Discussion、Pull Request、社群消息或其他公开方式披露漏洞细节。

如果受影响的仓库启用了 GitHub 的 Private Vulnerability Reporting，请优先使用仓库 Security 页面中的 Report a vulnerability 功能提交报告。

如果仓库提供了自己的 SECURITY.md 或其他安全报告说明，请优先遵循该项目自己的政策。

如果以上方式均不可用，可以：

• 通过该项目维护者公开提供的私下联系方式联系维护者；
• 创建一个不包含任何漏洞细节的普通 Issue，仅询问可用的私密安全联系渠道。

在建立私密联系之前，请不要在公开位置发布漏洞细节、利用代码、敏感日志或其他可能帮助他人复现漏洞的信息。

一份有帮助的漏洞报告通常可以包括：

• 受影响的仓库、组件、版本或 Commit；
• 漏洞的简要描述；
• 可以复现问题的步骤或最小化 Proof of Concept；
• 你认为可能造成的安全影响；
• 相关日志、截图、请求或其他技术细节；
• 如果已经找到，可能的缓解方式或修复建议。

报告一个安全问题并不需要你能够提供完整的利用代码或修复方案。

提交前，请尽可能移除与漏洞无关的个人信息、密码、access token、private key 以及其他秘密。

如果一个问题可能使攻击者能够进行以下行为，请优先通过安全渠道报告：

• 执行非预期的代码或命令；
• 绕过身份验证或权限控制；
• 未经许可访问、修改或泄露数据；
• 提升权限；
• 获取凭据、token、密钥或其他秘密；
• 显著破坏服务的可用性或完整性；
• 通过用户无法合理预期的行为攻击其他用户；
• 以其他方式影响项目或用户的机密性、完整性或可用性。

如果你不能确定一个问题是否属于安全漏洞，先私下报告通常更加稳妥。没有明显安全影响的普通 bug，可以通过项目正常的 Issue Tracker 报告。

请在公开漏洞的完整技术细节之前，给予维护者合理的时间调查、确认和处理问题。

在条件允许时，Project Hazelita 的维护者会尽量与报告者一起：

• 确认和理解漏洞；
• 判断受影响的范围；
• 开发或协调修复方案；
• 确定合理的披露时间；
• 在适当情况下发布 Security Advisory；
• 对报告者提供合理的致谢。

不同漏洞的复杂程度、风险和修复成本可能差异很大，因此本组织级默认政策不承诺固定的响应或修复期限。公开披露的时间与方式应优先考虑受影响用户的安全，同时尊重安全研究者所作出的贡献。

Project Hazelita 欢迎以改善项目安全为目的的善意安全研究。

进行测试时，请尽合理努力：

• 不访问与验证漏洞无关、且不属于你的数据；
• 不修改或删除他人的数据；
• 不破坏服务，或对其他用户造成明显影响；
• 使用证明问题所需的最低权限和最低影响方式；
• 如果继续测试可能造成伤害，请及时停止；
• 通过适当的私密渠道报告发现的问题。

漏洞验证应该足以说明安全问题存在，而不需要造成不必要的影响。

除非某个项目另有明确说明，Project Hazelita 目前不提供 Bug Bounty、奖金或其他漏洞报告奖励计划。

善意报告漏洞并不意味着授权进行可能违法、破坏服务或侵犯他人权益的行为。

对于过早公开可能使用户面临额外风险的问题，安全修复可以在私下进行。

在问题得到适当处理后，维护者可以发布 Security Advisory 或其他公告，说明：

• 受影响的版本或范围；
• 漏洞影响；
• 修复或缓解方式；
• 必要的升级建议；
• 对报告者的适当致谢。

本文是 Project Hazelita 各项目默认使用的组织级安全政策。

不同项目可能拥有不同的支持版本、威胁模型、部署方式、安全边界、漏洞报告渠道、响应与披露流程等。如果具体仓库存在自己的 SECURITY.md，则以该仓库的安全政策为准。另外，仓库未单独列出支持版本，并不意味着所有历史版本都会持续获得安全更新。