了解源代码审计服务
以确定的代码版本、模块边界和业务规则为起点，结合静态分析与人工审查核对安全缺陷。将有效发现关联到调用路径、文件位置和触发条件，并根据更新版本复核修复，说明缺失依赖及运行验证的限制。
源代码审计是什么？
源代码审计（Code Review）是由具备丰富编码经验并对安全编码原则及应用安全具有深刻理解的安全服务人员对系统的源代码和软件架构的安全性、可靠性进行全面的安全检查。
源代码审计服务的目的在于充分挖掘当前代码中存在的安全缺陷以及规范性缺陷，从而让开发人员了解其开发的应用系统可能会面临的威胁，并指导开发人员正确修复程序缺陷。
CMA / CNAS / CCRC
CMA
检验检测机构资质认定
CNAS
实验室认可
CCRC
信息安全风险评估服务资质
公司资质展示，适用范围按证书及项目核对。
我们会做什么
从需求与范围确认，到实施验证与资料交付，具体安排结合项目情况确认。
01
锁定版本与模块
确认仓库或代码包的版本标识、语言框架与模块边界，说明自研代码、外部依赖和实际部署版本之间的对应关系。
02
梳理架构与数据流
准备构建说明及关键业务规则，标记鉴权、文件处理和数据查询等敏感入口，核对缺失依赖对审计范围的影响。
03
分析线索与可达性
结合静态分析和人工审查，沿输入来源、调用链及异常分支核对缺陷，区分工具提示与具备证据的安全发现。
04
定位问题与修复项
记录文件位置、受影响版本、触发条件和修复建议，分别说明依赖更新、配置调整与代码修改所需处理的内容。
05
更新版本复核交付
根据约定在修复版本核对原问题及类似代码路径，保留版本差异与未验证事项，交付可用于开发整改的审计结果。
服 务 内 容
Service content
系统所用开源框架
包括反序列化漏洞，远程代码执行漏洞，spring、struts2安全漏洞，PHP安全漏洞等
应用代码关注要素
日志伪造漏洞，密码明文存储，资源管理，调试程序残留，二次注入，反序列化。
API滥用
不安全的数据库调用、随机数创建、内存管理调用、字符串操作，危险的系统方法调用。
错误处理不当
程序异常处理、返回值用法、空指针、日志记录。
源代码设计
不安全的域、方法、类修饰符未使用的外部引用、代码。
直接对象引用
直接引用数据库中的数据、文件系统、内存空间。
资源滥用
不安全的文件创建／修改／删除，竞争冲突，内存泄漏。
业务逻辑错误
欺骗密码找回功能，规避交易限制,越权缺陷Cookies和session的问题。
规范性权限配置
数据库配置规范，Web服务的权限配置SQL语句编写规范。
哪些情况需要源代码审计服务
关键模块发布审查
鉴权、文件处理或数据访问模块发生变更时，围绕改动及相关调用链核对安全缺陷，明确本次提供代码的覆盖范围。
依赖框架风险排查
软件使用开源框架或外部依赖时，结合版本和实际调用方式审查风险，避免仅凭组件名称判断漏洞是否能够触发。
开发整改闭环复核
开发团队收到审计发现后，将代码修复、配置修改与依赖升级分开记录，在相应版本复核问题及相邻处理路径。
服务重点
先锁定代码与业务范围：提交仓库或约定代码包的版本标识、模块边界、语言框架、构建说明及关键数据流。
关注缺陷是否真正可达：静态分析能够提供线索，人工审查需结合输入来源、调用链、权限判断和异常分支判断是否形成风险。
把修复送回开发流程：发现宜关联文件位置、受影响版本、触发条件与修复建议；整改后在更新版本复核，并检查类似代码路径。
源代码审计与模糊测试区别
在漏洞挖掘过程中有两种重要的漏洞挖掘技术，分别是源代码审计和模糊测试。源代码审计是通过静态分析程序源代码，找出代码中存在的安全性问题；而模糊测试则需要将测试代码执行起来，然后通过构造各种类型的数据来判断代码对数据的处理是否正常，以发现代码中存在的安全性问题。
企业做代码审计带来的好处！
明确安全隐患点
可以从整套源码切入最终明确至某个威胁点并加以验证
提高安全意识
有效督促管理人员杜绝任何一处小的缺陷，从而降低整体风险
提升开发人员安全技能
通过审计报告，以及安全人员与开发人员的沟通，开发人员更好地完善代码安全开发规范
我 们 的 服 务 特 点
降低成本，节省投资
在格修科技为客户打造的年度服务方案中，服务人员第一次源代码审计的结果将会成为后续审计服务的参考依据，避免了单次服务中每次都会为某一特定问题所累，节省了审计时间，同时也降低了客户在每个阶段的投入。
专家级解决方案，一切以解决问题为目标
格修科技有着专业的安全服务团队，团队成员无论是在风险评估、安全加固、渗透测试，还是在源代码审计等领域均有着丰富的经验，所有问题的解决方案均由团队成员根据多年经验总结而来，方案确实可行。
全程化服务，有效保证服务质量
格修科技可以为客户提供约定期限内的全程化源代码审计服务。服务的过程不仅仅是帮助客户发现问题，也会为客户的问题修补提供专业的建议和指导，做到问题发现、修补、验证的全程跟踪，每一次服务都会在前一次的基础上寻找新的突破口，力求最大程度地保证审计目标的安全。
先锁定代码与业务范围
提交仓库或约定代码包的版本标识、模块边界、语言框架、构建说明及关键数据流。说明哪些代码自研、哪些来自依赖或外部服务，以及鉴权、文件处理、数据查询等敏感入口。代码、部署配置与实际运行版本不一致时，应先标明差异。
关注缺陷是否真正可达
静态分析能够提供线索，人工审查需结合输入来源、调用链、权限判断和异常分支判断是否形成风险。对关键业务规则可与运行态验证配合；没有构建环境或外部依赖时，明确哪些结论仅来自静态分析，避免把所有工具提示直接列为可利用漏洞。
把修复送回开发流程
发现宜关联文件位置、受影响版本、触发条件与修复建议；整改后在更新版本复核，并检查类似代码路径。依赖更新、配置调整和代码修复应分别记录。源代码审计不能替代全部上线检查，运行环境和业务配置仍需验证。
常见问题
只提供部分代码可以审计吗？
可以先限定范围，但调用链、公共鉴权或配置缺失可能影响判断。应列明提供的模块与缺失依赖，把局部结论限定在对应范围内。
是否需要提交生产密钥？
不应把生产密钥作为常规审计材料。使用受控访问、脱敏配置和专门测试凭据满足验证需求，材料传递与留存方式需预先约定。
