文 / 海通证券股份有限公司 周靖 马冰 王晓平 陆颂华
在金融系统中，当分布式架构、云端部署日益成为主流后，系统模块化、组件化趋势明显，系统软件中开源组件的使用复杂且相互依赖。开源组件治理是整个开源治理活动中非常重要的一部分。组件多层、互相依赖，往往很难厘清关系，开源组件治理工作充满严峻挑战。
如何对这些开源组件进行治理呢？我司对开源组件治理体现在4方面，分别是开源团队设立、流程及制度设计、开源引入引出、开源检测及修复。
1.开源团队设立。开源治理涉及多个职能部门，需要组织层面自上而下的设计与支持。我司组建了虚拟团队，横跨研发管理、技术平台、安全等团队，由分管领导担任组长，牵头整个开源治理工作。团队的设立，为海通后续开源治理中的工具建设、引入引出、威胁识别、威胁处置等活动起到了关键支撑作用。
2.流程及制度设计。设计开源治理的流程及制度，用以贯通相关团队职能并保障具体治理工作落地。这些流程体现在开源组件完整的生命周期过程中，包含组件引入引出流程、组件使用流程、组件检测流程、组件安全应急处置等。海通证券有完整的软件研发管理规范，研发管理规范中包含开源治理的相关条项，对开源使用意识、开源使用具体操作、开源支持、开源检测等具体实践进行指导及要求，确保开源技术的合规使用及风险可控。
3.开源组件管理工具。开源组件引入引出是指对开源组件的使用进行引入审核、无效退出的管理事务，是开源组件生命周期中的入口及出口。
开源组件的有效管理需要依赖流程、制度来保障，而专业化的开源组件管理工具在治理工作中也能发挥很大支持作用。我司建设了专业化的开源组件管理工具，支持范围如下：一是支持多种开源组件代码类型，例如Java、C/C++、Golang、Python、JavaScript等组件语言类型；二是支持基本的引入引出审批流程，对引入的包在仓库中实现统一依赖管理，对引出的包标记黑名单实现屏蔽效果；三是实现统一包依赖管理，对包使用方式进行统一管理，支持通用的Maven、Gradle、NPM、Conan等包使用方式。
4.开源组件检测及修复。自动化的安全检测及修复是开源组件治理的核心活动。安全检测内容包含两部分：一是组件的漏洞检测，例如CVE、CNVD、CNNVD等来源的漏洞；二是组件的开源协议检测，例如LGPL这类传染性的高危协议。开源组件的修复活动为：工具平台从威胁情报接收到漏洞信息后，结合CMDB及应用资产清单评估漏洞影响面并自动计算出待修复系统清单，将修复流程直接推送干系方，实现统一推送、统一跟踪、统一修复。
二、开源组件治理实践分析
与银行业相比，证券行业的开源实践起步相对较晚，我司在探索常规治理之外，经过内部探索与思考，形成了自己的最佳实践，具体体现在以下几方面。
1.开源组件定制与封装。通常开源组件漏洞的呈现形式相对固定，体现在诸如通讯加密、多因素认证、SQL注入、XSS攻击、文件上传等。除加强系统漏洞扫描，加强互联网端WAF防御等，我司通过对常用组件分类封装、定制加强开源组件安全，主要体现在框架组件安全、技术组件安全、功能组件安全3方面。框架组件安全体现在研发框架级的整体安全，例如海通灯塔开发框架的ORM就进行了定制，在执行具体SQL之前自动检查SQL安全规范清单，如触发安全规范，则拒绝执行危险SQL；技术组件安全体现在多种类型组件上，包含加密方式、密钥长度、复杂度要求、连接类组件、安全Fastjson组件等；功能组件体现具体通用功能使用上，实现使用即默认安全的效果，包含文件安全上传、短信发送防爆破、日志打印组件自带脱敏功能等，例如文件上传功能缺省属性含有文件上传大小限制、上传频率限制，白名单化允许上传的文件类型，黑名单化高危文件类型等。
2.组件参与攻防，出厂即安全。在治理阶段才发现组件的安全问题会带来额外的修复成本，因此尽早对组件进行检测尤为重要。我司对组件的安全检测时机提前到开发框架阶段，对灯塔开发框架的各种组件开展例行模拟攻击，以真实攻击保障相应组件安全。模拟攻击包含常规的SQL注入、定向木马文件上传、密码爆破、反序列化攻击、认证绕过等攻击手段。通过安全团队具体攻击的组件打上相应安全能力标签，实现出厂即安全，赋能业务研发团队。
3.云梯平台助力自动检测。开源组件的威胁情报变化频繁且时效很重要，人工检测及定时检测机制均无法保障开源治理的及时性及有效性。我司云梯平台是一种DevOps工具平台，通过在云梯平台上增加相应安全检测节点，将开源治理指标作为一种质量门禁指标，融入日常研发工作流程中。借助云梯平台可以实现以下目标：一是可以对日常版本发布的二进制包进行漏洞检测；二是对依赖仓库中的组件进行漏洞检测；三是对具有传染性等高危开源协议组件进行检测并预警。
开源治理范畴很大，开源组件的治理只是其中一小块，我司在治理实践过程中不断发现问题、优化问题。在取得一定成效的同时，也有了进一步思考与展望，具体体现在以下几方面。
一是开源治理过程中的流程、数据还需进一步贯通。在不造成研发效能过多下降的前提下，进一步探索开源治理的多环节流程、数据统一归集，实现开源资产视图全景可视化、风险指标可视化、影响面可视化等。
二是开源治理的安全处置流程还需进一步优化。一旦发现开源问题，需要有更有效的流程、规范机制来拉通“一部两中心”（金融科技部、软件开发中心、数据中心），实现多中心联动并行处置。首先不断优化应用架构，减少暴露面；其次通过WAF等屏蔽通用攻击手法，过滤攻击类请求；第三通过建设内生开源安全，从源头上避免全员参与开源治理工作，由专业安全团队赋能业务安全研发。
三是开源治理的对象还需进一步扩大。开源组件、开源工具、开源中间件、开源软件等均可能造成开源安全问题。需要分类分级并设计顶层架构，自上而下形成开源治理体系，逐步完善相应的开源治理工作。
版权归原作者所有，如若转载，请注明出处：https://www.ciocso.com/article/19894.html
