DevOps环境下安全层面的监管控方案.docx

《DevOps环境下安全层面的监管控方案.docx》由会员分享，可在线阅读，更多相关《DevOps环境下安全层面的监管控方案.docx（4页珍藏版）》请在第一文库网上搜索。

1、DeVOPS环境下，不同厂商制品库安全层面如何做到监、管、控来自twt社区同行交流,欢迎更多同行参与交流代码制品库或容器镜像制品库安全性相关问题？中小型银行、应用系统大多以采购为主，不同厂商的产品在实施DeVOPS过程中，会形成不同的制品库，如自动化流水线生产的mvnjar,自动化生产的应用镜像等等。这里存在一个问题，就是安全性的相关问题。以往传统运维环节下，运维部门可以强行管控各类资源的版本，同时也会建设各种自动化统一操作平台。基于这些基础IT的版本管理和自动化运维平台，安全相关的问题都比较容易管控处理。比如说，统一的操作系统补丁升级、中间件补丁升级、版本管理、密码定期自动化更换、镜像底层安

2、全扫描啊等等。在DeVOPS推广后，一定程度上模糊了开发与运维的明显界限。传统运维层针对安全性的现有方案无法很好的适用于DevOps环境。比如说，各个厂商所带来的不同规格的制品库，其内容迥异，很难按照传统思路进行统一化的安全管控。这里的问题就是如何实现DeVOPS环境下，不同厂商制品库安全层面如何做到监、管、控。比方说：安全部门发布的一个开源jar的安全漏洞，如何实现制品库的自动扫描发现？问题来自社区会员wxid1某银行系统工程师28556259CMBC软件架构设计师：个人理解软件安全管控和工具没有绑定的关系，因为安全是硬性的，无论用什么工具都必须满足企业的安全要求，即使是传统运维还是DeVO

3、Ps。传统运维和DevOps的区别只是把安全和质量相关的规范，做成线上化的自动的。比方说：安全部门发布的一个开源jar的安全漏洞，如何实现制品库的自动扫描发现？这里要具体看是在开发端还是在生产端发现的，安全扫描手法也不一样，当然最好的办法是在构建时就拦截这些。1Chqq中原银行DeVoPS工程师：您的问题非常好，这也是中小银行的痛点问题。我觉得这可能属于一个更高层面一一“开源治理”的范畴，需要有一系列的管理和技术手段进行管控，不是一个工具、一个部门能够独立完成的。我觉得它至少包括下列3方面的内容：1、准入标准。建设完善的企业级开源软件安全评估与引入流程。2、安全管控。具备强大的开源组件安全管控

4、能力，包括已有的开源软件使用情况梳理、及时获取开源软件安全漏洞信息、对开源组件的安全测试等能力。3、修复或退出机制。实现安全漏洞的快速定位，通过对开源软件的修复或退出，快速解决问题，并考虑出现重大问题后的法务解决方案。目前，我们行是通过一些流程进行管控的，比如架构部门的评审、安全部门的安全扫描测试等，发现问题通知整改等手段进行管控。但我们也是刚刚起步，感觉还存在职责不清晰、覆盖不全面、缺乏长效机制等问题，治理效果还有待进一步提升，咱们可以持续探讨这个问题。1iwei1567JFrog解决方案架构师：随着开源软件及组件被组织广泛应用，带来的安全风险和法务风险也愈发严重。近年来无数企业被护网行动和

5、开源风险所影响，由于管理不严格、制度不规范，在护网行动中只能通过断网来方法，影响产品安全的同时，也对业务正常运转有极大的影响。所以开源治理的工作必然是下一阶段重点内容。那么如何通过开源组件及软件的管控，来助力开源治理呢？我们通过下述4种方法来为开源治理行动打下坚实的基础：1,控制源头，统一引入开源组件及软件无论传统行业还是互联网行业，开源引入的方式都十分重要，如果没有统一的引入源头及引入平台，使用者随意下载开源组件及软件，直接在组织内使用，带来的风险无法清查，对开源的使用、更新、退出等流程无法监管。2,识别开源风险开源风险分为安全风险和法务风险两部分，无论是哪个方面，对于普通的开发人员，均无法

6、识别到。如果风险被引入到交付体系中，将对产品的安全性和法务合规性有着严重的影响，开发人员为了修复风险，也将花费大量时间和成本。所以开源组件的风险识别，将是开源治理的最重要的部分。3,开源风险记录追踪对于所有交付软件资产，我们需要了解每个软件使用了哪些开源组件，每个组件是什么版本，每个版本有什么风险，以便在护网行动中，可以快速的定位暴露在互联网上的产品的安全情况，帮助我们快速设防。如果发生类似FaStjSon这种OcIay漏洞，我们也可以快速定位到风险的影响范围，进行全面的风险定位，快速修复，避免漏网之鱼的存在。4,开源风险处置当然仅仅识别到开源风险是不够的，我们需要对风险进行处置，知道风险如何进行修复。-全文完-