墨者防御联盟-提供超强DDoS高防/CC防护/大流量清洗服务!
当前位置:主页 > WEB安全 > 正文

悬镜-软件供应链安全白皮书

01-17 WEB安全

随着容器、微服务等新技术日新月异,开源软件成为业界主流形态,软件行业快速进展。但并且,软件供应链也越来越趋于复杂化和多样化,软件供应链安全风险不断加剧,针对软件供应链薄弱环节的网络攻击随之增加,软件供应链成为阻碍软件安全的关键因素之一。近年来,全球针对软件供应链的安全事件频发,阻碍巨大,软件供应链安全已然成为一具全球性咨询题。全面、高效地保障软件供应链的安全关于我国软件行业进展、数字化进程推进具有重要意义。

近日,在由中国信通院指导、悬镜安全主办的中国首届DevSecOps敏捷安全大会(DSO 2021)现场,《软件供应链安全白皮书(2021)》(以下简称“白皮书”)正式公布。本白皮书着重分析了软件供应链安全,梳理了软件供应链的安全现状,透过现状全面剖析软件供应链的安全风险及面临的安全挑战,有针对性地提出怎么对软件供应链的安全风险举行防范与管理,系统阐述了软件供应链安全的防护体系及软件供应链安全的应用实践以供参考,最终白皮书结合如今软件供应链安全的进展趋势举行了全面的分析及展望。

由于篇幅有限,仅摘选本报告“软件供应链安全管理”及“软件供应链应用实践”两部分举行分享。

悬镜-软件供应链安全白皮书

图:《软件供应链安全白皮书》封面

一、软件供应链安全管理

目前,业界已充分认识到造成网络安全事件浮上的要紧缘由之一,是由于软件开辟者在开辟过程中对开辟工具、开辟团队、开辟生命周期和软件产品自身治理不当,致使软件存在着安全缺陷,破坏或阻碍最后来用户的信息安全。

经过推进针对软件生命周期举行全流程安全管控的降地实践,有助于从软件生命周期的源头保障软件供应链安全。经过建立软件开辟过程中保证软件供应链安全的体系化想法,为软件开辟过程中尽大概幸免和消除软件的安全缺陷、保证软件供应链安全奠定重要基础。

从软件安全开辟生命周期角度分析软件供应链安全的应用实践想法,要紧有以下几个时期。

1、体系构建时期SDL 软件安全开辟生命周期

微软在21世纪初期的软件产品开辟实践中,意识到无法经过技术层面完全解决软件面临的安全风险。所以,微软尝试从流程和治理的角度解决那个咨询题,并探究在各个软件开辟环节中加入安全过程、把控安全风险,确保每个环节交付到下一环节的交付物都安全可控。因此,针对传统的瀑布式模型微软提出了“SDL 软件安全开辟生命周期” 这一概念。

软件安全开辟生命周期(SDL),是一具在关心开辟人员构建更安全的软件和解决安全合规要求的并且落低开辟成本的软件开辟过程。SDL将软件开辟生命周期划分为7 个时期(如图所示),并提出了 17 项重要的安全活动,旨在将安全集成在软件开辟的每一具时期,以减少软件中漏洞的数量并将安全缺陷落低到最小程度。SDL更侧重的是软件开辟的安全保障过程,旨在开辟出安全的软件产品。

悬镜-软件供应链安全白皮书

图 1 SDL 软件安全开辟生命周期

在 SDL 的 7 个时期中(如图 1所示),SDL 要求前 6 个时期的 16 项安全活动,为开辟团队必须完成的安全活动。 并且,SDL 以为开辟团队应该保持灵便性,以便挑选更多合适的安全活动,如人工代码分析、渗透测试、相似应 用程序的漏洞分析,以确保对某些软件组件举行更高级别的安全分析。SDL 重视各种工具的使用,重心在从需求时期到测试时期的工具集,如威胁建模、静态源代码分析等工具。

SDL 的 7 个时期要紧的含义如下:

培训:针对开辟团队举行安全意识与能力的培训,以确保 SDL 能有效实施并降地,并且针对新的安全咨询题与形势 持续提升团队的安全能力;

需求:经过安全需求分析,定义软件产品安全实现过程中所需要的安全标准和相关要求;

设计:经过分析攻击面,设计相对应的功能和策略,落低和减少不必要的安全风险。并且经过威胁建模,分析软 件的安全威胁,提出缓解措施;

实施:按设计要求,实现对应功能和策略,以及缓解措施涉及的安全功能和策略。并且经过安全编码和禁用不安 全的 API,减少实施时导致的安全咨询题,尽可能幸免引入编码级的安全漏洞,并经过代码审计等措施来确保安全编码规范的实行;

验证:经过安全测试检测软件的安全漏洞,并全面核查攻击面,各个关键因素上的威胁缓解措施是否得以验证;

公布:建立相应的响应打算,举行最后来安全检查,确认所有安全活动均完成后将最后来版本发送给客户;

响应:当浮上安全事件与漏洞报告时,及时实施应急响应和漏洞修复。在此过程中新发觉的咨询题和安全咨询题模式,可用于 SDL 的持续改进过程中。

DevSecOps

DevSecOps 是一种全新的安全理念和模式,由 DevOps 的概念延伸和演变而来。其核心理念是安全是整个 IT 团队 每个人的责任,需要贯通从开辟到运营整个业务生命周期每一具环节才干提供有效保障。

DevSecOps 覆盖编码时期、测试时期、预公布时期、公布时期、线上运营时期,强调自动化与平台化,由 CI/CD 平台推动整个开辟和运营流程自动化。DevSecOps 依靠于 DevOps 流程工具链(如图 2 所示),将威胁建模工具、安全编码工具、安全测试工具、容器安全检测工具、基线加固工具、漏洞治理工具等自动化工具无缝集成到 DevOps 流程中,进而实现开辟 – 安全 – 运营一体化。

悬镜-软件供应链安全白皮书

图 2 DevSecOps 工具链

特别多企业在向 DevSecOps 转型时,会发觉特别多传统的安全工具在集成性和有用性上都难以满脚 DevSecOps 的需求, 所以,在 DevSecOps 的不并且期需要采纳不同的 DevSecOps 安全工具(如图 3 所示),这些安全工具要紧的共同特点是高度自动化以及可集成性。

悬镜-软件供应链安全白皮书

图 3 DevSecOps 安全工具在不并且期的自动化程度

在软件供应链中每个时期都在面临不同的安全风险,为了更好的对软件供应链举行风险管理,在 DevSecOps 模式 下,安全开辟工具链需要尽可能覆盖软件生命周期中的所有时期(如图 4 所示)。

悬镜-软件供应链安全白皮书

图 4DevSecOps 模式下软件生命周期

除了以上所提到的工具之外,在 DevSecOps 的应用实践过程中,还有一些更为前瞻性的安全工具,具体可参考 DevSecOps 敏捷安全技术金字塔(如图 5所示)。该金字塔在《2020 DevSecOps 行业洞察报告》中首次被提出, 目前已进展到 2.0 版本。其描述了一组层次结构,金字塔底部是基础性技术,越上层的技术对 DevSecOps 实践成 熟度的要求越高。

悬镜-软件供应链安全白皮书

图 5 DevSecOps 敏捷安全技术金字塔 V2.0 版

DevSecOps 敏捷安全技术金字塔的不断升级,是为了给业界更好的预测和参考,对于 DevSecOps 敏捷安全技术 今后演进方向的预测是开放且持续性的,随着 DevSecOps 实践的不断进展,其中的安全工具会举行调整和更新。

2、设计时期软件供应商风险治理流程

软件供应商风险是指与第三方供应商相关的任何大概阻碍企业利益或资产的固有风险。在挑选第三方软件供应商 时,为了幸免因引入第三方供应商而带来众多潜在的安全风险,需要稳健的流程来识别和治理日益增加的软件供 应商风险。所以,企业亟需构建有效且稳健的软件供应商风险治理流程。

构建完整的软件供应商风险治理流程能够提高软件供应链的透明度,并且关心企业实现落低采购成本、识别和减 轻供应商相关风险以及对软件供应商风险治理系统的持续优化改进。以下是针对软件供应商差不多风险治理流程(如 图 6所示)。

悬镜-软件供应链安全白皮书

图 6 软件供应商风险治理流程

标准确立:结合企业的实际事情,DDoS防护,构建软件供应商评估模型,制定软件供应商考核的评估标准及安全框架;

资格评估:依照制定的软件供应商评估模型和相关标准,对初步符合要求的软件供应商举行多维度的综合性资格评估,选出匹配度最高的供应商;

风险评估:对经过资格评估的软件供应商举行安全风险评估,针对软件供应商面临的潜在的安全风险、存在的弱点 以及有大概造成的阻碍综合分析其大概带来的安全风险举行评估;

风险监控:对软件供应商实施长期性的安全风险监控,持续识别和治理软件供应商的安全风险,依照监测结果实施更新软件供应商的风险治理策略。

软件供应商评估模型

为了确保企业能够拥有较为稳定的供应链,提高企业的综合竞争力,通过多方面的综合考察分析,以下构建了一 个系统化、结构化的软件供应商评估模型以供参考。软件供应商评估模型的关键意义在于从不同的维度对软件供 应商举行评估,经过考察软件供应商的综合实力,以挑选最合适的合作伙伴。以下是经过十二种不同维度对软件 供应商评估的全过程(如图 7所示)。

悬镜-软件供应链安全白皮书

图 7 软件供应商评估模型

财务实力:评估软件供应商的财务能力以及稳定性,确保供应商具有稳定性和可靠性来提供业务所需要的服务;

质量同意:评估软件供应商的相关软件产品是否符合国家及行业标准要求,信息安全和数据爱护操纵流程必须遵 守法律、监管或合同义务以及任何行业标准的信息安全要求;

企业资质:评估软件供应链上的第三方供应商是否可以提供软件安全开辟能力的企业级资质,是否具备国际、国家或行业的安全开辟资质,在软件安全开辟的过程治理、质量治理、配置治理、人员能力等方面是否具备一定的经验,具有把安全融入软件开辟过程的能力;

技术储备:评估软件供应商是否拥有自主研发能力以及自主技术知识产权,对科技知识是否有举行不断的积存和及时更新,对企业提高技术水平、促进软件生产进展是否有开展一系列的技术研究;

合作能力:评估软件供应商是否拥有高效的沟通渠道以及全面的解决方案,拥有共同的价值观和工作理念有助于建立长期的合作关系;

软件交付能力:评估软件供应商在整个软件及信息服务交付的过程中,是否能满脚软件持续性交付的要求;

应急响应能力:评估软件供应商从软件开辟到运营时期是否持续实行实时监控机制,是否有利用适当的网络和基 于端点的操纵来收集用户活动、异常、故障和事件的安全日志,是否具有适当的业务延续性和恢复能力,以防止或减轻业务中断和相关阻碍;

服务能力:评估软件供应商的售前服务能力、培训服务能力以及售后维护服务能力是否满脚企业的要求,在合作 期间内是否能够始终如一的提供高水平的质量和服务;

创新能力:评估软件供应商的综合创新能力,包括技术创新能力、研究开辟能力、产品创新能力以及生产制造力等;

内部治理能力:评估软件供应商是否拥有完善的内部治理制度流程、有效的风险防范机制以及是否对职员定期举行安全培训等,对供应商内部安全开辟标准和规范举行审查,要求其可以对开辟软件的不同应用场景、不同架构设计、不同开辟语言举行规范约束,审查软件供应商对其自身信息安全保密程度;

软件成本:评估软件供应商所提供的软件成本是否存在虚报等现象,审查产品及相关服务是否能够按照合理的价格交付;

软件适用性:评估软件在开辟部署以及动态运行时的适用性,是否能够持续满脚新的需求。

软件供应商风险治理的作用

经过对软件供应商风险治理有助于企业更加高效准确地操纵软件供应商带来的新的安全风险,以下是软件供应商 风险治理的具体作用。

落低风险:经过对软件供应商举行完全的审查能够识别其大概对业务构成的安全威胁的任何潜在弱点,依照软件供应商对企业业务的阻碍确定漏洞的重要性;

落低成本:经过对软件供应商风险举行充分的评估,能够以主动而非被动的方式应对安全威胁,减少潜在的安全风险,幸免网络安全攻击或其他数据泄露等咨询题给企业造成的财务损失;

提高效率:经过对软件供应商举行实时风险监控,能够提早预知风险并及时做出响应,提高企业处理安全风险的 效率;

培养长期合作关系:经过对供应商风险的治理、评估和跟踪监控,加强对供应商健康状况的监督,有助于培养可靠的长期合作关系。

3、编码时期构建详细的软件物料清单

软件供应链安全始于对关键环节的可见性,企业需要为每个应用程序持续构建详细的 SBOM(Software Bill of Material,软件物料清单)(如表 2 所示),从而全面洞察每个应用软件的组件事情。SBOM 是描述软件包依靠树 的一系列元数据,包括供应商、版本号和组件名称等多项关键信息,这些信息在分析软件安全漏洞时发挥着重要作用。

悬镜-软件供应链安全白皮书

表 1 软件物料清单示例

上表是一份软件物料清单示例,其中 SPDX 和 SWID 是两种国际通用的 SBOM 字段标准。SPDX(The Software Package Data Exchange,软件包数据交换)是 Linux 基金会下的开放性标准,其用于交流软件物料清单信息,包括组件、许可证、版权等信息。SPDX 经过为公司和社区共享重要数据提供通用格式来减少冗余工作,从而简化 流程并提高合规性。SWID(Software Identification,软件标识)标签旨在为组织提供一种透明的方式来跟踪在他们的托管设备商安装的软件,它于 2012 年由 ISO 提出,并于 2015 年更新为 ISO/IEC 19770-2:2015。

SWID 标 签文件包含有关软件产品特定版本详尽的描述性信息。除表格中的两种应用最为广泛的 SBOM 字段标准外,还有 CycloneDX、CoSWID、CPE、Grafeas 等其他较为常见的标准,各标准的应用场景存在一定的区别。

SBOM 的概念源自创造业,其中物料清单是详细讲明产品中包含的所有项目的清单。例如:在汽车行业,创造商会 为每辆车维护一份详细的材料清单。此 BOM 列出了原始设备创造商自个儿创造的零件和第三方供应商的零件。当发觉有缺陷的部件时,汽车创造商能够准确地懂哪些车辆受到阻碍,并能够通知车主维修或更换。

同样,构建软件的企业也需要维护准确、最新的 SBOM,其中包括第三方和开源组件的清单,以确保其代码质量高、合规且安全。企业经过要求软件供应商提供 SBOM,以发觉潜在的安全和许可证咨询题,或者应用程序是否使用过 时的库版本。

当发觉此类咨询题时,治理员能够要求供应商使用较新版本重建应用程序,在等待更新的软件期间,安全人员有机遇采取暂时缓解措施来爱护应用程序免受攻击者利用该漏洞举行攻击,还能够关心安全人员在漏洞 被披露或核心库公布新版本时 , 对应用程序和代码举行抽查以幸免浮上安全咨询题。

举个例子:假如安全人员手中有一份在其环境中运行的每个应用程序的物料清单,这么早在 2014 年 4 月,当 Heartbleed 漏洞最初被披露时,安全人员就无需测试每个应用程序中是否包含 OpenSSL,而是能够经过检查列表 就即将懂哪些应用程序依靠于易受攻击的版本和需要采取的措施。

SBOM 生产流程

在成熟的体系下,SBOM 的生产能够经过软件生命周期每个时期所使用的工具和任务流程化地完成,这些工具和 任务包括知识产权审计、采购治理、许可证治理、代码扫描、版本操纵系统、编译器、构建工具、CI/CD 工具、包 治理器和版本库治理工具等(如图 8 所示)。

悬镜-软件供应链安全白皮书

图8 SBOM 生产流程

SBOM 中应该包含软件组件与此组件所依靠的任何其他基础软件组件之间的关系。软件产品在公布任何版本时, SBOM 都应作为产品文档的一部分被提供,在 CI/CD 的标准实践中,SBOM 中包含的信息将不断更新。它从在需求中集成安全性需求开始,或者是 SBOM 中的一些元素基本在需求时期被添加到用例中,如此安全性和 SBOM 就能够成为 DevOps 过程的标准和结构化的一部分。

为了确保持续一致性,应在测试工作中将 SBOM 作为测试用例的一部分,并且 SBOM 信息应随着使用工具和组 件的更新而更新,使 SBOM 信息自动更新成为 CI/CD 管道中每个构建周期标准的一部分。在公布运营时期使用 SBOM 能够在使用的库或组件存在漏洞时,以更快的时刻检测出有哪些应用程序中存在这些漏洞,并及时举行修复工作。

SBOM 可提高软件供应链的透明度

虽然 SBOM 对很多人来讲还是特别陌生,但其需求却不断呈现增长态势。Gartner 在其 2020 年的“应用程序安全测 试魔力象限”中预测到:“到 2024 年,至少一半的企业软件买家要求软件供应商必须提供详细的、定期更新的软 件物料清单,并且 60% 的企业将为他们创建的所有应用程序和服务自动构建软件材料清单,而这两组数据在 2019 年都还不到 5%。”

现代软件是使用第三方组件组装而成的,它们以复杂而独特的方式粘合在一起,并与原始代码集成以实现企业所 需要的功能。在现代多层供应链中,单个软件大概有成百上千的供应商,从原材料来源到最后来组装系统的全套供 应商中找出某一组件的来源需要花费大量的时刻和精力。所以,为所有组件构建详细准确的 SBOM,关心企业跟 踪当前运行的程序、源代码、构建依靠项、子组件等所依靠组件的使用事情,检测软件组件是否带有已知的安全 漏洞或功能漏洞。

悬镜-软件供应链安全白皮书

图 9 SBOM 的作用

SBOM 有助于揭示整个软件供应链中的漏洞与弱点,提高软件供应链的透明度,减轻软件供应链攻击的威胁。经过 使用 SBOM 能够关心企业举行漏洞治理、应急响应、资产治理、许可证和授权治理、知识产权治理、合规性治理、 基线建立和配置治理等(如图9所示)。

经过自动化创建 SBOM 能够在漏洞披露时及时地举行响应排查以及快速的安全修复,最小化软件供应链的安全风 险;在开源组件和版本快速迭代的事情下,从风险治理的角度跟踪和持续监测闭源组件和开源组件的安全态势;

并且 SBOM 列举了治理开源组件的许可证,能够爱护企业免受不当使用相关的法律或知识产权的风险,爱护应用 程序在软件供应链中的合规性,幸免将已知缺陷传递到软件供应链的下游。

SBOM 为漏洞风险管理节约大量时刻

SBOM 的使用能够为软件供应链的漏洞管理节约大量时刻。及时性关于企业在漏洞修复时是很重要的。以往, 企业在修复已部署系统的漏洞缺陷时往往需要几个月甚至是数年的时刻,其重要缘由之一是企业无法在漏洞浮上 的第一时刻知晓该信息。

软件供应链下游的企业需要等待上游软件供应商完成软件补丁,才干够举行漏洞修复, 在等待的时刻内,下游企业往往会面临无法预知的安全风险。而构建详细准确的 SBOM 则能够幸免这一现象的发生, 允许所有利益相关者在漏洞发觉时即将开始评估漏洞,并开始制定相关的补救措施。以下经过一张对照图来讲明 SBOM 对漏洞风险管理时刻的阻碍(如图 10 所示)。

悬镜-软件供应链安全白皮书

图 10 SBOM 对漏洞风险管理时刻的阻碍

受感染的开源组件在软件中未被修复的每一分钟都会增加潜在被利用的风险,SBOM 有助于企业在漏洞披露的早期 对漏洞举行识别,经过 SBOM 提供受感染开源组件和依靠项的准确位置,采取适当的步骤举行修改,为企业在风 险分析、漏洞治理和补救过程中节约数百小时至数月的时刻。

使用基于 SCA 技术的工具

企业需要慎重、合理地挑选、猎取和使用第三方闭源组件和开源组件。软件安全团队或研发团队经过必要的技术 手段确保所使用的第三方组件的安全性,及时猎取所使用第三方组件和开源组件的漏洞情报,并适时做出响应。

软件成分分析(Software Composition Analysis ,SCA)是一种对二进制软件的组成部分举行识别、分析和追踪 的技术。SCA 能够生成完整的 SBOM,分析开辟人员所使用的各种源码、模块、框架和库,以识别和清点开源软 件(OSS)的组件及其构成和依靠关系,并精准识别系统中存在的已知安全漏洞或者潜在的许可证授权咨询题,把 这些安全风险排除在软件的公布上线之前,也适用于软件运行中的诊断分析。

软件成分分析分为两种模式,静态和动态。静态模式是使用工具对目标工程文件举行解压,识别和分析各个组件 的关系;动态模式则是依靠于执行过程,在程序执行的并且收集必要的活动元数据信息,经过数据流跟踪的方式对目标组件的各个部分之间的关系举行标定。 经过使用基于多源 SCA 开源应用安全缺陷检测技术的安全审查工具,能够精准识别应用开辟过程中,软件开辟人 员故意或违规引用的开源第三方组件,并经过对应用组成举行分析,多维度提取开源组件特征,计算组件指纹信息, 深度挖掘组件中潜藏的各类安全漏洞及开源协议风险。

某金融企业的业务团队无法答应速度的迟滞,在研发效率和编码速度的考量下,大量的软件应用都基于第三 方的组件、开源代码、通用函数库实现,随之而来是绝大多数应用程序都包含开源组件的安全风险,为企业 带来了很多未知的安全隐患。 为了更好地举行开源组件管理工作,该企业引入基于 SCA 技术的工具,与 DevOps 流程无缝结合,在流水线 的测试时期自动发觉应用程序中的开源组件,提供关键版本操纵和使用信息,并在 DevOps 的任何时期检测 到漏洞风险和策略风险时触发安全警报。所有信息都经过安全和开辟团队所使用的平台工具实时发送,实现 及时的反馈循环和快速行动。

在不改变该企业现有开辟测试流程的前提下,将 SCA 工具与代码版本治理系统、构建工具、持续集成系统、 缺陷跟踪系统等无缝对接,将源代码缺陷检测和源代码合规检测融入到企业开辟测试流程中,关心企业以最 小代价降地源代码安全保障体系,落低软件安全咨询题的修复成本,提升软件质量。

4、公布运营时期建立成熟的应急响应机制

在软件的公布运营时期,企业需要具备安全应急响应能力(如图 11所示),能在软件公布后对发生在软件和软件 补丁猎取渠道的软件供应链安全事件、软件安全漏洞披露事件举行快速的安全响应,操纵和消除安全事件所带来的 安全威胁和不良阻碍,进而追溯和解决造成安全事件的根源所在。

公布运营时期包括监测告警、应急响应、事件处置、持续跟进等关键活动。在日常的运营治理中,企业能够经过采 用自动化分析技术对数据举行实时统计分析,发觉潜在的安全风险,并自动发送警报信息。在有突发事件浮上时, 经过监测预警,安全人员能够迅速地举行安全响应,在最短的时刻内确定相关解决方案并举行事件处置,在解决之后举行经验总结并改进。经过监测预警技术对软件系统举行实时自动监测,当发觉安全咨询题时,即将发出警告, 并且实现信息快速公布和安全人员的快速响应。

悬镜-软件供应链安全白皮书

图 11 安全风险监测分析及响应

在公布运营时期发生突发事件之后的应急响应与对安全事件举行处理的治理能力相关,所以,企业需要加强检测预 警能力、提高应急响应速度、加快应急处置效率,从事后被动救火转化为主动应急治理。充分预估突发事件的场景, 经过治理活动与技术手段幸免突发事件的发生,在突发事件发生时可以及时监测预警,并有序举行处理行为。

由于在应用程序公布特别久之后,仍有大概在其中发觉新的安全漏洞,这些漏洞大概存在于构成应用程序的底层开源 组件中,导致“零日”漏洞的数量不断增加。所以,企业需要制定事件响应和漏洞处理策略,与率先的漏洞研究机 构举行合作,积极监控大量漏洞信息来源。并且,举行持续性的安全检查,定期的安全检查能够爱护应用程序免受 新发觉的安全漏洞的阻碍。

构建完善的运营保障工具链BAS

2017 年,Gartner《面向威胁技术的成熟度曲线》中首次提及入侵与攻击模拟( Breach and Attack Simulation, BAS)工具(如图 12 所示),并将其归到新兴技术行列。在 2021 年,Gartner 将 BAS 纳入“2021 年顶级安全和 风险治理趋势”。

悬镜-软件供应链安全白皮书

图 12 BAS 技术原理

BAS 经过模拟对端点的恶意软件攻击、数据泄露和复杂的 APT 攻击,测试组织的网络安全基础设施是否安全可靠, 在执行结束时,系统将生成对于组织安全风险的详细报告,并提供相关解决方案。并且结合红队和蓝队的技术使 事实上现自动化和持续化,实时洞察组织的安全态势。

BAS 能够确定漏洞的覆盖范围并对检测出的漏洞提供补救意见,防止攻击者对漏洞加以利用。除了自动化和持续 监控之外,BAS 还使安全团队改变了他们的谨防方式,采取更为主动积极的策略,维护组织各个方面的安全。

WAF

早在 2007 年,国家计算机网络应急技术处理协调中心检测到中国大陆被篡改网站总数累积达 61228 个,比 2006 年增加了 1.5 倍。其中,中国大陆政府网站被篡改各月累计达 4234 个。为了更好的应对网络攻击,Web 应用防护 系统也被称为网站应用级入侵谨防系统(Web Application Firewall, WAF)应运而生,WAF 能够对来自 Web 应用 程序客户端的各类请求举行内容检测和验证,确保其安全性和合法性,对非法的请求予以实时阻断,从而对各类 网站站点举行有效的安全防护(如图 13 所示)。

悬镜-软件供应链安全白皮书

图 13 WAF 技术原理

WAF 经过增强输入验证,能够在运营时期有效防止网页篡改、信息泄露、木马植入等恶意网络入侵行为,从而减 小 Web 服务器被攻击的大概性。并且,WAF 还能够推断用户是否是第一次访咨询,将请求重定向到默认登录页面并 且记录时刻,经过检测用户的整个操作行为能够更容易识别攻击。

RASP

作为第一道防线,WAF 可以阻挠差不多攻击,但难以检测到 APT 等高级威胁,不仅这样,企业需要持续“调整”WAF 以适应不断变化的应用程序,这一过程消耗了安全治理人员大量的精力。此刻,运行时应用程序自我爱护技术 (Runtime Application Self-protection,RASP)(如图 14所示)作为新一代运行时爱护技术被引入,RASP 能够 提供更深入的爱护能力,更广泛的覆盖范围,同时能够花费更少的时刻。

RASP 将爱护代码像一剂疫苗注入到应用程序中,与应用程序融为一体,使应用程序具备自我爱护能力。RASP 结 合应用的逻辑及上下文,对访咨询应用系统的每一段堆栈举行检测,当应用程序遭受到实际攻击和损害时,RASP 可 以实时检测和阻断安全攻击,无需人工干预,最后来实现软件应用的自我爱护,确保软件应用的安全运行。

悬镜-软件供应链安全白皮书

图 14 RASP 技术原理

RASP 在运营时期能够应对无处不在的应用漏洞与网络威胁,为应用程序提供全生命周期的动态安全爱护,能够精 准识别应用运行时暴露出的各种安全漏洞,举行深度且更加有效的威胁分析,快速定位应用漏洞,大大提升修复 效率,保障应用程序的安全性。

威胁情报平台

经过建立威胁情报平台(Threat Intelligence Platform,TIP)(如图 27 所示),能够关心安全人员明确企业的在 线资产和安全状况,依照企业自身资产的重要程度和阻碍面,举行相关的漏洞修补和风险治理;并且能够关心安 全人员了解企业自身正在遭受或今后面临的安全威胁,提供解决建议。

悬镜-软件供应链安全白皮书

图 15 威胁情报平台原理

威胁情报平台与各类网络安全设备和软件系统协同工作,为威胁分析和防护决策提供数据支撑,DDoS防护,经过对全球网络 威胁态势举行长期监测,以大数据为基础公布威胁态势预警,实时洞悉风险信息,进而快速处置风险。

容器安全工具

在公布运营时期,经过使用容器安全工具(Container Security)(如图 28 所示),能够自动化构建容器资产相关 信息,提供容器环境中各类资产的状态监控,包括容器、镜像、镜像仓库和主机等基础资产信息,使资产拥有较 强的可扩展能力;经过建立智能应用补丁扫描工具,为安全人员提供镜像治理、镜像检测以及自动化补丁修复建议。

悬镜-软件供应链安全白皮书

图 16某容器安全工具架构

为了更好地应对未知和迅速变化的攻击,容器安全工具能够对数据举行持续监控和分析,经过结合系统规则、基 线和行为建模等要素,自适应识别运行时容器环境中的安全威胁;建立一键自动化检测机制,给安全人员提供可 视化基线检查结果,并且将企业现有的安全技术与持续运营的安全模型相结合,实现持续化的动态安全检测。

二、软件供应链安全应用实践可信研发运营安全能力成熟度模型

中国信息通信研究院云计算与大数据研究所自 2019 年起,联合业界众多头部厂商专家制定《可信研发运营安全能 力成熟度模型》标准,提出可信研发运营安全能力体系框架(如图 17 所示)。可信研发运营安全能力体系框架的 构建继承 SDL 与 DevSecOps 的核心理念,安全前置,吸收 SDL 与 DevSecOps 体系的优点,优化具体安全实践要素,是一种贯通研发运营全生命周期的安全理念。

悬镜-软件供应链安全白皮书

图 17 可信研发运营安全能力体系框架

可信研发运营安全能力体系框架强调安全左移,分为治理制度以及涉及软件应用服务全生命周期的需求时期、安 全需求分析时期、设计时期、开辟时期、验证时期、公布时期、运营时期和停用下线时期八大部分,每个部分提 取了关键安全要素,规范了企业研发运营安全能力的成熟度水平。依照各时期安全要素达标事情,可信研发运营 安全能力成熟度模型共分为 3 个级别,自低向高依次为基础级、增强级和先进级。

云安全共享责任模型

在云计算环境下,云服务提供商与云租户需要举行软件供应链安全共治,但云服务普遍存在安全责任划分不清楚 与管理措施不明确等咨询题,为了解决这些咨询题,2019 年,DDoS防护,微软在《Shared Responsibility in the Cloud》中提到 云安全共享责任模型(如图 18 所示)。云安全共享责任模型指出,在基础设施即服务(IaaS)、平台即服务(PaaS) 和软件即服务(SaaS)三种不同的云服务模式下,云服务提供商(Cloud Service Provider,CSP)和客户之间需 要分担的安全责任不同。CSP 需要承担客户在使用云服务时保障物理安全的责任,客户需要负责确保其解决方案 及其数据被安全地识别、标记和正确的分类,以满脚任何合规义务的责任,其余的责任则由 CSP 和客户共同承担。

悬镜-软件供应链安全白皮书

图 18 云安全共享责任模型

在构建以混合云作为运行环境的软件程序时,应认真评估应用程序的依靠性和安全阻碍,经过使用成熟的 DevSecOps 模型能够关心组织评估整个软件供应链,并确定需要严格操纵的安全关键点。 为了提高可见性和支持混合云体系结构,很多云服务商显示或允许应用程序接口(API)与安全进程的交互。不成 熟的 CSP 大概不懂怎么以及在多大程度上向客户提供 API。例如,经过检索日志或权限操纵的 API,云租户能够 获得敏感性较高的信息。可是这些 API 能够关心云租户检测到未经授权的访咨询行为,所以 API 的开放是必要的。

Grafeas 开源打算

Grafeas(希腊语中的“scribe”)是由 Google 发起,联合包括 Redhat、IBM 在内的多家企业共同公布的开源计 划。Grafeas 是一具开源工件元数据 API(如图19 所示),它提供了一种统一的方式来审计和治理软件供应链。 Grafeas 定义了一具 API 规范,用于治理软件资源,例如容器镜像、虚拟机镜像、JAR 文件和足本。组织能够使用 Grafeas 来定义和聚合有关项目组件的信息。Grafeas 为组织提供了一具中央事实来源,用于在不断增长的软件开 发团队和管道中跟踪和执行策略。构建工具、审计工具和合规性工具都能够使用 Grafeas API 来存储和检索有关各 种软件组件的综合数据。

悬镜-软件供应链安全白皮书

图 19 Grafeas 开源打算原理

并且,作为 Grafeas 的一部分,Google 推出了 Kritis,其是一种 Kubernetes 策略引擎,经过在部署前对容器镜像 举行签名验证,能够确保只部署通过可信授权方举行过签名的容器镜像,落低在环境中运行意外或恶意代码的风险。

Grafeas 为组织成功治理其软件供应链所需的关键元数据提供了一具集中的、结构化的知识库。它反映了 Google 在数百万个版本和数十亿个容器中构建内部安全和管理解决方案所积存的最佳实践,包括:

使用不可变的基础设施来建立针对持续性高级威胁的预防性安全态势;

基于全面的组件元数据和安全证明,在软件供应链中建立安全操纵,以爱护生产部署;

保持系统的灵便性,并确保环绕通用规范和开源软件的开辟人职员具的互操作性。

Grafeas 旨在关心组织在现代软件开辟环境中应用上述提到的最佳实践,实现以下功能和设计要点:

全面覆盖:Grafeas 依照软件组件的唯一标识符存储结构化元数据,所以组织无需将其与组件的注册表放在一起, 它能够存储来自不同储存库组件的元数据;

混合云适配性:组织能够使用 Grafeas API 作为中央通用元数据存储;

可插入:Grafeas 可轻松添加新的元数据;

结构化:针对常见的元数据类型的结构化元数据模式,让组织能够添加新的元数据类型,同时依靠于 Grafeas 工 具能够治理这些新数据;

访咨询操纵:Grafeas 允许组织操纵多个元数据的访咨询;

查询能力:使用 Grafeas 的组织能够轻松查询所有组件的元数据,不必解析每个组件的单一报告。

在软件供应链的每个时期,不同的工具会生成有关各种软件组件的元数据,示例包括开辟人员的身份、代码、何时 签入和构建、检测到哪些漏洞、哪些测试经过或失败等,接着 Grafeas 会捕获此元数据。  

报告下载地址:https://www.dsocon.cn/#/down

版权保护: 本文由 主页 原创,转载请保留链接: /web/139592.html


QQ客服

400-0797-119