算法工程师安全自评估 160 项指标逐行核查 Checklist

新闻中心

一、为什么必须做安全自评估？

现在算法已经深入金融风控、医疗诊断、智能交通这些关键领域，但随之而来的风险也越来越突出 —— 比如用户数据泄露、模型被对抗攻击篡改结果、代码里藏着未修复的漏洞，这些问题一旦爆发，不仅会造成业务损失，还可能违反法规。

《数据安全法》《个人信息保护法》还有算法备案的要求都很明确，咱们算法工程师作为技术落地的关键角色，不能等出了问题再补救。通过系统化的自评估提前找出风险点，既能保证技术合规，也能给算法应用加上一道安全防护网。

二、核心核查 Checklist（160 项）

下面分 5 个核心模块整理了 160 项核查指标，每一项都标注了具体要求，大家可以直接对照着填核查结果（打√或填状态）。

（一）数据安全模块（30 项）

数据是算法的基础，从采集到销毁的全流程都要盯紧，这部分重点查 30 项内容：

核查维度	序号	核查项	具体要求	核查结果（√通过 /× 不通过 /○待核查）
数据采集	1	用户授权是否合规	必须拿到用户明确同意（不能默认勾选），还要存好授权记录（包括授权时间、范围）
	2	数据来源有没有问题	自己爬的数据要确认合法，第三方买的数据必须要对方提供授权证明，避免用无授权数据
数据存储	3	敏感数据有没有加密	身份证号、手机号这类敏感信息，要用 AES-256 加密存储；数据库要开启 TDE 透明加密
	4	存储权限控制严不严	只有必须用到数据的人才能给权限，谁访问过、什么时候访问的，都要在日志里记下来
数据预处理	5	有没有做去标识化处理	姓名、银行卡号这些能直接定位到个人的信息，要么删掉，要么脱敏（比如银行卡号只留后 4 位）
	6	异常数据有没有过滤掉	训练数据里可能混进标注错误的数据，甚至是别人恶意注入的 “中毒数据”，要用工具排查干净（比如人工抽样检查或用数据清洗工具）
数据使用	7	是不是只拿需要的数据	训练或推理时，只调用必需的字段，别多拿冗余数据（比如只需要用户年龄，就别把地址也一起取出来）
	8	跨业务线用数据有没有走审批	如果数据要从 A 业务线用到 B 业务线，必须先找安全部门审批，不能自己直接转用
数据销毁	9	过期数据有没有按时销毁	按公司制度到期销毁，销毁记录要保存 6 个月以上（比如销毁时间、负责人、方式）
	10	销毁方式合不合规	电子数据要多次覆写（别只删文件），硬盘、U 盘这些物理介质要物理粉碎，不能随便丢弃
...	11-30	（含数据传输加密、备份恢复、跨境数据合规等 19 项）	比如传输数据要用 HTTPS，备份数据要异地存储，跨境数据要符合数据出境要求等

（二）模型安全模块（40 项）

模型是算法的核心，从设计到退役的每一步都可能有风险，这部分重点查 40 项：

核查维度	序号	核查项	具体要求	核查结果（√通过 /× 不通过 /○待核查）
模型设计	11	有没有考虑隐私保护设计	如果处理敏感数据（比如医疗数据），要看看是不是该用联邦学习、差分隐私这些技术，避免原始数据泄露
	12	鲁棒性有没有考虑到边缘场景	比如输入值特别大或特别小的时候，模型会不会输出错误结果？要提前做边缘场景的防护设计
模型训练	13	有没有防训练数据中毒	可以用 CleanLab 这类工具排查异常样本，避免有人恶意修改训练数据导致模型失效
	14	训练过程有没有监控记录	训练时改了哪些参数、loss 值有没有突然异常波动，这些都要记下来，方便后续追溯
模型验证	15	对抗样本测试过没有	用 FGSM、PGD 这些常见的对抗攻击方法测试，确保模型准确率下降不超过 5%
	16	模型有没有偏见	检查模型输出会不会对特定性别、地域的用户有歧视（比如同样条件下，女性用户的信用评分更低）
模型部署	17	模型传输和部署包有没有加密	部署包要用 RSA 加密，传输的时候走 HTTPS，别明文传
	18	模型版本有没有管控	没经过测试的版本绝对不能上线，每次版本更新都要记清楚变更内容（改了什么、谁改的、为什么改）
模型退役	19	退役模型有没有彻底删掉	部署节点、存储硬盘里的模型文件要全删掉，别留备份
	20	退役模型的关联数据有没有清理	跟退役模型相关的训练数据、测试数据，也要一起清理，避免冗余数据泄露风险
...	21-40	（含模型解释性、访问权限、更新流程等 19 项）	比如模型要能解释决策逻辑，模型访问要鉴权，模型更新要走测试流程等

（三）代码安全模块（25 项）

代码是算法落地的载体，漏洞往往藏在细节里，这部分重点查 25 项：

核查维度	序号	核查项	具体要求	核查结果（√通过 /× 不通过 /○待核查）
代码开发	21	有没有规避常见漏洞	参考 OWASP Top10，比如防止 SQL 注入、XSS 跨站脚本攻击，写代码时要注意过滤输入
	22	代码里有没有硬编码敏感信息	API 密钥、数据库密码这些绝对不能直接写在代码里，要存在配置中心或密钥管理系统
版本控制	23	代码仓库权限有没有控制	只有项目成员能访问代码仓库，不能把代码传到公开仓库（比如 GitHub 的公开项目）
	24	关键代码变更有没有审核	核心模块的代码修改，必须两个人审核通过才能提交，提交记录里要写清楚修改原因
依赖管理	25	依赖包有没有扫过漏洞	用 OWASP Dependency-Check 这类工具扫依赖包，高危漏洞（CVSS 评分≥9.0）要立即修复
...	26-45	（含代码测试、文档安全、分支管理等 19 项）	比如代码要写单元测试，敏感文档不能外传，分支管理要按规范（别直接在主分支改代码）等

（四）部署运行安全模块（35 项）

算法上线后不是万事大吉，运行过程中的安全更要盯紧，这部分重点查 35 项：

核查维度	序号	核查项	具体要求	核查结果（√通过 /× 不通过 /○待核查）
运行环境	26	容器配置有没有风险	容器禁用特权模式，限制容器能访问的资源（比如 CPU、内存），避免容器被攻击后影响整机
	27	服务器有没有加固	没用的端口要关掉，防火墙、IDS 入侵检测系统要开启，定期打系统补丁
访问控制	28	API 接口有没有鉴权	接口必须用 Token 或 OAuth2.0 鉴权，不能有不需要登录就能访问的匿名接口
	29	有没有做访问频率限制	单个 IP 每天调用接口不能超过 1000 次（可根据业务调整），防止有人发起 DoS 攻击
监控审计	30	运行日志有没有记录全	要记清楚谁调用了接口、什么时候调用的、输入输出的关键信息，日志至少保存 6 个月
	31	异常行为能不能及时告警	比如接口高频调用失败、输入数据异常，要在 10 分钟内触发告警（邮件或钉钉通知）
应急响应	32	故障恢复有没有预案	万一模型服务断了，要能在 30 分钟内切换到备用节点，别影响业务使用
	33	安全事件能不能及时处置	如果发生数据泄露，要在 2 小时内上报安全部门，按预案处理（比如封禁账号、清理数据）
...	34-65	（含灾备方案、补丁更新、权限回收等 29 项）	比如要定期做灾备演练，系统补丁每月更新，员工离职后要及时回收系统权限等

（五）合规性模块（30 项）

法规是底线，这部分重点查 30 项合规要求，确保算法应用不踩红线：

核查维度	序号	核查项	具体要求	核查结果（√通过 /× 不通过 /○待核查）
法规遵循	34	个人信息处理合不合规	严格按《个保法》第 13 条来，处理个人信息必须有合法理由（比如用户同意、履行合同等）
	35	数据分类分级有没有做	按《数据安全法》第 21 条，把核心数据、重要数据定级，不同级别数据按要求防护
算法备案	36	该备案的算法有没有备案	推荐算法、排序算法、风控算法这些需要备案的，要在网信部门完成备案
	37	备案信息跟实际部署一致吗	备案时填的算法逻辑、应用场景，要跟线上实际运行的一致，不能备案一套、实际用另一套
审计追溯	38	安全审计记录有没有留存	每年要做算法安全审计，审计报告（包括发现的问题和整改情况）要保存好
	39	用户能不能查、删算法相关数据	按《个保法》要求，用户要查自己的算法决策数据（比如为什么被拒贷）、要删除数据，得支持
...	40-70	（含跨境数据、伦理审查、投诉处理等 29 项）	比如跨境传输数据要走安全评估，算法要过伦理审查，用户投诉要在 15 天内回复等

三、Checklist 怎么用？（实操指南）

光有清单不够，得知道怎么落地，这里给大家整理了具体用法：

1. 多久查一次？

月度自查：不用全查，重点盯高频风险项 —— 比如数据加密有没有失效、API 接口鉴权有没有问题，花 1-2 小时就能搞定；

季度全面核查：160 项指标全部过一遍，每一项都要确认，最后形成核查报告（注明通过项、不通过项、整改计划）；

专项核查：重大版本更新前、新业务上线前，额外查一次相关模块（比如新业务用到医疗数据，就重点查数据安全和合规性）。

2. 查到问题怎么改？（5 步整改流程）

标记问题：在 Checklist 里把 “不通过” 的项标出来，写清楚问题具体是什么（比如 “依赖包有 2 个高危漏洞未修复”）；

找根因：别只看表面，要挖根本原因 —— 比如 “依赖包漏洞” 可能是因为没定期扫描，而不是忘了修复；

定方案：针对根因出整改方案，要明确谁来改、什么时候改完 —— 比如 “每周五下午用 OWASP 工具扫依赖包，高危漏洞 24 小时内修复，由开发组长负责”；

验结果：整改完要重新核查，确认问题解决 —— 比如漏洞修复后，再扫一次确认没有高危漏洞；

存记录：把核查表、整改方案、验证结果都归档，万一后续有审计，能拿出来证明。

3. 指标能自己调吗？

当然可以，不同行业、不同技术场景，风险点不一样，大家可以这么调整：

按行业加指标：做金融的可以加 “反欺诈算法合规性核查”，做医疗的加 “病历数据隐私保护专项核查”；

按技术加指标：如果用生成式 AI，要加 “prompt 注入防护核查”“生成内容合规性检查”；

按业务减指标：如果算法不用跨境数据，“跨境数据合规” 相关的指标就可以暂时不用查。

四、实操案例：遇到问题怎么处理？

给大家举个真实案例，方便理解怎么用 Checklist 解决问题：

问题：模型训练数据没做去标识化

核查结果：× 不通过（对应数据安全模块第 5 项）；

实际情况：采集了一批医疗数据，直接用来训练模型，数据里还留着患者的完整身份证号；

根因分析：数据预处理时忘了做去标识化，也没人做数据抽检；

整改方案：用差分隐私工具脱敏身份证号（只留前 6 位和后 4 位，中间用 * 代替），以后预处理完要抽样 10% 检查；

验证过程：脱敏后抽 100 条数据，人工看有没有完整身份证号，再用隐私计算工具测脱敏合规性；

归档记录：把脱敏前的数据样本、脱敏后的样本、工具检测报告，都存在项目的安全文件夹里。

五、最后说两句

这 160 项指标覆盖了算法从数据采集到模型退役的全生命周期风险，不是说要大家花很多时间去查，而是要把核查变成日常工作的一部分 —— 写代码时想想有没有漏洞，部署前看看有没有合规风险，慢慢就成习惯了。

技术在变，风险也在变，大家要定期更新 Checklist，别让指标过时。毕竟安全不是一次性的事，而是持续优化的过程，只有把每一个小风险都堵住，算法应用才能走得稳、走得远。

截屏，微信识别二维码

微信号：18148905161

（点击微信号复制，添加好友）

打开微信

关于我们

新闻中心

算法工程师安全自评估 160 项指标逐行核查 Checklist