各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 207期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。

上期精彩内容请点击：信息泄露渠道及风险感知；数据脱敏规则探讨

话题抢先看

1. 开源软件的引入流程是怎样的，有哪些安全评估机制？

2.《上海市企业数据合规指引》中提到，企业不得使用风险不可控的开源软件开发工具包等工具。，如何理解其中的“不可控”？

3. 调查显示，2022年勒索软件利用的漏洞中，76%来自 2019 年及之前的旧漏洞。如何看待企业冒着被攻击的风险，长时间未修补这些旧漏洞？

4. 《网络产品安全漏洞管理规定》等法规下的漏洞安全管理。

话题一：大家的企业对开源软件引入流程是怎样的，有哪些安全评估机制？

A1：

感觉小企业可以无脑用，大企业自己分析源码自己开发适合自己的。

A2：

一、明确非必要不引入、谁引入谁负责；
二、制定管理办法和引入流程指引；
三、安全评估机制主要有：
1.病毒、木马扫描；
2.源代码扫描；
3.SCA工具检测报告；
4.漏洞库检索（NVD、CNVD、CNNVD）；
5.准入指标（开源协议类型、MD5校验、开源社区活跃程度等等）。

A3：

1.评估开源协议；
2.评估版本更新时间；
3.评估行为，是否需要账号登录，同步数据，文件上传；
4.代码审计不评估，用的人多知名度高就用。

A4:

1.管理类：许可证合规评审，针对合法商用，法律义务及使用风险；
2.技术类：病毒扫描、漏洞扫描、静态扫描/开源组件扫描、沙箱测试等。

A5：

1.有规范，有执行人；
2.引入前评估开源软件在网络架构中可能带来的风险（从产品架构，网络架构各方面评估）；
3.安全测试，把可能存在的安全问题找出来进行定制化的优化修改；
4.符合要求后，走发起部门走引入流程，通过技术架构，安全，以及CTO的审批。

对了，还有个开源许可协议。

A6：

说的有道理，理论上是需要有的，比如SCA其实就是对于三方开源组件的安全管理运营。

A7：

主要就是开源威胁治理，核心工具是SCA，做得好可以上DevSecOps，做好开源数据源监测，资产开源清单，线上应急响应。

A8：

开源软件理想化是引入前做卡点，形成SBOM，联动漏洞库信息引入没有漏洞的版本（这是事前）；漏洞预警和版本联动，做漏洞响应（这是事中）。
但是大多数公司安全都是落后于业务发展进行建设的，建议还是先从SBOM先开始做，做到底账清晰，这个可以和CI流程集成，然后再按照版本进行漏洞修复（这样存量风险和增量风险都可以感知到）。

A9：

我们主要通过SCA检测，后续会搞SBOM清单建设。

A10：

开发新增了一个Pypi的第三方库，这个不和安全团队报备吧？

A11：

这个建议报备下，不过看你们是啥的公司，如果对于访问的黑白名单控制不是很严格，且对于三方组件仓库未做相对应的管控，报备了也没啥用。有管控还是报备好，不然估计你都访问不通。

Q：在去年出台的《上海市企业数据合规指引》中提到，企业不得使用风险不可控的开源软件开发工具包等工具。对于这个“不可控”，大家如何理解，如何做到可控？

A12：

不在国家某机构的目录中，即为不可控？

A13：

主要是来源不可控，维护不可控，管理不可控，威胁不可控。

A14：

还可以补充一下：软件供应链不可控、许可证协议变更不可控。

A15：

不可控：
1.是否具备熟悉掌握其技术原理和使用经验的人员；
2.是否依赖第三方厂商：如果依赖厂商，其是否有实施经验、能否在合同中承诺维护职责；
3.是否有100%的源代码；
4.使用何种开源许可证，是否影响后续的应用。

A16：

说到底：一问三不知就是不可控，可控就是底账清晰同步变化。

A17：

再加两个，可持续性，开源社区稳定，能够持续维护。可替代性，万一出现断供，有可替代产品。

A18：

如果只是做个插件，跟进主线，那是自主，但不可控。硬Fork，肯定可控，能不能自主不好说。所以这应该是鼓励大家硬Fork，自己维护自己的版本。

A19：

Fork之后还要自己维护？

A20：

我说一下这个理由，如果不是硬Fork后自己维护，那么你需要跟进主线（我相信没几个人能跟得起），如果主线搞了点啥东西你不敢跟或者跟不上，这绝对算不上可控。你想跟主线提PR也不一定都能接收的。所以只有硬Fork然后自己维护，那才叫可控，这代码真的你想咋搞就咋搞了。

A21：

Log4j大家用之前检测出漏洞了吗？

A22：

这种深层漏洞肯定很难啊，而且是未知漏洞，能把已知漏洞搞清楚掌握住都很不错。出现漏洞第一时间能知道对应到哪些资产上，有应急措施，就成功了一大半。

Q：引申一下，最近ChatGPT很火，就是不清楚怎么用到安全里面来，大家有好的思路不？

A23：

ChatGPT和其他深度学习模型一下，有一个大问题，就是不可控。你不知道他会不会给出一个错误的答案，在安全的特定场景下他的准召率是多少。多少安全的AI模型，实验室搞到99.99%的准确率，在生产环境还是不敢开。

A24：

不是都有误报的么，现在大家都要搞ChatGPT类似的产品了。

A25：

发现漏扫出来的一些修复建议存在误差，不能直接给业务派单，目前是准备人工运营一些常见的漏洞描述和修复建议的信息，大家有什么好的实践么？

A26：

边写边调整吧，发出去就跟业务说有建议或者反馈直接反应更正。然后维护知识库，常见的都放里面，直接点击看，案例、相关风险，都可以整进去。

A27：

知识库可以，能把日常运营的东西沉淀下来。你们的知识库和Wiki类似?

A28：

区分内部和全公司可看。内部包含事件处理报告、事件处理SOP、其他操作等。给业务看的包含常见漏洞说明和案例、风险，以及一些可能业务不熟悉的安全知识。

话题二：最近，Ivanti 的一项调查显示，2022年勒索软件利用的漏洞中，76%来自 2019 年及之前的旧漏洞。如何看待企业冒着被攻击的风险，长时间未修补这些旧漏洞？

A1：

相关企业可能不知道自己有哪些老旧漏洞未修补，也不知道有哪些老旧漏洞暴露在互联网。可以用一些厂商的漏洞管理系统。

A2：

安全的漏洞管理系统最好还是不要和功能测试的BUG系统进行共用。

A3：

最大的问题是修复版本的影响太大，稳定性或者工作量风险，造成不能按时修复，只能带病上线。

A4：

那些对业务连续性要求不高的某些系统或者某台主机，往往不重视，认为即使重装这些主机的损失，也不及自己银行卡或者单位账户少了一毛钱。

A5：

跑着的业务不敢动。各种依赖兼容性问题，修复没那么简单。

A6：

说到底还是拉通运维和开发的一个事情，这块最好是有一个运营系统方便一些，你总嘴上沟通，无论是效率还是扯皮都是事情，以工单的形式推动，感觉对开发和运维也公平些，至少算他们的KPI统计吧，不是人家默默无闻的配合。

A7：

大部分不去改动都是一些老旧系统，兼容性差，修复风险极高，大部分都会选择不修复，然后进行加固处理。对于一些单位来说，出现安全风险还能接受，但是出现业务风险，那就是不可接受了。

A8：

核心还是安全漏洞修复有时候不可控，举例Fastjson升级为V2避免漏洞，关闭Autotype影响业务功能，漏洞修复不能破坏兼容性，一两个系统还好，面对上百个系统做的完全修复很不容易。而且防勒索病毒不一定一定要修漏洞。

A9：

还是业务和人力成本问题，看老大话语权了，能从WAF拦就从WAF拦。

A10：

其实该说的大佬们都说的差不多了，我觉得从勒索现象本身来看，这个冒着被攻击风险不修补漏洞其实不是根本问题。可能回答超纲了，其实我觉得应该问如果看到勒索软件可以利用旧漏洞这件事更合理。我觉得，其实主要就是任性，勒索软件一般都是批量攻击的，说白了就是捏软柿子。那么他喜欢攻击什么人呢，就是安全意识薄弱，未修复漏洞或者懒得修复的人。

如何看待这种现象呢？我其实觉得很大一部分是公司性质、规模和业务本身来决定的。比如小公司没有专门的安全人员，他们都不知道系统有啥漏洞，也不知道怎么修复，更加不会关注漏洞。大公司被攻击一般都是人员意识差，某个部门被当软柿子捏了。至于修复难度大这个，一般都有临时和永久解决方案，如果有专业团队来操作至少会有临时解决方案。所以究其根本就是思想上不重视、安全意识差。

Q：说到底，在推动漏洞修复时会有哪些问题，是否有来自业务等部门的阻力？

A11：

推动漏洞修复的时候问题可多了。业务部门阻力算是里边相当大的一个问题了。推动漏洞修复的时候需要关注的点是漏洞评估，定级。修复方案和闭环。前两个还好做，修复方案和闭环是两个较难的问题，这里要评估业务、修复难度、修复周期和闭环。每个环节都可能成为卡点。一般最优解决方案，就是下发工单抄送部门负责人，以漏洞不修复会造成什么样的业务影响为由限定时间修复。另外还得平衡部门利益跟兼顾员工KPI，反正是相当艰难。

A12：

推动困难一方面是业务责任部门不了解相关安全问题的严重程度，甚至于不知道安全是什么，另一方面是认为业务稳定性压倒一切，不愿意进行变更，还有可能是修复业务存在成本，在小型业务上，存在无人承担成本，导致不修复的情况。

A13：

把安全纳入KPI就好了。

A14：

这个是个方法，但是要业务部门认，其实没有危险发生的时候，人总会觉得是安全的。纳入KPI如何去考核也是问题，业务部门经常会怼过来，这就体现出最后一个闭环问题你不限定时间他们永远不修复，你限定时间他们不停的让你不好过，任何修复点都来问你怎么搞。如果不找到利益共同点，KPI强压可能适得其反，互相不痛快，效率更低。

Q：在《网络产品安全漏洞管理规定》等法规下，大家漏洞安全管理是怎么做的，有无实践分享？

A15:

首先要培训好安全人员，开发人员，发现漏洞先内部通报，绝对不得发往任何论坛。再是分析是内部漏洞还是外部的。内部的内部消化，外部的沟通确认。

A16：

有安全设备的可以打虚拟补丁，没有的按照漏洞严重程度，严重的是能修就修，不严重的一概不修复，我是这样干的。

A17：

基于漏洞的严重性，根据系统的重要程度（业务重要性、数据敏感度等）及利用难度（隔离区、内网或公网可利用等）综合判断风险程度，根据风险程度判定修复时效，如果有安全防护则根据安全防护情况来对风险进行降级，然后按照降级后的风险等级判定时效。

A18：

中危以上级别的漏洞我们要求在上线前修复，已上线的项目限期整改或临时用虚拟补丁、WAF等手段防护，漏洞修复和绩效挂钩。

FreeBuf 观点总结

许多企业都离不开开源软件，对于开源软件的安全引入与评估，有群友认为要从版本、开源协议以及具体行为（是否需要账号登录，同步数据，文件上传）等进行评估，涉及技术类的还需要进行病毒扫描、漏洞扫描、静态扫描/开源组件扫描、沙箱测试等操作。也有群友认为核心就是开源威胁治理，主要工具是SCA，做得好可以上DevSecOps，做好开源数据源监测，资产开源清单，线上应急响应。

对于企业不得使用风险不可控的开源软件开发工具包等工具中“不可控”的理解，大家结合实际，归纳为来源、维护、管理、威胁、软件供应链、可持续性不可控等方面。

在企业为何难以修复一些老旧漏洞的讨论中，大家众说纷纭，最主要的声音源于会对一些连续性较强的业务带来影响，可能存在兼容性差、修复风险高等问题，这与公司的规模及性质、安全水平，甚至部门之间利益及职责、矛盾也息息相关。在漏洞安全管理方面，可基于漏洞的严重性，根据系统的重要程度及利用难度综合判断风险程度，确立修复策略。

本期话题讨论到此结束啦~此外，FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！

【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】

注：目前1群、2群已满，如有疑问，也可添加Kiki群助手微信：freebuf2022，备注：甲方会员

“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1100+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。