缺陷附件脱敏操作规范应包含哪些内容：空白模板与填写说明

缺陷附件脱敏操作规范要解决的是“提交缺陷时，截图、日志、录屏里哪些信息必须处理、由谁处理、处理完谁来复核”的问题。一份可直接使用的规范应包含五块内容：脱敏对象清单、逐类判断规则、处理方式登记、复核记录、调整与维护机制。本文以空白模板为主体，配套逐字段说明、必填规则和一份完整填写示例，三处字段名称保持一致，复制后即可改为团队初版规范。

要点总览（TL;DR）

• 规范应包含五块内容：脱敏对象清单、逐类判断规则、处理方式登记、复核记录、调整与维护机制，五张表按“对象→规则→处理→复核→维护”串联。
• 对象清单按附件类型（截图、日志、录屏、导出文件、压缩包）分行填写，判断规则具体到字段或画面区域，处理动作与对象清单用同一套词。
• 必填底线是附件类型、是否需脱敏、处理方式、处理人、处理时间、处理动作、复核人、复核时间、复核结论；例外保留、外发共享时补充例外说明与接收方。
• 处理登记与复核记录通过附件编号关联，处理人与复核人原则上分开，复核结论须明确写“通过”或“退回”。
• 规范上线后按新增附件类型、脱敏遗漏、工具或制度变化触发修订，按月或按迭代抽查，版本号与变更记录在表五留痕。

可复制空白模板：缺陷附件脱敏操作规范

下面是一份文档型空白模板，可直接复制到文档工具中填写。模板由生效信息、五张表和维护记录组成，表头即为字段名，与后文字段说明逐一对应。

规范基本信息

项目	填写内容
规范名称	缺陷附件脱敏操作规范
版本号	V____
生效日期	____年__月__日
责任人	（姓名/角色）
适用范围	（适用的产品线、项目、缺陷提交渠道）
关联文档	（缺陷提交规范、缺陷分级标准等）

表一：脱敏对象清单

序号	附件类型	典型内容	敏感要素	是否需脱敏	处理方式
1
2
3
4
5

表二：判断规则

序号	识别对象（字段/画面）	敏感判定标准	保留或处理	处理动作	判定依据
1
2
3
4

表三：处理方式登记

附件编号	对应缺陷编号	处理动作	处理人	处理时间	处理说明

表四：复核记录

附件编号	复核人	复核时间	复核结论	证据位置	备注

表五：维护与变更记录

变更日期	版本号	变更内容	变更原因	提出人	审批人

字段说明：每张表要填什么、怎么填

五张表按“对象→规则→处理→复核→维护”的顺序串联：表一定义哪些附件进入管理范围，表二回答每类内容怎么判断，表三记录实际做了什么，表四确认处理是否到位，表五记录规范本身的修订。填写时先完成表一和表二，再在日常提交中滚动填写表三、表四。

表一：脱敏对象清单

字段	含义与填写口径
附件类型	按文件形态归类，如截图、日志文件、录屏、导出报表、压缩包。同一缺陷可能同时涉及多类，分行填写。
典型内容	该类附件通常包含什么，如“页面报错截图”“接口请求日志”“操作过程录屏”。用于帮助提交人快速对号入座。
敏感要素	该类附件中可能出现的敏感信息类别，如账号、手机号、身份证号、客户名称、内部地址、密钥。只列类别，不抄录真实值。
是否需脱敏	填“是”“否”或“视内容而定”。填“视内容而定”时，须在表二中给出对应判断规则。
处理方式	该类附件默认采用的处理手段，如遮盖、裁剪、替换、重录、脱敏后重新导出。与表三的实际处理动作使用同一套词。

表二：判断规则

字段	含义与填写口径
识别对象	具体到字段或画面区域，如“登录页截图中的账号输入框”“日志中的请求头 Authorization”。粒度越具体，执行时争议越少。
敏感判定标准	说明在什么条件下视为敏感，如“出现完整手机号”“包含可定位到具体客户的企业名称”。
保留或处理	二选一填写。保留需说明保留理由，例如该信息是复现缺陷的必要条件且已获授权。
处理动作	与表一“处理方式”用词一致，便于统计与核对。
判定依据	规则来源，如公司信息安全制度条款、客户合同约定、项目组内部约定。选填，但涉及例外时建议填写。

表三与表四：处理登记和复核记录的区别

表三记录“谁在什么时候对哪个附件做了什么”，是执行记录；表四记录“另一个人检查后认为处理是否合格”，是验证记录。两张表通过“附件编号”关联，处理人与复核人原则上应为不同人员。表三的“处理说明”写动作细节，如表二要求遮盖三处、实际遮盖了哪三处；表四的“证据位置”写复核所依据的材料存放位置，如处理前后对比图所在目录或文档页面。

表五：维护与变更记录

每次修订规范都在表五新增一行，写明变更日期、新版本号、变更内容、变更原因、提出人和审批人。版本号建议采用“V主版本.次版本”形式，判断规则或对象清单发生实质变化时升主版本，措辞修正或补充示例时升次版本。

必填与选填：哪些字段不能空

规范落地时最常见的失效情形是关键字段留空，导致事后无法判断某个附件是否处理过、由谁处理。建议按下表划定填写底线。

档位	字段	理由或适用情形
必填	附件类型、是否需脱敏、处理方式	三者构成对象清单的最小闭环，缺一项则表二无法对应。
必填	处理人、处理时间、处理动作	用于追溯责任与时间线，缺失则处理记录失去意义。
必填	复核人、复核时间、复核结论	复核结论须明确写“通过”或“退回”，不能只签名不表态。
选填	判定依据、证据位置、处理说明	常规处理可简写；涉及例外、外发或争议时转为必填。
条件必填	例外说明	当某附件按规则应处理但决定保留时，必须写明理由与批准人。
条件必填	共享范围与接收方	附件需外发或跨团队共享时补充，说明提供给谁、用途是什么。

必填项空缺时，复核环节应直接退回，不进入缺陷流转的下一状态；若因客观原因无法补齐，由规范责任人在表五登记例外并注明补录期限。条件必填项在触发条件出现时按必填对待，未触发时可留空。

填写示例：一份完整的脱敏规范样例

以下示例为演示情景，用于说明模板各表如何配合填写，团队可对照改写为自身规范。

示例场景设定

某项目收到一个“订单列表页加载失败”的缺陷，提交人附了三类材料：页面报错截图、后端接口日志、操作过程录屏。截图中可见登录账号与客户名称，日志中包含请求头令牌，录屏中出现了内部测试环境地址。

对象清单与判断规则的填写结果

附件类型	典型内容	敏感要素	是否需脱敏	处理方式
截图	页面报错、列表数据	账号、客户名称	是	遮盖
日志文件	接口请求与响应	令牌、内部地址	是	替换后重新导出
录屏	操作过程	内部环境地址、账号	是	重录或裁剪

识别对象	敏感判定标准	保留或处理	处理动作	判定依据
截图中的账号输入框	出现完整账号	处理	遮盖	信息安全制度第__条
截图中的客户名称列	可定位到具体客户	处理	遮盖	客户合同保密条款
日志请求头令牌	出现有效令牌字符串	处理	替换为占位符后重新导出	信息安全制度第__条
报错堆栈信息	不含个人信息与内部地址	保留	无需处理	复现缺陷所需

处理方式与复核记录的填写结果

附件编号	对应缺陷编号	处理动作	处理人	处理时间	处理说明
ATT-01	BUG-1024	遮盖	提交人A	__月__日 10:20	遮盖账号与客户名称共两处
ATT-02	BUG-1024	替换后重新导出	提交人A	__月__日 10:35	令牌替换为“***”，保留请求路径
ATT-03	BUG-1024	重录	提交人A	__月__日 11:00	重录时避开环境地址栏

附件编号	复核人	复核时间	复核结论	证据位置	备注
ATT-01	测试负责人B	__月__日 14:10	通过	缺陷记录附件区	—
ATT-02	测试负责人B	__月__日 14:15	退回	缺陷记录附件区	响应体中仍有内部地址，需再次替换
ATT-03	测试负责人B	__月__日 14:20	通过	缺陷记录附件区	—

对照检查：示例中出现的“遮盖、替换后重新导出、重录”与表一处理方式用词一致；表二每条识别对象都能在表三找到对应处理记录；表四每条记录都对应一个附件编号，复核结论明确。读者改写时保持这三条对应关系，模板即可自洽使用。

调整与维护方法：让规范随团队变化更新

规范上线后需要有人负责维护，否则新增的附件类型、新出现的泄露场景会落在规则之外。维护工作可以归纳为触发修订、定期抽查、版本管理和流程衔接四件事。

触发修订的情形

• 出现新的附件类型，如新增了性能分析文件、自动化测试报告导出包，对象清单需补充对应行。
• 复核中发现脱敏遗漏或误判，需回看表二规则是否表述不清，并补充识别对象。
• 缺陷提交工具、日志采集方式或环境地址规则发生变化，处理方式与判断标准随之调整。
• 客户合同或公司信息安全制度更新，判定依据需要同步修订。

定期抽查的方式与频次

建议按月或按迭代抽查已关闭缺陷的附件，抽取比例可按团队缺陷量确定，例如每迭代抽取10至20条。抽查关注三点：附件是否按表一进入管理范围、表三处理记录是否完整、表四复核结论与实际附件状态是否一致。抽查结果记入表五或在团队例会上通报，连续出现同类遗漏时升级为规则修订。

版本号与变更记录的维护方法

规范文档本身应放在团队可访问的固定位置，每次修订更新版本号并在表五留痕。旧版本保留只读存档，便于追溯某条缺陷提交时适用的是哪一版规则。规范责任人变动时，在基本信息中更新责任人并在表五记录交接。

规范与缺陷提交环节的衔接

规范要真正生效，需要嵌入缺陷提交的实际动作：提交人在上传附件前对照表一自查，处理后在表三登记，复核通过后缺陷才进入修复流转。若团队使用 ONES Project 管理缺陷，缺陷可一键提交至对应项目或迭代并持续跟踪修复情况，附件与处理记录随缺陷一并留存；规范文档本身可放在 ONES Wiki 中，利用页面模板库建立制式化模板，借助页面版本记录保留历次修订并可回滚，再按角色配置读写权限，让提交人、复核人和规范责任人各按职责访问。这样，模板中的对象清单、处理登记与复核记录就有了稳定的存放位置，抽查时也便于按缺陷逐条核对。

常见问题

团队缺陷量很少，还需要单独维护复核记录表吗？

需要保留复核记录，但可以简化填写方式。缺陷量少的团队可以把表三和表四合并到同一张登记表中，用“处理人”和“复核人”两列区分角色，复核结论仍要明确写“通过”或“退回”。复核人可以是提交人之外的任意一名成员，关键是处理与复核由不同人员完成，事后能查到谁在什么时间确认过附件状态。

附件按规则应当脱敏，但脱敏后缺陷就无法复现，怎么处理？

这种情况属于例外保留，应在表二中把该识别对象标注为“保留”，并写明保留理由，例如该信息是复现缺陷的必要条件。同时在表三的处理说明中记录保留决定，在表四复核时由复核人确认理由是否成立。若附件需要外发或跨团队共享，还要补充共享范围与接收方字段，说明提供给谁、用途是什么，避免例外被默认扩大。

规范中的判断规则和公司信息安全制度冲突时以哪个为准？

以公司信息安全制度和客户合同约定为准，规范中的判断规则是这些制度在缺陷附件场景下的落地细化。填写表二时在“判定依据”列写明规则来源条款，出现冲突时先按更严格的一方执行，并在表五登记修订，把规范条款调整为与制度一致。规范责任人应定期核对制度更新，避免规范长期停留在旧口径。

抽查发现某条已关闭缺陷的附件没有处理记录，应该怎么补救？

先确认该附件是否属于表一的管理范围。属于范围内的，由规范责任人联系提交人补录处理信息，补录时注明补录原因和补录时间；无法确认处理情况的，重新处理并补做复核。若同类遗漏连续出现，说明表二规则表述不清或提交环节缺少提醒，应升级为规则修订，在表五记录变更内容与原因，并在团队例会上通报抽查结果。

规范文档放在哪里，才能让提交人和复核人都方便对照使用？

规范文档应放在团队都能访问的固定位置，并保留旧版本只读存档，便于追溯某条缺陷提交时适用的是哪一版规则。若团队使用 ONES Wiki，可借助页面模板库建立制式化模板，利用页面版本记录保留历次修订并支持回滚，再按角色配置读写权限，让提交人、复核人和规范责任人各按职责访问。缺陷附件与处理记录则随缺陷在 ONES Project 中留存，抽查时可按缺陷逐条核对。