五类定制软件如何进行代码审核?

在进行如何进行代码审核的话题之前我们可以先聊聊我们为啥要进行代码审核，除了法规、指南的强制要求以外，还有更为重要的一些因素。

1.代码是系统逻辑的本源，界面操作、权限设置、审计追踪、内部功能等都是代码写出来的。

只有审核源代码，才能确认：审计追踪是否真实开启、能否关闭、能否删除、能否后台篡改数据、才能确认：数据修改、删除、审批逻辑是否合规，是否存在后台绕过前端校验、直接修改数据库的漏洞。前端可以伪装合规，但代码底层逻辑骗不了监管。代码审核是验证数据完整性最根本、最有效的手段，没有代码审核，数据完整性承诺全部无效。

2.制药行业定制软件核心控制点在于生产工艺参数、批记录、检验结果、批放行、物料管理、偏差 OOS/OOT 等。代码审核可发现：工艺参数逻辑漏洞、步骤可跳过、放行逻辑宽松、数值可篡改、边界校验缺失等质量风险。避免开发人员无意编写错误逻辑、逻辑缺陷导致产品质量失控、批记录失真、放行误判。从源头保证系统执行逻辑完全符合 URS、GXP要求，而非开发随意编写。

3.定制软件最容易出现监管严查问题，如：

硬编码管理员密码

开发后门账号、隐藏超级权限

后台万能修改接口

数据库账号密码明文写在代码里代码审核是唯一能彻底发现后门、隐藏权限、违规账号的手段。不做代码审核，企业完全不知道系统后台是否有违规入口，存在巨大质量与安全风险。

4.进行代码审核可验证：代码实现逻辑↔ URS需求 ↔ FS功能规范↔ DS 设计规范双向可追溯。防止开发私自增加未授权功能、调试接口、隐藏操作、偏离GXP管控要求。确保系统只做法规允许的事，不做法规禁止的事。

5.GXP核心原则：职责分离、相互监督。代码审核由非开发人员（验证、IT、QA）独立执行，开发不得审核自身代码。重要性：防止开发人员自行修改逻辑、掩盖缺陷、规避管控，形成有效制衡，满足GXP独立复核原则。当然有时候验证、IT、QA没有进行代码审核的资质或者能力，那也不得不依靠开发人员的协助，但是有一点需要明确的就是，代码审核的时候，验证/IT/QA需有人参与，确保代码审核的合规性、有效性。

6.GAMP5 明确要求：源代码审核通过才能进入集成测试、才能开展系统验证，才能上线使用。未代码审核直接上线验证，验证结果无效，监管不予认可。

7.当出现数据异常、质量偏差、监管核查时：源代码+代码审核记录是最原始、最有力的举证资料，可证明系统逻辑合规、无篡改漏洞、开发受控，制药企业可自证清白。无代码审核，出现问题企业无法举证，直接承担全部质量责任。

读完上面的内容，大家应该知道了代码审核的必要性和重要性，接着我们开始今天的主题，那就是如何进行代码审核以及代码审核报告需要包含哪些内容。

代码审核第一步：明确前提

1.适用对象：5类定制开发软件（自研/外包定制、源代码可控）

2.审核原则：风险越高审核越严；独立审核；开发≠审核；双向可追溯；审核留痕；不通过禁止上线

3.审核内容：源代码逻辑、数据完整性 ALCOA+、权限、审计追踪、校验、异常处理、后门、硬编码账号密码、变更可控等

第二步：审核启动准备

1.项经理发起代码审核申请

2.确定审核范围：按风险分级

高风险（批放行、生产控制、LIMS、数据修改、权限管理、审计追踪模块）：100% 全量源代码审核

中风险：核心逻辑全审，辅助功能抽样审核

低风险：抽样审核

3.组建审核小组（强制独立）

开发人员：不得担任审核人（回避原则）（审核人员无能力、资质进行审核时，开发人员需要进行协助）

审核人员：QA+IT+业务用户/验证工程师（必须非开发）

审核人员需要进行培训，确保核人员理解了代码审核的概念、代码审核流程、以及是否理解了代码审核内容。

4.准备审核依据文件：用户需求–URS、功能规范–FS、设计规范–DS、编码规范、数据完整性要求、变更记录、版本基线

5.锁定代码基线：打版本 Tag，冻结代码，审核期间禁止私自改代码

GAMP5 要求：代码必须是已提交、版本受控、基线固化版本，不能审开发中途草稿代码。

第三步：源代码正式审核

审核人按照固定检查表逐项审核，逐项记录，不是随便浏览。常规制药代码审核检查项：

需求可追溯：代码逻辑是否完全符合 URS/FS/DS，无额外未授权功能

数据完整性：数据是否不可篡改、写入是否校验、删除 / 修改是否留痕

审计追踪实现：是否自动记录、不可关闭、不可修改、时间正确

权限控制：分级权限、越权判断、会话超时、退出控制

安全合规：无硬编码账号密码、无后门、无隐藏管理员、输入防注入

异常处理：报错合理、不会崩溃、不会绕过校验直接保存数据

编码规范：命名、注释、版本一致、无废弃注释代码、无测试遗留代码

电子签名：符合 21CFR Part11，签名关联操作、不可复用、不可抵赖

审核输出：代码审核检查表（每一行模块/每一个文件都有审核结论：符合/不符合/建议修改），代码审核检查表见附件1。

第四步：问题判定与整改

1.审核人对问题分级（GXP风险分级）

严重缺陷（高危）：破坏数据完整性、绕过审计追踪、权限漏洞、后门，禁止通过，必须整改重审

主要缺陷：逻辑不符合需求、硬编码、测试代码残留，整改完成重新全量审核

一般缺陷：格式、注释不规范，整改即可，无需全面重审

2.开发针对问题提交整改方案+整改记录

3.QA 复核整改内容，确认代码已更新、重新打新版本基线，审核人二次复核（回归审核），确认问题全部关闭

第五步：审核批准、放行

1.审核人签署《源代码审核报告》（CRR），结论：源代码审核通过，同意进入集成测试/验证阶段

2.QA 最终批准放行

第六步：上线后变更代码审核

这里有一个误区，那就是：代码审核是不是首次软件开发进行即可，后续无需在进行？答案肯定是错的。软件上线后任何代码变更（补丁、升级、功能修改）：都需要发起变更控制（CC）、

、对变更涉及的代码片段重新审核、回归审核/批准/更新基线/更新归档文档、未经代码审核的变更，严禁上线执行。

附件1：代码审核表

软件名称：

版本号：

风险等级：□ 高 □ 中 □ 

低审核日期：

审核人：

开发负责人：

QA 批准人：

一、代码基线与版本控制

1.代码已建立明确版本基线，审核期间未被修改？

2.代码纳入版本管理（Git/SVN），提交记录可追溯？

3.无未授权分支、未合并代码、临时调试代码？

4.所有变更均有变更控制单号（CC）关联？

5.源代码与设计文档（DS/FS）版本一致？

二、需求可追溯性

1.代码实现完全对应 URS/FS/DS 需求，无超范围功能？

2.每个功能模块均可追溯到需求条目？

3.无隐藏功能、后门、调试入口？

4.无未定义的自动执行逻辑？

5.业务逻辑与用户需求一致，无逻辑偏差？

三、数据完整性（ALCOA+）

1.数据写入前有校验，不允许空值 / 非法值直接入库？

2.关键数据不可随意修改 / 删除，修改必须留痕？

3.时间戳准确、不可篡改、不可回写？

4.数据存储采用防篡改机制（如加密、只读权限）？

5.无直接 SQL 拼接，防止注入与数据篡改？

6.日志 / 审计记录与业务数据不可分离？

7.数据导入 / 导出有校验与权限控制？

四、审计追踪（Audit Trail）

1.系统自动记录：何人、何时、何事、何地、修改前后值？

2.审计日志不可关闭、不可删除、不可清空？

3.审计日志存储独立、防篡改、权限受控？

4.关键操作（修改、删除、审批、放行）均被记录？

5.时间来源可靠（无客户端篡改可能）？

五、权限与访问控制

1.采用基于角色的权限（RBAC），权限最小化？

2.关键功能（审批、修改、删除）需二次权限判断？

3.密码强度、过期策略、锁定策略在代码中实现？

4.会话超时有效，防止未授权访问？

5.无越权漏洞（水平越权、垂直越权）？

6.管理员账户不可匿名、不可硬编码、不可共享？

六、电子签名（如适用 21CFR Part11）

1.电子签名与操作强绑定，不可复用？

2.签名包含：用户名、时间、意义、操作内容？

3.签名不可伪造、不可篡改、不可撤销？

4.签名逻辑不依赖客户端可控参数？

七、安全与漏洞

1.无硬编码密码、密钥、Token、连接串？

2.无测试账号、后门账号、万能密码？

3.输入参数校验完整，防注入、XSS、文件上传漏洞？

4.敏感信息传输加密（HTTPS/TLS）？

5.无调试信息、堆栈信息暴露给用户？

6.无本地可篡改的配置文件？

八、异常处理与稳定性

1.异常捕获完整，不崩溃、不丢失数据？

2.错误提示安全，不泄露系统结构？

3.事务处理正确，失败可回滚，不产生脏数据？

4.边界值、极端情况处理完善？

5.无死循环、无内存泄漏、无资源未释放？

九、编码规范

1.代码符合内部编码规范？

2.命名规范、注释清晰、关键逻辑有说明？

3.无废弃代码、注释代码、调试代码？

4.无冗余、无用、未调用函数？

5.日志规范，不记录敏感信息（密码等）？

十、批记录 / 生产相关逻辑（如适用）

1.批处方、工艺参数不可随意修改？

2.批记录自动生成，不可人为跳过？

3.关键步骤不可跳过、不可逆向执行？

4.批放行逻辑严格，无漏洞可绕过？

十一参考文件

序号	文件
[1]	GAMP 5A Risk-Based Approach to Compliant GxP Computerized Systems Second Edition
[2]	IS0 9001：2015，质量管理体系
[3]	IEEE-Std-730-1998, IEEE Standard for Software Quality Assurance Plans, June 1998.
[4]	IEEE-Std-730.1-1995, IEEE Guide for Software Quality Assurance Planning, December 1995.
[5]	IEEE Std 610.12－1990（R2002），IEEE Standard Glossary of Software Engineering Terminology, September 2002.
[6]	IEC 62279, Railway applications – Communications, signaling and processing systems – Software for railway control and protection systems, September 2002.
[7]	GB/T 16260-2006/ISO/IEC 9126:2001，软件工程 产品质量
[8]	ISO/IEC 90003, Software engineering- Guidelines for the application of ISO 9001:2000 to computer software, February 2004.

十二、审核结论

□ 全部通过，允许进入测试 / 验证

□ 存在一般缺陷，整改后无需重审

□ 存在主要缺陷，整改后需重新审核

□ 存在严重缺陷，禁止上线，必须全面重审

严重缺陷描述：

整改要求：

开发人员签字：

审核人签字：

QA 批准签字：