《存量线上系统安全漏洞管理：从渗透测试到全面收敛》｜总第286周

原创 群秘 君哥的体历 2025-04-24 23:01

在当前信息化背景下，企业面临的网络安全威胁日益严峻，尤其是存量线上系统中的高危漏洞问题。尽管每年邀请外部安全厂商进行渗透测试，但仍然能发现新的高危漏洞。

---

讨论中提出了多种解决方案，包括建立标准化渗透测试流程、采用多层测试方法（白盒、灰盒、黑盒）、引入众测机制以及利用大模型增强应用安全网关等。但是，这些方法的有效实施依赖于资源投入和管理层的支持。

---

此外，如何在有限资源下找到最优解，逐步减少漏洞数量，成为企业和安全团队共同面临的挑战。本期周报探讨了如何通过综合手段提升存量系统的安全性，减少高危漏洞的发生，从而保障企业的网络安全。

0x1本周话题

---

话题一：想请教下，对于存量线上系统，我们每年都请外部安全厂商来协助渗透测试，每次都能发现高危漏洞，有没有什么好的方法能一次性较为全面的把已知应用漏洞挖掘完或者收敛到很低的水平？

A1
：
目标明确，下次采购时要求对方建立标准渗透步骤，并自行复现或开发自动化渗透工具。每次发现的漏洞应进行根源分析。

A2
：
新发现的高危漏洞是由于应用版本升级造成的吗？还是服务商有意每次只放出部分漏洞？

A3
：
我们确实进行了复盘，但大多数问题是设计上的缺陷，无法彻底重来。控制增量、减少存量是关键策略。新上线系统必须经过安全测试，逐步更新要求。每年多花钱请几家厂商进行测试。

A4
：
每次使用的都是不同的服务商，大部分问题是存量问题，不是升级导致的。

A5
：
建议如下：
– 首先处理重要系统，通过源代码审计（针对自研系统）、供应商出具权威安全机构的代码审计报告（针对外购系统）、众测等方式进行全面检测。

• 再处理次重要系统。

• 分析每次发现高危漏洞的原因，采取针对性措施，以控制增量。

• 完成前两个步骤后，修复漏洞并叠加防护措施。

A6
：
A厂商渗透发现一堆问题，修复后B厂商又发现一堆问题，领导质疑能否一次性解决所有问题，答案是不可能完全消除。

A7
：
每个服务商都进行黑盒测试，路径会有遗漏。可以考虑将API和参数梳理出来进行全量测试。

A8
：
如果有这种办法，世界上就不会有漏洞了。每次领导问时，我们都解释说虽然有标准渗透测试流程，但由于测试人员个人能力不同，无法保证全面覆盖。

A9
：
人工渗透的标准和测试用例再全面，由于黑盒的缘故，API不可能覆盖完，所有功能点也不可能全部测试到，因此测试质量无法保证。

A10
：
这个方法在我们的备选方案中，已经梳理出2600多个API，全量测试的工作量很大。

A11
：
尽管做了全功能测试，但仍被众测发现很多漏洞，领导质疑管理能力和测试人员的能力，但我们只能通过各种手段尽量去发现，无法一次彻底解决。

A12
：
不可能完全消除漏洞，但有没有比较全面或好的方法能尽量收敛数量，降低到最低水平。

A13
：
全量测试在立项阶段很难通过，除非领导明确表示不考虑同行业采购价格，否则难以解释为何一个系统的测试工作量比其他系统高那么多。

A14
：
你们已经找到了路径：代码白盒+API梳理+灰盒识别+黑盒兜底。如果把API提供给外部厂商，领导是否能接受？主要是涉及工作量、资源和资金投入的问题。

A15
：
见过一家公司，他们将高危漏洞列成名单，优先解决名单内的漏洞，这样开发和安全团队配合得较好。

A16
：
承认质疑，优秀的人才年薪几百万，我们请不起。全量API提供出去本身就是一个风险，这件事一般由内部人来做，外部渗透测试的本质是发现内部人的不足，需要反思改进。

A17
：
归根结底是资源投入的问题，方法论上就是白灰黑轮番测试，全接口及参数梳理，找最广泛和专业的高手来测试，一轮下来应该可以相对收敛到最小。

A18
：
我们也期望这样，如果领导比较懂且愿意承担一定责任，可以尝试众测。

A19
：
初期阶段这种方法合适，而且好落地。就像君哥说的
：

网络安全是一个偏实践的行业，很多问题不是纯理论，也不是纯攻击问题，而是怎么在有限资源下的随时间为横轴的最优解落地过程
，这里需要大量的实践分享和总结
。

A20
：
几年前就提出过众测，但领导暂时不接受。

A21
：
名单之外的漏洞不管是什么做法？

A22
：
可接受风险。漏洞太多，先解决高危可利用的漏洞。众测难约束，可以试试国家队，若不接受就算了。

A23
：
渗透测试和漏扫不可能解决所有安全隐患，风险演进、版本迭代和技术发展都会产生新的风险。先解决主要风险，其他问题可以持续跟进，防止出现安全事件。

A24
：
众测有利有弊，确实能发现常规测试发现不了的漏洞，但也可能给一些人提供合法途径攻击系统。

A25
：
处置上按优先级来，但从发现角度来说，盯着高危漏洞不一定能减少被发现的比例。

A26
：
可以考虑每年邀请几家或十家厂商，搞一场类似于竞赛的专项渗透测试。

A27
：
PK测试成本较高，金额小了没人愿意参与。

A28
：可以考虑用可信应用安全网关的方式，在应用访问前和过程中做多维度的持续验证，确保访问应用的可信度，即便有漏洞，也能通过网关隔离不可信的数据包。

A29
：
我们需要阶段性给领导成果，不然领导可能会失去耐心和信心。比如设定三年内降低20%的目标，第一年先把高危漏洞在自测阶段消灭80%，使外部发现减少。

A30
：
PK测试不仅自己人累，还涉及到漏洞评分、厂商间争议解决、奖金发放等复杂流程。

A31
：
多团队交叉验证、激励措施走分成比例方式，阶段性轮换交付团队，优胜劣汰。

A32
：
外部测试和内部测试的定位要分开，内部攻击队的责任是发现问题，外部测试的责任是中立评价。

不要混为一谈，外部测试的问题不需要降低，而是内部自测遗漏的问题需要减少。

A33
：
不能重复发生这一点很关键。这是第一性原理，攻击思路无穷无尽，但适合业务场景的问题必须深究，进行规范和检查，减小代码漏洞的暴露面。

A34
：
对已出现过的漏洞进行分类整理，无论哪家服务商提供服务，都要求对这些漏洞做重点关注。

A35
：
如何定义问题是关键，颗粒度不同意味着预期不同。没有漏洞和没有理论上黑盒扫描出来的SQL注入漏洞是两个不同的概念。

A36
：
互联网喜欢闭环，漏洞也需要真闭环。一个核心或高风险漏洞出现后，复盘的行动是否有效，是否减少了类似攻击方式发生的可能性。

A37
：
业内有一种反向RBI的做法，将用户对系统的访问返回成视频流，通过浏览器解析成用户可看、可识别的元素，但客户端解析不到系统参数和API。

A38
：
这种技术听起来可行，但上量后性能消耗大，不如直接关闭页面，换成简单的CHAT界面，避免复杂的JS和API。

A39
：
厂家声称性能没问题，做过压力测试，但我没有亲自测试过，无法确认。

A40
：
敲字攻击防不住的话，那就不行了。问问有没有大规模案例。

A41
：
相当于接口都不暴露了，只与可信网关对接。

A42
：
主要是大模型的推理和判断能力持续提升。

Q
：
访问请求的可信是如何判断的呢？

A43
：
通过大模型判断信息流的可信度。使用CHAT界面时，信息流会先经过大模型过滤，天然具有WAF功能。

A44
：
不需要安装，只需在CHAT界面配置PROMPT就可以。这种方式更像是通用转义器，基本只能攻击大模型本身，无法攻击背后的接口。

A45
：
利用大模型的推理能力打败入侵，同时大幅降低大模型的性能消耗。

攻击者的命令在各类安全设备中会产生大量告警日志，消耗大量token，而在入口处干掉则消耗很低。

A46
：
基于AI的WAF，不知道现在基于大模型的攻击报文检测能力达到什么水平，是否有客观的测试数据？

A47：
不需要，按
这个思路
，是用户输入就是LLM问答，系统去对接agent，重新盖楼，而不是在原来的楼里加智能防盗。如果命题就是这个，那我表示通用模型的话一般般，token资源利用价值不突出
。

---

0x2 群友分享

【安全资讯】

《东方通暴雷，财务造假被立案！！或将退市！！》

《央视报道：奇安信吴云坤揭密美国特工对亚冬会网攻窃密内情》

《3 名程序员、各判 3 年：出狱后、3 年内禁止从事网络安全管理和网络运营及相关工作》

《美国国土安全部终止资助，CVE漏洞数据库面临停摆危机》

《哈尔滨市公安局悬赏通缉3名美国特工》

《CNNVD | 关于Oracle多个安全漏洞的通报》

【行业思考】

中国人民银行等六部门联合印发《促进和规范金融业数据跨境流动合规指南》

《大模型上下文协议MCP投毒攻击通知｜攻击应对方案》

---

由于微信修改了推送规则，需读者经常留言或点“在看”“点赞”，否则会逐渐收不到推送！如果你还想看到我们的推送，请点赞收藏周报，将
【君哥的体历】
加为星标或每次看完后点击一下页面下端的“在看”“点赞”。

【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球
，方便大家查阅。

往期群周报：

金融专网安全双维防御：蜜罐溯源技术与敏感信息合规传输策略解析。｜总第285周

主动防御策略结合隐私保护与运维风险管理，构建多方位安全体系，提升数据安全与合规性。｜总第284周

团队如何在隐私泄露风波中优化安全投入，同时探讨基于算力的大模型在安全运营中的应用。｜总第283周

****## 如何进群？

如何下载群周报完整版？

请见下图：

‍

‍

‍

‍

‍

‍