安全问题报告与响应规则

一、如何向我们报告安全问题

发现公司产品、服务或客户项目可能存在漏洞、异常访问或数据泄露时，可发送至market@zyaps.com。邮件标题建议使用“安全报告／受影响服务／问题概述”。正在影响业务的紧急问题，请同时使用项目合同或交接资料中的紧急联系渠道。

请尽量提供受影响的产品或网址、发现时间及所在时区、问题现象、必要的复现步骤和联系方式。截图和日志应只保留说明问题所需的内容，去掉无关个人信息。请勿直接发送密码、有效令牌、全量客户数据或不相关的内部文件；确需提供敏感证据时，先联系确认安全传递方式。

公开邮箱用于接收报告，不代表已承诺全天候值守。项目的服务时段和紧急处理方式按双方约定执行。

二、测试需要授权，发现问题应及时停止扩大访问

公开报告渠道不构成主动测试的授权。进行渗透测试或其他主动验证前，应取得相应系统权利人的书面授权，明确目标、时间、方法、账号、数据范围、停止条件和联系人。我方不能替客户或其他服务商授权测试其系统。

不得进行破坏性删除、勒索、植入长期访问程序、使服务不可用、欺骗无关人员或扩大数据访问。已经发现能读到真实资料时，取得说明问题所需的最小证据后就应停止并报告，不要为了证明影响规模而批量下载。

问题尚未修复时，避免公开可直接利用的细节。报告不自动产生奖励或其他特别安排，如有相关约定，由双方另行明确。

三、接收后怎样分工和处理

安全负责人指定受理人及替代联系人，登记收到时间、受影响范围、证据和联系方式。打开附件或链接前检查安全性，避免报告本身带来新风险。

公司通常在约定服务时段内2个工作日确认收到并开始核实。疑似正在泄露、登录保护被绕过等紧急情况，应立即升级，不等待普通受理周期；合同或法规要求更快的，执行更快要求。

以上期限按自然日计算，是公司管理目标，不是所有漏洞统一的法定修复期限。分级要考虑实际权限、利用难度、数据和客户影响，不能只看扫描工具分数。

四、先控制损失，再查清原因

研发和运维人员应根据情况限制异常访问、关闭受影响接口、撤销泄露密钥或隔离服务，同时保存必要证据。记录谁在何时采取了什么措施、影响哪些对象、结果如何。

不要未经评估就清空服务器或直接恢复旧备份，以免破坏证据或覆盖有效数据。重要日志和文件应限制访问，并保存能够校验其完整性的文件摘要。取证只收集必要内容，避免再次扩大客户资料的暴露范围。

客户沟通由项目负责人和安全负责人协调，先说明已经确认的事实、影响及措施。尚不清楚的部分明确标为正在核查，不能无依据保证“绝无泄露”。

五、修复后必须重新验证

研发负责人应找出问题原因，检查同类接口、其他客户、批量操作、历史链接、后台任务和缓存。不能只修复报告中提到的单个入口。

修复方案按发布流程检查版本、配置、兼容性及失败后的恢复办法。部署后重新执行原复现步骤，同时验证类似入口和正常业务，记录实际环境、版本和结果。

无法按期完成时，写明原因、临时措施、责任人、批准人及下次复查时间；紧急问题不能无限期挂起。影响客户的，应告知已知影响、已采取措施、客户建议操作和下一次更新时间。

六、客户通知、法定报告与对外说明

问题已经构成安全事件时，安全负责人应按《国家网络安全事件报告管理办法》及其他适用规定，判断事件等级、报告主体、渠道和时限。具体分工与时限检查见服务支持与业务连续性管理规范。

向客户通知、向主管部门报告，以及依法向受影响个人告知，应分别落实。需要先报告已有情况的，不得等到完整调查结束或内部审批完成后才启动。

发布公告或技术说明前，应与受影响方协调，说明受影响版本、修复版本及临时防护办法，避免暴露个人信息和仍可利用的细节。对外材料应与已核实事实一致。

七、什么时候可以关闭问题

安全负责人应确认影响范围已经核查，修复或临时替代措施通过验证，必要的通知和报告已经完成，相关数据、凭据和权限得到处理。仍有风险或后续工作的，应明确批准、责任人和期限。

问题单关闭不等于实际环境已经修复，必须有上线后的验证记录。公司定期检查处理耗时、逾期和重复问题，将原因用于改进设计、代码检查、监控、培训和供应商管理。向客户提供证明时，只提供与其项目有关且经脱敏的内容。