企业内部安全漏洞修复流程的建立与思考

云下信安 2025-05-23 07:25

最近因为工作问题，一直在与企业内部的漏洞修复进行跟进，针对企业内部修复有一些自己的见解 。

笔者根据自己在漏洞修复的具体参与工作，针对这些工作，给出具体实施的时候存在的一些注意事项（偏向具体实施），以及自己的一些心得感受和对安全从业人员的技术要求（踩过不少坑）。

1.漏洞发现与接收

1.1 内部漏洞扫描工具

1.1.1工具类型

开源如Nessus、AWVS、Xray（开源版）

商业版如各个厂商的扫描器（包括硬件、软件）这里笔者就不细说了，但是需要注意，有的单位存在信创改造要求，常用的漏扫设备对信创系统的漏洞扫描存在差异性，这个时候需要通过渠道获取信创版本的漏洞扫描器（精进要求）

1.1.2注意事项

1.注意漏扫软件的来源，小心下载带有恶意文件的扫描器。

2.及时关注购买的扫描器的维保时间和许可时间，提前准备好续费或更换的要求。

3.笔者目前没经历过，但是有朋友经历，使用国外扫描器时，可能过了免费试用期，通过破解或其他渠道，继续使用，扫描器厂商发现未授权使用扫描器，直接对公司的公共邮箱发送律师函。

4.具体扫描时需要注意扫描时间，同时不要影响到具体的业务连续，像AWVS在扫描时会有大量数据包，可能会导致服务器宕机，这点需要注意，具体扫描时间和扫描频率需要根据业务量、服务器承载效果进行综合判断。

5.具体实施的注意事项见
1.2渗透测试
。

1.2 渗透测试/代码审计（内部人员进行/外部厂商进行）

1.2.1 渗透测试

这里不讨论具体渗透测试的细节，讨论渗透测试的具体实施流程。

相关单位针对内部渗透测试一般有如下需求：

1.计划性渗透测试

针对不同环境【办公网、业务网、测试网】进行渗透测试，一般是计划性工作，根据单位内部的业务需求进行渗透测试，一般季度一次或面临重大情况时【hw、重保、监管通报】进行渗透测试工作。

2.系统上线前的渗透测试

在系统上线前【包括上线到测试环境、测试上线到准生产、准生产上线到生产】等进行渗透测试，提高系统安全性，减少风险项。

3.漏洞修复后的渗透测试

在漏扫或渗透测试后出现漏洞，相关部门或第三方修复后，对修复后的系统进行复测。

1.2.2注意事项

1.渗透测试时需要应用到专业工具，无论是专用渗透测试机器还是自带机器接入网络，都要注意工具的安全性

2.渗透测试的时间（生产环境）尽可能排在业务较低时进行，且引入的测试数据要及时联系相关部门进行处理，避免对业务造成影响。

3.及时联系网络，对渗透测试对应的系统、区域开放网络权限。

4.渗透测试时需要及时保存相关报告，可以的话保存渗透测试的相关流量，防止开发和业务部门因为某些问题时，甩锅给安全部门

1.2.3 代码审计（包含注意事项）

代码审计与渗透测试类似，但是存在情况，该类代码（包含各类jar包）在某些单位的代码审计中（无论是外部厂商还是内部人员）可能会将代码导出，由相关人员使用自己的点进行审计（笔者经历过多家单位，都是这么操作），这对相关审计人员的保密要求和文件流转情况有要求，需要及时对审计人员电脑中的留存代码进行删除，防止出现代码泄露。

1.3 外部漏洞报告

1.3.1白帽反馈

部分单位搭建自己SRC平台或通过其他渠道如雷神众测、漏洞盒子等，收集本单位的漏洞。

1.3.2 第三方平台（包括网络监管部门和外部厂商）

各地区网安总队、网信办、CNTD、安全厂商友情提供等，通过对公邮箱或函，或者针对安全部门的私人关系或合同关系，提供对应单位的漏洞信息。

1.3.3 注意事项

1.外部漏洞报告偏向于逻辑漏洞，联系开发部门修复前要及时验证，判断是否会对业务造成影响，是否为正常的业务逻辑（可能还涉及和渗透人员反馈）。

2.外部渗透可能会通过一个接口漏洞，针对多个域名/系统进行漏洞的提交，在漏洞赏金和金额要求这块可能会需要和单位法务部门沟通确认。

3.SRC这块可能涉及到刷漏洞或者不同人员同步提交的情况，需要相关人员及时保留证据，及时沟通，同时还要定期对渗透的服务器进行入侵检测，防止白帽对系统进行除渗透外的额外操作。

4.监管单位同步的漏洞信息时，需要及时反馈，同时安全部门尽可能要申请上级资源，推动安全事件（漏洞）的修复，提高安全在部门的话语权（逐步）。

5.涉及到外部厂商给的漏洞信息时，后续可能会涉及到具体合作，这个需要看安全负责人和安全的具体需求。

6.外部反馈的出去XSS、SQL注入等常见的漏洞，很多为逻辑漏洞（包括越权、条件竞争等），

1.4 威胁情报平台

1.4.1（CVE/CNVD/厂商通报（偏向产品漏洞））

该类偏向于具体应用、具体设备的漏洞，例如Log4j漏洞；或者产品类漏洞，例如某信服VPN漏洞、某信操作系统漏洞等，在修复时不仅仅是开发人员的事情，还涉及到具体合同（维保）方的事情，需要将系统、组件落实到具体部门。

1.4.2 注意事项

1.在修复时，漏洞修复时可能会涉及到组件引入方，例如某个组件引入了有威胁的应用，这个时候可能涉及到引入组件的维保方或归属方提供修复方案或修复建议。

2.落实具体修复部门，根据单位内部性质的不同，可能会涉及修复的本地化差异问题。

一般情况下根据环境、系统、组件进行责任方的确认，这个在第三节进行详细说明。