通常在任何一个企业或者组织中要讨论一件事情的价值,必须要结合企业的业务场景来讨论,我这里先列出来在所有不同的企业中大家关心软件供应链安全的所有维度,然后我们再单独拆解每一个维度进行分析,如何说清楚这一部分的价值,当然最后还是要根据企业的业务属性,总结出来企业最重要/公司战略层面最关心的问题来说明价值。
建设产生价值 = 降低风险(软件供应链资产 * 资产关联风险) + 提升品牌影响力
软件供应链资产 = 开源组件 + 开源软件 + 商采软件 + 办公软件
资产关联风险 = 数据泄露 + hvv攻破 + 业务连续性风险 + 满足客户合规风险 + 许可证合规风险
软件供应链资产台账
对于一个企业来说,所有的信息安全风险都是跟资产相关的,所以在分析软件供应链安全风险的时候,我们肯定也是需要首先从软件供应链资产出发:
开源组件:企业所有软件项目直接或者间接依赖的所有开源组件及这些开源组件的依赖关系
开源软件:企业所有使用的开源软件
商采软件:所有从外部采购的商业软件,包括直接采购的软件、采购的硬件中包含的软件资产
办公软件:所有员工办公用到的所有供应链软件
资产关联关系:软件所属负责人、部署的服务器、业务级别、是否涉及敏感数据、关联厂商等等
盘点清楚软件供应链资产的好处:知晓全局的风险情况(后续所有的量化管理都有了分母)
一旦某个供应链资产曝出0day漏洞或者投毒,可以快速响应
可根据全局风险进行分类分级,分阶段规划进行治理
数据泄露风险
对于任何一个涉及信息化和数字化的企业来说,当谈到安全的时候首先关注的是数据安全,在数据安全的问题中首当其冲关注的就是不要出现严重的安全事件,所以当你去聊软件供应链安全建设的价值时,首先要考虑的是在你所在的企业里软件供应链的攻击是否会造成企业的数据泄露风险?
可以从以下几个维度去量化数据泄露风险:
历史安全事件数:历史上所有由软件供应链安全漏洞/攻击导致的与数据泄露相关的事件
关联数据泄露风险:历史安全事件可影响泄露的重要数据规模
潜在威胁分类:可能导致以上同类型的安全事件的风险分类,含开源组件漏洞、商业软件漏洞、投毒事件、办公软件漏洞、外包开发系统风险等
潜在威胁统计:当前公司所有的软件资产中涉及以上每一类风险的数量,如开源组件漏洞数、商业软件漏洞数、投毒事件数量等等
hvv防守能力提升
这个价值适用于需要参加hvv的企业,最近几年hvv比较主流的攻击方式就是通过供应链资产进行攻击;为了提升防守质量可以考虑提前做几项工作:
盘点软件供应链资产,提前梳理攻击面(可量化)
针对这些软件供应链资产,该修复修复,该下线下线
涉及三方商采软件供应链资产的需要通知厂商来值守
业务连续性保障
历史事件数:历史上所有由软件供应链安全导致业务连续性的事件(如:被攻击导致挖矿、勒索事件等)
事件关联影响量化评估:业务中断时间、业务中断导致的损失等
满足客户合规
作为软件供应商,客户要求提供软件安全评估报告、SBOM清单等
盘点历史所有的客户要求记录:如xxx客户要求提供软件物料清单
如果不满足导致的后果说明
提升许可证合规
业务出海或者监管单位做安全认证,要求出具许可证合规认证,一般找公司负责知识产权合规的法务同事可获取相关信息
盘点历史所有涉及开源许可证合规要求的记录
如果不满足导致的后果说明
品牌影响力价值
如果您在的企业是某个行业头部企业或者正在冲击行业头部,那么在软件供应链安全领域的前沿探索及落地,能够提升企业在行业内的品牌影响力
横向对比同行,说明这块的先进性
预期对外加强技术影响力建设的收益:专利、技术分享、奖项评选等
注意:当你在表述这些价值的时候,一定要把最终的落脚点落到和企业经营相关的重要指标上来(最好从公司当年的核心经营指标出发,这样能够迅速和各个管理层达成共识),比如成本下降、明确的合规风险、具体的损失等等
2
运营成本
软件供应链安全建设要达到预期的效果,通常需要通过持续运营的方式来保障,这里的运营工作主要包含三部分:
运营成本 = 工具部署接入成本 + 漏洞修复成本 + 安全运营成本
工具部署接入成本
降低这部分成本的最核心关键在于:首先需要评估出来公司当前涉及软件开发流程和管理流程中已具备哪些成熟的基础设施(IDE、代码仓库、私有源、CI/CD、容器镜像管理等),然后第一阶段的建设设计方案最好和当前成熟的基础设施无缝集成(无需额外的代码开发及额外的采购);然后最好是在做分期规划建设的过程中优先建设性价比最高的部分,价值明确且相对投入成本最低的部分。
成本的核算需要关注三个维度:人力及预算、时间、项目管理成本
需要和哪些相关部门联动,得到哪些部门的什么样的支持;一旦涉及到跨部门需要的支持越多,那么通常这里面除了实际的研发成本投入之外还有巨大的潜在沟通和管理成本,所以建议设计方案时,最好是能够无缝适配,减少其他部门的人力投入
如何需要涉及到其他部门的配合,一定要关联部门给出成本的评估,如人/天 甚至关联预算成本等
此外就是自身项目组在这件事情的落地上需要投入的人力、预算成本、时间排期等
漏洞修复成本
我们今年跟大部分之前已经做过一部分软件供应链安全建设的客户交流时,听大家提到的最难的问题是什么?就是发现费了很大劲部署了工具之后检测发现的一大堆问题都没办法解决,导致预期要解决的问题无法闭环解决落地。究其背后原因,很多时候我们在做方案的时候,很容易只关注预期能解决什么问题、系统建设的成本等,而忽略了在实施过程中发现的安全问题解决的成本:
首先在做方案时,要说清楚预期每个阶段要解决哪些问题?通常来说第一个阶段肯定是解决那些能轻易被攻击的漏洞及关键业务系统的问题
需要评估调研这些关键问题,有多少占比是可以用多少成本修复的,预估单漏洞修复用时;这里也是墨菲安全花了很大功夫在做的事情,如何持续降低单漏洞的修复成本(通过更详尽的兼容性评估、可操作的修复方案及漏洞真实影响分析等)
给出以上数据的量化评估:阶段性可解决问题的占比、单个问题预期修复所用时长(这些都是后期考核时所需的关键指标)
安全运营成本
软件供应链安全治理时,首先我们大的思想是软件开发者是软件安全的第一责任人,安全的职责是管理+赋能。在这个定位清晰的情况下,我们需要做的运营工作:
管理相关制度、规范、流程建设
管理相关要求的宣贯、培训、考试等
工具使用的培训、技术支持等
工具的持续迭代、策略优化等
阶段性治理效果量化统计输出,同步给所有参与这件事的管理层及执行层,让每一个参与的人知道自己付出的每一份努力所带来的价值
3
关于OSCS社区技术开放日交流活动
上一篇技术文章我有提到会创建一个技术交流群,暂时我们把这个群命名为软件供应链安全技术交流群(OSCS),社群会定期组织技术开放日交流活动,包括线上技术研讨会,线下闭门会,年度技术峰会等。
我们预计在 7月18日 举行第一期技术开放日的活动,为保证探讨的深度和质量,我们决定采用闭门的线上研讨会形式,邀请甲方技术大佬进行主题分享和研讨。下面是活动介绍:
研讨主题
企业软件供应链安全建设价值
研讨目的
参与收获
研讨议程
研讨时间:下周二(7月18日)晚上19:30
研讨时长:预计90分钟(含分享+研讨)
研讨方式:腾讯会议网络研讨会
参与人数:为保障研讨质量,限定15-20人
参与要求:实名参与,甲方相关方向技术负责人
成果输出:研讨结论我们会脱敏后形成文字稿,在获得与会人员许可后通过公众号等方式向社区分享
参与方式:加一下OSCS社区运营同学微信,备注公司-姓名,审核通过后,运营同学给大家发送直播链接,并邀请加入社区交流群