应用安全检查评估办法

应用安全检查评估办法第一章总则第一条目的与依据为加强公司信息系统应用安全管理，规范应用系统开发生命周期中的安全检查与评估工作，识别并消除潜在的安全风险，保障业务系统的连续性、完整性及保密性，依据《中华人民共和国网络安全法》、《中华人民共和国数据安全法》、《个人信息保护法》及行业监管相关规定，结合公司实际情况，制定本办法。第二条适用范围本办法适用于公司各部门、各分支机构（以下统称“各单位”）所有自主建设、外包开发、采购的商业软件以及开源组件的应用安全检查评估活动。涵盖从需求分析、设计、开发、测试、上线运行直至下线废弃的全生命周期过程。第三条基本原则（一）谁主管谁负责，谁运营谁负责，谁使用谁负责：各单位对本单位负责的应用系统安全承担主体责任。（二）预防为主，防控结合：坚持安全左移，将安全检查评估前移至开发阶段，尽早发现并修复安全隐患。（三）客观公正，科学规范：采用标准化的评估方法、工具和流程，确保评估结果的准确性和可重复性。（四）动态管理，持续改进：根据业务发展和技术演进，定期修订评估标准，持续优化安全防护体系。第四条术语定义（一）应用安全检查评估：指通过人工审查、工具扫描、渗透测试等手段，对应用系统的代码、功能、逻辑、数据交互等方面进行的安全性检测与评价活动。（二）静态应用程序安全测试（SAST）：指在应用程序不运行的状态下，通过分析源代码或二进制文件来发现安全漏洞的技术。（三）动态应用程序安全测试（DAST）：指在应用程序运行的状态下，通过模拟外部攻击者的行为对应用进行黑盒测试的技术。（四）交互式应用程序安全测试（IAST）：指在应用程序运行过程中，通过插桩代理监控代码执行与数据流，结合SAST和DAST优势的检测技术。（五）软件成分分析（SCA）：指对应用程序中引入的第三方开源组件、商业库等进行识别，分析其版本信息及已知漏洞的技术。第二章组织架构与职责分工第五条信息安全管理部门职责信息安全管理部门是应用安全检查评估的归口管理机构，主要履行以下职责：（一）制定、修订并发布应用安全检查评估相关制度、技术标准和操作规范。（二）负责建设、维护应用安全检查评估所需的工具平台及测试环境。（三）统筹组织年度及专项应用安全检查评估计划，并对计划执行情况进行监督。（四）负责对核心及重要应用系统进行安全评估，或委托第三方专业机构进行评估。（五）汇总评估结果，出具安全评估报告，并跟踪整改情况。（六）对各单位的整改落实情况进行考核评价。第六条应用系统主管部门职责应用系统主管部门（即业务归属部门）是安全整改的第一责任人，主要履行以下职责：（一）发起本部门应用系统的安全检查评估申请，配合评估团队开展测试工作。（二）提供评估所需的系统资料、测试账号、网络环境及必要的权限支持。（三）根据评估报告组织开发团队或供应商进行安全漏洞修复和整改。（四）在规定时间内完成整改并向信息安全管理部门申请复测。（五）对于无法立即修复的漏洞，制定并落实临时防护措施及整改计划。第七条应用系统开发与运维部门职责（一）在开发阶段集成安全编码规范，配合进行代码安全审计。（二）负责整改阶段的技术实施，包括代码修改、配置加固及版本更新。（三）配合评估团队验证漏洞修复的有效性。（四）在运维阶段定期进行巡检，发现异常及时上报。第三章评估分类与适用场景第八条评估类型划分应用安全检查评估分为以下几类：（一）上线前安全评估：指新建、重构或发生重大变更的应用系统在正式上线投产前必须进行的安全评估。（二）定期安全评估：指按照年度计划，对已上线运行的应用系统进行的常规性全面安全体检。（三）专项安全评估：指针对特定安全威胁（如勒索病毒、Log4j漏洞等）、特定时间段（如重大节假日、攻防演练期间）或特定监管要求开展的临时性评估。（四）应急安全评估：指在发生安全事件、系统异常或接收到外部安全通报后，为查明原因、定位风险而开展的紧急评估。第九条评估触发条件（一）符合以下情形之一的，必须进行上线前安全评估：1.所有面向互联网提供服务的应用系统。2.处理敏感个人信息、重要数据或关键业务逻辑的应用系统。3.涉及资金交易、用户权限管理的核心应用系统。4.架构发生重大变更或功能模块新增超过30%的系统。（二）符合以下情形之一的，应当开展专项或应急安全评估：1.监管部门通报存在安全隐患的。2.在外部攻防演练、漏洞众测中被发现存在高危漏洞的。3.应用系统使用的第三方组件被披露存在严重安全漏洞的。4.发生疑似入侵、数据泄露等安全事件的。第四章安全检查技术标准与规范第十条代码安全审计标准代码安全审计应重点关注以下内容，并遵循《安全编码规范》：（一）输入验证：检查是否对所有来自用户不可信的输入（包括表单、URL参数、Cookie、Header等）进行了严格的类型、长度、格式和范围校验，是否存在过滤绕过风险。（二）输出编码：检查是否对输出到浏览器、数据库、操作系统的动态内容进行了适当的编码，防止跨站脚本攻击（XSS）、SQL注入、命令注入等。（三）身份认证与会话管理：检查密码复杂度策略、登录失败处理机制、会话超时设置、会话标识符生成随机性及是否固定，是否存在多因素认证缺失或弱实现。（四）访问控制：检查是否存在越权访问，包括水平越权（访问同级用户数据）和垂直越权（低权限用户访问高权限功能），以及是否默认拒绝原则。（五）加密与敏感数据保护：检查是否使用强加密算法（禁止使用MD5、SHA1、DES等弱算法），密钥存储是否安全，敏感数据（如身份证号、密码）在日志中是否脱敏。（六）错误处理：检查是否为用户展示了过于详细的堆栈跟踪或错误信息，防止信息泄露。（七）API安全：检查API接口是否进行身份认证、权限校验、速率限制及输入过滤。第十一条漏洞扫描与渗透测试标准（一）扫描覆盖率：漏洞扫描应覆盖应用系统的所有Web页面、API接口及移动端服务接口。（二）测试深度：渗透测试应至少涵盖OWASPTop10漏洞类别，包括但不限于注入类漏洞、失效的访问控制、安全配置错误、组件漏洞等。（三）业务逻辑测试：除常规技术漏洞外，必须结合业务场景进行逻辑漏洞测试，如：1.金额篡改：在支付、转账、充值环节是否存在金额参数篡改。2.竞态条件：高并发场景下的库存超卖、优惠券重复使用等问题。3.任意文件操作：文件上传、下载、读取路径是否存在遍历风险。4.验证码绕过：验证码是否可复用、可回溯或通过OCR识别。5.密码重置：密码找回链接是否可预测，是否存在逻辑跳转。第十二条第三方组件安全标准（一）组件清单管理：应用系统必须建立完整的第三方组件清单（SBOM），包括组件名称、版本号、来源、许可证类型及用途。（二）漏洞匹配：通过SCA工具检测组件是否存在已知的高危和中危漏洞（CVE）。（三）维护策略：禁止使用已停止维护（EOL）的第三方组件；对于存在已知漏洞的组件，必须升级到修复版本或采取缓解措施。第十三条配置安全核查标准（一）服务器配置：检查应用服务器（如Nginx,Apache,Tomcat）、中间件及数据库的配置安全性，包括关闭不必要的端口和服务、隐藏版本号、禁用不安全的HTTP方法（如PUT、DELETE）等。（二）安全头设置：检查是否配置了必要的安全HTTP响应头，如：1.Strict-Transport-Security(HSTS)：强制使用HTTPS。2.X-Content-Type-Options:nosniff：防止MIME类型嗅探。3.Content-Security-Policy(CSP)：定义资源加载策略，防止XSS。4.X-Frame-Options：防止点击劫持。（三）HTTPS配置：检查是否全站强制启用HTTPS，TLS版本是否为1.2及以上，加密套件配置是否安全，证书是否有效。第五章评估实施全流程管理第十四条评估准备阶段（一）评估申请：需求单位填写《应用安全评估申请单》，明确评估范围、目标系统URL/IP、测试环境、联系人及系统基础信息。（二）资料提交：需求单位需提供《系统设计说明书》、《系统架构图》、《API接口文档》、测试账号（包括不同权限角色的账号）及特殊功能说明。（三）方案编制：评估团队根据申请资料编制《安全评估实施方案》，明确评估目标、范围、工具、方法、时间进度及风险规避措施。（四）方案审批：实施方案由信息安全管理部门负责人及相关业务负责人审批通过后方可执行。第十五条评估执行阶段（一）环境确认：评估团队在测试环境中部署扫描工具或人工测试环境，确认网络连通性及账号可用性。严禁在生产环境直接进行具有破坏性的测试（如DoS攻击、数据库删除操作）。（二）静态分析：使用SAST工具对源代码进行扫描，识别代码层面的逻辑缺陷和编码规范问题。（三）动态扫描：使用DAST工具对运行中的应用进行爬虫和漏洞扫描，获取初步漏洞列表。（四）组件分析：使用SCA工具对第三方依赖库进行版本核查和漏洞匹配。（五）人工渗透：高级安全工程师对自动化工具扫描的结果进行验证，剔除误报，并针对业务逻辑漏洞进行深度挖掘。（六）日志收集：在测试过程中，收集应用服务器及WAF（Web应用防火墙）日志，分析异常请求。第十六条评估报告阶段（一）结果整理：评估团队汇总自动化扫描和人工测试结果，对漏洞进行去重、分级和关联分析。（二）风险评级：根据漏洞的被利用难度、影响范围和数据敏感程度对风险进行评级（详见第六章）。（三）报告编制：编制《应用安全检查评估报告》，报告应包含：1.评估概述：目标、范围、时间、方法。2.系统概况：架构、技术栈、功能模块。3.漏洞详情：漏洞名称、类型、风险等级、受影响URL/文件、复现步骤、修复建议、截图证明。4.统计分析：漏洞数量分布、高危风险占比、趋势对比。5.总体评价：系统安全现状评分及合规性结论。（四）报告评审：报告由技术负责人审核，确保描述准确、建议可行。第十七条结果通报与整改阶段（一）报告发送：评估报告经审批后，通过安全邮件或内部加密平台发送给需求单位负责人及开发团队负责人。（二）及整改通知：对于存在高危及以上漏洞的系统，信息安全管理部门下发《安全隐患整改通知书》，明确整改截止日期。（三）整改实施：需求单位组织开发人员进行漏洞修复。对于无法立即修复的漏洞，需提交《风险缓释计划》，说明临时防护措施及最终整改时间表。（四）整改验证：整改完成后，需求单位提交《复测申请》。评估团队对已修复的漏洞进行回归测试，确认漏洞已修复且未引入新问题。第六章漏洞分级与整改闭环机制第十八条漏洞分级标准参照CVSS（通用漏洞评分系统）及行业实践，将漏洞风险划分为四个等级：风险等级评分范围(CVSS)定义描述典型示例严重(Critical)9.0-10.0攻击者无需权限或仅需低权限即可获取服务器控制权、核心数据或造成业务大面积中断。SQL注入导致GetShell、未授权访问导致RCE、反序列化漏洞、弱口令导致后台接管。高危(High)7.0-8.9攻击者可获取敏感数据、篡改关键数据或对业务造成较大影响。存储型XSS、越权访问（获取敏感信息）、核心业务逻辑漏洞（如金额篡改）、无回显的命令执行、敏感信息明文传输。中危(Medium)4.0-6.9攻击者对系统局部产生影响，需结合其他条件或特定场景方可利用。反射型XSS、CSRF、目录遍历、信息泄露（版本号、堆栈）、错误的会话管理。低危(Low)0.1-3.9影响范围极小，利用难度大，或仅造成轻微信息泄露。缺少安全头、Clickjacking风险、低版本SSL/TLS支持、调试信息泄露。第十九条整改时限要求为确保风险及时消除，各类漏洞整改时限要求如下：漏洞等级整改时限特殊情况说明严重24小时内必须立即采取临时阻断措施（如关停服务、封禁接口），直至修复完成。高危3个工作日涉及架构调整或需依赖供应商修复的，可申请延期至7个工作日，需经分管领导审批。中危10个工作日版本迭代周期内修复完毕。低危下个版本发布前最长不超过30天。第二十条闭环管理机制（一）台账管理：信息安全管理部门建立统一的《应用安全漏洞管理台账》，记录漏洞发现、整改、复测全过程状态。（二）延期管理：确因技术困难或业务原因无法在规定时限内完成整改的，需求单位需提前2个工作日提交《整改延期申请表》，说明原因及后续计划，经信息安全管理部门审批后方可延期。（三）漏洞挂起：对于因环境依赖、第三方厂商未发布补丁等原因暂时无法修复的漏洞，经评估后可列入“挂起”列表，但必须每季度进行一次复审，一旦条件具备立即启动整改。（四）复核验证：整改验证必须包含回归测试，确保修复方案有效且未引发副作用。验证通过后，更新台账状态为“已修复”。第七章工具平台与自动化要求第二十一条工具链建设公司应建立完善的DevSecOps工具链，支持自动化安全检查：（一）代码审计平台：集成主流SAST工具（如SonarQube,Fortify），支持多语言源代码分析，并与CI/CD流水线集成。（二）漏洞扫描平台：部署企业级DAST工具（如AWVS,BurpSuiteProfessional），支持主动扫描和爬虫配置。（三）组件检测平台：部署SCA工具（如Snyk,BlackDuck），实时监控开源组件漏洞。（四）交互式扫描平台：在测试环境部署IASTAgent，实现运行时数据流分析。第二十二条CI/CD集成要求（一）构建阶段：在代码编译阶段自动触发SAST扫描，对代码规范和基础漏洞进行检测。扫描失败率超过阈值（如5%）应阻断流水线。（二）测试阶段：在应用部署到测试环境后，自动触发DAST扫描和SCA分析。（三）卡点设置：对于上线发布流程，设置“安全门禁”。存在严重或高危漏洞的系统，严禁通过发布审批。第二十三条工具使用规范（一）账号管理：工具平台应实施统一身份