Cursor Skin Manager 会导入外部光标文件、保存本地数据并修改 Windows 当前用户的光标注册表，因此安全问题需要在公开披露前完成私密确认和修复协调。

项目只为最新公开 Release 接受安全修复，不为旧版本长期回移补丁。发现问题前请先使用最新版本复现。

截至 2026-07-14：

发布新版本后，最新公开版本自动成为受支持版本；维护者会在需要时更新上表。预发布构建、第三方重新打包版本和非官方修改版不在支持范围内。

以下问题通常应作为安全漏洞私密报告：

• 特制 .cur、.ani、.inf、.zip 或目录结构可以造成任意代码执行、命令注入、路径穿越或应用数据目录外的文件写入。
• 应用能够意外读取、覆盖、移动或删除用户未授权的文件。
• 注册表修改越过预期的 HKEY_CURRENT_USER 光标范围，或产生权限提升和跨用户影响。
• 文件事务、备份或恢复逻辑可被利用来绕过验证、破坏数据，或以非预期路径替换文件。
• 应用、安装包、发布流程或依赖中的问题可导致凭据、私人数据或本地文件泄露。
• 官方 Release 的完整性、构建产物或供应链出现可验证的安全风险。

依赖或 Windows 组件的问题如果可以通过 Cursor Skin Manager 的真实使用路径触发，也可以先向本项目私密报告；维护者会判断是否需要同时联系上游。

以下问题一般应通过普通 GitHub Issues 报告：

• 不涉及越权、数据泄露或可利用影响的崩溃、卡顿、预览错误和导入失败。
• 损坏光标文件被拒绝、角色映射不完整或应用后 Windows 没有立即刷新。
• 缺少 WebView2、系统环境不兼容、未签名应用触发 SmartScreen 提示。
• 第三方皮肤包下载失效、素材缺失、视觉内容、许可或 install.inf 自身错误。

不确定时，优先使用私密漏洞报告并说明你认为存在的安全影响，避免在公开 Issue 中猜测或披露可利用细节。

不要创建公开 Issue、Pull Request 或 Discussion，也不要在截图、日志和示例仓库中公开利用细节。

请打开仓库的 Report a vulnerability 页面，通过 GitHub Private Vulnerability Reporting 创建私密报告。报告和后续沟通仅应包含定位问题所需的信息。

当前项目不公布个人安全邮箱，也不通过社交账号、普通 Issue 或无关 Pull Request 接收漏洞详情。

报告中请尽量包括：

• 受影响的 Cursor Skin Manager 版本、Windows 版本和系统架构。
• 问题类型、攻击前提、可达到的影响和你对严重程度的判断。
• 最小且可重复的验证步骤，以及预期结果和实际结果。
• 相关文件格式、目录结构、注册表位置或调用路径。
• 已脱敏的日志、截图、概念验证或测试文件。
• 已知缓解方式，以及是否已经向其他项目或个人披露。
• 希望在最终公告中使用的署名；不希望署名时请明确说明。

不要提交真实受害者数据、访问令牌、密码、签名密钥、无权分发的光标包或不必要的个人文件。测试文件应自行制作并缩减到能够证明问题的最小范围。

项目不承诺固定确认、修复或发布日期。维护者会根据可用时间、可复现性、影响范围和严重程度按以下流程处理：

1. 确认与补充：在私密报告中确认可读取，并请求缺失的版本、环境或复现信息。
2. 初步评估：复现问题，判断安全影响、受影响版本、严重程度和是否涉及上游依赖。
3. 协调修复：在非公开环境准备最小修复、回归测试和必要的缓解说明。
4. 发布更新：创建新版本和 Release，不移动已经公开的标签；高风险问题可优先发布修复。
5. 协调披露：在用户可以获得修复后，视风险发布 GitHub Security Advisory、受影响版本、修复版本和致谢信息。

请在协调完成前保持报告私密。需要补充或询问进度时，直接在 GitHub 私密报告中回复，不要转到公开渠道。维护者可能在证据不足、无法复现或不具有安全影响时关闭报告，并说明判断依据。

进行安全测试时请：

• 只使用你拥有或获准使用的设备、账号、文件和数据。
• 将测试限制在证明问题所需的最小范围，发现敏感数据后立即停止。
• 不进行社会工程、拒绝服务、持久化、横向移动、恶意软件传播或破坏性测试。
• 不访问、复制、修改或公开他人的数据，也不利用问题获取实际利益。
• 给维护者合理的私密调查和修复机会，再协调公开披露。

本项目目前没有漏洞赏金计划，也不承诺报酬。善意、守法且遵守以上边界的报告会被认真评估；是否公开致谢由报告者和维护者共同确认。

仓库启用了 Dependabot Alerts 和 Dependabot Security Updates，并通过每周 Dependabot 检查 npm、Cargo 和 GitHub Actions 依赖。更新 PR 不自动合并，必须经过现有 CI、依赖审计和人工确认。

自动安全检查包括：

• npm audit：高危和严重 npm 漏洞会阻止依赖安全工作流通过。
• cargo-deny：检查实际发布的 Windows x64 Rust 依赖图中的已知漏洞、unsound 公告、许可证和依赖来源。
• CodeQL：扫描 JavaScript 和 TypeScript 的扩展安全规则集。
• 许可证清单：验证锁定的 npm 与 Cargo 依赖声明，出现未审查的许可证时阻止合并。
• GitHub Actions：第三方 Action 固定到完整提交 SHA，并保持工作流最小权限。

发现高危或严重依赖漏洞后，维护者按以下顺序处理：

1. 判断依赖是运行时或开发依赖、直接或传递依赖，并确认在本项目真实使用路径中是否可触发。
2. 优先升级到最小的兼容修复版本；不能直接升级时评估移除依赖、关闭受影响路径或采用上游缓解措施。
3. 执行完整前端、Rust、供应链和生产构建检查。构建结果发生变化时同步递增应用版本；已发布用户受影响时创建新的修复 Release。
4. 临时例外必须在 PR 或私密安全记录中写明公告编号、影响范围、暂不修复原因、缓解措施和复查条件，不允许静默或无限期忽略。仅存在于未发布目标的依赖也必须用目标依赖树证明，并在新增对应平台支持或上游依赖升级时重新评估。

中低严重性告警也需要分流和记录，但是否阻止发布取决于可触发性、影响范围和上游修复状态。具体本地命令见 docs/DEVELOPMENT.md，第三方依赖声明见 docs/THIRD_PARTY_LICENSES.md。

普通支持渠道和第三方皮肤包边界请参阅 SUPPORT.md。