您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
DevSecOPs在金融机构的落地实践
 
作者:cn1188181
  1663  次浏览      16
 2021-12-24
 
编辑推荐:
本文主要 从文化、流程及技术等方面探索、实践并落地了DevSecOps,通过固化流程、加强人员协作以及工具化、自动化技术手段将安全无缝内嵌到研发流程中。
本文来自于 个人图书馆 ,由火龙果软件Alice编辑推荐。

DevSecOps落地实践

2012 年,Gartner首次提出 DevSecOps 理念。四年后,它发布了一份名为《DevSecOps: How toSeamlessly integrate Security into DevOps》的报告。 这份报告的核心理念是:安全是整个IT团队(包括开发、运维及安全团队)每个人的责任,需要贯穿从开发到运营整个业务生命周期的每一个环节。对应 DevOps 快速交付和灵活响应变化,DevSecOps 的价值是在不牺牲安全性的前提下,快速和规模地交付安全决策。

基于Gartner关于DevSecOps的理念,机构从文化、流程及技术等方面探索、实践并落地了DevSecOps,通过固化流程、加强人员协作以及工具化、自动化技术手段将安全无缝内嵌到研发流程中。

1 人

首先,要培养自己的安全团队,建设自身的专业安全能力。设立约有20个专业安全人员的团队,覆盖应用安全、GRC(治理、风险和合规)、数据安全、业务安全、安全运营等方向。其中应用安全团队负责DevSecOps的研究与落地,设置专门的安全顾问,负责项目安全评估与咨询,以及项目安全建设的全流程跟踪。

2 文化

高层支持。 借助监管要求、外部咨询、安全案例等形式,积极和高层沟通,强化应用系统生命周期安全管理的必要性,争取高层的认同与支持,获得更多的资源。

确立软件安全开发生命周期管理方法论。 借鉴业界成熟的安全生命周期管理方法论,结合企业现状,形成一套信息系统生命周期安全管理的框架,规定在软件安全开发的不同阶段需要开展的安全活动,且该框架各个活动模块是灵活可裁剪的,根据IT成熟度决定采取的安全活动。 安全活动干系人。 通过安全宣贯、BSI白皮书、安全顾问、项目安全评估等形式,对IT人员进行软件生命周期安全开发实践的推广,并明确项目安全建设过程中涉及的干系人的主要活动、职责和义务,让IT人员意识到安全是整个IT团队每个人的责任。

安全培训。 开展一系列的信息安全技能培训,提升IT人员安全专业技能。基于不同角色,定制不同的培训课程。除了线下活动,还要在网络培训学院及信息安全门户,提供培训视频、技术指南、漏洞知识库、最佳实践等,让IT人员可自主学习,提升安全技能,主动在日常研发和运营过程融入安全要素,降低安全风险。 安全积极分子。 将开发人员培养成安全积极分子,通过其潜移默化的影响,带动其他开发人员的安全意识,在日常开发过程中融入安全要素,同时也能解决安全人员不足的问题。另外,在内部信息安全门户建立了漏洞修复知识库,鼓励开发人员将日常漏洞修复过程分享出来,共同维护该知识库,其他开发人员修复漏洞时,可参考知识库进行快速修复,降低修复成本。

以史为鉴。 收集和总结以往发生的真实漏洞案例,形成“漏洞-以史为鉴”,对研发及运维人员进行安全宣贯,可以引发其共鸣,达到更好的安全意识宣贯的效果。另一方面,共性的漏洞问题也反馈给研发,从架构等层面进行优化,从根源上解决此类安全问题。

3 流程

安全策略。 安全团队和质量团队合作,对应用系统进行分类分级,定义不同的安全策略,将安全活动嵌入到项目流程中。系统分类分级维度有研发模式、网络模式、用户场景等。通过在项目过程定义中加入安全策略,可以督促开发人员在研发过程中主动进行安全活动,潜移默化提升其安全意识。

安全活动。 机构在DevOps研发运营一体化过程中通常会进行以下安全活动,选取部分主要活动进行说明。

1)安全需求标准库

安全需求标准库,以等保2.0为基础框架,汇总各种安全需求而形成的安全通用需求库,主要需求来源有:

  • 国家法律法规及标准,如《网络安全法》、《网络安全等级保护基本要求》等;
  • 行业监管法令、指引及技术标准,如《证券期货业信息系统安全等级保护基本要求(试行)JR-T 0060-2010》、《证券公司网上证券信息系统技术指引》等;
  • 公司自有信息安全策略、标准及指南,如《xxxx公司信息技术数据管理规范》;
  • 业界安全实践,如OWASP ASVS、OWSAP TOP 10等。
  • 安全需求标准库可以提供项目进行安全需求与架构设计时,安全考虑的依据和范围,降低安全需求活动执行的难度,提高效率。

    2)轻量级威胁建模

    威胁建模是分析应用程序安全性的一种结构化方法,通过识别威胁,定义防御或消极威胁控制措施的一个过程。威胁建模属于微软SDL中核心部分,微软一直是这一过程的强有力倡导者。但传统的威胁建模流程过于繁琐,且对人工投入要求较高,很难适应业务的敏捷、快速迭代开发模式。故在实际使用中,对威胁建模进行了优化,结合安全需求分析和架构设计过程,进行轻量级的威胁建模,主要包含攻击面分析和安全威胁库。

    第一步,问卷调研。 目的是要了解系统的关键信息,为后面的攻击面分析及威胁建模做准备。调研问卷主要包括系统架构、使用场景、重要数据、部署方式 4部分。

    第二步,攻击面分析。 进行基本的攻击面分析,采用简化的数据流图,关注系统与外部系统的边界等。

    第三步,威胁识别。 将识别出的攻击面,基于业务场景与威胁库(安全专家经验、长期积累而形成的安全威胁库,也可以直接采用安全需求标准库)进行匹配,识别出系统面临的威胁点。

    第四步,安全设计方案。 根据威胁分析结果,匹配安全需求标准库,输出进行威胁缓释需要实施的安全需求基线,制定最终的安全设计方案。

    当前的轻量级威胁建模仍处于手工阶段,为了提高效率,安全团队在SDL安全开发全流程赋能平台中,可以进行自动化轻量级威胁建模功能开发。项目组自主填写安全调查问卷,然后平台根据安全威胁库,自动输出安全设计方案。其中,安全人员要不断丰富安全威胁库。未来,可考虑结合代码分析、多维度安全测试以及人工智能、NLP等技术,进行智能化威胁建模。

    3)源代码安全扫描(SAST)

    源代码安全扫描,即静态应用程序安全测试(SAST,Static Application Security Testing),是指分析应用程序的源代码或二进制文件的语法、结构、过程、接口等来发现程序代码存在的安全漏洞,有些工具也会依赖于编译过程,通过一些抽象语法树、控制流分析及污点追踪等技术手段来提升检测覆盖度和准确。

    SAST的优点是广泛支持多种语言和架构,对漏洞类型的覆盖率比较高;缺点是误报率高、扫描速度慢、依赖安全专家对结果进行过滤和确认。

    基于软件开发成熟度现状,直接用开源SonarQube+FindSecurityBugs插件(最新版共138条安全规则,https://find-sec-bugs.github.io/)。研发已经部署有代码质量管理平台SonarQube,基于该平台安全团队采用find security bugs插件进行安全漏洞扫描,将安全规则集和代码质量规则集集成,形成“ht-sonar”profile,项目组只需要一次集成sonar扫描,即可以兼具代码质量及安全扫描功能。

    SonarQube中Vulnerabilities即是安全规则扫描出来的安全漏洞,对于项目组来说,对应的项目只需要集成了sonar扫描,既可在日常构建过程中自动进行安全扫描,根据SonarQube中的安全测试结果,自行进行漏洞的修复工作。项目上线前,只需要提交最终的SonarQube源代码安全测试结果给安全人员审核即可。 由于Find Security Bugs插件规则还不是太全,且只支持Java,所以需要进行调优。 本年度引入白盒厂家,基于sonar进行源代码安全扫描插件的定制化开发,主要调优方向有:

  • 对已有扫描器的检测效果和误报漏报进行分析调优;
  • 覆盖和增强Find Security Bugs插件所涉及的安全检测能力并中文化安全风险提示;
  • 支持Python、JavaScript、PHP语言的安全规范检测;
  • 支持更多编程语言安全扫描,支持C、C++语言的安全问题检测;
  • 安全编码规范执行自动化检测;
  • 增加商业扫描器所能检测的安全缺陷类型(如Checkmarx能检测的主流安全漏洞类型)。
  • 定制化sonar安全插件在使用上不影响原有的研发构建过程(仍然为mvn sonar:sonar)。

    源代码安全检测可以在多个环节进行集成,集成点主要有:

  • 开发人员本地源代码安全检测,可以采用IDE插件方式。
  • 代码提交时进行源代码安全检测,如gitlab通过webhook触发源代码扫描,设置代码安全漏洞门禁,对于有中高危漏洞的拒绝commit。安全编码规范是否遵从可以在这里管控。
  • CI构建过程中进行源代码安全扫描。
  • 在这三个阶段,前两个阶段安全规则可以更全面,即使有些误报也可以接受,而在CI构建过程中,为了构建的速度以及成功率,如果有安全质量门限,安全扫描规则要尽可能精简并准确。

    4)黑盒安全测试(DAST)

    黑盒安全测试,即动态应用程序安全测试(DAST,Dynamic Application Security Testing),是指在测试或运行阶段分析应用程序的动态运行状态。它模拟黑客行为对应用程序进行动态攻击,分析应用程序的反应,从而确定该Web应用是否易受攻击。

    DAST,优点是测试结果准确率较高;缺点是扫描速度偏慢,漏洞覆盖率低,无法有效支持API及微服务。

    机构目前采用的黑盒安全测试工具有AppScan、AWVS、OWASP ZAP和Arachni,可以通过自动化安全测试平台进行封装和分布式扫描调度,提供API方式给DevOps平台集成。

    从使用效果来看,黑盒扫描出来的漏洞有限,只能作为一种补充,后继考虑引入基于流量的黑盒安全测试技术。IAST集成测试效果更好。

    5)交互式应用安全测试(IAST)

    IAST交互式安全测试技术是一种实时动态交互的漏洞检测技术,通过在服务端部署Agent程序,收集、监控Web应用程序运行时函数执行、数据传输,并与扫描器端进行实时交互,高效、准确的识别安全缺陷及漏洞,同时还可精准确定漏洞所在的代码文件、行数、函数及参数。IAST,融合了SAST和DAST技术的优点,无需源码,支持对字节码的检测,提高了应用安全测试的准确性。

    IAST极大的提升了安全测试的效率和准确率,适用于敏捷开发和DevOps,可以在软件的开发和测试阶段无缝集成到DevOps,让研发人员在执行功能测试的同时,无感知的完成安全测试,实时输出安全测试结果。而IAST的缺点就是需要特定语言的支持,目前主流支持语言是JAVA、C#等,因此在整个软件开发生命周期中,需要SAST、DAST及IAST共同使用,结合各自的优势,及时、准确的发现更多的安全风险。

    IAST工具使用时可由测试人员自行安装agent,在功能测试同时就可以完成安全测试,自行进行漏洞修复。与DevOps平台集成后,在版本发布到SIT或者提测环节,自动化将agent部署到测试环境中,在研发测试人员无感知下完成安全测试。

    6)开源组件安全扫描(SCA)

    Gartner调查显示,应用程序中最终需要开发人员编写的代码数量平均少于10%,然而,开源软件中存在大量的安全隐患,企业在享受开源软件带来便利的同时,也承担着巨大的安全风险。调研发现,有不少企业在研发阶段还未开展开源组件安全治理。

    开源组件的安全漏洞愈发引起大家重视,机构也很早就进行开源组件的安全治理,主要实践如下:

  • 引入开源组件的安全扫描工具。 引入商业的BlackDuck,支持安全风险及许可证合规检测。开源的有OWASP Dependency Check。
  • 自动化集成。 将开源组件扫描工具和研发DevOps平台工具链CI过程集成,实现DevOps流程中的开源组件安全自动化。
  • 识别组件,建立开源组件资产库。 项目在CI日常构建过程中,开源组件扫描工具会进行软件组成分析,包括框架、模块和第三方库等,形成应用程序的开源组件清单。同时,所有扫描的项目开源组件清单、项目信息等,都会统一集中到开源组件资产库,并进行开源组件的资产管理。当有开源组件安全漏洞信息披露时,安全团队可以立即做出判断,了解哪些应用系统受漏洞的影响,通知项目组快速修复漏洞。
  • 建立内部安全开源组件仓库。 应用构建时,第三方组件都从该仓库获取,这样可以保证应用不包含已知漏洞的组件,降低了安全风险。

  • 制定开源组件使用策略。 只允许开发人员从内部的安全开源组件仓库获取第三方组件,并设置专人管理。如果内部仓库没有所需的第三方组件,开发人员则向管理员申请,由管理员和安全人员合作,从外网下载相应的第三方组件,并经过开源组件安全扫描工具检测为安全版本后,提交到内部仓库。

  • 持续监测开源组件威胁。 由于开源组件威胁在持续变化,因此需要在应用系统的生命周期内对其组件进行持续监控。如果组件出现安全漏洞,需要通知相应的项目组及时修复,同时移除内部仓库中不安全版本组件,更新为安全版本。
  • 但是要注意,开源组件在治理初期比较困难。由于组件之间的依赖性较强,以及兼容性问题,开源组件的漏洞修复比较困难,尤其对于存量老系统。因此,开源组件的治理策略是从上往下,首先常规扫描收集开源组件资产数据,根据现状制定改进策略,如内部安全开源组件仓库、架构组件标准化等。

    7)容器安全扫描

    随着容器技术的兴起,越来越多的应用选择容器部署,因此容器的安全性也受到了广泛的关注。基于此,DevOps项目组和安全团队结合双方专业优势,形成了一套行之有效的容器安全最佳实践,建立了容器全生命周期安全管理方法论,利用完整的安全工具链对容器进行检测、监控及修复,保障容器镜像及运行环境的安全。

    Docker安全配置基线。 根据CIS的Docker安全标准整理了Docker容器安全实践指南,该指南包括了主机安全配置、Docker守护进程配置、Docker守护程序配置文件、容器镜像和构建、容器运行安全、Docker安全操作等方面多个控制点,给研发及运维人员提供Docker安全加固指南,降低Docker安全风险。 Kubernetes安全。 部门在开发测试环境和生产环境中,采用了Kubernetes作为容器云的编排服务和集群运行环境,Kubernetes安全直接关系到容器的运行安全。Kubernetes 提供了很多能够提高应用安全的方法,根据实践总结了Kubernetes部署安全指南,用于指导Kubernetes的安全部署。 内部安全镜像仓库。 通过内部安全镜像仓库,避免了研发人员从互联网拉取带有安全漏洞的镜像到运行环境,从源头消除已知含有漏洞组件的使用,提高容器安全性。

    1)内部所有容器构建,只能基于内部安全镜像仓库:禁止开发人员从公共网络直接下载镜像。开发团队和安全团队合作,建立和维护内部的镜像仓库。架构师、容器项目组和安全团队持续维护镜像库为最新版本,同时建立了开发人员请求新镜像的流程;

    2)开发测试环境和生产环境所有依赖的统一管理:两者的公开基础映像,统一由平台团队管理。开发团队在构建映像过程中可能用到的开源组件依赖包,统一由质量团队管理;需要进行升级和特定支持应用安全所需要的操作系统和相关应用包,统一由安全团队管理。各团队在开发测试及生产环境专门搭建本地私用库,由固定服务器外连指定的少数可信源(官方或官方认证站点);

    3)从互联网Docker镜像仓库拉取镜像时,必须经过Docker安全扫描,确认无安全漏洞,才可以拉取到内部安全镜像仓库;

    4)第三方开源组件入库时,触发开源组件安全扫描工具,进行已知开源组件漏洞检测,如有漏洞则进行隔离和提示管理员,确定下一步操作,经过确认无安全漏洞的开源组件才可以入库。 容器安全扫描工具自动化集成。 机构自有的DevOps平台承载公司所有容器的CI/CD,DevOps平台通过与容器安全扫描工具集成,在容器构建过程中融入安全要素,解决了镜像的安全问题,同时CI构建报告中直接集成容器安全扫描结果,提高了安全漏洞修复效率及易用性。 目前机构生产环境的Docker主机均从机构内部私有Registry中提取生产镜像。当构建工具上传镜像到私有Registry后,容器安全扫描器会从该Registry中获取镜像的副本,实施安全测试。整个过程可分解为以下关键步骤:

  • 当开发团队自动提交构建或构建触发器时,构建工具将从源代码控制工具中提取源代码;
  • 构建工具可以在构建过程中运行一些测试,当测试成功时,镜像将推送到企业私有Registry;
  • 容器安全扫描器从私有Registry获取相关容器镜像,分析元数据清单,进行安全扫描;
  • DevOps平台通过容器安全扫描器API接口获取扫描报告。
  • 容器安全风险度量及可视化。 为了对项目组的容器安全风险进行度量及直观展示,从容器镜像的项目分布、安全漏洞、操作系统等纬度进行了可视化展示,便于项目组进行容器安全风险的持续监控及容器安全漏洞的修复。

    8)威胁监控

    企业在安全运营过程中,需要面对的安全数据越来越多,如流量数据、安全防护设备与网络基础设施数据、终端数据、资产与漏洞信息、情报数据等,各种告警数据分散且没有打通,有限的安全人员和海量日志告警是突出矛盾,而安全效能越高就需要更多的数据。如何从海量告警数据中高效发现极少量的真实事件线索,也是对安全团队的极大考验。而在实际的安全运营中,常常缺少高效的安全业务运营工作平台,无法实现网络安全、数据安全和业务安全等多领域的闭环运营。 安全态势感知是近几年的一个热点,但是在调研安全感知态势产品过程中,会发现存在一些问题: 厂商的普遍性标准化产品与多样的行业运营需求难对齐;

    厂商设备“面向告警”而非“面向风险和运营效能”,自动化运营程度和效能有限;

    单一安全厂商的技术实力有限,多源技术引入是趋势,但是厂商间技术集成性和互通性差,充分技术整合异构外部能力就成了迫切需求。

    要满足企业要求可以基于开源技术实现,同时进行商业产品的能力集成,主要的功能有海量安全日志集中化管理、NTA网络流量分析、网络安全威胁态势可视化、UEBA内部用户行为分析、TI情报中心、EDR端点检测与响应、SOAR安全编排与自动化响应等。

    通过收集、处理、分析企业安全数据,借助外部威胁情报和大数据分析技术提高效率,赋能公司安全响应中心运营人员检测、响应和预测内外部威胁和事件。随着人员能力和产品成熟度螺旋式上升,持续降低公司的攻陷检测时间(MTTD)和攻陷响应时间(MTTR),实现对企业面临的内外部威胁快速检测、实时分析和自动化处置能力,使得企业具备安全可知、可见、可控的全网安全态势感知能力。 通过该平台的海量数据实现快速有效发现威胁的能力,使得安全运营人员持续专注优先威胁,利用自动化手段,弥补安全人员限制,最终提升了运营驱动的威胁和事件快速响应支撑能力。

    9)安全响应

    漏洞响应的主要流程如下(以weblogic漏洞响应为例):

    a)漏洞情报。 从厂商公告、安全情报厂商、安全社区和朋友圈等渠道获取漏洞情报。

    b)漏洞评估。 根据漏洞影响的资产类型、公司资产数据库,确定受影响的服务器以及应该参与响应的系统管理员。有风险的漏洞按照严重(严重可被exp的RCE漏洞)、高危(其他可被exp的远程利用漏洞)、中危(可被exp的本地其他漏洞)和低危(其他漏洞)四级分类。

    c)预警定级。 依据安全响应中心漏洞响应应急预案中的设定,确定本次漏洞响应级别为3级“黄色”。(预警通告等级分为三级,由高到低依次用红色、橙色和黄色表示,分别对应发生或可能发生一级、二级和三级事件)

    d)发布预警。 通过邮件方式对全IT发布“橙色”预警。邮件正文直接给出已知受影响的系统名称、IP地址、人和团队等信息,同时要求其他人员开展自查,防止遗漏。

    e)组织修复。 系统管理员根据官方给出的修复方式组织修复;安全运营人员联系网络层IPS厂商获取IPS特征签名,并下发全网。

    f)验证修复。 利用漏洞扫描器、POC脚本等方式对漏洞进行修复验证。使用漏洞扫描器就该漏洞进行全网扫描。

    g)解除预警。 通过邮件方式解除预警。

    为了提升漏洞应急响应能力,重点关注漏洞情报的获取、精细化的资产管理(特别是高危组件的使用情况)、应急响应流程的制定、漏洞快速检测能力等。在安全运营过程中,为了实现安全漏洞的快速响应,对漏洞响应过程进行了工程化,实现了安全漏洞响应RPA。

    4 技术

    DevSecOps核心理念之一,是要工具化和自动化,所以工具必不可少。机构已经初步建立了端到端完整的安全工具链,并自动化集成到DevOps流程中。

    目前DevOps中安全工具自动化部分,主要有DEV环境的源代码安全扫描、开源组件安全扫描、移动APP加固,SIT阶段的Docker安全扫描、黑盒安全扫描及交互式安全扫描。团队目前也在开发自动化安全测试平台,将各种商业/开源安全工具,如源代码安全扫描、黑盒安全扫描、渗透测试工具等集成进来,对外提供集成安全测试能力支持,并通过API接口方式集成到DevOps平台。机构已经具有较完备的安全武器库,给IT提供火力支撑。

    5 度量

    管理学大师彼得·德鲁克曾经说过,“你如果无法度量它,就无法管理它”。要想提高DevSecOps效能,自然要首先解决效能的度量问题。

    DevSecOps过程度量指标。应用安全团队制定了DevOps过程中安全活动对应的门限及度量指标,通过门限控制软件进入制品库的度量标准,通过度量指标来衡量项目的安全成熟度。

    指标驱动运营。

    为了提高端到端安全交付效能,制定了项目安全建设运营指标,如项目安全评估的覆盖率、端到端安全交付效能、安全工具链DevOps集成率、安全测试能力覆盖率、安全漏洞修复率、安全漏洞漏出率、标准化安全组件、软件安全能力成熟度等。设计指标以能够指导行动为基本原则。在运营过程中,不断用指标数据来验证成效,使得安全更加聚焦于重点方向。 常态化风险报告机制。 常态化项目风险报告运营,建立安全风险响应度量机制,对响应效能等进行度量,驱动团队改进优化。基于度量识别的安全问题自动反馈到问题团队,并周期性总结安全风险报告,对改进效果进行度量并持续反馈,实现安全问题的闭环管理。 软件安全成熟度。 每年应用安全团队都会进行软件安全成熟度自评估。软件安全成熟度评估模型基于BSIMM(软件安全构建成熟度模型),BSIMM分为4个领域12类实践,总共包括120多项活动。安全团队对每一项进行解读,依据行业属性进行自身评估指标的制定,每年会根据BSIMM变化,同步回顾并修订评估指标。

    评估时,基于自定义的指标,应用安全团队多人对每个活动的成熟度进行打分,最终以蜘蛛图的方式呈现出当前的软件安全成熟度。

    基于成熟度评估结果,会进行差距分析,和业界领先进行比较,发现不足之处,结合实施的成本和收益,确定下一年度可行的改进方向,制定成熟度行动计划,不断提升软件安全成熟度。

    6 人安全工具及平台

    为了提升安全运营效能,安全团队可以自主研发人工智能安全平台、内部用户行为分析平台、应用安全工程中台等。

    1)应用安全工程中台

    应用安全工程中台,包括安全SDK组件武器库、SDL安全开发全流程赋能平台、自动化安全测试平台、漏洞全生命周期管理平台及应用资产安全风险感知平台等,助力DevSecOps安全运营效能提升。

    2)人工智能安全态势感知平台

    可以主要基于开源技术实现,同时具备集成其他商业产品的能力,通过安全能力的集成,进行协同防御。采集的数据源包括流量数据(http、dns等)、安全防护设备与网络基础设施数据(NGFW、WAF、IPS、IDS等)、终端数据(操作系统日志、防病毒日志、EDR等)、资产与漏洞信息、情报数据(第三方开源、商业威胁情报)、数据库日志、业务与用户认证数据等。

    基于安全运营按照成熟度分为五个阶段。

    3) 应用资产安全风险感知平台

    基于资产测绘、IT资源管理平台、防火墙策略、流量监控、API集市、应用系统目录、安全评估记录等数据,建立应用资产图谱。从项目安全设计、源代码扫描、黑盒扫描、开源组件风险、渗透测试、API监控、安全监控、威胁情报等纬度,对DEV研发及OPS运维qua全生命周期风险数据进行自动化采集、智能分析、可视化、告警及联动响应等。

    基于资产、风险、威胁等多维度风险模型,构建应用安全风险画像,实时感知应用安全风险态势,及时发现应用的风险点,如上传接口未加固、web管理后台暴露、敏感接口认证弱等,快速响应从而缓释风险。

    总结

    如今,敏捷和DevOps已经相当成熟,如何在快速交付价值的同时控制安全风险,仍是很多企业面临的挑战。本文的DevSecOps实践可以作为参考指南,降低企业学习及实践成本。

    在DevSecOps实践中,安全人员应该积极主动的融入进去,秉承DevOps的精神,拥抱“团队协作、敏捷和职责共当”的哲学,将安全更好的内嵌到软件研发过程中,通过安全赋能IT,在提高安全工作效率的同时,降低IT系统信息安全风险。

     

       
    1663 次浏览       16
    相关文章

    DevOps转型融入到企业文化
    DevOps 能力模型、演进及案例剖析
    基于 DevOps 理念的私有 PaaS 平台实践
    微软开发团队的DevOps实践启示
    相关文档

    DevOps驱动应用运维变革与创新
    运维管理规划
    如何实现企业应用部署自动化
    运维自动化实践之路
    相关课程

    自动化运维工具(基于DevOps)
    互联网运维与DevOps
    MySQL性能优化及运维培训
    IT系统运维管理
    最新课程计划
    信息架构建模(基于UML+EA)3-21[北京]
    软件架构设计师 3-21[北京]
    图数据库与知识图谱 3-25[北京]
    业务架构设计 4-11[北京]
    SysML和EA系统设计与建模 4-22[北京]
    DoDAF规范、模型与实例 5-23[北京]
     
    最新文章
    DevOps 道法术器,立体化实施框架
    DevOps 中高效测试基础架构的最佳实践
    DevOps 在公司项目中的实践落地
    如何基于 Kubernetes 构建完整的 DevOps 流水线
    阿里云Kubernetes实战
    最新课程
    DevOps体系实践、工具与平台
    基于Kubernetes的DevOps实践
    互联网运维与DevOps
    基于Kubernetes构建企业容器云
    企业级DevOps工作体系与平台
    更多...   
    成功案例
    北京 DevOps体系实践、工具与平台
    神龙汽车 DevOps体系实践、工具与平台
    中国移动通信 网络规划与管理
    某航空公司 IT规划与企业架构
    某金融公司 IT服务管理(ITIL V3)
    更多...