CI\CD流程上软件成分分析如何解决间接依赖问题、安全运营本质与安全有效性验证讨论、如何提升渗透测试质量... | 总第181周

‍‍

0x1本周话题TOP3

话题1：请问在cicd流程中进行软件成分分析的时候，大家遇到间接依赖的问题是怎么解决的？

比如maven声明了当前代码使用依赖是最新的版本，间接依赖存在低版本，但是这种情况编译之后显式声明的会覆盖掉间接依赖的，实际已经修复了。

A1:java算是比较复杂的，十几层依赖甚至更多层都有可能。遇到上述这种情况，一般就以直接依赖的为准，除非能证明间接依赖真的存在问题。我们目前做的比较粗，认直接依赖是较新版本，否则官方没有去管间接依赖的话，自己弄成本太大。看看其他大佬有没有更好的办法。

A2:直接扫描产物来的直接，如果有不依赖的低版本可以让研发排掉。

A3:Java间接依赖存在漏洞也得处理，排包或者升级，有的漏洞，可能这个组件就是利用链里的一环，引入了依赖，就可能被利用。如果实际已经通过显示指定版本修复了，检测还是会报漏洞版本，那么要优化的是检测环节的准确性。

A4:试试mvn dependency:tree，但是输出结果要自己进行txt文本解析，两三百行代码吧。基础工具如git、mvn等，字符界面输出结果没有json 结构化格式选项，要自己动手解析的情形比较多。

A5:我们cicd接了黑鸭，java直接扫产出的jar包，虽然踩了一堆坑总算用起来了。

A6:不建议的路线：自己去解析pom 后，再仿mvn规则去计算最终结果。maven软件那么大，是有道理的。

A7:也可以试试dependency-check，OWASP开源的的一款软件组成分析(SCA, Software Composition Analysis)工具。解析pom不够的，间接依赖在pom上不会完全体现，个人认为扫描产物是最好的方式，还有意外收获，就是报告上会罗列所有的依赖包，可以二次解析后作为资产收集的手段。

A8:是的，组件作为资产管理起来，应用量多的话，通用漏洞排查推升级，内部攻防找利用链，效率都会高很多。

A9:排查影响面的利器，还有修复跟踪。

A10:我们内部采集得非常全，到处都在收。 上面大家提到的全部纳入了

1） 白盒扫描， mvn dependency:tree

2） HIDS 动态采集java进程jar包 

3） RASP采集 

4）产出物jar包、镜像扫描和采集 

5）同时分析了maven仓库的下载日志，发告警 

6) 白盒扫描，pom.xml解析的也有

A11:资产管理应该是做好安全运营工作的第一步吧，又回到了如何完整地做SCA。

A12:严谨点，jar 解压解析是另外一种补充，而且需要有个前提，即提前建立依赖信息数据库，如名称和哈希码，否则分不清依赖包是原产的还是被篡改的。

Q:间接依赖包存在漏洞，这个修复的动作会比较大吧？这个是怎么处理的？如果是外购软件，各位怎么扫?

A13:哪里会有完整的方法,一般碰到问题，找个Java架构师，增加场景和能力，时间久了，越来越经常派上用场，这事就成了。每一篇sca都不可能“全”，意义在分享了可借鉴的实践。

A14:HIDS采集得清清楚楚的，容器的信息也都会关联上。覆盖方法，非单点，参考同行经验，群里朋友也分享过。

A15:但白盒就没有了啊。

A16:这个得看具体的应用对稳定性的要求，也看研发的能力。基础组件/中间件团队升级要保障稳定性，每个版本的变化都要搞清楚，这类其实有些组件很难升级，就得安全分析实际影响，再决定要不要升。业务方自己引入的包，一般是升级或者排包之后在测试/预发环境跑一段时间，没啥问题再上线。遇到过有的研发能力比较强，有意愿，会分析的比较清楚再处理。

A17:有些漏洞有复杂的利用条件，光运行时是不够的，需要源码库遍历，源码解析，特征提取，以及大数据记录。但对外购，运行时检测，进一步，找到关联的文件，再解压解析，是一种“我已经努力了”。

实际工作中，我碰到很多研发自研的依赖包出了问题，（真没外人可以背锅了），自研的发布流程比开源更奇怪，需要更复杂的排查，这类场景漏洞库是没有用的。说到底，要从第一性原理出发，积累自己的底层能力。

A18:这个还是要有团队去研究这些基础组件，之前随便扫了个es的镜像，log4j的都在，没人敢说这个怎么处置得当，顶多测试的时候不影响业务正常使用就算通过。

A19:这种我们一般会评估漏洞的对自身真实风险等级,而不是都升级。

Q:话说很多组件漏洞按照cvss3.1的评分标准，虚高严重，大佬们有没有感受。

A20:你加上时间分值和环境分值以后也很高吗？

A21:没有加时间和环境分，拉到的数据都是cve的基础分，比如同样是rce，有的就是很常见的写法就会导致出现漏洞点，有些漏洞需要应用代码有极特殊的调用和写法才有漏洞点，基础分都是9.8。

得研发反馈难升级的组件才会评估吧。应用量大，组件漏洞太多了，有心无力。

A22:你们公司团队真厉害，我们的开发团队有时候连代码审计报告都看不懂。

话题二：推荐大家看看《核电厂人因管理》。我做安全运维工程师的时候，管很多防火墙、F5、交换机和加密机，有一次周日值班，上午业务部门说网银有个业务，一部分用户登录后，后面用户就登录不了，运维那边应用管理员说应用和服务器都重启过了，也没发现什么原因，我想了想昨晚我做的变更（新上应用连接数据库50000端口）知道问题在哪了，数据库端口50000没有设置长连接。后来这个案例就是人因误操作的典型案例。数据库端口要设置长连接，这个坑估计很多人都踩过。还有某信fw297天bug。

A1:看现在的mysql oracle 以及nosql 默认都是长链接了。最早刚开始用防火墙的确不少踩过长链接的坑。

Q:还有F5 snat的问题，单边桥问题，vs里没有pool member问题，加密机不能ping做监控问题，还有ca密钥、密押等问题。

A2:db2很有年代感，跑在400上的。而且有些银行的业务的确不能过墙，只好绕行了。

加密机真是个神奇的东西。长得还短，每次本地输密钥插console线，都要爬进机柜里了。

A3:最早用netscreen防火墙也有这个坑，当初查了很久才发现要配置长连接。

A4:早些年防火墙就是安全的代名词，现在感觉啥也不是啊。安全设备就是武器，关键是知道放哪里，怎么用。我是见过一堆防火墙，然后安全策略都是any any any permit的。

A5:早些年主要以C/S为主，防火墙访问控制还是比较有用的，现在B/S了，感觉防火墙真心意义不大了，连入侵检测感觉也很鸡肋了。waf最有用。

A6:Ips对于非web还是有点意义。入侵检测要持续更新策略，不然就没意义，淹没在一大堆的误报里面。

A7:银行的waf基本都用的是最好的产品：imperva。但我们验证后发现不同银行的边界安全拦截率差别很大，有的拦截率98%以上，有的20%，差别不是设备和产品，而是上面的安全策略。

A8:是的，以前见过一家证券imperva上的策略做的很细，基本能拦都拦，不该拦也不拦。

A9:WAF的安全策略需要根据业务系统来吗？还有目前国内一直在力推XC改造，imperva会慢慢退出市场吧。

A10:会的，关键点不是imperva，而是安全整体的效果，依赖设备+策略+运行维护保养水平。

A11:产品不重要，何况同质化趋势越来越明显。运营最关键。

A12:只用缺省策略的确是个问题。但WAF怎么用才算好？有没有一些指引或者标准给参考呢？

A13:拦截类设备和检测类设备的策略风险偏好还是会有所不同。

A14:持续运营降低误报率，用攻防和BAS降低漏报率？

A15:我觉得目前信创有个很大问题（或者说风险）：很多安全产品由于完全达到和非信创产品一样的安全效果，需要做大量的改造和适配，所以目前普遍信创版本的安全产品，其安全能力做了很多阉割，导致其实际安全效果和非信创版本相差比较大，但由于甲方缺乏安全验证和专业辨识能力，导致这种问题和风险没有被及时发现，但随着攻击者对信创环境越来越熟悉和研究的越来越多，这个问题（风险）会逐步的加速暴露，从而造成巨大的安全事件。

过去我们通过一些用户侧验证发现，很多安全设备在信创系统上的检测能力并不太符合预期。例如：运行在信创系统上的WAF的拦截能力相比原有WAF降低了很多，端点类防护检测产品agent运行在信创系统上就只能检测少部分的攻击手法（主机被暴力破解并植入木马，端点安全没有任何告警，事后排查发现因为信创系统登录日志文件格式发生一些变化，但是安全设备没有在检测能力上进行优化适配，导致无法有效检测）。

但是这些都是比较大的隐患，由于缺少验证手段，企业安全建设者无法清晰的掌握基于信创的安全防护能力到底水位是如何的。应该通过各类型常见的的攻击方式在信创系统上进行模拟验证，掌握无法防护的盲区，提前优化对攻击的防护检测能力以及提前设定应对措施。

A16:waf有时候是根据业务调优的，有些漏洞业务系统技术栈不涉及，安全策略直接优化不拦截，BAS打的流量能过去，但实际没影响，这种统计会不会有些失真？

A17:所以上云就避免了底层的部分XC问题。将难题留给了供应商。

A18:因为要逐步推进信创，我们全国所有分支的信创一体化终端，是将两家产品的安装包合在一起的，这样子会出现各自负责各自的测试工作，带来的风险也更大。

A19:安全防护体系存在的逻辑是：不管后面有没有漏洞，最好各类攻击技术手段都能拦截和检测，这是安全防护体系存在的基础。（不能因为商户都锁门了，门口保安就不执行安全检查策略了）。

某些漏洞业务系统技术栈不涉及，有可能是涉及但安全团队不掌握，或者现在确实没有，但不代表哪天某个业务会涉及，当然也可能是真的没有。但最好能控制这个风险。

业务方有时候还会反问：我的业务是有漏洞导致被攻击成功了，但你们安全团队对漏洞的攻击也没有防住，是不是也需要改进？

A20:厂商对新兴领域为了抢市场，没有走完整测试流程赶鸭子上架就对外销售，这现象在国内安全厂商太严重了。

除了信创，macOS领域的一些安全产品也是如此，除了UI空壳，基本没功能，也敢直接卖给客户。

A21:安全也讲究平衡点，现在的waf普遍都存在误拦截，如果为了所有漏洞开启了所有策略，反而会加大对业务的影响，这样反而会因小失大，策略调优的意义就在于剔除一些不是防御重点的策略，又能保障业务的连续性。

A22:这个看风险倾向了。对于风险比较敏感的企业，以及特殊时期（红蓝对抗、重保）肯定是倾向于更低的漏报率了。

A23:全严格策略的话还是太绝对了，需要根据自身业务和开发技术栈去合理配置。

A24:嗯，这点我同意，安全其实就是风险偏好和容忍度的选择。

A25:逐渐积累形成贴合业务的WAF拦截基线模板吧。先记录，然后选择性开启高危级别的拦截策略。

A26:乙方厂商的安全产品考虑的客户种类技术栈业务类型较多，是一种全面覆盖型的，有些不用的策略，经过内部评估验证，剔除掉反而会更优。

A27:最好自己能掌握哪些能防御和检测，哪些不能。然后再做风险偏好和容忍度的选择。

A28:安全策略根据实际业务场景不断优化可以慢慢减少误报和漏报，这个需要对业务了解和安全技术能力都要求比较高。

A29:可接受的风险及损失底线。现在BAS其实也有这块的选择，可以只选择自己企业的技术栈的POC去测试。

A30:但这种方式运营成本会比较高。要求技术栈梳理的很清晰，并且能够一起迭代优化。

A31:安全为业务保驾护航，安全把业务误拦截，都会算一个故障了。所以还是需要投入人力去运营。

运营在我看来就是一个核心，把控对风险的容忍程度。无论在技术实施上怎么做，都需要通过这个核心去思考做取舍。嗯业务连续风险也是安全风险的一种，同样也需要去考虑的。

Q:安全的容忍程度一般怎么和企业业务流程的风险偏好结合起来呢？

A37:这个看你们的情况了，有很多东西可以帮助具体化容忍度，比如红蓝对抗、上级规范。或者做下BCP。

话题三：请教一下各位专家，可以采取哪些措施提升或保证渗透测试质量呢？短期和长期的措施都可以？

A1:参考外部的SRC，众测平台的评分标准，乙方提交的漏洞按照评分标准来。如果预算够的话可以引入外部的白帽子。

A2:现在SRC这种模式已经式微了,主要还是要建立自己的SEIM作为安全运营平台。

A3:内部交叉测试、SRC、采购外部厂商交叉测试。

Q:引入外部的白帽子作为长期服务或者正式员工么?您是强调自有安全人员来做渗透测试？

A4:一个正式员工，几个外包服务。有平台自然有标准了。再就是多找厂商进行交叉测试。尤其利用好外采的机会。

Q:这个怎么理解呢？

A5:建立平台自然要以标准来建，所以就会方便梳理各项指标了。要看你的项目的名义，尽量跟入场的人沟通你们的目标，然后评估他们的能力，大概就知道他能做到哪种地步了。我们Q4邀请厂商来做了一次外网和内网的渗透，资料都是我们提供给他们的，甚至打不动了，我都会跟他说我们本身薄弱点让他自己想想办法突破。

Q:你们的siem 做到啥地步了？自建还是采平台？

A6:23年的目标是完全建成，现在才开始。至于建设方式目前在评估，先看自建能不能满足需求。

A7:这个我再多了解一下平台建立过程的标准。

A8:你去把各家厂商都喊过来，让他们给你们出方案，你进行比较就大概有数了。传统厂商给你说的东西，你自己多掂量一下，因为他们的ppt很多东西都是大饼。多看一下新厂商。再就是看一下老板对业务连续性和安全的态度。

A9:我们自建，没有对应的安全开发啊，怕起了项目又干不了。

A10:先找开源项目接入几个平台测试一下，这样就算外采也能知道自己的真实需求。不会被厂商忽悠了。

Q:SIEM平台建立很容易，用好才是难点。

A11:所以就是说先找几个用用才能知道自己真正需要什么样的，怎么才能用好。不能让厂商走在你自己调研前面。另外先搞清楚，要建SIEM还是SOC。

Q:SIEM和SOC这两个区别是什么呀？

A12:我觉得目前市场上，siem和soc区别不大，没有本质区别。只是SIEM更倾向于所有日志关联安全分析，SOC倾向于资产安全运营。

A13:但是现在的soc也有流量归集和分析，以及事件归集啊。

A14:我也只是接触过皮毛，感觉十几个人的团队是玩不起来这东西。某大厂，单安全运营就十几个人。

A15:严格意义上来说，SIEM是SOC的一部分。想要玩转，也许还不止十几个人，因为还有很多的外包服务以及后台的支持服务。标准化程度的高低决定了可行性，标准化是目前很多集团企业面临的大问题，异构有好处，缺陷同样很明显。

仅供参考：https://blog.csdn.net/dylanOO1/article/details/107863716

Q:抛砖引玉问个问题，假如一个系统的代码这块，没有做SQL注入防护，大量使用拼接，对于渗透测试人员来说，是给他找一两个问题证明系统这块有问题，还是全给他找出来？

A16:全找出来有点难吧。

A17:就叫关联到测试质量或者测试覆盖的问题了，安全测试是能力证明呢还是bug测试。

A18:渗透只要到几个点，但是整改和测试得根据分类进行覆盖。

A19:一般都是报告中说明，整个系统都有这个问题，整改完成后复测。

A20:如果只是证明，那你很难限制安全测试人员是不是覆盖了所有的测试用例。一个项目，几个系统发现点问题就可以交差了。一般来说是5个不同接口左右就可以证明了。

A21:全找白盒吧，渗透不可能全覆盖的，说的不是一回事，漏洞在流量里看不到。毕竟不是开发人员，如果基础差，通过质检提高质量也难吧?

A22:哎说回来，我们在这里讨论的很多时候都是“正确的做法”，但落地都会有缺陷，打折扣才是常态。

A23:这种情况如果要解决，我个人感觉还是要在系统上线前引入白盒测试。单就这个问题来说，尽可能的的找全，然后邮件同步给他们领导以及安全的领导，让他们整改，整改完毕后复测。

Q:目前贵行针对互联网系统，上线前有全覆盖人工白盒测试吗？

A26:同样也要引入技术能力解决问题，比如WAF+RASP方案，纯期望能找出所有注入点，这个花费其实很高。

A27:是的，我们SRC都收不到几个洞。WAF可以，RASP的话，金融不一定敢上。

A28:我看过有的银行很早就上了RASP，不敢上我觉得未必，就像WAF一样，一样需要学习，调整，优化，这都是过程，我们开WAF规则，也不会一下就开拦截规则，肯定也是监控规则，RASP也是一样。

0x2 本周精粹

休刊

0x3 群友分享

【漏洞情报】

【漏洞通告】关于微软 PowerShell 远程代码执行漏洞的通告

【安全资讯】

九问+一图，读懂《关于促进数据安全产业发展的指导意见》

范渊免职——网安界其人曾异军突起又将“落幕”？

工信部等十六部门联合印发《关于促进数据安全产业发展的指导意见》

奇安信获利近 6 亿：累计减持威努特 25.93% 股份，不再是其股东

时隔15年，高盛再度大规模裁员！3200人将丢饭碗！（国内证券从业者如何应对？）

受贿 196.5 万、判 6 年，行贿方包括：华为3COM、绿盟、天融信、山石网科、金税信息、杰赛、齐明、常鑫、维豪、网融等

SECISLAND安全官推文目录

软考那些事儿，看这一篇就够了！

7软考电子证书发布，抵扣个税正当时

【安全技术】

《数字银行可信纵深防御白皮书》重磅发布【附全文下载】

第46篇：伊朗APT组织入侵美国政府内网全过程揭秘（上篇）

【今日上线，一览无遗】《2022年度网络安全综合态势观察手册》，囊括6大报告！

-------------------------------------------------------------------------------

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

往期群周报：

证券公司网络和信息安全三年提升计划探讨、杂谈软件正版化律师函广撒网现象、企业报废笔记本电脑有哪些数据销毁方式？| 总第180周

关于软件组成分析、开源软件治理部分，安全参与和介入工作以及牵头部门的讨论、什么是基于安全标记的访问控制... | 总第179周

关于蔚来数据泄露的思考，以及SAST白盒扫描做业务上线卡点的探讨，针对内部https流量问题的解决方法等...| 总第178周

如何进群？

如何下载群周报完整版？

请见下图：

原文始发于微信公众号（君哥的体历）：CI\CD流程上软件成分分析如何解决间接依赖问题、安全运营本质与安全有效性验证讨论、如何提升渗透测试质量... | 总第181周