域名解析国外动态软件有哪些_百家讲坛 | 软件供应链的四个关键痛点思考与实践

刘志成，乐信集团信息安全中心总监、OWASP广东区域负责人、Cyber​​ Plus社区杰出专家，专注于企业数字化过程中的网络安全风险管理，对大数据、人工智能、区块链等新技术在金融风险管理领域的应用，以及新技术带来的技术风险管理有丰富的理论和相关经验。

关于软件供应链的理论、方法、模型和热门文章已经不胜枚举，我至少在三个场合、三篇文章中表达和阐述了我的观点和立场。在这篇受网络安全社区委托的文章中，我将从深入实践的角度重新审视我认为存在的普遍误解和尚未解决的问题，希望给同行们带来一些启发和思考。

01

需要

我想重点关注四个领域。

第一是业务系统、软件和组件。这是信息时代企业信息系统的主流获取方式。即使在数字化转型呼声此起彼伏的今天，这仍然是传统行业信息系统最大的落地方式。对于数字原生企业或者数字化转型比较完善的企业，一些基础的管理功能、非关键的支撑系统、底层的信息基础设施，仍然是难以避免的信息系统落地方式之一。

第二是开源系统、软件和组件。数字时代信息需求的复杂性、多样性和波动性催生了如繁星般璀璨的创业公司，创业资源的整合需要生态协同。开源模式不仅是单向的公益输出，也是从社区引来众包资源、丰富产品能力的关键渠道。但开源软件研发组织协作模式的松散性、目标的不确定性、商业价值的逐利性带来了更多风险和问题。

第三是移动互联网时代的APP第三方SDK与服务。移动互联网已经是一个步入中年的名词，其实从兴起到现在也不过十几年的时间，技术的演进与变化融入了微服务的概念，在整合第三方SDK与服务时注重功能的协同，忽视了系统的治理与管理。在《个人信息保护法》、《数据保护法》密集出台的合规背景下，安全与隐私保护风险日益凸显。

第四，遗留废弃系统。信息技术的更新周期极快，随着业务需求的频繁变化，主流的敏捷交付模式，新系统、新功能陆续上线，由于业务变更、技术变更，部分系统被废弃。但由于下线流程不规范、不标准，存在资源回收、业务暴露等风险。对于部分因零星业务需求而未下线的系统，存在维护资源不足，或者商业软件失去商业服务的相关保障。以上四个方面在软件供应链安全中需要的风险和管控措施，以及安全意识教育和管理流程的落实上存在差异。不同企业的安全团队背景、与技术团队、业务团队的协作模式都不同，容易导致损失，给企业带来额外的风险。

02

商业软件

一般而言，商业软件都有供应商持续更新、处理和解决安全问题，并有相应的合同通过服务水平协议（SLA）来保证软件的安全属性，供应商承担相应的责任。当然，已经过了服务期限或不再属于供应商服务和保护范围的软件和历史遗留系统则被归类为遗留和废弃系统。

理想的商业软件具有完善的产品开发安全管理，发布的软件在软件开发周期安全管理流程（S-SDLC）的需求阶段已经进行风险评估，在设计阶段已经进行安全能力集成，在开发阶段已经进行代码和集成安全测试。在客户端部署提供云服务时，具有安全防范能力建设，配置相应的安全保障策略，在安全测试和监控过程中支持客户进行安全预警的应急响应和服务，承担相应的安全责任，并将相关安全风险转嫁给客户。当然，在现实环境中，商业软件公司要么忽视安全研发管理，要么缺乏安全研发管理能力，要么部署实施人员缺乏意识和能力，导致商业软件带伤上线。在我个人的实践经历中，国内一家以移动设备安全管理（MDM）闻名的厂商，在检测中发现了6个以上的高危漏洞，并及时进行了修复、响应和整改。 国外某厂商的ESB存在明文传输密码的低级漏洞，还以整改需求属于商业开发为由威胁付费整改，不支持SSL协议部署的补偿方案，让人意外。当然，在国家攻防演习中，频频曝光安全漏洞的厂商也会犯一些低级问题，这些是研发过程中安全管理阶段流程、能力、意识缺失带来的安全隐患。

因此，企业在采购商业软件时，需要增加供应商安全能力评估环节作为采购依据，并在采购合同中明确供应商的安全义务与责任，避免采购、部署、运行过程中出现权责不清、响应不到位、整改不及时、责任不落实等被动局面。在实践中，对供应商的评估包括能力评估、流程评估、可信度评估，明确安全责任条款响应与合同约束，实现对安全的一票否决权。

03

开源软件

开源软件的起源、背景、目的、运作模式千差万别，供应商的能力、资质、目的和意愿，以及所承担的责任和义务都不一样。同时，不同企业采用开源软件的目的、目标和使用方式，与企业的商业目标和宗旨，以及对开源软件本身的贡献和投入的目的和宗旨也有所不同，其复杂程度远远超出了商业软件的范畴。软件产品企业在采用开源软件和组件时，除了要注意安全风险，还必须注意相关的许可协议、责任和商业使用风险。这也是一些软件组成分析（SCA）厂商的卖点之一。本文主要关注安全风险的评估和治理，因此这部分内容不再赘述。

对于单一业务的应用系统，开源组件的治理由于团队规模、业务复杂度等原因并不复杂。但对于多业务团队、多应用系统、分布式开发团队或者敏捷开发团队来说，如果开源组件的引入、应用、生命周期管理缺乏系统化、统一化，就会带来治理的复杂性。在现有开源组件治理过程中，一位业内朋友，有数百个开源组件，涉及上千个研发项目，由于公司没有组件引入管控流程和安全风险整改流程，付出了巨大的代价。

企业的架构委员会或开源组件治理委员会需要建立开源组件引入审核机制。任何开源组件引入都需要经过可用性和安全性评估，包括开源项目背景、主要贡献企业、主要贡献团队、项目宗旨、团队稳定性、版本发布的稳定性、应用的流行度、用户评论的可用性等。对组件架构、安全机制、管理机制、路线图等均应进行审核，充分确认与企业场景的匹配性、开源组件的可用性、可持续性、连续性、兼容性。建立可信工件库作为企业开源组件的唯一可信来源。对于开源组件的二次开发修改，必须以企业为依据进行评估、测评、实施，为安全漏洞的修订整改打下基础，避免版本和二次开发带来的复杂性和安全风险。

目前市场上开源组件的安全治理主要集中在问题发现阶段，由于开源软件种类繁多，且存在长尾效应，开源组件安全厂商很难对开源组件安全漏洞进行详尽的验证，也难以实现场景化的代码级修复建议，这项工作尚未闭环。由于缺乏对供应商的义务约束，开源软件可能不再对漏洞进行更新和修复版本，难以降低风险。企业也可能因为定制化的二次开发而难以直接升级开源项目的新版本，在缺乏POC验证和代码级修复建议的情况下，其评级机制和安全修复安全团队需要面对来自研发团队的质疑和挑战。因此，开源组件的安全修复是目前难以逾越的鸿沟和特定的难点。

我曾经和主流的SCA厂商、第三方SRC运营者探讨过如何实现开源组件的安全修复。解决长尾问题的路径包括基于行业特征的开源组件漏洞POC验证能力和代码级修复的订阅服务。各行业通过对TOP20公司的扶持，基本可以覆盖80%的开源软件漏洞修复，20%可以基于人力支持提供增值服务。在这个过程中，开源组件安全厂商可以建立自己的先发优势和知识库门槛。初期的开源组件POC验证和代码级修复可以通过开源项目或者SRC众筹的方式建立起来，可惜目前为止，动作相当有限。

04

APP第三方SDK

APP在移动互联网的价值与挑战一直是数字化无法回避的话题。APP的下载和推广成本日益增加，小程序、H5在快速业务推广、快速应用方面具有优势，但业务发展到一定阶段后，平台约束、切入痛点往往无法回避APP回归、用户终端环境验证、用户定位与环境、行为数据收集等话题。面对国家合规要求、用户知情同意等要求，APP在夹缝中生存，在合规与业务需求之间寻找平衡点。具备广告、引流、终端能力优势的第三方SDK是APP快速发展、满足业务需求的前提。不可忽视的是，第三方SDK是一把双刃剑，在满足业务需求的同时，也给业务合规带来风险。国家网信办主导的APP安全治理逐步深入，第三方SDK的合规整改报告频频见诸报端。 这就要求企业建立对第三方SDK的评估、管控和处置的生命周期管理能力。

朋友的公司遇到过不同业务APP集成不同第三方SDK版本导致研发流程变化的效率问题，以及APP开发第三方SDK基线的评估和建立问题。对此，第三方SDK引入的评估与商业软件的管理是一致的，需要做好引入的管控。在第三方SDK的管理上，需要借鉴开源组件的治理，建立统一的产品库和统一的安全基线，避免重复引入有风险的安全组件的问题。

第三方SDK的隐私保护检测和运行时动态监控能力很容易被忽视，这与传统的静态检测不同，第三方SDK的后台服务涉及动态数据采集和处理，需要及时监控，避免违规风险。

05

遗留和废弃的软件

业务下线是业务生命周期流程中的一个环节，软件下线则是软件生命周期中的关键环节。两者有紧密的关联性，但也有具体的区别。不同的公司可能有不同的流程体系或不同的文化，也有不同的团队来支撑其实施。协调不足、经验和能力不足带来的问题不容小觑。

朋友所在公司按照常规敏捷模式进行业务和系统关闭，缺乏标准化流程和验证机制，导致仅仅关闭域名解析，停止软件系统服务、回收硬件资源、归档备份数据，缺乏相应的流程和机制。由于长期暴露在内网，部分微服务架构由于域名解析配置问题，在互联网环境下可以通过域名拼接的方式访问，从而产生相应的攻击面暴露风险。

当然，以上例子涉及的检测、治理和验证方式有很多，如果有资产管理系统、流量分析监控系统、资产暴露检测监控系统，就可以发现问题，并改变控制措施。本文仅从软件供应链安全的角度，针对遗留和废弃软件的治理，提供相应的解决方案。

需要建立完整的业务下线流程，所涉及的软件系统需要从数据归档、资源释放、服务下线的完整流程建立并执行审计、检查、验证机制，避免因系统废弃而造成的资源浪费和安全风险。

由于历史原因，遗留系统仍有零星的业务需求，无法下线，软件系统由于资源问题、服务周期问题等难以规范地应对和升级安全风险，这对安全团队来说是一个很大的挑战，补偿措施和风险承受能力，以及应用级的行为检测和响应，或许是规避安全风险更可行的方法。

软件供应链安全是目前的热门领域，相应的方法论、理论研究探讨、安全产品层出不穷。但场景化的需求决定了能否发现、解决、管理相应的问题与风险，并带来实用价值才是选择的唯一标准。作为安全团队负责人或者软件供应链安全负责人，需要在功能满足、能力建设的基础上关注运营需求，在实践过程中不断发现不足和问题，深入思考，提供前瞻性、全局性的解决方案。本文针对一些容易被忽视和忽略的具体点，提供给大家参考，也希望能给推动软件供应链安全领域的发展带来一些启发和帮助。

- 结尾 -

强调

活动期间

强调

内坦加社区奉献活动