作者简介：刘志诚，乐信集团信息安全中心总监、OWASP广东区域负责人、网安加社区特聘专家。专注于企业数字化过程中网络空间安全风险治理，对大数据、人工智能、区块链等新技术在金融风险治理领域的应用，以及新技术带来的技术风险治理方面拥有丰富的理论和相关经验。
关于软件供应链的理论，方法，模型以及普及性文章已经汗牛充栋，我个人也在至少3个场合，3篇文章进行过观点，立场的表达和阐述。网安加社区的这篇约稿，我就从深入实践的角度重新梳理一下自己认为存在普遍误区和难题尚未突破的领域进行一次剖析，希望能给同仁们带来一些启发与思考。
一、需 求我重点要谈及的涉及到4个领域。
一是商业系统、软件、组件，这是信息化时代，企业信息化系统的主流获取方式，即使在数字化转型呼声此起彼伏的当下，对传统行业而言，这仍是占据最大份额的信息系统实现方式。数字化原生企业或数字化转型比较充分的企业，一些基础的管理功能，非关键支撑系统以及底层信息化基础设施，仍是难以绕开的信息化系统实现方式之一。
二是开源系统、软件与组件，数字化时代信息化需求的复杂性，多样性和易变性，催生了璀璨星辰般的创业企业，创业资源的整合需要生态的协同，开源模式不仅是单向的公益输出，同样是在社区汲取众包资源，丰富产品能力的关键渠道，但开源软件研发组织协同模式的松散性，目标的不确定性，商业价值的利益驱动，带来更多的风险和问题。
三是移动互联网时代APP的第三方SDK与服务，移动互联网已经属于一个进入中老年的词汇，其实其崛起也就十几年的时间，技术的演进和变迁，融合了微服务的理念，集成第三方SDK和服务时，重视了功能的协同，忽视了体系化的治理和管理，在《个人信息保护法》《数据保护法》密集出台的合规背景下，安全和隐私保护风险日益突出。
四是遗留遗弃系统，信息技术的更新换代周期极快，随着业务需求的频繁变更，以DevOps为主流的敏捷交付模式，新系统，新功能上线，因业务变更，技术变更，一些系统被废弃，但由于下线流程不规范，不标准，存在资源回收，业务面暴露等风险，对一些因零星业务需求未下线的系统，缺少维护资源，或商业软件已经丧失了商业服务的相关保障。上述四个领域在软件供应链安全中，存在的风险，需要的控制措施，在安全意识教育和管理流程的落实上，存在差异，不同企业不同安全团队与技术团队业务团队协作的背景，模式不同，容易顾此失彼，给企业带来额外的风险。
二、商业软件商业软件一般而言是具有供应商，持续更新，处理和解决安全问题，有相应的合同通过服务水平协议（SLA）保障软件的安全属性，由供应商承担相应责任。当然，相对于已经过了服务期，或不在供应商服务，保障范围的软件和历史遗留系统，归属于遗留和遗弃系统处置。
理想的商业软件是具备完善的产品研发安全管理的，所发布的软件在软件开发周期安全管理流程（S-SDLC）中需求阶段进行了风险评估，设计阶段进行了安全能力集成，研发阶段进行了代码、集成的安全测试，在客户侧部署和提供云服务时，具备安全的预防能力建设，配置了相应的安全保障策略，支持客户在安全检测和监测过程中安全预警的应急响应和服务，承担相应的安全责任，转移客户的相关安全风险。当然，现实环境中商业软件企业要么疏于安全的研发管理，要么缺乏安全的研发管理能力，要么因部署实施人员意识和能力不足，导致的商业软件带伤带病上线。
在个人实践经验中，某以移动设备安全管理（MDM）出名的国内厂商在检测中发现6项以上高危漏洞，修复、响应，整改不及时，国外大厂Oracle 的ESB存在明文传输密码的低级漏洞，还以整改需求属于商业开发为由要挟付费整改，并且不支持SSL协议部署的补偿方案，让人大跌眼镜。当然，在国家攻防演练活动中，频繁曝出安全漏洞的厂商所犯的同样是一些低级问题，是在研发过程安全管理阶段流程、能力和意识缺失所带来的安全风险。
因此，企业在采购商业软件时，需要增加供应商安全能力评估的环节，作为采购的依据，在采购合同中明确供应商的安全义务与责任，避免在采购完成，部署，运营过程中的责任不清，响应不到位，整改不及时，责任不承担的被动局面。实践中，对供应商的评估包括能力评估，过程评估，可信评估以及明确的安全责任条款响应与合同约束，做到安全的一票否决权。
三、开源软件开源软件的起因，背景，目的和运作模式差别巨大，供应商的能力，资质，目的和意愿、承担的责任和义务各不相同。同时，不同企业采用开源软件的目的，目标，使用方式，也和业务的目标，目的，以及在开源软件自身的贡献和投入上的目的，目标也不相同，复杂性要远远超过商业软件的范畴。软件产品类的企业在采用开源软件、组件时，除了关注安全风险外，还要关注相关的许可证协议，商业用途的责任和风险，这也是一些软件成分分析（SCA）厂商的卖点之一，本文重点在于探讨安全风险的评估与治理，这部分就不再赘述。
单一性的业务应用系统因团队的规模，以及业务的复杂度，开源组件的治理尚不复杂，但对多业务团队，多应用系统，分布式开发团队或敏捷开发团队的模式下，如果缺少开源组件引入，应用，生命周期管理的体系化和统一化，会带来治理的复杂性。某业界的朋友在存量开源组件治理过程中，几百个开源组件涉及到几千个研发工程，因企业未做组件的引入管控流程，整改安全风险过程，付出了极大的代价。
企业的架构委员会或者开源组件治理委员会，需要建立开源组件的引入评审机制，任何开源组件的引入需求，需要对开源组件进行可用性安全评估，包括开源项目的背景，主要贡献企业，主要贡献团队，项目的目的，团队的稳定性，版本发布的稳定性，应用的普及性，和用户评价的可用性，对组件的架构，安全机制，管理机制，路线图进行评审，全面确认与企业场景的匹配性，开源组件的可用性，可持续性，延续性和兼容性。建立可信制品库，作为企业开源组件的唯一可信来源，对于开源组件的二次开发与修改，必须建立在企业的基础上评估评价与实施，为安全漏洞的修订和整改奠定基础，避免版本、二次开发带来的复杂性和安全风险。
目前市场的开源组件的安全治理主要集中在问题的发现环节，由于开源软件的种类繁多，长尾效应，开源组件安全厂商难以实现穷举的开源组件安全漏洞的验证，也难以实现基于场景的代码级修复建议，这个工作并未做到闭环。开源软件由于供应商缺少义务约束，可能已经不再更新和修复漏洞的版本，难以实现风险的降低，而企业也有可能因为自定义的二次开发而难以直接升级开源项目的新版本，而缺少POC的验证以及代码级修复建议，其评级机制和安全修复安全团队都需要面对研发团队的质疑和挑战。因此，开源组件的安全修复是目前难以逾越的鸿沟和面对的具体困难。
如何实现开源组件的安全修复，我跟主流的SCA厂商以及第三方运营SRC都有过些探讨，解决长尾问题的路径包括，以行业特征为主的开源组件漏洞POC验证能力和代码级修复的订阅服务，每个行业通过对TOP20企业的支持，基本可以涵盖80%的开源软件漏洞修复，20%可以提供以人力支撑为主的增值服务，而开源组件安全厂商在这个过程中可以建立自己的先发优势和知识库门槛。对于初始开源组件POC验证和代码级修复可以通过开源项目或运营SRC众筹方式建立。可惜，至今为止，行动颇为有限。
四、APP第三方SDKAPP在移动互联网的价值和面临的挑战一直是数字化绕不开的话题，APP的下载和推广成本日渐增多，小程序和H5在业务快速推广，快速应用方面具有优势，但在业务发展到一定阶段后，平台制约和入口痛点往往绕不开回归APP的话题，用户终端环境的验证，用户的定位以及环境，行为数据的采集，在面对国家合规需求，用户知情同意等一些列要求下夹缝中生存，在合规与业务需求之间寻找平衡。而在广告，引流，终端能力方面具有优势的第三方SDK，是APP快速开发，满足业务需求的必备前提。不能忽略的是，第三方SDK是个双刃剑，在满足业务需求的同时，也带来业务合规的风险。在网信办牵头下的APP安全治理逐渐深化，第三方SDK的合规与整改通报也经常见诸报端。这就要求企业对第三方SDK建立评估，管控和处置的生命周期管理能力。
某朋友的企业出现不同业务APP集成不同第三方SDK版本引起的研发流程变更的效率问题和APP研发第三方SDK基线评估和建立的问题。在这点上第三方SDK的引入评估与商业软件管理一致，做好引入的管理和控制，在第三方SDK的管理上需要借鉴开源组件的治理，建立统一的制品库和统一的安全基线，避免重复引入风险安全组件的问题。
第三方SDK的隐私保护检测和动态运行时监测的能力是容易忽略的点，这有别于传统意义上的静态检测，第三方SDK后台服务涉及到动态的数据采集和处理，需要能够及时的监测，避免违规风险。
五、遗留和遗弃软件业务下线是业务生命周期过程中的一环，软件下线是软件生命周期中关键的一环，两者之间存在着密切的相关性，也有着具体差异，不同企业可能有不同的流程制度或不同的文化，不同的团队支撑实现，而其中因协同不足，经验能力不足造成的问题也不容小觑。
某朋友企业的业务下线和系统下线，基于约定俗成的敏捷模式，缺少标准化的流程和验证机制，导致下线系统仅下线域名解析，对软件系统的服务停止，硬件资源回收，数据存档和备份，缺少相应的流程和机制。而长期暴露在内网范围内，因域名解析配置的问题，某些微服务架构在互联网环境下可以通过域名拼接访问，造成了相应的攻击面暴露风险。
当然，上述例子涉及到的检测、治理、验证模式众多，如果具备资产管理系统，具备流量分析与监控系统，具备资产暴露面的检测与监测系统，都能实现问题的发现与控制措施的变更，本文仅从软件供应链安全的角度，对遗留和遗弃软件的治理，给出相应的解决方案。
需要建立完善的业务下线流程，其中涉及到的软件系统需要从数据归档，资源释放，服务下线的完整流程建立执行的审核，检查，验证机制，避免遗弃系统带来的资源浪费和安全风险。
遗留系统因历史原因，业务仍有零星需求不能下线，软件系统因资源问题以及服务周期问题，难以对安全风险进行规制的响应和升级，这对安全团队而言是比较大的考验，补偿措施和风险接受，以及应用级的行为检测和响应，规避安全风险，可能是比较可行的方法。
软件供应链安全作为当下的热门领域，相应的方法论，理论研究和探讨，安全产品层出不穷，而场景化的需求决定能够发现，解决，和管理相应的问题和风险，带来实际价值才是选择的唯一标准。作为安全团队的负责人或软件供应链安全的负责人需要在功能满足和能力建设的基础上，关注运营需求，不断发现实践过程中的不足和问题，深入思考，给出具有前瞻性和全局性的解决方案，本文给出一些容易疏忽和忽略的具体点，供大家参考，也希望能带来一些启发和帮助，促进软件供应链安全领域的发展。
- End -
,
