微页制作网站模板下载,wordpress获取分类的文章列表,广州旅游网站建设,广州最繁华的三个区2023 年 7 月 18 日晚 19:30#xff0c;软件供应链安全技术交流群#xff08;OSCS#xff09;组织了第一次线上的闭门研讨会#xff0c;本次研讨会我们收到 71 个来自各个企业关注软件供应链安全的技术专家的报名#xff0c;根据研讨会参与规则要求#xff0c;我们对报名… 2023 年 7 月 18 日晚 19:30软件供应链安全技术交流群OSCS组织了第一次线上的闭门研讨会本次研讨会我们收到 71 个来自各个企业关注软件供应链安全的技术专家的报名根据研讨会参与规则要求我们对报名人员进行了审核最终来自互联网、金融、运营商、软件厂商、国央企超过 35 名安全专家参与了当晚的研讨会。 《软件供应链安全建设价值》主题分享
研讨会的第一部分是由墨菲安全创始人OSCS 发起人章华鹏带来的主题分享章华鹏用三个公式来分享如何思考软件供应链安全的建设价值。 接下来对公式中的各个因子进行逐一的拆解和剖析首先要管理软件供应链安全的风险盘点清楚软件供应链安全资产是其中最关键的环节资产台账是需要管控的风险的对象的总集也是未来衡量其建设价值的重要分母分母说不清楚价值就说不清楚。 关于软件供应链资产台账的采集可以从办公软件、自研生成软件、外采生产软件等三个维度来进行采集和统计。 软件供应链攻击可能导致的数据泄露仍然是企业最关心的风险点。 其次是软件知识产权合规的满足做为软件使用方和软件生产方都有非常重要的代码知识产权合规管理问题。 此外大家最关注的还是hvv期间自己不要被攻破毕竟现在攻防演练最常用的攻击手段就是利用来自软件供应链的漏洞。 除了一年一度的大型攻防演练日常大家最关心的风险其实就是因为软件供应链的通用漏洞被勒索的风险。 对于企业内部中高阶管理人员来说软件供应链安全是一个新的技术方向在新的技术方向有一些前沿的技术探索和实践并对行业有所输出必然是提升自己在行业内的影响力的很好的一种方式。 关于建设的收益讲完了再来讲讲建设所需的成本这个成本大多数时候主要还是运营成本实际上接入成熟的软件供应链安全能力运营成本是非常可控的。 首先是部署和使用软件供应链安全能力的成本这个成本如果是使用成熟的商业产品那么成本非常可控如果是自研那么从工程和漏洞知识库的运营方面来说都非常高。 此外就是软件供应链安全问题的处置成本漏洞如何快速修复且规避软件升级带来的兼容性问题过滤掉不会真实触发的漏洞将是最核心的挑战。 关于日常的安全技术运营是保障持续运营效果非常重要的手段持续提升开发人员的安全意识明确企业软件供应链安全治理要求是必需的。 分享几个企业关于软件供应链安全治理的案例 高性价比的治理方案 体系化的进行整理的案例 会前收集问题的研讨摘录 Q1如何保证漏洞数据的正确性 很多 CVE 漏洞有很多数据字段是缺失的从各个公开的渠道采集的一些漏洞一些数据信息不一定是准确的。这个问题核心是说怎么保证做供应链工具安全检测的时候整个漏洞库数据是准确的包括它的一些字段、修复方案、影响范围等等 | 某互联网企业大佬过往会收很多漏洞情报收完之后专门安排一些同学去做加工处理 来校准数据。 | 某软件厂商大佬我们是实际这方面积累的不多主要是用集团的能力。我们在漏洞比如说 在 SCA 识别出来然后和漏洞库碰撞之后的漏洞修复方面是有一些沉淀我们团队会去做一些漏洞利用条件的提取尽可能的把这些东西沉淀下来给开发看转成开发的一些语言帮助他们更好的去修复漏洞其实就是减少他们的工作量。 | 某软件厂商大佬我们会发现外部的漏洞库有几个比较坑的地方比如说 CVE 的漏洞前段时间和某金融企业的安全团队在交流CVE 的很多漏洞它标识的组件影响范围是非常不准确的还有log4j 漏洞其实是影响的模块是不一样的。比如有 log4j-corelog4j-api 等等有很多不同的这个模块漏洞影响模块不一样但是在 CVE 里面的标识信息就只写了一个 log4j。当你去做漏洞匹配的时候就有可能导致会把所有 log4j 相关的漏洞都会匹配出来。但是实际上不同的漏洞影响的模块其实不一样的这是一个比较典型的坑这个坑就像刚才讲的可能需要人工去留用每一个漏洞它实际影响的情况去做一些分析。这个分析可以保证后面匹配结果的一些准确性这是其中一个点。 再比如修复方案其实很多数据是没有的甚至说要去校准不同的数据来源采集的数据里面每一个漏洞的修复方案的准确性。 十多年前阿里的空虚浪子心做 Java 漏洞研究他有提过怎么去挖 Java 的 0 day Java 的一些 0 day 漏洞是需要做某个配置的情况下才会触发这个 0 day。有些人会在社区里面教别人去做那个错误的配置。很多外面采集的一些数据给的修复方案其实都是不对的。我其实觉得没有什么特别多的技巧每个漏洞可能需要去梳理它真正的影响包括漏洞的修复方案可能要去做一些校验。这样推给研发去修的时候保证安全的专业性和权威性不受到挑战。 Q2软件供应链攻击的威胁和防范措施供应链的透明度和可追溯性供应链安全与合规。 | 某软件厂商大佬第一个问题实际是供应链的一些能力建设第二部分其实更多的是软件供应链资产台账的建设。第三部分更多的其实合规一个是出海可能更多的是考虑许可证的合规。另外是国内自主可控信创的一些合规。下次可以围绕这个问题专门来做一次研讨会。 Q3如何减少供应链漏洞的误报情况 | 某软件厂商大佬减少误报我理解是有两件事情要做。 第一件事情是识别的供应链成分的准确性这一部分我们过去的一些实践主要是去识别比如像 Java 的很多项目它在 pom.xml 里去做配置的时候有标记 scope 为 test 的有的是 runtime 的等等它有不同的标签。不同的标签对应组件是会在不同的这个编译环境里面去用到的。这是一个需要注意的地方比如说测试环境会用到的组件可能在线上不会受影响那么再去发漏洞的时候要把这一部分排除掉。 第二块是在做供应链成分分析的时候要考虑成分分析的准确率。比如说像 Python做包管理工具做包管理依赖的时候可能不会识别准确的具体版本当去泛匹配的话那可能会导致误报这是最基础的一些误报当然还有很多其他情况。 第二个主要情况漏洞可达性的验证在海外做这件事情是非常多的但是国内提的非常少。我们统计 95% 以上的漏洞是误报比如 fastjson 只是匹配到这个版本是有漏洞的但实际上 fastjson 缺陷类函数方法在代码里面会不会触发包括说它触发的这个函数类方法在代码里面有调用但它的污点是不是能够传进来一些被可控的参数甚至说有一些漏洞它对于依赖环境像 JDK 版本有依赖那它才会被触发的。那这些都是在减少误报检测结果的时候需要考虑的点。在海外有比较成熟的基础叫漏洞可达性的分析我们目前做的比较多的是函数类方法这种代码级别的识别最近也在做依赖环境识别的这种匹配降低漏洞不可达的情况。 上面的回答中也有提到研发让演示漏洞是不是真的受影响。有时候研发其实比安全更懂代码中漏洞会触发这个函数类方法其实是没有调用的这会导致说研发会质疑安全给的结果是不准确的。 | 某软件厂商大佬我是比较赞同刚才说的那两种思路其实还有种方法是把漏洞库串起来可是我们对于工具改造这方面是没有太多经验因为我们得用公司的产品。我们维护的其实是漏洞的利用条件。另外一种是针对误报的漏洞维护误报的漏洞库反向去优化我们的漏洞库。 | 某互联网企业大佬有些困惑为什么大家会有误报的问题除了 fastjson、log4j 这种影响范围比较大的其他的高危漏洞顶多影响几十个几百个资产修复成本也不高。 | 某软件厂商大佬其实有一些公司有一些组件依赖比较复杂要做升级可是系统现在已经没有人维护了新人刚接手要去维护这个老系统要做升级升级完之后可能会出现兼容性问题所以不太愿意修。 另外有一些公司研发相对来说比较强势项目的进度又卡得比较紧很多时候研发的心理是我不想修漏洞我也不认可安全天天让我修漏洞这件事情那研发就会质疑漏洞是真的会有影响吗如果研发刚好很懂安全判断代码逻辑里面确实是不会被这个漏洞触发如果发生了这样的质疑安全再找他去修漏洞他的配合度肯定就不高了。因为只做版本匹配其实只是一个潜在的隐患。并不意味着说这个漏洞一定会触发或者说会对线上代码造成影响。很多公司的研发部门会对这件事情质疑比较多的。 但像在某某云这种国企单位或者公司管控要求很高尤其是国家的基础设施那公司有制度那就必须要改研发的配合度会很高。但是大部分的泛互联网的客户其实很难解决这个问题。 Q4怎么有效建设推广建设好之后怎么能充分发挥作用 | 某软件厂商大佬今天咱们先不展开先讨论主要通用的方法。第一运营推广像某某云的经验基本上会出制度、规范、要求。某某云是提了漏洞清零的要求所有交付给客户的基础容器的漏洞是要求清零的。出制度、出考核出奖惩去做制度的宣贯运营给研发提供配套的工具。去做考核某某云的推广是比较强的。问题里提到得不到开发的认可就暂停了。我个人感觉应该是公司管控要求没有那么严。 Q5主要矛盾和收益如何定义 | 某软件厂商大佬之前是事件驱动现在每天不一定有那么多事件那去做这件事情就相当于原来的驱动力没有了例行做这件事情的话长期的收益怎么去评估。 我原来在贝壳的时候和在百度的时候做安全的思路和理念发生了一个非常大的变化也有可能是因为在贝壳的老板是建行出来的。互联网公司典型的思路是出大的事件了那我赶紧趁机会把能力建设一下。但是在银行或者在很多关基行业它的建设是比较倾向于先把整个公司整体的风险降低比如说要把整个资产识别出来比如说办公网、生产环境、包括外采的系统的所有的资产梳理出来梳理出来之后会去分析。尤其 CTO 甚至 CEO 这个层面关注的是能不能讲清楚整个公司在软件供应链安全这个方向全局的现状是什么样子的比如有多少资产这些资产有多少隐患隐患是否可以通过我们历史发现问题来解决比如说美团所有的SRC发现了多少类似漏洞或者出现了多少攻击的事件护网期间有多少攻击事件从所有的维度去统计出来全局的资产关联了有多少风险。甚至说从分析结果里面去预测出哪些重点资产重点业务对应的漏洞是公司最大的潜在风险。接下来今年会根据以上结果将潜在隐患风险最大的一些系统作为今年治理的目标明年可能这个要求可能会变得更高当资源更多了那就可以做二期的治理。这是从自身去分析公司的主要矛盾是什么。 另外一个维度是横向对比横向对比的逻辑是在同类行业里我公的安全建设做的好一点可能就不来攻击我从而去攻击别的友商了。比如同行业大家做的怎么样举个蚂蚁的例子蚂蚁本身有金融属性和互联网的属性所以蚂蚁对于持续保证安全能力的领先性和深度是有很强的能力的。 另外一个方面是把全局风险说清楚。在说清楚前提下leader认可并确定要把这些重要的风险进行治理那就会投入资源。如果leader不认可风险需要治理至少是把负责的方向说清楚我觉得这是做安全的一个很重要的逻辑。要给leader讲清楚公司现在有多少潜在的风险需要投多少资源能够治理到什么程度。至于需要治理到什么程度交给公司来做决策。但是如果说不清楚作为员工责任就比较大了。 | 某互联网企业大佬你的前提是先建设资产的视野。资产是肯定要做建设的但后续的漏洞管控可能未必算成一个风险从case来看实际利用漏洞的case是比较少的包括实际有用 log4j 来产生攻击的。目前偶尔有漏洞扫描的诉求平心而论风险没有那么高。 | 某软件厂商大佬需要看每个公司具体的情况美团其实在这块投入还是非常多的基础安全做得相对来说很不错。所以我觉得这个地方需要评估有无存量的全局风险。如果没有那重点可能是在新出 0 day或者新出漏洞的时候保证治理好就可以了。 | 某互联网企业大佬分享一个视野我发现内部找不到漏洞之后其实有很多自己研发的组件是有升级诉求的。 | 某软件厂商大佬这个我了解到有一家互联网公司目前正在做。他们的案例是做源安全网关。在私有源卡所有的内部二方组件内部开发的通用组件要传到私有源的仓库里面去必须保证所有二方组件上传的时候是没有安全问题的。 | 某互联网企业大佬我这个视野不是从安全角度出发的。我发现的痛点是对二方组件研发有低版本的困扰低版本可能不稳定有一些功能不兼容所以需要升级的但是自己推起来又非常困难。其实我们可以帮公司的组件做统一版本管控这可能是安全之外收益。 Q6AI 如何帮助企业预测和防止那个供应链中的安全威胁 | 某软件厂商大佬分享一下我们最近和 AI 结合做的一些探索。小范围分享一下我们的一些想法。结合 AI ,我们不是做预测主要是解决软件供应链安全的问题。 第一是在做开源组件选型相关的事情。我们发现软件供应链安全的问题不能简单的把它理解成一个安全的问题。比如在选用某一个组件或者升级某一个组件的时候不仅要考虑解决安全问题还要考虑这个组件的可扩展性社区维护的健康度、成熟度场景的适配比如说在金融行业的场景是不是能够适配交易支付这种场景能不能适配。所以在组件选型方面我们用 AI 来做做开源组件选型的智能分析。对内容提炼和总结做场景的分析在什么场景下适合用什么样的开源组件。 另外一点是生成修复代码或者说是做软件升级的兼容性评估。我们发现升级一个软件的时候大家会考虑升级完之后会不会有兼容性的问题。就要分析大量这个组件的不同版本之间的差异和它的一些 issues 、release notes 的信息。我们在这方面用 AI 大模型的总结提炼的能力来做一些探索。 Q7分析依赖状态和威胁程度 | 某软件厂商大佬前面ppt里有提到我们可以把所有代码仓库中所有软件的依赖成分全部分析一遍然后去关联出来漏洞的严重程度做漏洞的影响分析和数据统计。我们在这方面做了一件事情把 CVE 威胁重新建模把威胁分了三类强烈建议修复、建议修复和可选修复。强烈建议修复是把有POC、EXP 的风险等级高危严重以上的漏洞单独梳理出来作为真正有影响的。做威胁程度的分析还可以关联单个漏洞影响多少资产或者业务的重要程度是什么以此做分级的处置产出报表。我觉得这个是去做价值分析很重要的一点。 Q8如何加强开发者对于软件供应链安全建设的价值的认同 | 某软件厂商大佬我觉得企业去做软件供应链安全建设很重要的一点是深度依赖开发者来参与这项工作比如开发者修复安全漏洞所以需要开发者对于安全建设的价值认同。这个过程中我认为有两个点是非常重要的。 第一点是要通过一些事件甚至是通过企业内部的一些事件案例做企业内的真实案例分享这是比较有效的一种方式。比如说 log4j 、fastjson 出现漏洞导致公司出现安全事件或者通过蓝军攻防模拟做攻防演练发现代码是可以被攻击导致公司数据泄露或者导致服务被入侵的风险。 第二点是在治理完安全风险后不仅仅需要给安全的老板汇报还需要做面向企业内部的正向宣传。通过正向的宣传可以让开发人员了解安全的真实影响和风险。比如说定期开展内部案例分享哪些开发者哪些部门在开发环节在做开源组件选型准入的时候已经把项目的安全性提升得很好。甚至哪些业务部门在每周、每个月解决了哪些安全问题解决的时效性解决效果怎么样。还有一个做法是可以每周每个月可以把建设的成果给所有参与到这项工作里面的开发者做分享培训像是风险数据的公示、内部访谈标杆案例。这样也可以比较好的建立开发者对于整个软件供应链安全建设价值的认同。 Q9如何量化和体现供应链安全治理效果 | 某软件厂商大佬有一些关键的指标比如漏洞处置的时效性平均每个漏洞修复的数量资产台账相关的风险下降的数量突发 0 day 漏洞或者供应链漏洞处置的时效性单事件的处置效率提升度等。 如果是作为偏关基行业来说流程制度的完善度行业的最佳实践论文专利优秀课题的评选都是可以从直接、间接的说明价值的。
自由讨论
| 某物流企业安全大佬我从比较老的传统企业转到比较互联网化的公司现在的主要问题是 SCA 流程建设起来后老板的中心思想是降本增效为主尽量企业内部自己做节省资源。做 SCA 这个事情的时候我们这边的研发会比较配合来修复漏洞但是一定要有比较精确的修复手法。比如说高危漏洞或者是 fastjson 类型的约定好必须做修复。我们也调研了很多产品Murphysec 产品有一个功能是代码真实调用这也是可以作为精确修复的一个条件。 第二个问题就是在低资源的情况下该怎么投入。现在流程是跑起来了高、中危漏洞基本可以被解决掉研发和安全也形成了一些比较好的互动和规范。但是在老板不愿意投入资源的情况下作为安全应该怎样去衡量和对应。比如业务增长到了什么体量供应链安全应该做到什么程度或者人员上应该投入到什么程度才达到一个比较好的效果。好像业界没有衡量的比例或者标准。所以说这一起讨论一下大家是怎么做的
| 某软件厂商大佬这个问题我感觉和美团的问题有点像治理到一定程度驱动力可能已经没有了那还要不要再投入呢 我先抛个砖我以前尝试过一些比较有效的方法 第一点是同行业、同规模企业的对比。比如说美团和百度、腾讯进行对比这个方向同行业公司投入了多少人做到什么了程度。举个例子蚂蚁的很多漏洞可以做到自动化修复而且蚂蚁要求全部修复等等。 第二点是回归企业内部实际风险的角度从攻防的视角去暴露风险。检测出来漏洞之后通过类似红蓝对抗的做法找一些真实的漏洞做渗透或者内部找一个重要业务系统的重要漏洞做内部的攻防做实际的演示发现漏洞会导致多少数据泄露。 在08年左右百度在安全方面不是很重视也没有很多资源当时剑心在百度做的第一件事情是去攻击内部最核心的系统给老板汇报风险情况这是很直观地让老板看到风险的重要方式。
| 某物流企业安全大佬这样确实比较合理攻防角度我们也在应用但是基本没有什么供应链安全的漏洞了。同行业的对比下我们投入确实是不太够的。
| 某运营商安全大佬简单补充一下在我们软件供应链刚起步的阶段促使我们给软件供应链安全的投入最大的原因是和整个阶段有关系的。首先传统的做法是一直在做防护在做检测。比如前面美团大佬提出来的 log4j一个企业里面是避免不了会有非标应用存在的我在这个方面去投入识别但也做不到 100%。那就要去模拟攻击然后做这方面的检测等等把缺失的弥补起来最终达到一个标准。 我们发现这一块的投入很高。当一个漏洞出现的时候比如说 log4j 我们去分析成因以及从攻击者视角分析利用链的时候没有办法很快的确认影响面的时候特别是当时受 log4j 影响的资产有 2500 多个没有办法很快的让业务完成修复和分优先级。 所以我们当时的做法是拆解攻击链和利用链大概拆解了六步六步的利用链里面涉及到 DNS 涉及到执行的具体代码。总归是在这六步里一步一步的拆解在网络层代码运行时在其他的环节层层设限设卡在内网里去投入一些能力让这些反向连接出不去等等这些操作。再从事件响应的角度上去投入这件事情成本是非常高的而且业务影响也会比较大。那几年有很多核弹级的漏洞爆出来业务本身也经受不住这种折磨他们也会主动的去提出安全是不是有更好的方法来前置解决所以我们可以适当性的给业务找一些麻烦。 在这个过程中我们发现投入一些精力在安全左移上面包括三同步从采购对非标类的应用纳入管控新产品的上线要列入检测等。在这一套逻辑上如果加入了供应链安全方面的检测能力和手段或者知识库的储备那实际上对于事件响应的成本而言是有极大降低的对效率是有极大提升的。从这个角度来看 ROI 投资回报比肯定是正向的。
| 某银行安全大佬当供应链建设到一定阶段包括黑白灰、SCA 都建设起来之后下一步的建设方向是什么想请教下大家。除了持续优化建设工具的漏洞发现能力、漏洞修复能力、漏洞准确性。其他的建设方向是什么 我有几点想法各位可以看一下可行性。一方面是 AI AI 我觉得未来可以体现安全价值。第二方面是应用安全数据的审计我今年做了一些应用数据安全审计方面的建设。调研了很多头部厂商都有一个问题是大家都是基于流量层的产品把流量镜像过去然后看流量里面有没有关于 API 的敏感数据传输。但是我们这边的数据加密是比较严格的没有办法解密这种设备就失效了。在实践中发现 IAST 对解密流量的支持是非常好的不知道这两方面能不能结合。 第三方面不可达漏洞的验证。我们在漏洞修复的时候我们的场景基本是拍脑袋。一方面是看业内修了哪些漏洞第二方面是看漏洞能不能利用是不是有威胁。所以不可达漏洞分析也是我们未来考虑建设的一个方向看大家有没有有其他好的想法可以参考一下。
| 某出海企业安全大佬我们现在流程都建起来了最近刚好在定下半年目标。我们的业务场景比较复杂包含比较多IoT云端、APP、嵌入式等还包括各种智能家居的硬件可以建设的方向很多。我们接下来的方向是找一些过去覆盖度不够的业务去重点做威胁建模。比如我们对外的一些业务是要开发者来接入我们的平台包括 SDK 这类的东西会站在开发者的角度发现 SDK 里面有没有问题。对接云平台和 APP 嵌入硬件开发的过程中我们会对外提供一些 IDE 插件但是这些东西可能过去覆盖度不够深入这个会是我们后面重点的方向。
| 某互联网公司安全大佬我们最近也在做 AI 方向的建设比如我们在做 SDL 的时候会涉及到流程推动或者工具的 QA 问题。通用的 QA 问题或者是修复建议比如安全SDK。我们会把一部分类似于客服的工作转交给AIGC。
