网安加·百家讲坛

发布时间:2023-8-24 | 杂志分类:其他
免费制作
更多内容

网安加·百家讲坛

《百家讲坛》征稿启事CONTRIBUTIONS WANTED百家讲坛 | 原创稿件征集活动开启!《网安加 · 百家讲坛》立足于网络安全发展时势,面向网络安全、软件研发与测试、软件质量领域的专家,广纳远见卓识,以展现不同角度不同专业意见,为行业人员提供最新资讯。现有奖征文渠道正式开启,欢迎各路专家打包投递。投稿须知 :1、字数:1500 字及以上;2、稿费:200 元 / 千字,上限 800 元;3、投稿作品需为原创作品,杜绝硬广,要求主题鲜明, 图文并茂最佳;4、投稿形式:以 Word 文字版发送;5、投递稿件需经过审核,审核通过即录用稿件。奖项设置 :1、入选稿件,按稿件字数,作者可获得相应稿费;2、以季度为期,每期稿件阅读量 PK,当月文章阅读量首位文章的作者额外获得 1000 元奖金,具体以每月最后一个工作日公布消息为准。关于百家讲坛 :《网安加·百家讲坛》是由 100+ 资深软件开发专家、安全领域 KOL、甲方企业 CSO 等直播分享的“理论 +实践 + 案例”专业内容,目前定期为 2000+ 政企、大型互联网、金融、高校等提供内部资料参考。选题范围:聚焦于软件研发效能、软件... [收起]
[展开]
网安加·百家讲坛
粉丝: {{bookData.followerCount}}
文本内容
第3页

《百家讲坛》征稿启事

CONTRIBUTIONS WANTED

百家讲坛 | 原创稿件征集活动开启!

《网安加 · 百家讲坛》立足于网络安全发展时势,面向网络安全、软件研发与测试、软件质量领域的专家,广纳远见

卓识,以展现不同角度不同专业意见,为行业人员提供最新资讯。

现有奖征文渠道正式开启,欢迎各路专家打包投递。

投稿须知 :

1、字数:1500 字及以上;

2、稿费:200 元 / 千字,上限 800 元;

3、投稿作品需为原创作品,杜绝硬广,要求主题鲜明,

图文并茂最佳;

4、投稿形式:以 Word 文字版发送;

5、投递稿件需经过审核,审核通过即录用稿件。

奖项设置 :

1、入选稿件,按稿件字数,作者可获得相应稿费;

2、以季度为期,每期稿件阅读量 PK,当月文章阅读

量首位文章的作者额外获得 1000 元奖金,具体以每月

最后一个工作日公布消息为准。

关于百家讲坛 :

《网安加·百家讲坛》是由 100+ 资深软件开发专家、

安全领域 KOL、甲方企业 CSO 等直播分享的“理论 +

实践 + 案例”专业内容,目前定期为 2000+ 政企、大

型互联网、金融、高校等提供内部资料参考。

选题范围:

聚焦于软件研发效能、软件安全开发、DevSecOps、

SDL、软件供应链安全、云原生安全、数据安全等领域

的各种新锐观点、技术分享。

投稿渠道:

添加微信:xiaoankt02 进行投稿,请备注“姓名 + 主

题”,并发送个人简介。

投稿形式:以 Word 文字版发送,入选稿件不返稿底,

请自留稿底。

免责声明:

本资料由网安加社区整理,内部所有文章均与作者确

认核对,且资料仅供内部学习交流使用,未经网安加

社区允许,其他人员不得复制。

* 最终解释权由网安加社区所有

第4页

GPT-4 等人工智能大模型横空出世,成为近段时间科技圈长时间持续的热门

话题。我们观察到网络空间的攻防双方,实际在很长一段时间处于相对平衡的状

态,但随着 AI 大模型技术的出现及在安全行业的广泛应用,必将再次动态重构这

个平衡,各方迭代进化的速度,将决高低、也决生死。

网安加社区软件开发及安全领域的众多专家紧跟前沿,对于 AI 大模型技术

给网络安全及软件开发领域带来的深远影响,做了非常有价值的工程实践探索,

相信这些成果对安全行业的发展会起到促进作用。

同期另一件事件同样引起我的关注,由于引用的开源组件里的一个 bug,导

致 ChatGPT 出现严重的个人信息泄露事件。抛去光芒,ChatGPT 依然是一款软件,

几乎所有软件都引用了开源组件,因此,开源组件的安全治理在软件定义一切的

时代也是一道必答题。

行业的问题,就是我们网安加社区的工作方向,我们将持续开展相关最佳实

践的交流探讨,希望各位有志之士也一同加入进来,见证成长。

网络安全的奇点将至

网安加社区创始人:

卷首语/PROLOGUE FOREWORD

第5页

从两个旧案谈软件安全的重要性

ChatGPT 在互联网安全研发领域的变革作用

浅谈 ChatGPT 和网络安全行业的爱恨情仇

开源安全治理解决方案分享

浅谈开源治理

DevSecOps 实践:如何在研发过程中做好供应链安全

DevSecOps 度量和正确的使用方式

OWASP 中国 S-SDLC CMM 项目介绍

软件安全研发建设之路

安全与业务战略一致性的理想与现实

漫谈安全的两三事

OCBC 框架下企业云化 CSPM 落地思考和实践探索

多场景下的安全运营集约化

API 安全与实践

甲方的个人信息保护实践

护网行动和企业信息安全体系治理逻辑

网安大咖说第一期 | 拐点已至——2023安全新风口

网安大咖说第二期 | AI狂飙——ChatGPT会颠覆网络安全行业吗?

线下活动| “ChatGPT对研发管理的冲击与契机”线下沙龙成功举办圆满

线下活动| 开源安全治理行业最佳落地实践私享会成功举办

线下活动| 2023 CI/CD安全技术研讨会成功举办

专家招募

专家入驻

02 百花齐放

01 百家论道 04

06

12

15

20

24

27

32

35

39

42

46

51

56

65

68

71

71

72

72

74

75

76

CONTENTS/目录

第6页

4

百家论道 LECTURE ROOM

从两个旧案

谈软件安全的重要性

国内知名网络安全专家,

研究方向为信息安全等级保护、

工业控制网络安全、智慧城市网

络安全体系框架等。曾任工业控

制系统信息安全技术国家工程实

验室专家委员;贵阳市攻防演练

技术总策划,攻防演练风险管控

平台总设计师;贵阳大数据安全

靶场顾问;福州市政府特聘网络

安全专家;第一届、第二届和第

四届数字中国建设峰会网络安全

保障专家组组长;雄安新区网络

安全首席顾问。编写著作三部,

发表各类文章百余篇,授权发明

专利三项。

陆宝华

二十多年前,笔者亲自办过两个案件。

第一个,当时某计划单列市的政府某部门的服务器,向国外的邪教网站发

送邪教的材料和文章,被上级部门监控到了,案件不需要太多的侦查,很快就

破案了。是为这个政府部门开发软件的企业的技术总监干的,他利用远程登录

到系统后台,使用政府服务器,发送了相关反动数据。后经查实他本人是邪教

组织的重要成员。

第二个,还是这个城市的交警的违章罚款系统,被人非法使用,删除了大

量的违章人员的数据。侦查也不困难,是为交警开发软件系统的企业的技术核

心人员,与检车线上的检车员相互勾结,由检车员向违章司机收取罚款,然后

电话告诉这个技术人员,他远程后台删除。

这两个案件,都是由软件企业为政府系统开发的软件上预留了相应的后门

而导致的。虽然案件过去二十多年,但是,对于今天来说仍有警示作用。

首先,这两个软件上线时,只做了功能检测,而没有相应的安全检测,实

际上这俩当事人,都考虑了可能会有安全检测这个环节,他们提供的用于测试

的软件(仅为功能测试)与安装运行的软件并不是一个版本。

这就出现了两个问题,一是没有进行安全检测,二是即使是进行了安全检

测,由于安装的版本与被检测的版本并不一致,给了作案人员可乘之机。

同时也说明了两个问题,一是上线的软件一定要进行安全检测,二是一定

要保证软件的检测版本与安装运行版本必须保持一致。

实际上,这两起案件都是预留了远程登录的接口,算是后门,技术上不高

明,更不复杂,并且作案人没有专业黑客的本领,否则作案人把作案活动的痕

迹都打扫干净,那案件侦破难度将大幅提升。

对于第二个方面,国际标准 ISO15408 中的第三部分,“分发与操作”中,

就有明确的规定,说心里话,没经过这两起案件时,虽然记住了相关的要求,

但是对相关的意义的理解还不是那么深,正是革命导师所说“感知了的东西,

我们并一定理解它,而理解了的东西,我们一定会更深刻地感知它。”

实际上,除了这两个案件之外,在笔者的工作中,还发现过某企业为政府

开发的网站,普遍存在同样的漏洞,实际上这个企业就是想降低成本,把一个

带有明显漏洞的软件模块直接拿来用,为多家单位开发了网站。

应该说,近年来由于各种管理机制的不断健全,软件开发企业的行为也得

到了规范,故意预留后门和不经安全检测就将一些模块拿来用的现象已少有发

生,但是并没有杜绝。

2019 年底,为确保雄安新区某局的重要业务系统软件的安全,我通知开发

商(国内一个相当著名的企业),要对他们的软件进行安全检测。该企业得到通

知后,高度重视,充分准备,自行做了软件的黑盒安全检测和白盒代码审计工

第7页

5

LECTURE ROOM 百家论道

作。但在 2020 年 4 月份检测工作实际开展过程中,通过

使用一个国内厂家的灰盒安全测试工具进行检测,软件

中一个不算大的模块,查出四个高危和七个中危漏洞,

吃惊之余,软件开发商与工具提供商就检出漏洞进行了

充分沟通,最终对检测结果非常认可。

黑盒检测,很难照顾到全面,往往是一条线打进去

了,也就认为检测到了问题,没打进去也就认为相对是

安全了。白盒看上去很全面,但是代码审计不是那么容

易做的。并不是说这两个检测不重要,而是说这样的检

测是不够的。灰盒检测,通过“插桩”技术实现交互式

的检测,发现的确定性问题更多、定位也更精准。建议

是这三种检测都应该做,特别是对安全性要求较高的应

用程序,灰盒一定要做。

软件的安全,是网络空间安全的生命线,一个系

统,没有软件,也就没什么用处,当然也就没有数据,

更谈不是系统的服务功能。也就不用谈安全了。那么,

我们建系统干嘛呢?

十多年以来,软件定义一切的口号叫得很响,并且

也确实在稳步地推进,软件定义一切是必要的,可如果

软件本身不安全,那所定义的一切,还有安全可言吗 ?

软件安全,应该分为系统软件安全、中间件安全和

应用程序的安全。系统软件,就那么几家,中间件的开

发商也不算多,这种检测的机制和能力,不是我们各个

单位所具有的。

系统软件和通用中间件的开发商,往往有很庞大的

检测队伍和机制,相对来说检测的能力很强大,但仍然

会时不时曝出一些漏洞,有些漏洞甚至已经成为了一些

网络战的工具。而应用程序的开发商,缺少这种检测能

力,软件本身的安全性实际上更差。用软件定义一切,

恰恰不是由系统软件决定的,应用软件是定义这一切的

决定因素。

应用软件的安全检测,是我们保障安全的关键所

在。笔者一直认为,对于由他人的侵害所导致的安全问

题(我们就叫它“人祸”吧),解决的根本方法是“保证

正确的授权操作”。这里包含了三层意思,一是操作需要

授权;二是授权必须正确;三是正确的授权操作机制必

须有保证。

对应用程序来说,这三个方面往往都需要考虑:

授权机制,可以通过操作系统等系统软件来实现,

但是,这些系统软件很难将访问控制的颗粒度做得很

细,建立一个主体,对应一个客体的访问授权机制。一

个应用,对于操作系统来说,就是一个客体,而所有有

权访问这个客体的人,操作系统都得放行。这就需要在

应用程序中建立更细颗粒度的访问控制机制(授权操作

机制)。所以说,软件安全并不仅仅是查漏洞,如果安全

机制没有真正的建立,那么就等于把前面打开,随便进

入了,那么就不需要什么黑客技术了。

应用程序要不要建立安全机制,实际上要结合系

统来分析,当操作系统等系统软件能够完全解决授权操

作的问题时,当然不必在应用程序中再画蛇添足,并且

操作系统等系统软件更底层,解决安全问题会更可靠一

些。当操作系统不能细粒度地建立这种访问控制机制时,

就需要在应用程序中来建立,与操作系统一起把“正确

的授权操作”机制建立起来。

软件安全的另一个方面,当然就是保障问题了,要

解决好“正确的授权操作”机制,不会被破坏,不会被

绕过,不会因各种因素而失效的问题。漏洞显然是第一

大问题,这也是人们一提安全,就关注漏洞的原因。

前面说,漏洞的检测可以是黑盒,也可以是白盒,

更可以是灰盒,如果进行联合检测,就会使漏洞水平大

大降低。

除了漏洞之外,还有一个需要解决的保证因素:隐

蔽信道检测问题。隐蔽信道,在计算环境中有存储隐蔽信

道和同步隐蔽信道。在网络环境中,隐蔽信道会更复杂。

对于应用程序来说,主要面向的计算环境,所以要从同

步隐蔽信道和存储隐蔽信道入手进行检测。当然检测还

是要考虑面向更高的安全等级的系统,GB 17859 中规定对

于安全第四级(结构化保护级)以上级别才考虑隐蔽信

道问题。所以,更多的软件保障问题,还是针对漏洞。

对于漏洞的检测,实际上,我们还有很长的路要

走,这是因为漏洞没有办法穷尽,并且一个漏洞修补之

后,很可能会产生新的漏洞。状态机转换的原理,对于

软件的漏洞检测是非常重要的,可惜开发是有很大难度

的。人工智能的出现,或许对软件的漏洞检测会提供更

好的帮助。

除了安全检测工作,还要考虑所检测的软件与安装

的软件版本号必须一致,也就是说安装的应用程序,必

须是经过检测并且是合格的软件。要保证这一点,实际

上并不难,一是可以将检测过的程序进行哈希,并将哈

希值和算法交给使用单位,使用单位可以对安装的程序

进行哈希后,进行比对。还可以由检测部门直接将检测

合格的程序交由用户单位。

最后,建议读者认真地读一读 ISO15408,尽管难

懂,但是管用。

第8页

6

百家论道 LECTURE ROOM

ChatGPT 在互联网安全研发领

域的变革作用

华为土耳其研究所外聘高

级项目顾问,网安加社区特聘专

家,负责华为云应用生态圈产品

线研发管理。曾为华为全球技术

服务中心、华为制造 IT 以及华为

流程 IT 解决方案提供等多个部

门提供长达 8 年的顾问服务。曾

任职环信科技华南区项目总监,

金蝶国际软件研发工程师。获得

PMI-PMP、PMI-ACP、PRINCE2、

NPDP、MSP、P3O 等认证。拥有 1

项国家专利,4 项软件著作,具

有丰富的项目管理实战经验。

潘继平

本文将会探讨 ChatGPT 在互联网安全研发领域的变革作用,以下是文章的

结构图:

一、引言与背景

(一)网络安全挑战

随着互联网的普及和技术的迅速发展,网络安全面临越来越多的挑战。黑

客攻击、数据泄露、恶意软件和各种网络犯罪活动不断威胁着个人和企业的数

据安全。软件开发领域尤其容易受到网络安全问题的影响,因为软件系统中的

漏洞往往是攻击者利用的入口。

(二)软件安全重要性

网络软件安全对于保护数据、确保用户隐私和维护企业声誉至关重要。一

个安全的软件系统可以防止未经授权的访问和操作,保护敏感信息不被泄露。

而一个有安全漏洞的软件系统可能会导致严重的后果,包括财产损失、法律责

任和品牌声誉受损。因此,在软件开发过程中关注安全问题并采取相应的措施

至关重要。

(三)ChatGPT 与代码分析

ChatGPT 是基于 OpenAI 的 GPT-X 架构的人工智能语言模型,具有强大的自

然语言处理和理解能力。在许多应用场景中,ChatGPT 表现出了优异的性能,包

括文本生成、翻译、问答和对话等。此外,ChatGPT还可以应用于代码分析领域,

第9页

7

LECTURE ROOM 百家论道

帮助识别潜在的安全漏洞、分析代码风险、提供代码优

化建议和修复方案。

作为一种先进的人工智能技术,ChatGPT 具有以下

潜在价值:

1、提高代码审查效率:传统的代码审查过程通常需

要耗费大量人力和时间。借助 ChatGPT,我们可以自动

化地对代码进行分析,从而显著提高审查效率和准确性。

2、发现难以察觉的安全漏洞:由于 ChatGPT 具有强

大的模式识别能力,它可以在代码中发现那些人类审查

员容易忽略的安全漏洞,提高软件系统的整体安全性。

3、教育和培训:ChatGPT 可以作为一个教育工具,

帮助开发人员了解最佳实践和安全编码原则,提高他们

在编写安全代码方面的技能。

4、支持多语言和框架:ChatGPT 不仅支持 Java,还

可以处理其他编程语言和框架,这使其成为一种通用的

代码分析工具,可广泛应用于各种软件开发项目。

5、集成到现有的开发流程:ChatGPT 可以轻松地与

现有的开发工具和流程集成,例如持续集成 / 持续部署

(CI/CD)流程,从而在整个软件开发周期中提供实时的

安全分析。

6、与现有安全工具协同作用:ChatGPT 可以与静态

代码分析(SAST)、动态代码分析(DAST)等现有安全工

具配合使用,共同提高代码的安全性和质量。

7、自动化修复建议:ChatGPT 可以根据分析结果自

动生成修复建议,从而帮助开发人员快速解决潜在的安

全问题。

8、安全审计和合规检查:ChatGPT 可以用于自动化

的安全审计和合规检查,帮助企业及时发现潜在的安全

风险。它可以分析企业的网络结构、系统配置、数据存

储等方面,确保符合行业标准和法规要求。

9、隐私保护:随着用户对隐私保护的关注日益增

强,ChatGPT 可以为互联网企业提供隐私保护方案。它

可以帮助企业识别数据处理中的隐私风险,并提出相应

的保护措施,以确保用户数据的安全。

10、恶意行为识别和预防:ChatGPT 可以通过分析

用户行为、网络流量等数据,实时识别并预防恶意行

为,如网络欺诈、黑客攻击等。这有助于提高网络安全

水平,降低企业和用户的潜在损失。

11、安全趋势预测:借助大数据和机器学习技术,

ChatGPT 可以分析网络安全领域的历史数据,预测未来

的安全趋势。这对于制定有效的安全战略和应对措施具

有重要意义。

12、跨领域合作:ChatGPT 可以作为一个桥梁,促进

不同领域的安全研究人员进行合作和交流。通过共享知

识和资源,各方可以共同应对日益严峻的网络安全挑战。

13、开源项目支持:ChatGPT 可以参与到开源项目

中,协助开发者修复安全漏洞、优化代码结构、提高软

件质量。这有助于提升整个开源社区的安全水平。

经过对 ChatGPT 在互联网安全研发领域的应用价值

的探讨,我们了解到了其广泛的潜力。然而,我们也应

当警惕 AI 技术可能被恶意利用的风险。因此,在使用

ChatGPT 时,企业和研究人员应确保遵循道德和法律规

定,以确保人工智能为互联网安全作出积极贡献。接下

来,我们将比较 ChatGPT 与其他常见的代码分析工具和

方法的优势和劣势。

二、ChatGPT 分析代码的能力与对比

在对比 ChatGPT 与其他常见的代码分析工具和方法

时,我们可以从以下几个方面进行分析。以下是静态代

码分析工具、动态代码分析工具和 ChatGPT 的各自优劣

分析:

(一)静态代码分析

静态代码分析工具在不执行代码的情况下对源代

码进行分析,以识别潜在的安全漏洞、代码质量问题

和不符合编码规范的地方。常见的静态代码分析工具有

SonarQube、FindBugs、Pylint 等。

1、优势:

(1)无需执行代码,减少了测试环境的搭建成本。

(2)可以集成到持续集成(CI)系统中,便于自动

化检查。

第10页

8

百家论道 LECTURE ROOM

(3)提供了详细的报告,有助于开发者理解和修复

问题。

2、劣势:

(1)可能会产生误报和漏报,需要人工确认。

(2)难以识别复杂的漏洞和逻辑错误。

(二)动态代码分析

动态代码分析工具在代码执行时分析程序行为,以

检测潜在的安全风险和性能问题。常见的动态代码分析

工具有 OWASP ZAP、Burp Suite、Fuzzing 工具等。

1、优势:

(1)能够发现实际运行中的问题,准确性较高。

(2)可以识别一些静态分析工具难以发现的问题。

2、劣势:

(1)需要运行代码,可能会带来较高的测试成本。

(2) 需要专业知识进行有效的测试,操作难度较高。

(三)ChatGPT 优势

ChatGPT 作为一种基于人工智能的代码分析方法,

可以通过自然语言处理技术分析代码,并为开发者提供

安全建议。

1、优势:

(1)可以理解自然语言,更易于与开发者交流。

(2)能够学习大量的编程知识,提供全面的分析。

(3) 可以自动发现潜在的安全风险,并提供修复建议。

2、劣势:

(1)对于一些特定领域的安全漏洞,可能不如专业

的安全工具准确。

(2)可能受限于训练数据的质量和数量,存在一定

的误报和漏报风险。

(四)提升安全质量

每种代码分析方法都有其优势和劣势,选择合适的

工具取决于具体的项目需求和场景。静态和动态代码分

析工具专注于代码的安全性和质量问题,适合用于专业

的安全审计和性能调优。而 ChatGPT 作为一种基于 AI 的

代码分析方法,可以提供更广泛的支持,包括安全策略

制定、漏洞挖掘分析和安全培训等。它具有较强的自然

语言理解能力,与开发者交流更为便捷。然而,ChatGPT

可能在特定领域的安全漏洞识别方面不如专业的安全工

具准确,并且受训练数据的质量和数量限制,存在一定

的误报和漏报风险。

为了充分发挥各种工具的优势,开发团队可以考虑

将 ChatGPT 与静态和动态代码分析工具结合使用。这样

可以确保项目在不同方面得到全面的检查,从而更好地

提高代码的安全性和质量。

例如,团队可以首先使用静态代码分析工具对源代

码进行自动化检查,发现潜在的安全漏洞和编码问题;

然后使用动态代码分析工具对程序在运行时的行为进行

检测,以识别实际运行中可能出现的问题。最后,可以

利用 ChatGPT 的自然语言理解能力和编程知识库为开发

者提供安全建议、修复漏洞的指导以及其他与安全相关

的支持。

三、ChatGPT 安全漏洞识别

为了更具体地了解 ChatGPT 的性能,我们将分析几

个 Java 案例,了解其在识别安全漏洞方面的表现。

(一)SQL 注入识别

首先,我们将探讨 ChatGPT 如何识别和处理 SQL 注

入漏洞。不安全的 Java 代码示例:

1、ChatGPT 分析:

此代码存在 SQL 注入风险,因为直接将用户输入的

username 和 password 拼接到 SQL 查询语句中。攻击者

可以通过构造恶意输入来执行任意 SQL 语句。

2、修复建议:

使用预编译语句(PreparedStatement)来防止 SQL

注入攻击:

(二)XSS 攻击识别

接下来,我们将分析 ChatGPT 在识别跨站脚本 XSS

攻击方面的表现。不安全的代码示例:

第11页

9

LECTURE ROOM 百家论道

1、ChatGPT 分析:

此代码存在跨站脚本攻击(XSS)风险,因为直接

将用户输入的 username 和 comment 输出到 HTML 页面。

攻击者可以通过提交包含恶意脚本的输入来执行任意

JavaScript 代码。

2、修复建议:

使用输出编码来防止 XSS 攻击:

(三)绕过权限识别

最后,我们将讨论 ChatGPT 在识别权限绕过漏洞方

面的能力。不安全的代码示例:

1、ChatGPT 分析:

此代码存在权限绕过风险,因为仅依赖于用户会话中

的 role 属性来检查用户是否具有管理员权限。攻击者可

能通过伪造会话数据来绕过权限检查,执行管理员操作。

2、修复建议:

使用更安全的身份验证和授权机制,例如 Java

EE 的内置身份验证和授权或使用第三方库如 Spring

Security 来确保权限验证的安全性:

通过以上示例,我们可以看到 ChatGPT 在分析不同

类型的安全漏洞(如 SQL 注入、跨站脚本攻击和权限绕

过)方面的表现。它能够识别出存在的安全风险,并提

供修复建议。然而,需要注意的是,ChatGPT 可能受限

于训练数据的质量和数量,因此在实际应用中,开发者

应结合专业的安全工具和人工审查来确保代码的安全性。

四、融合安全策略与实践

在此部分,我们将探讨如何将 ChatGPT 与其他安全

策略和实践相结合,提高整体安全性。以下是一些建议,

以说明如何将 ChatGPT 与安全开发生命周期(SDL)、安

全编码准则和敏捷开发相结合。

(一)安全开发生命周期(SDL)

安全开发生命周期是一个将安全性纳入整个软件开

发过程的框架,包括需求分析、设计、实现、测试和维

护等阶段。ChatGPT 可以在以下方面与 SDL 相结合:

1、需求分析:在确定项目需求时,ChatGPT 可以协

助开发者识别潜在的安全需求和风险,并提出相应的安

全措施。

2、设计:在设计阶段,ChatGPT 可以评估架构和设

计文档,指出可能存在的安全缺陷并提供改进建议。

3、实现:ChatGPT 可以在代码编写过程中自动发现

潜在的安全漏洞,并为开发者提供修复建议。

4、测试:ChatGPT 可以辅助生成安全测试用例,确

保软件在各种攻击场景下的安全性。

5、维护:在软件维护阶段,ChatGPT 可以持续监测

新的安全威胁,并帮助开发者更新安全策略。

(二)安全编码准则

安全编码准则是一套编写安全代码的规范和最佳实

践。将 ChatGPT 与安全编码准则相结合可以帮助开发者

在编码过程中遵循安全性原则。例如:

1、ChatGPT 可以自动检查代码是否符合安全编码准

则,如输入验证、输出编码和错误处理等方面的规范。

2、 ChatGPT 可以作为一个实时的安全编码指导工

具,提供安全编码示例和解释,帮助开发者养成良好的

编码习惯。

(三)敏捷安全开发

敏捷开发是一种迭代和增量的软件开发方法,强调

团队协作、客户反馈和适应性。将 ChatGPT 与敏捷开发

相结合可以实现安全性与敏捷性的平衡。例如:

1、在敏捷开发过程中,ChatGPT 可以作为一个安全

顾问,为团队提供实时的安全建议和风险评估。

2、ChatGPT 可以帮助团队优先处理安全需求和漏洞

修复,确保在敏捷迭代过程中安全性得到充分关注。

3、在敏捷团队的代码审查和知识分享环节中,

ChatGPT 可以提供安全相关的反馈,帮助团队成员更好

地理解和遵循安全编码准则。

4、ChatGPT 可以作为敏捷团队的安全培训工具,通

过与开发者的自然语言交互,提高团队成员在安全领域

的认识和技能。

第12页

10

百家论道 LECTURE ROOM

ChatGPT 与安全开发生命周期(SDL)、安全编码准

则和敏捷开发相结合,可以在整个软件开发过程中实现

更全面、持续和自动化的安全保障。通过 ChatGPT 的自

然语言理解能力和编程知识库,开发团队可以在各个开

发阶段获得实时的安全建议,提高软件的安全性和质

量。然而,需要注意的是,ChatGPT 并不能替代专业的

安全工具和人工审查,开发者应结合多种安全策略和实

践来确保软件的安全性。

五、应对 ChatGPT 局限性

虽然 ChatGPT 具有显著的优势,但它也存在一定的

局限性。在本部分,我们将探讨如何克服这些局限性,

以更好地应对新兴的技术和安全威胁。ChatGPT 在安全领

域的应用具有局限性,需要充分认识并采取相应措施克

服这些限制。以下是一些主要的局限性及相应的解决方法:

1、训练数据限制:ChatGPT 的知识和能力受训练数

据的质量和数量限制。这意味着它可能无法识别一些新

兴的技术和安全威胁。

解决方法:定期更新和扩充 ChatGPT 的训练数据,

包括最新的安全漏洞、攻击手法和修复策略。这可以通

过与安全社区合作、收集安全报告和研究等途径实现。

2、缺乏专业领域深度:虽然 ChatGPT 具有较强的自

然语言理解能力和编程知识库,但在特定领域的安全漏

洞识别方面可能不如专业的安全工具准确。

解决方法:将 ChatGPT 与专业的安全工具(如静态

代码分析、动态代码分析和漏洞扫描工具)结合使用,

确保项目在不同方面得到全面的检查。

3、误报和漏报风险:由于训练数据和模型本身的局

限,ChatGPT 可能存在误报和漏报的风险,可能会误导

开发者。

解决方法:在使用 ChatGPT 的输出时,开发者应保持

谨慎,并结合人工审查和其他安全策略进行验证。此外,

通过持续改进模型和算法,可以降低误报和漏报的风险。

4、泛化能力限制:ChatGPT 可能在特定的场景和

上下文中表现不佳,因为它需要根据给定的输入进行推

理,而不是依赖于具体的背景知识。

解决方法:优化模型训练,使其更具泛化能力。通

过引入领域专家的知识、特定场景的训练数据和具有更

强上下文敏感性的算法,提高模型的泛化性能。

5、可解释性和透明度:ChatGPT作为一个黑盒模型,

其决策过程和推理逻辑可能难以理解和解释。

解决方法:研究可解释性和透明度方法,例如通过

注意力机制、局部可解释性模型(LIME)等技术,提供

关于模型输出的更多信息和解释。

克服这些限制需要开发者、研究人员和安全专家共

同努力。通过定期更新训练数据、结合专业安全工具、

人工审查、优化模型泛化能力和提高可解释性,我们可

以使ChatGPT在应对新兴技术和安全威胁方面更加有效。

同时,通过与安全社区的紧密合作,确保最新的安全知

识和实践得到分享和传播。

六、ChatGPT 实践案例分析

在这一部分,我们将通过案例,展示实际企业如何

成功地将 ChatGPT 应用于网络软件安全领域,以及他们

在实践中遇到的挑战和经验教训。

(一)案例背景

某创新型互联网公司(以下简称为“公司 A”)开发

了一款在线教育平台。公司 A 决定将 ChatGPT 应用于其

软件开发流程,以提高产品的安全性。

(二)应用过程

1、需求分析与设计:公司 A 在项目初期就引入了

ChatGPT,协助团队分析安全需求并在系统设计阶段提出

相应的安全措施。

2、代码实现:在编码过程中,公司 A 的开发人员使

第13页

11

LECTURE ROOM 百家论道

用 ChatGPT 自动识别潜在的安全漏洞,并根据其提供的

修复建议进行修改。

3、代码审查与测试:公司 A 在代码审查阶段将

ChatGPT 作为一个辅助工具,以发现可能被人眼遗漏的

安全问题。在测试阶段,ChatGPT 协助生成安全测试用

例,确保产品在各种攻击场景下的安全性。

(三)挑战和经验教训

1、误报与漏报:公司 A 在实践中发现,ChatGPT 有

时会产生误报或漏报。为了解决这个问题,公司 A 结合

专业的安全工具和人工审查来确保代码的安全性。

2、局限性:由于 ChatGPT 的训练数据和领域专业知

识的局限,公司 A 发现它在某些特定场景的安全分析中

表现不佳。因此,公司 A 加强了与安全社区的合作,持

续更新训练数据,并引入领域专家的知识。

3、审查过程的优化:公司 A 在使用 ChatGPT 的过程

中,改进了代码审查流程,使其更加结构化和高效。例

如,开发人员可以通过 ChatGPT 获取实时的安全建议,

而不是等待定期的代码审查。

4、持续改进:公司 A 认识到将 ChatGPT 引入软件开

发过程并非一劳永逸。为了保持其在安全领域的有效性,

公司 A 定期对 ChatGPT 进行更新和优化。

通过这个案例,我们可以看到,虽然 ChatGPT 在

实际应用中存在一定的挑战,但通过结合专业安全工

具、人工审查和持续改进等策略,企业可以充分利用

ChatGPT 在网络软件安全领域的潜力。以下是一些关键

的经验教训:

(1)多层次防护:将 ChatGPT 与其他安全工具和实

践相结合,形成多层次的防护体系,以确保软件在各个

开发阶段都得到全面的安全检查。

(2)人工与自动化相结合:虽然 ChatGPT 可以自动

识别潜在的安全漏洞并提供建议,但人工审查仍然是必

要的。结合人工审查和自动化工具可以在提高效率的同

时,确保软件的安全性。

(3)长期投入:将 ChatGPT 纳入软件开发过程需要

长期的投入和维护。定期更新模型、训练数据和算法是

确保其持续有效性的关键。

(4)安全文化推广:成功地将 ChatGPT 应用于网络

软件安全领域,需要在整个团队中推广安全文化。通过

培训、分享会和内部交流等方式,提高团队成员对安全

问题的认识和技能。

(5)定期评估和反馈:对 ChatGPT 在实际应用中的

表现进行定期评估和反馈,以便发现潜在问题并及时进

行改进。与安全社区保持紧密合作,共享最新的安全知

识和实践。

通过将 ChatGPT 应用于网络软件安全领域,我们

可以更有效地识别和解决潜在的安全问题,提高软件质

量,保障用户数据安全。在未来,随着人工智能技术的

不断进步,ChatGPT 在代码分析和软件安全方面的应用将

更加广泛,为网络软件安全领域带来更多的价值和创新。

在未来我们能做的事情还有很多,包括:

1、开发领域专用的 ChatGPT 模型:针对特定行业或

安全领域,开发定制化的 ChatGPT 模型,以提供更加精

确和深入的安全建议。

2、采用多模态学习:结合多种数据源(如代码、文

本和图像等)进行训练,以提高 ChatGPT 在安全分析和

推理方面的能力。

3、实时安全监控和响应:研究将 ChatGPT 与实时安

全监控和响应系统相结合的方法,以便在面临安全威胁

时快速作出反应并提供相应的解决方案。

4、模型安全性:确保 ChatGPT 模型本身的安全性,

防止潜在的对抗攻击和数据泄露等风险。

ChatGPT 将在确保软件安全方面发挥更加重要的作

用,为开发者应对不断变化的技术和安全威胁提供支

持。新时代的革命已经到来,我们应积极拥抱这一变革,

以实现更低成本、更高质量和更高安全性的发展目标。

第14页

12

百家论道 LECTURE ROOM

浅谈 ChatGPT 和网络安全行

业的爱恨情仇

脑动极光首席信息安全

官、OWASP 中 国 北 京 区 域 负 责

人、西班牙 UAB 大学硕士、北京

某高校网络空间安全学院研究生

导师、网络安全研究生实习基地

导师、中国卫生信息与健康医疗

大数据学会首届委员、网安加

社区特聘专家,参与编写 GB/T

39725 健康医疗行业数据安全指

南、3 个健康医疗行业标准,荣

获国家三级荣誉证书(技术贡献

类)。网络安全行业从业十余年,

曾于金融集团、上市企业及互联

网企业、Top 国企担任安全负责

人角色,负责基础安全、法务合

规、隐私合规、安全研发、风控

及业务安全、SRC(安全应急响

应中心)、数据安全、内审内控

等工作。

OpenAI 在 2022 年 11 月推出了影响全球各行业的、革命性的人工智能语言

模型 ChatGPT。ChatGPT 与其他 AI 的区别在于 ChatGPT 忽略搜索引擎,通过从

机器学习数据中提取相关信息来形成原始响应。

我的毕业论文是《Research on the development and application of

artificial intelligence》,幸好那时候还没有 GPT,这种变革的进步还未出

现,不然论文几乎要重新开题,当然正是这种变革,引起了亿级用户的好奇和

注意,也让无数的科技用户被其能力所震撼。但对安全从业者而言,不得不考

虑 ChatGPT 对恶意行为的促进,毕竟 ChatGPT 为黑客开辟了新的途径,所以,

对行业而言,随着人工智能日益增长的影响并采取相应行动至关重要。

在 ChatGPT 发展之初安全问题一直被选择性忽视,但在今年 3 月 23 日,

OpenAI 的 CEO(Sam Altman)公开承认开源库出现错误,导致聊天记录被泄露,

随后韩国媒体报道三星在引入聊天机器人 ChatGPT 不到 20 天,便曝出机密资料

外泄等三起涉及 ChatGPT 误用与滥用案例,相关资料内容已被 ChatGPT 学习(代

表会被用于回答使用者的问题):

1、A 职员,把有问题的源代码输入 ChatGPT,并询问了解决方法;

2、B 职员,把源代码输入到 ChatGPT,并寻求优化方法;

3、C 职员,将手机录制的会议内容转换为文件后输入到 ChatGPT,制作会

议记录。

3 月 31 日,意大利禁止了 ChatGPT,意大利数据保护局(IDPA)在调查违

反欧洲隐私法规的情况时命令从即日起禁止使用聊天机器人 ChatGPT,并不允许

OpenAI 处理意大利用户信息。IDPA 动作起因是 3 月 20 日 ChatGPT 平台出现了

用户对话数据和付款服务支付信息丢失情况,平台未应尽义务提醒、告知,并

缺乏大量收集和存储个人信息的法律依据,也说明了数据安全风险已经引起有

些国家的警惕,随后法国、爱尔兰和德国的监管机构也在调查 ChatGPT 是否违

反了 GDPR 法律,美国 NIST 也颇有远见的提前发布了《人工智能风险管理框架》

(英国、德国等也在路上,我国更是一力降十会)。

一、ChatGPT 的价值

ChatGPT 是一个基于 OpenAI GPT 模型的聊天机器人,它可以进行自然语言

对话,是大型语言模型,它可以进行自然语言预测,在许多方面都表现出色:

1、自然语言处理、文本生成、语言理解、对话系统、知识图谱、推荐系统等。

张 坤

第15页

13

LECTURE ROOM 百家论道

2、文本生成任务,如生成文章、段落、句子等,也

可以进行文本分类、情感分析、实体识别等。

3、机器翻译、语音识别、自然语言理解等问题,并

且可以与其他技术结合使用,例如深度学习、神经网络等。

ChatGPT 最大的价值在统计,如:

1、为 AI 提供了一种稳定、可靠、安全的方式进行

通信的方式,可以支持大规模语言模型的训练和部署,

为自然语言处理领域提供了强有力的支持。

2、ChatGPT 还可以用于智能客服、智能助手、智能

写作等方面的应用,帮助企业提高效率和用户体验。

3、提供自然语言交互的服务,帮助用户解决问题、

获取信息、进行对话等。

4、 ChatGPT 还可以为用户提供个性化的问候、娱

乐、社交等服务,从而提升用户的生活质量。

ChatGPT 最大的价值在于提供了一个可靠的、可扩

展的、高性能的分布式训练平台,使得人工智能助手的

训练和优化变得更加容易和高效。通过使用 ChatGPT,

可以方便地训练各种语言模型、问答模型、推荐模型

等,提高人工智能助手的性能和质量,为用户提供更好

的服务。

二、ChatGPT 的风险

如开头所言,ChatGPT 的差异源于响应的模式,许

多网络安全人员也更关注这种细微差别对网络安全的影

响,ChatGPT 来帮助识别网络威胁,但黑客也可以利用

其实现恶意目的。各种开源的版本已经有了多年的历史,

但毫无疑问 ChatGPT 是迄今为止最先进的存在。特别是

ChatGPT 带给用户的真实人的感受,而从黑客的角度来

看,ChatGPT 是一个游戏规则的改变者。

例如:网络钓鱼是最常见但不可怕的 IT 威胁,大多

数网络钓鱼骗局都很容易辨认,包括拼写错误、语法错

误、标准模板、乱七八糟的措辞、翻译导致的语意偏差

等,但 ChatGPT 提供的无偏差交互可以有效地加强网络

钓鱼活动的成功率,而且,ChatGPT 的编码能力、庞大

的数据集、无限的算力、成熟的模型,为其在任何场景

下的作用提供了无限的潜力。

技术不分黑白,但使用群体和使用目的有差异,

ChatGPT 也不例外,它可以帮助恶意攻击者自动化、加

速和优化现有的能力:

1、ChatGPT 的滥用:虽然 ChatGPT 通过内容过滤器

来避免滥用,但可以通过其 Web GUI 或编程 API 绕过内

容过滤器以获得恶意代码(例如获取源代码以创建多态

恶意软件,这更难被反恶意软件发现)。另外还可以用于

查找并利用最新的漏洞。

2、ChatGPT 自动化应用:ChatGPT 可以无视相关隐

私策略和伦理条款为代码或电子邮件编写脚本,黑客可

以要求 ChatGPT 编写网络钓鱼电子邮件,也可以用公众

人物的角度编写电子邮件,并包含指向恶意页面的特定

链接,甚至还可以通过自动文本生成来执行勒索软件攻

击以讨论谈判。

ChatGPT 不需要人工干预来生成其响应,可以为恶

意攻击行为降低攻击成本和人工干预,如果使用传统

方式进行网络钓鱼攻击或更有针对性的鱼叉式网络钓

鱼,需要更多的投入和人工干预,而且成功率更低,

但 ChatGPT 的自动化能力、语言能力、自动编码能力和

场景建设能力将更容易创建大规模、更复杂且非常可信

的网络钓鱼活动。另外据相关情报,已经有黑客团队把

ChatGPT 用于基于文本的电子邮件模拟的鱼叉式网络钓

鱼活动之外的活动,例如:大规模的“Deep Fake”活动。

ChatGPT被用于聊天机器人展示、生成音频和视频输出,

可以被用于欺诈、误导、冒充、诽谤、品牌攻击等。

3、大范围错误信息发布:尽管 ChatGPT 本身很智

能,但在某些情况下,它们可能会产生错误信息,导

致用户受到误导,而且如果机器人没有足够的知识库

建立,其回答将不准确。ChatGPT 通过恶意引导或修改

ChatGPT 使用的内容以影响它学习上下文的方式,可以

让大规模的错误信息发布成为可能,这可能会导致社交

媒体的大风暴。

4、ChaGPT 未来会嵌入到更多的技术、产品中,从

供应链风险来看,可能带来全局的灾难性影响,无论是

偶然错误还是恶意利用。对于依赖 ChatGPT的组织来说,

如果遭受攻击,则可能会导致整个系统被破坏。ChatGPT

也有可能成为黑客入侵的目标。如果黑客成功地进入,

则它们将获取访问所有相关数据的权限,并有可能利用

其进行其他形式的攻击。

5、 信 息 泄 漏: 敏 感、 涉 密 的 信 息 如 果 被 输 入

ChatGPT,之后就会成为聊天机器人数据模型的一部分,

并可以与其他人共享,从而导致数据泄露。对企业而言,

任何未经授权向 ChatGPT 披露机密信息都可能违反所在

企业的保密要求。

6、版权问题:简单来说就是通过 ChatGPT 生成的代

码、图片、音视频、文本等所有权的问题,例如 ChatGPT

在开源库上接受训练并在回答问题时“重放”该代码,

第16页

14

百家论道 LECTURE ROOM

然后开发人员将该代码放入公司发布的产品中,这可能

会使公司违反开源软件(OSS)许可证。虽然,服务条款

表明 ChatGPT 不能用于任何其他 AI 的开发。

7、隐私和安全问题:虽然 ChatGPT 提示用户不要输

入敏感信息或个人信息,例如姓名或电子邮件地址。但

是未知的风险仍然存在,例如是否遵守所在国家、地区

隐私法、是否采取了适当的控制措施来保护个人数据、

如何保障用户的数据权益以及其他会导致滥用和声誉损

害的风险。

三、ChatGPT 对网络安全的正向促进

如果黑客比从业者更懂得利用 ChatGPT,可见的网

络攻击比历史上任何时候都要多,ChatGPT 带来的便利

性可能会让黑客的攻击行为增加,也可以减少黑客的工

作量,让他们在更短的时间内造成更大的破坏。它的通

信能力还可以提高僵尸网络的连通性。

从趋势来看,ChatGPT 就像几十年前的计算机和互

联网,全球人民的好奇心让 ChatGPT 变得越来越流行,

一些公司也已经建立了相对应的产品能力,无可厚非它

提供了竞争优势,而在网络安全行业,我们面对使用

ChatGPT 的恶意使用者,可以做得更多,更好地去发掘

ChatGPT 的未来及其在网络安全中的作用,无论是积极

的还是消极的:

1、师夷长技以制夷:让 ChatGPT 成为防御武器库的

一部分。攻击者的邪恶用途成为我们的演练脚本,经过

训练成为我们的防护能力,可以使用 ChatGPT 发现并修

复软件中的漏洞。攻击者生成攻击脚本,我们可以利用

ChatGPT 生成自动化的安全测试脚本,协助进行安全测

试和漏洞扫描。这些自动化测试脚本可以更快速、更准

确地测试网络和系统,发现潜在的安全漏洞,从而提高

网络安全水平。

2、威胁情报:ChatGPT 可以快速准确地分析大量威

胁情报并提取有用的信息,可以帮助安全工作人员防止

潜在的网络攻击和识别新的威胁。ChatGPT 也可以更好

地协助分析和报告安全威胁,有助于我们更快地发现、

确认威胁情报,更快地修复这些威胁。另外基于历史数

据和机器学习算法,ChatGPT 可以预测潜在的网络威胁。

它可以帮助我们预测和计划未来的网络攻击。

3、安全研发:ChatGPT 技术在软件开发领域的深

入,通过更安全的内容(常见漏洞、编码错误、设计风

险等)进行训练。有助于软件开发人员复用安全代码能

力,构建漏洞更少、更安全稳健的软件。

4、安全测试:在网络安全渗透测试、漏洞扫描、漏

洞赏金计划、风险分析等方面,通过对 ChatGPT 部分或完

全自动化的使用,可以弥补人员、技术、工具的差异化。

5、情报收集:一直以来 Google、Baidu 等都是攻

击者和防护者的重要情报来源,通过对 AI 定向搜索的使

用,可以更精准地获取所需情报,例如域名信息、IP 信

息、端口信息、软件供应链构成等。

6、恶意代码分析:ChatGPT 可以识别和分类范围广

泛的恶意软件,包括勒索软件、木马和病毒。经过测试,

ChatGPT 已经具有了快速理解和定位混淆的恶意软件代

码的能力。经过深度训练和策略完善,有助于安全研究

人员对 APT 等深度恶意行为的分析和发现。

通过分析网络流量、日志和其他数据源,ChatGPT

可以执行主动威胁搜寻的角色,也就是我们常说的态势

感知。

7、网络安全培训:可以通过训练 ChatGPT 构建个性

化的网络安全培训体系,通过与使用者交互,可以提醒

使用者注意网络安全和隐私问题,教育他们如何避免恶

意软件、钓鱼网站、欺诈、垃圾信息识别等攻击方式。

8、数据隐私:ChatGPT 可以检查用户协议和隐私政

策,以发现潜在风险和合规性问题。它可以帮助我们确

保遵守法规要求,保护客户数据的安全性,降低人员成

本和合规风险。

9、应急响应:ChatGPT 可以通过提供实时信息和响

应来帮助安全团队进行事件响应。它可以帮助组织快速

遏制和减少安全事件。

ChatGPT 可以用于识别和分类网络安全威胁,帮助

网络安全人员更好地了解和应对不同类型的网络攻击。

可以更快速、准确地检测和识别潜在的入侵风险,制定

更加有效的安全策略。总的来说,ChatGPT 对网络安全

行业具有很多正面的影响,但也存在一些负面影响。因

此,在使用 ChatGPT 时,需要谨慎处理,并确保其安全

性和合法性。至少目前风险大于收益。但相信,无论风

险还是收益,随着 ChatGPT 等工具的发展,对网络安全

的影响也越来越大,对某些企业、团体或者机构而言,

尽信书不如无书,应该评估ChatGPT是否可以安全使用。

第17页

15

LECTURE ROOM 百家论道

开源安全治理解决方案分享

开源组件安全分析与合

规专家,系统架构师、分析

师;拥有十余年的安全开发

经验,对 SCA 相关产品和技

术实现原理均有深入研究,

现 任 开 源 网 安 SourceCheck

产品负责人。

汪 杰 一、开源背景

随着社会数字化进程的不断推进,开源技术被广泛应用于各个行业,推动

产业的快速发展。毫无疑问,开源技术的应用有诸多好处,企业可以免费获取

开源软件,以更低成本加快项目进度。而且开源软件大多数由开源社区支持,

能一定程度上保证软件质量。同时,企业可以借助它快速占领市场,实现商业

目的。

技术是一把双刃剑,不当使用开源技术也会带来大量风险。据统计,99%

的项目使用了开源软件,其中有 77.5% 的项目存在开源软件漏洞,每个项目平

均有 52.5 个漏洞。从许可合规的角度来看,65% 的代码库存在许可证冲突,85%

的代码库包含 4 年未更新的开源组件。

此外,近几年开源应用安全事件的频发也造成重大影响。2020 年 12 月,

SolarWinds 遭遇国家级 APT 团伙高度复杂的供应链攻击,超过 18000 家客户

全部受到影响,可任由攻击者完全操控;2021 年 11 月,代码质量管理平台

SonarQube 被爆存在未授权访问漏洞,国内外数万家企业的敏感数据泄露,重点

应用代码泄露;2021 年 11 月,广泛应用的开源组件 Log4j 被曝存在超危漏洞,

72 小时内受到 84 万次攻击,国内外知名企业均受到重大经济损失,相关网络攻

击至今仍在继续。

针对开源技术的风险,业内也越来越重视,相关的开源技术监管工作已全

面铺开。许多金融行业、通讯行业、科技制造业的企业已自发组成生态联盟,

建立起相关开源治理的信息通道。中国信通院也在积极联合安全厂商和标杆企

业,共同发布开源治理白皮书、开源治理工具评估等一系列指导标准,以促进

行业的可持续发展。

二、开源治理思考

(一)开源检测技术思考

如何知道应用中使用了哪些开源组件,可以从五个方面来考虑:

1、检测技术多样性:根据软件形态可以将检测技术分为源代码检测和二进

制检测两种技术。其中源代码检测又可以细分两类,一类是有包管理器管理的

软件,能迅速能检测到一些依赖关系;一类是无包管理器管理的检测技术,如

C/C++ 语言,这类技术可以根据源码目录结构、部分代码特征指纹等来提取使用

第18页

16

百家论道 LECTURE ROOM

的开源组件信息,利用代码片段指纹信息的提取与匹配

技术,能找出代码中拷贝的第三方开源成分的代码。

2、编程语言众多:据不完全统计,全世界有 600 多

种编程语言,常用的语言大概有 20 多种,要想精准检测

每种语言,必须要有特定的检测技术,针对每种语言的

包管理器的技术、语法、编译原理等来提取代码特征和

二进制特征。

3、文件格式多:不同语言的自身特点,加上编译环

境的差异,在不同应用场景下就会有很多格式。如安装

包格式、二进制文件格式、移动应用格式等。

4、检测场景多样性:不同的机构对开源的使用和检

测场景不一样,大致可以分为三类。第一类,一些第三

方检测、评测等机构一般都使用单个应用包上传检测的

方式;第二类,有较完善的研发流程体系的企业,一般

倾向于自动化,集成企业现有的平台或者工具,比如像

源代码管理工具、持续集成工具、缺陷管理工具等实现

研发过程的检测;而第三类企业,不关注研发流程而更

加关注安全防护方面,更偏向于应用运行时的检测等。

5、依赖传递复杂性:开源组件的依赖性是指在开发

过程中,一个开源组件需要依赖其他的开源组件才能够

正常工作。这些依赖关系可能是直接依赖或间接依赖,

并形成一个依赖链。检测依赖的技术,一种是通过包管

理器技术,可以实时检测分析,更加精准;针对无包

管理器管理的软件可以编译提前生成依赖关系数据并缓

存,这类也可以找出依赖关系,但同一份代码在不同编

译器、不同架构下生成的依赖关系可能不同,所有针对

无包管理器的检测,要想检测的准,不仅仅是需要软件

包本身,还需要提供当前软件包所处的环境。

(二)开源应用思考

对于开源应用的思考,分为开源组件管控和开源组

件管理两个方面。

1、开源组件管控,包括漏洞与许可风险管控、自研

组件管控、组件基线库管控、引入和退出和其他管控措

施。漏洞与许可风险的管控,就是漏洞的发现、确认、

修复计划、发版计划、预警计划等等,简而言之就是对

整个漏洞全生命周期的管控,许可也是如此,还包括

许可的兼容分析等。自研组件管控分为两种,一种是全

功能型的自研组件,针对某个业务全自研开发;另一种

是中间件级的组件,即定制化修改的开源组件。做好这

两类自研组件的管控,才能便于在后面的检测过程中进

行定位和筛选。组件基线库管控,包含自研组件和开源

组件,在企业内部必须要形成一个安全可信的基线版本

库,不管是后面的引入或退出都是有必要的。其他管控

措施,如黑白名单、策略规则,来配合开源组件的管控。

2、开源组件管理,通过制定计划、组织资源、分配

任务、协调沟通等方式来实现目标,以便更加有效的使用

开源组件。这里主要分为组织管理和流程管理。组织管理,

通过设置相关的部门和机构来统一协调管理,协调资源,

促进沟通。流程管理,上面管控提到的所有需要制度和流

程的地方需要通过相关制度和流程管理,如组件的引入和

退出制度流程,黑白名单定期维护流程等等。

(三)开源安全的思考

开源组件的安全工作,包含漏洞修复、使用安全意

识、更新与维护、实施访问控制和安全策略、审查和评

估开源组件、建立应急响应计划等六个方面。

1、开源组件漏洞修复:当发现一个漏洞时,要知道

它修复的必要性是什么,如果没有修复经验时应该怎么

办,这些问题都是需要考量的。

2、开源组件使用安全意识:安全意识并不仅仅是靠

制度流程或规范来创造的,它一定是在整个流程的使用

过程中,通过大量的培训和实践去产生安全意识。有了

安全意识,所有的研发人员都会积极参与到整个研发的

开源安全治理工作中。

3、及时更新和维护组件:随着时间的推移,组件

的风险和漏洞会越来越多,只有及时更新与维护这些组

件,才能实时应对新的风险和漏洞。

4、实施访问控制和安全策略:比如对开源组件的下

载、上传和修改都要做一些限制,防止整个开源组件在

实施和使用过程中被不断的篡改错误,引发新的问题。

第19页

17

LECTURE ROOM 百家论道

5、审查和评估开源组件:在做组件引用时,要查看

开源组件的源代码、所属社区、风险报告等信息,来判

断该组件是否适合企业引用。

6、建立应急响应计划:在发生安全事件或漏洞利用

时,如 0day 漏洞、投毒组件,企业或组织应该建立应急

响应计划,以及时响应并恢复正常运营。这包括对组件

进行漏洞修复和安全更新,并与组件开发者和社区保持

沟通。

三、开源治理解决方案

针对开源安全治理工作,总体能力方案主要从技

术、安全和管理制度三个方面来展开,如下图所示:

( 一)管理制度

管理制度,包括组织架构、流程制度和安全培训。

组织架构,可以建立这样一个架构矩阵,最上层是

统一领导工作的开源治理办公室,下面配备开源治理专

家组以及开源治理管理员,给整个开源治理工作提供建

议。再往下是安全部门和合规部门,对开源组件的漏洞

和许可风险进行识别和规划,主导开源治理安全工作,

最下层是产品研发部门,进行实际的风险修复工作。

(二)安全

安全是最核心的部分,覆盖整个软件研发生命周期,

可以分为三个阶段:源头安全、过程安全和运营安全。

1、源头安全

源头安全,也就是需求设计阶段,在新项目启动时

要做两件事。

一是建立开源软件引入及选型评估模型。

整个模型可以从 4 个维度去考虑:第一是组件可

靠性,有些个人开发者因为兴趣上传之后不再维护,因

此需要从社区的活跃度与软件活跃度来判断组件是否可

靠。第二是安全漏洞,就是从漏洞利用难度和风险评估

的角度来考虑。第三是法律合规,包括许可合规、专利

使用要求、商标及著作权。最后是技术应用,就是性能

满足度和业务满足度。

同时,开源软件的引入还需制定相关的引入和审批

流程。在引入开源软件时,要经过软件成分分析、代码

质量分析、代码安全分析和性能分析,只有开源软件满

足所有要求,才会将其纳入到整个项目中。

二是做好组件管理,打造安全可信组件库。

将可信的组件纳入引入审批流程中,可加速开源组

件选型,配合组件的准入流程和制度可以有效控制组件

的引入。通过扫描制品库,得到企业或者组织内所有的

制品信息,扫描的制品可以分为开源组件和自研组件,

自研组件通过自研率分析可以区分出完全自研组件和修

改的开源组件,这对后续的自研组件管理意义重大。当

扫描完所有制品后,可以分为可修复和不可修复的组

件,可修复的组件在资产定位中找到对应的项目进行逐

步修复,修复完成后和无风险的组件共同纳入可信组件

库中。对于不可修复的组件进行加白加黑或者其他操作

处理。同时需要对可信组件库进行实时监控扫描,一旦

发现可信组件库中的组件有风险,通过定位资产重新回

到之前的流程中进行修复操作。

2、过程安全

过程安全可以细分为五种情况。

(1) 全生命周期安全,自动化集成。在开发阶段,

通过插件集成开发工具,帮助开发人员在编码过程中实

时检测发现漏洞;集成代码仓库可以对企业或组织内所

有的代码进行批量扫描检测,可以从管理视角全局审计

代码使用的开源组件情况;通过集成 CI(持续集成)平

台,可以有效对违反安全策略(由平台设置的规则策略)

的构建操作进行阻塞操作,并将异常构建发送到 SOC 中

心进入提单流程。在发布前的安全测试环节,可以对物

料包进行安全扫描,确定没有问题就可以直接发布。

(2) 源码安全,建立安全源码仓库。源码安全有

四个阶段:第一是代码编写阶段,可以集成开发工具检

测,遵循组件管理规范;第二是代码提交阶段,集成代

管理制度 安全

技术(工具)

组织架构

流程制度

安全培训

需求设计 编写代码 代码仓库 构建平台 制品库 生产环境

组件引入

安全制度

组件修改

安全制度

代码提交

访问控制制度

源头安全 过程安全 运营安全

管理能力 检测能力 集成能力 知识库能力

审核流程 组件管理

资产管理 风险策略规则

源码扫描

二进制扫描

插件集成

API集成

私服

防火墙 风险预警 漏洞修复

应急响应制度

漏洞修复制度

组件更新制度

根据策略规则

放行或者阻塞

建立可信

制品库

明确治理目标

开源治理办公室

开源治理专家组 开源治理管理员

安全部门 合规部部门

产品研发部门(研发、测试)

制度保障

组织机制 管理制度 风险管理

选型 使用

运维 退出

技术管理

制度与流程

培训制度

责任确定

第20页

18

百家论道 LECTURE ROOM

码托管平台检测,集成策略规则,遵循代码访问控制;

第三是修改开源阶段,进行代码同源检测识别修改的开

源组件,以便在未来发生风险时可及时修复,同时要规

避许可合规和漏洞风险,遵循代码修改控制策略;第四

是源码仓库,要进行定时扫描和实时的风险预警。

(3) 制品安全,建立私服防火墙。前面在源头安全

提到建立安全可信组件库,建立后还需要对可信组件库进

行防护,要对外部和内部进入组件库的流量进行监听和审

计,发现违反策略规则的组件进入时,要进行阻断;同时

也要对制品库进行实时扫描,一旦发现风险要及时预警。

(4) 管控安全,建立安全卡口。基于全生命周期安

全实施管控安全,在整个研发过程的关键节点,如代码

仓库、持续集成平台、制品库等,增加安全卡口,进行

合规校验,如果不符合规则,则进行预警。

(5) 安全预警,建立沟通渠道。当应用检测到漏洞或

识别到未知风险时,可以通过邮件、短信等多种方式将检

测结果通知给相关责任人,并且可以直接对接到第三方协

作平台,如缺陷管理平台等,方便多人协作处理漏洞。

3、运营安全

运营安全阶段,有三项重要工作。

第一是建立应急响应制度,通过知识库能力中风险

预警,可以在 24 小时内同步新的威胁情报到 SOC 中心,

配合应急响应机制进行响应。

第二是建立漏洞修复制度,当确认漏洞有效以及有

对应的解决方案时,要根据管理能力中的资产管理,盘

点出当前影响的漏洞在哪些项目中存在,并根据项目的

属性定好修复优先级,统一进行逐步修复或者加固。

第三是建立组件更新制度,对新出现漏洞的组件的

不同情况进行区别处理,比如老旧组件,在社区没有维

护的情况下可以进行退出操作。对于要升级的组件,通

过知识库中的组件兼容性分析和评估后,进行有规划的

升级和更新。

(图一 开源组件安全及合规管理平台(SourceCheck))

第21页

19

LECTURE ROOM 百家论道

(三)开源组件安全及合规管理平台 SourceCheck

开源组件安全及合规管理平台(SourceCheck)是开

源网安自主研发的软件成分分析(SCA)产品,用于第三

方组件的安全分析与管控,包括企业组件使用管理、组

件使用合规审计、新漏洞感知预警、开源代码知识产权

审计等,可实现对源码与制品的精准分析,是帮助企业

实现开源风险治理的最佳工具。( 本文图一)

很多企业内部不清楚使用了哪些组件、不清楚问

题如何修复、无法掌握安全风险、应急分析响应慢、漏

洞预警不及时、缺少响应的管控手段,这些都可以通过

SourceCheck 来解决,它能精准把控开源组件风险,透

明化管理软件资产链条,最小化风险治理成本,最快实

现安全组件选型,零人工介入自动化集成。

SourceCheck 的优势主要体现在六个方面:

1、 海 量 数 据, 专 业 可 靠: 支 持 Java、Python、

Go、C++ 等 15 种以上主流语言,支持 20 多种包管理器,

拥有 1.2 亿组件版本库,兼容 CNNVD、CNVD、NVD 等权威

漏洞库。

2、多维检测,全面分析:支持源码包、二进制包、

远程仓库、容器、私服检测,支持组件级、文件级、代

码片段级检测,支持组件依赖分析、溯源分析,支持源

码自研率分析,支持组件漏洞、许可合规分析检测库。

3、自主研发安全可控:入选国家信创产品名录,拥

有数十项 SCA 领域发明专利,通过信通院开源可信工具

评估测试,响应国家政策,优先兼容国产操作系统、国

产数据库。

4、24 小时预警与风险修复:支持新漏洞预警,支

持组件推荐版本,支持漏洞修复建议。

5、无缝集成:支持与主流开发工具 IDEA、Eclipse

等插件集成,支持与GitLab、Jenkins、Jira等工具集成,

有丰富的 Restful API 接口。

6、丰富的场景:私服安全,实现私服扫描及私服防

火墙保护;安全左移,研发阶段早发现、早处理;持续

集成,实现流水线、自动化;安全管控,黑白名单、阻

断机制;安全审计,漏洞风险、合规风险。

四、开源治理总结

开源治理是一个体系建设的工作,涉及多个部门,

而不仅仅由安全部门独立承担。在治理环节中,组织者

对于企业内部的员工进行赋能培训非常重要,让员工意

识到开源治理的重要性比制度流程强制监管更加有效;

尤其在开源治理执行环节中,阶段性治理目标的明确非

常重要。最后,工具大部分解决的是问题发现和处理的

效率,并不能完全杜绝问题。

第22页

20

百家论道 LECTURE ROOM

浅谈开源治理

中兴通讯开源合规和安全

治理总监、ECPOC,在开源许可证

合规、EAR合规、开源安全管控和

风险应对等领域具有丰富的实践

经验。资深产品经理、研发过程

改进专家、资深合规专家,长期

从事企业级产品经营、研发过程、

规范及过程管控系统的研究与建

设,致力于企业级开源可信供应

链管控机制的建设与落地运营。

信通院可信开源供应链资深咨询

评估师、开源治理标准专家、信

通院 2022年度优秀标准专家、可

信开源治理讲师、金融开源治理

社区技术专家。开源社正式成员,

2022年中国开源先锋 33人之心

尖上的开源人物。

项曙明

一、开源软件生态演变及存在风险

所谓软件,就是一系列按照特定顺序组织的计算机数据和指令的集合,其

最终的存在价值在于实现计算机用户和计算机本身之间的沟通桥梁,做到帮助

用户实现对于计算机的良好控制。随着信息时代的不断发展,信息化水平的不

断深入,人们对于计算机和网络的依赖性也随之增加,这也同样推动着软件事

业的向前发展。而在这种发展潮流之下,开源软件起到了推波助澜的决定性作

用,也焕发出越来越强劲的生命力。

所谓开源软件(OSS,Open Source Software),通常的定义为一种其源

码可以被公众使用的软件,并且此软件的使用、修改和分发也不受许可证的限

制。开源软件最早出现于 20 世纪 70 年代,至今已经经历了数十年的发展历程,

其在操作系统、编译工具链、数据库、服务器以及移动端等方面都有杰出的作

品产生,已经成为了当前一股不容忽视的力量,并渗透到了当前社会生活和工

作的各个领域,特别是完全改变了软件的生产模式,由传统的闭源开发模式逐

步演变为混源的软件组装式开发模式,开源软件及其衍生组件在当代软件代码

中的占比达到了 90% 左右,从不同的侧面和角度影响着人们的日常生活。

开源软件最早的思想起源于黑客文化,1984 年,美国国家工程院院士

Richard Stallman建立起操作系统GNU(GNU’s Not Unix),标志着基于“自由软件”

思想的操作系统落成。GNU 的诞生,揭开了开源运动的序幕,并且通过 GPL 协议

来保障其能够永久地实现免费共享和自由的使用、修改与分发。1985 年 10 月,

Richard Stallman 成立了自由软件基金会 FSF(Free Software Foundation),

主要目的是为开发 GNU 募集资金。1989 年,Stallman 带头起草了 GNU 通用公共

协议证书,明确提出了“反版权”思想。1991 年,芬兰大学生 Linus Torvalds

基于 GNU GPL 框架了 GNU/Linux,标志着 Linux 的诞生。至此,开源软件的发展

得到了更多人的支持,并且逐步走向正轨。

随后开源软件的发展起起落落,从高潮到低谷,但是从 2005 年开始新一轮

的开源软件研发又开始继续发展,并且在这个阶段由于网络的发展呈现出又一个

峰值,移动数据传输也在这个时间登上了历史舞台,各种新技术方面的开源软件

不断涌现,许多开源项目也逐步由个人发起的黑客文化逐步向有组织先期开发,

研发到一定程度再贡献到开源社区,并期待该开源项目能够成功、形成自己特有

经常参加国内各种开源社区的分享、标准和其它活动时听到,也在各种开

源社区群、微信群中看到这样的一些声音和观点:“开源治理”治理的是什么?

我用开源软件还没有用好、我有项目要贡献到开源社区、我只是进行开源贡

献,为什么要说治理呢?近期接到网安加社区的这篇约稿,我就从我对开源软

件理解的角度来浅谈一下我对开源治理的一些看法,希望能给产业界和开源界

的同仁们带来一些思考与启发。

第23页

21

LECTURE ROOM 百家论道

的商业生态的商业模式进行演变,开源组织(公司)、开

源贡献个人都期待在开源的商业模式下获得成功。

开源软件的成功又刺激了各行各业的软件企业、创

业公司更广泛的使用开源软件,这可以有效地降低开发

成本、加快开发进度、促使产品快速上市,帮助企业获

得了一个又一个的成功。在广泛被使用的过程中某些开

源软件也逐渐演变成为各种各样的事实标准,并成为某

些商业项目招标的门槛,从而促进其被更广泛地使用。

随着数字化转型和云原生技术的蓬勃发展,开源软件也

彻底改变了软件行业生态和开发模式,并逐渐演变为一

种实实在在的商业模式,也彻底改变了整个软件生态和

竞争模式。

开源软件在为人们带来各种实实在在好处的同时,

其本身所固有的各种风险也暴露了出来,并严重影响企

业正常的经营活动,影响到广大个人消费者的正当权益

和使用软件产品的信心,危及到整个软件行业的良性发

展。简单来说,开源软件存在的风险主要有以下几种:

(一)许可证合规使用风险

我们知道,开源软件虽然实现了免费共享和自由使

用、修改与分发,但是其代码版权从来没有放弃,它永

远属于开源代码的贡献者。而且每一个开源软件在其分

发的过程中均会遵循一种或多种许可证,这些许可证的

法条在赋予使用者免费自由使用开源软件的同时也明确

规定了其必须遵循的义务;所以在不同的使用场景下,

如果违反了许可证义务将会导致许可证合规使用风险。

(二)产品安全风险

开源软件数量众多,但是大家有没有发现,开源软

件一般都规定了软件使用者“责任自负”,也就是许可证

均不会强制自由软件发布者给予使用者担保,不承担适

售性、满足特定使用目的、知识产权等任何担保。所以

开源软件功能、性能和产品安全质量也是不担保的,而

开源软件的代码质量、分发后出现的 CVE 漏洞,甚至开

源软件依赖的其它开源软件的漏洞、使用了开源软件的

第三方软件的安全这些均需要使用开源软件的项目自己

来承担。

(三)EAR 和可信供应链风险

开源软件作为公开可获得软件中的一种,在满足一

定条件下是受 EAR 管辖的,如何消除 EAR 的风险,使企业

能够 EAR 合规地使用相关开源软件。另外,这些开源软件

出现漏洞后能否及时获得消除漏洞后的可用版本、不能

及时获得消除漏洞版本的时候能否顺利的获取源码进行

自我修复漏洞、能否顺利获得最新的开源社区版本等供

应链方面的风险也同样存在。这些漏洞若不能及时消除,

可能会影响软件版本的正常运行,受到黑客攻击导致各

种数据泄露,特别是个人数据泄露而引起违规而受到处

罚。还有如出现的某些开源社区针对某些国家受限的问

题、美国的开源漏洞不及时公开的问题等均属于该范畴。

说到这里,我们就来说说开源治理问题,为什么有

开源治理、为什么要开源治理,我不治理又怎么了?

大家参与软件项目都带着一个目的,那就是希望项

目能成功!不论是开源项目还是商业项目其成功的定义

稍有差异,但是最终的结果是一样的,希望自己的项目

能被广泛使用、最终借助该项目组织和个人能够获得相

应的商业回报。那么问题来了,什么样的软件项目才能

够获得成功呢?撇开项目本身,我认为一个项目要成功

必须被广泛使用,大家愿意用,并借助你这个软件来增

加自己项目成功的概率,这时候你项目的用户关注的是:

1、该软件遵循什么许可证?是商业许可、OSI许可,

还是其它不太常用的许可证?其许可证风险怎样?我是

否可以有效地、低成本地合规使用?

2、该软件产品质量如何,研发过程中有没有有效地

合规和安全管控机制,产品分发后能否及时通报漏洞信

息,快速分发补丁版本,有效降低或消除我们使用的安

全风险?

3、该软件的可获得性如何?版本有没有连续性,是

否会出现后续版本无人守护或者难以获得的窘境?

4、开源社区项目非常多,我该如何找到这样的项

目?它的合规性、安全性有所保障或者能够非常容易的

进行治理。

5、我知道我想要寻找怎样的软件组件了,那么我们

自己项目分发的软件能获得广大客户的认同吗?我该怎

么做?

所以这时候就出现了软件治理的问题,它涉及开源

选型、合规使用、安全治理、合规分发和运维时的安全

应对,只有把这些风险有效的降低和消除,才能提升自

己项目被选择的机会,最终取得成功。所以我认为开源

治理是现代软件项目与生俱来的一门功课,无论怎样的

项目、无论你如何参与项目、不同的只是治理的目标、

内容和范围有所不同而已。当然,个人自己学习研究或

企业内部自用而不求广泛分发的项目也就不存在上述项

目成功的纠结,不在讨论范围之内。

第24页

22

百家论道 LECTURE ROOM

二、软件开发及分发模式演变

软件开发及分发模式的演变丰富了开源治理的内

涵,也逐步增加了开源治理的难度和广度,所以在谈论

开源治理之前有必要简单陈述一下,以便于后面更好理

解开源治理。

云原生时代软件供应链技术跃迁式演变,对软件研

发模式和分发内容产生了巨大变更,主要变现体现在:

(一)软件成分的变化,也即新制品

以前的软件开发是一个团队、一个项目组进行闭源

开发,代码基本全是项目组自己写的,所以其制品只有

一个版本号就能完整地标识出其版权归属,项目团队对

该项目制品全权负责。

全球开源应用契合自动化开发模式,开源因为其便

利性成为了当前软件开发中不可或缺的组成部分,混源

的组装式开发已成为主流。代码中除了有项目组自研的

代码以外,还会有本公司其它团队开发的代码——如平

台或组件,以及其它商业软件、技术协作软件、外包软

件、ODM/OEM 软件、SDK 驱动等第三方软件;当然还会有

项目组主动引入的开源软件,这时候的软件成分就开始

变得复杂了,也不是项目组能够全部掌握和守护的了,

这时候 SBOM 就显得尤为重要,它关乎着新制品的组成、

合规和安全,如下图所示:

再后来,我们发现上述混源开发中使用到的软件组

件,其在开发过程中基本上全部都使用到了开源软件,

也就是上述 SBOM 若从版本树的角度出发一直追踪到“叶

子”节点,我们就会发现,绝大多数“叶子”均是开源,

据可靠数据统计,目前软件项目平均使用到开源软件在

整个项目代码中的占比达 90% 左右,所以说开源软件逐

渐主导了当代软件。

(二)开发过程的演变,导致版本发布方式出现新变化,

也即新发布

软件研发过程也从需求、设计、开发、测试到分发

的瀑布模型,逐步演变至互联网时代的敏捷开发,强调

的是快速迭代的价值交付,再逐步演进到云原生时代的

DevOps,要求进行快速的研发到运维,在这样快速演变

的过程中,分发的对象也逐步从单一的可执行制品到运

维环境的统一发布,在此过程中,如何确保分发物的合

规和安全性。

(三)数字化应用架构演变,导致软件新技术层出不穷

数字化应用架构的演变,新技术的引入,应用架构

从单体应用逐步到 SOA,并逐步演进到微服务,软件分

发物就是一组微服务,如何确保这些微服务能够有效地

进行合规和安全治理给我们提出了新的课题。

(四)数字化基础设施的演进,为软件开发提供了新环境

云原生技术的发展,夯实了数字底座,简化了部

署环境,基础设施逐步从 IDC 物理机向虚拟化、容器化

方向演变,与此相对应的基础设施,项目组相应的分发

物、分发方式也随之改变,如容器分发除了原来传统的

软件版本以外,还需要一起分发的基础镜像和一组运行

依赖,这些基础镜像和运行依赖的合规安全性问题也就

成为新的开源治理对象之一了。

三、为何需要开源治理

前面说了,若软件项目没有商业分发、商业成功这

方面的诉求,完全是可以不需要做任何的开源治理的。

但偏偏绝大多数的软件项目都有商业成功方面的压力,

既然需要成功,就要求我们的软件项目遵从外部法律法

规、客户要求等约束,并能低成本、高效地完成项目的

合规和安全治理,而项目使用到的开源软件的治理也就

显得尤为重要。

(一)软件商业分发

既然一般软件使用到的开源软件占比达到整个项

第25页

23

LECTURE ROOM 百家论道

目代码量的 90% 左右,而企业进行商业分发的目的是要

满足客户的商业要求,并使客户在使用该商业软件过程

中不会出现由于合规和安全问题而导致客户商业利益受

损。为客户创造价值,从而也为自己获得更多成功的机

会。所以商业软件的开源治理,可以使客户放心使用你

的产品,以防出现:

1、由于没有有效开源治理,导致商业诉讼,而使客

户购买的商业软件停服或不能获得版本更新的风险。

2、由于没有有效开源治理,导致不能及时发现漏

洞、及时修复漏洞发布修复版本,而使客户面临被攻

击、系统瘫痪不能正常运行、漏洞导致个人信息数据泄

露面临巨额罚款的风险。

(二)开源生态建设和开源贡献

商业软件的分发是传统软件商业模式,由于使用到

了开源软件,其商业模式也需要做相应调整。除此以外,

现在还有很多企业和个人热衷于项目开源和贡献,构建

开源生态建设。前面说到,开源是一种商业模式,所以

开源生态建设和开源贡献最终也需要其开源项目获得成

功,其商业模式才能够得以变现。

那么如何使开源项目获得成功的概率增加呢?如果

不进行开源治理会有哪些影响?

1、若不进行开源治理,开源项目可能会导致许可证

冲突、许可证合规治理困难、导致在最终用户的开源选

型中落选,不能被广泛使用也就难以获得成功。

2、若不进行开源治理,开源项目可能都不知道使用

了哪些开源软件、这些开源软件是如何使用的,从而增

加最终用户开源合规治理的难度。

3、若不进行开源治理,开源项目就不能及时了解和

发现所使用到的开源软件的漏洞信息,不能及时更新安

全版本,也会影响到开源选型的成功率而影响项目成功。

(三)提升研发效能

企业一般会有很多商业分发的项目,也会有一些项

目开源,既然已经知道这些项目若想成功就必须进行开

源治理。那么如何进行开源治理,才能提升开源治理研

发效能?进而提升企业的投入产出,更好地实现商业目

标?从这一点来讲,主动构建适合企业有效的开源合规

和安全管控机制,提升组织开源治理能力,也是企业在

开源生态环境下的最佳选择之一。

四、开源治理的类别

前面讲了开源软件生态的演变及存在的风险,也了

解了在新制品、新发布、新技术和新环境下开源治理所

要关注内容的变化、以及在当前开源生态已无法绕开的

场景下,企业进行软件商业经营的过程中必须进行开源

治理才有可能取得成功。那么一般来说,开源治理会涉

及到哪些类别和内容呢?

通过分析,我们知道,企业与开源有关的活动主要

有以下三条主线:

(一)软件的可信开发与运维

它是支撑企业进行软件商业化合规和安全治理生产

的主流程。主要是构建企业的开源治理框架,主要内容

包括:

1、选择可信开源:SCA 工具、组件广场、开源选型、

官网同源、供应商认证、第三方选型。

2、可信使用开源:同源构建、版本同源、合规和

安全治理、安全左移。

3、可信产品分发:合规分发、安全分发。

4、可信产品运维:可信追溯、安全应对。

(二)可信开源开发

企业进行项目开源和贡献时,为了提升开源项目的

成功率而进行的可信开源社区、可信开源项目开发。其

开源治理主要包括:以可信开源项目、社区标准为要求

贡献可信开源项目和开源社区。提供可信开源项目和组

件,提升开源项目的成功率。

(三)可信内源开发

它是企业进行开源治理过程中的必要补充,指的是

为了支撑“可信开发与运维”和“可信开源开发”的开

源治理而进行的可信内源开源治理,它主要包括开源项

目孵化、企业使用开源项目守护、以及内源项目开发。

其开源治理主要包括:

1、开源文化建设,以内源方式构建内部组件开发

和交易机制。

2、内部孵化开源项目,为可信开源项目做好准备。

3、核心开源组件识别及可信商业化要求内源开源

守护。

企业只有结合自身特点和商业模式,选择合适的开

源治理类别和目标,一步一个脚印,从 SCA扫描开始做起,

逐步构建起支撑企业经营的全方位的开源治理管控架构

和能力,它和企业软件处于什么阶段、企业大小无关。

第26页

24

百家论道 LECTURE ROOM

DevSecOps 实践:如何在研

发过程中做好供应链安全

资深安全研发顾问、安全

敏捷教练、DevSecOps 专家、安

全工具专家、研发效能专家。有

10 年软件安全行业从业经验。

具有丰富的研发实践、安全工

具开发和实践、S-SDLC 实践、

DevSecOps 实践经验。辅导多家

企业从零开始构建 DevSecOps、

S-SDLC。

潘志祥 一、DevSecOps 与供应链安全

现在很多企业都建立了 DevOps 流程,但安全基本还处在流程之外,没有融

入传统 DevOps 流程,导致安全一直都是敏捷交付的瓶颈。

(一)DevSecOps———供应链安全治理基石

在很多企业寻求 DevSecOps解决方案的背景下,安全左移的理念愈发重要。

美国国防部白皮书中也提到 DevSecOps 落地的核心就是安全左移,但其中强调

的安全左移是在研发阶段做安全测试,这样的左移并不彻底。真正实施安全左

移比较彻底的是微软的 SDLC 理念,强调安全应该在更早期阶段介入。

经过近几年的不断实践,DevSecOps 已经做到了比较深度的安全左移,并

不只是在研发阶段做安全测试,而是在需求阶段就考虑安全,甚至是在立项阶

段就介入安全。

安全左移的价值不容忽视,我们知道在不同阶段发现并修复问题的成本是

呈几何增长的。如果在研发阶段发现并且修复问题的成本是“1”,在测试阶段

修复问题的成本就是“2”,在发布阶段修复问题的成本就变成了“10”,在运行

阶段发现并修复问题的成本就会是“100”,甚至于对业务运营的影响难以估量,

因为有些安全问题就是一个企业的生命线。

(二)供应链安全治理落地难点

1、供应链安全治理环节分散。在编码、编译、部署等环节都容易出问题。

2、研发修复成本高。安全问题修复滞后,频繁回归。

3、供应链安全治理依赖多工具能力。单一工具难以覆盖供应链安全所有的

治理对象,现在提到供应链治理工具基本都是 SCA,但是像操作系统、中间件这

些都是在供应链治理过程中需要考虑的治理对象。

4、安全是孤岛而不是流程。安全工具独立使用,安全漏洞只存在于安全工

具内,没有跟研发、测试、安全、运维流程打通,没有融入流程,进而导致安

全工作只能阶段性介入,影响交付节奏和周期。

5、缺乏全流程治理经验。基于安全木桶理论,补足安全短板,做到供应链

安全的全面治理也有赖于安全经验。

6、没有供应链资产管理。这一块主要是针对 SBOM 解决方案而言,SBOM 只

是一个静态的软件物料清单,如果发现 0day 安全问题,扫描所有代码仓库的

第27页

25

LECTURE ROOM 百家论道

效率显然太低,而且扫描之后能否快速呈现有问题的软

件,也是需要去考虑的,从资产管理以及事后盘查等角

度出发。

(三)交付管道

CI/CD 交付管道,也就是流水线,现在的安全工具

基本都是采用编排的形式接入到流水线中。因为安全工

具种类繁多,不可能每一个都登录进去制定扫描计划,

加上现在很多核心系统都实现了服务化改造,在每个工

具上针对每个服务应用去创建检测任务的工作量对安全

团队来讲几乎无法完成,所以现在的安全检测工具已经

上升到了编排的维度。

值得一提的是,尽管在流水线中可以同时发起多个

检测工具进行检测,但在实际情况中并不会这样来编排

流水线。如果是研发测试环境的流水线,通常会将安全

检测全部靠后,因为此时要做的事情是快速把应用构建

起来进行部署,然后让研发和测试去验证功能。验证完

功能之后,再去看安全检测工具检测到的漏洞,因为在

部署之后,安全检测工具同时开启检测,功能测试与安

全检测工作几乎可同时完成。

如果是针对上线的流水线,所有安全检测工具编排

会尽量靠前,而且此时安全检测工具必须要有安全卡点

的能力,也就是在每个工具中设置一个安全阈值,比如

针对 SCA 工具,定义它的超危组件不能超过一个,否则

不允许执行后续的流水线。通过这种方式,就能实现质

量一致性保障通道。所谓质量一致性保障,就是无论在

何种业务研发背景下,每次通过流水线交付出去的制品

都符合质量要求。这就能形成一种文化,即研发人员在

提交代码时就会思考能否过安全卡点,如此思考安全问

题的方式也就得以改变。

此外,现在针对安全工具的很多解决方案是在流水

线里写一个脚本,把代码提交到白盒检测工具中扫描,

然后去拿检测结果,但是现在很多微服务应用少则几十

个,多则成百上千个。面对上千个应用,每天提交一次

代码到流水线中检测,任何一款白盒工具能无法支撑。

所以将安全工具放到流水线中,常态化、自动化执行对

于安全工具的技术要求也发生了根本性的变化。它并不

是在流水线中简单写个脚本去调用检测工具的检测接

口,然后获取数据,而是要考虑每一种检测工具的检测

能力是分布式的。

所以我们在 DevSecOps 流水线中可以衍生很多跟现

在企业实施思路不一样的地方,我们可能要评估现在的

流水线能否承载核心系统未来的业务发展,整个安全执

行的效率是否达到要求。而且无论在什么状态下,软件

的质量都要符合风险可接受的范围。

二、DevSecOps 安全能力体系建设

DevSecOps 有两个发展方向,一个是 One by one,

一个是 All in one。

One by one 就是基于 Jira、Jenkins、GitLab 的解

决方案,组合在一起形成一个自动化流程。All in one

是一体化平台,它不是简单的将工具集成进来,而是在

平台上重新开发。

(一)DevSecOps 一体化平台

DevSecOps 是效率的代名词,之所以很多企业一直

在提倡它,是因为供应链治理工作的复杂性,除了供应

链治理以外,还要考虑云原生安全、应用安全、数据安

全、合规安全等,企业要想做好这些安全工作比较困

难。White Hat 组织在 2021 年针对全美公共事业部的互

联网应用发布了一份安全调研报告,报告显示制造业有

60% 以上的企业存在可利用漏洞,暴露窗口期在 365 天

以上,金融行业有 40% 以上的企业存在此类问题。由此

可见,国内的在线运营系统,其安全状况也不容乐观,

在这种情况下一体化平台将是发展的必然趋势。

根 据 GitLab 和 Jenkins 的 官 网 介 绍,GitLab 的

配置文件叫 gitlab-ci.yml,是解决持续集成的问题;

Jenkins 的配置文件是 Jenkinsfile,是持续部署的解决

方案。国外的 CI/CD 流水线比较严谨,CI 与 CD 的功能

更加明确,但是简单的将 GitLab 与 Jenkins 相加并不等

同于 CI/CD,所以真正在做 CI/CD 时必然是向一体化的

趋势发展。

在一体化的平台框架之下,可以进行大量的数据挖

掘。需求从邮件列表提出来,进入到需求中心,到产研

环境,再到预发环境,然后上线。需求这一数据对象流

第28页

26

百家论道 LECTURE ROOM

经很多工具,每一个工具停滞的时间都由不同角色的工

作来决定。DevOps 讲究高效的端到端价值流交付,但

是像需求平均交付周期、需求流负载、产研周期等指标

都统计不出来,就不能算真正的 DevOps,只是一个自

动化流程而已,这也是很多企业的现状。所以一体化的

DevOps,也将是未来研发效能的发展趋势。

(二)DevSecOps 安全能力体系

DevSecOps 安全能力体系,就是针对整个研运流程去

做安全能力抽象。比如在设计阶段做威胁建模,但现在

做威胁建模的企业并不多,因为它的落地非常依赖于负

责人丰富的经验,除了要懂安全,还要懂渗透、攻击、

研发、架构、业务等等,才能考虑怎样去解决这些风险。

在供应链这一块需要做很多检测,比较多的就是直

接引用的第三方组件,我们在供应链中经常会提到开源

软件,但是我更偏向于提开源组件或第三方组件,因为

开源软件的范围太泛了。比如 Redis 缓存,从第三方组

件的角度来考虑,就是在代码里引入了一个 Redis 的调

用组件,这个组件可能有问题,但是 Redis 部署的服务

可能也有问题,所以开源软件治理的范围从组件和软件

两个角度来讲,就有两个不同的维度需要去治理。

Redis 的环境基本上都要进行基线扫描,甚至要人

工去做安全配置检查,所以安全不能只想着引入工具和

如何使用它,而是这个工具能解决什么问题,接下来要

怎么把它放到流程里面,自动化建立起来。

接下来,如果要做供应链安全治理,只需要建立

一个视图即可,能查到所有应用资产下面的组件漏洞信

息,以及每一个部署环境的信息。所有的检测任务或者

漏洞的修复情况,只需在流程中完成即可。

三、DevSecOps 实践落地

实践一:IDE 安全自测

一旦建立流程之后,必须确保让研发有一个高效的

流程可以提前感知,因为研发会考虑提交的代码要过安

全卡点,否则会影响 KPI 考核。而且代码提交到线上之

后触发 CI 流程比较耗时,如果在 IDE 层面有检测插件,

研发就可以快速自测,就能知道自己引入了哪些有问题

的包,经修改检测无误就可以将代码上传。

实践二:创建安全私服

如果我们使用第三方私服,或者不对内部的私服做

任何安全管控,在做软件构建之后就需要依赖大量的检

测。如前所述,在测试阶段发现漏洞的修复成本是研发

阶段的两倍,因此为避免在研发阶段投入更多成本,可

以在所有的第三方组件进入私服时进行安全审计,只有

符合安全要求才能进入私服。其实这也是 SCA 工具的一

个功能,它开放了一个网络代理,当我们去公共的组件

仓库下载组件时,组件会经过代理的检查,检查通过再

将其放到仓库中;如果检查有问题,可以有不同的处理

策略,比如先放到一个缓存队列中去做评估或者直接拒

绝。在具体实施时,可以再配置外部私服,然后动态去

做入库检测以及构建的动作。

实践三:建立一致性质量内循环

CI/CD 是两个阶段的流程,但是现在企业能做到 CD

的并不多,因为 CD 有不同的理解,一个是持续交付,一

个是持续部署。持续部署是一个技术行为,跟 CI 差不

多,但是持续交付则需要非常多的能力来支撑。CI 环节

也不是一个过程,因为在不同的环节有不同的流水线去

做安全工作,整个安全工作已经实现了一个常态化自动

化,敏捷的特点就是小步快走,检测到增量漏洞后快速

修复,这个增量漏洞并不只是定义到修复超危漏洞,而

是低危漏洞也要一起修复。这是进入了一个比较好的状

态,质量内循环建立起来会非常高效,软件安全的质量

控制也会更加高效。

实践四:建立安全管控机制

安全管控机制,就是前面说到的安全工具卡点,现

在几乎是没有哪一个安全工具有卡点能力。一般做安全

卡点,都是自己通过写脚本,然后去判断当前的安全漏

洞数据情况。现在的工具可以去配置添加不同的卡点阈

值要求,然后去选择执行策略,比如说终止或继续,同

时还可以快速通知到相关的责任人。

计划阶段

威胁建模

安全分析与设计

安全需求评审

架构安全评审

数据安全评审

安全需求标准库

编码阶段

安全编码

代码实时安全检测

源代码安全评审

证书、秘钥安全

开源组件安全

License合规

代码库安全防护

运营阶段

网站威胁扫描

应用安全监控

数据服务安全管理

安全事件监控响应

云上云下资产漏洞扫描

运行时安全防护(RASP)

舆情风险威胁

安全应急响应

能力

引擎

镜像扫描引擎 源代码审计引擎 成分分析引擎 资产发现引擎 漏洞检测引擎 入侵检测引擎 基线扫描引擎 恶意文件库攻击行为模型

安全需求库 安全设计库 安全研发库 安全测试库 安全培训 研发安全培训 应急响应方案 基线库漏洞库

测试、持续集成阶段

镜像扫描

依赖分析(SCA)

代码规范扫描

APP安全扫描

安全质量门禁

代码安全扫描

(SAST)

漏洞扫描

渗透测试

接口安全测试

APP安全扫描

APP安全加固

制品库安全防护

灰盒安全测试(IAST)

动态安全扫描(DAST)

制品安全检测

镜像安全检测

配置安全管控

安全基线检测

重大漏洞检测

第29页

27

LECTURE ROOM 百家论道

DevSecOps 度量和正确的使

用方式

某世界 500 强金融企业

DevOps/DevSecOps 负责人。

英国伦敦帝国理工学院博士

毕业。毕业后在多家大型银

行从事 DevOps 工作。2019 年

加入腾讯 TEG。2020 年作为

首席技术布道师加入腾讯云

CODING。从 2018 年到 2020 年

间,作为演讲嘉宾出席过国

内外 30 几场技术峰会和论坛

分 享 DevOps 和 DevSecOps 经

验(Open Source Summit,DevOpsDays,National DevOps

Conference,Gdevops 等)。

在企业发展的过程中,有很多问题都是可以被感知到的,但是可能缺乏一

种方式去量化它。所以我们需要一把“尺子”使得团队里的人都能够感受到变化,

以及分析这种变化是不是我们希望的趋势和使用这把“尺子”去影响我们对未

来的判断。度量,就是在企业内部落地这把“尺子”的方式之一。

一、为什么需要度量

管理学之父德鲁克说:“如果你不能度量它,就无法改变它”。度量可以帮

助我们更深刻地理解研发效能,甚至影响我们的决策,指引改进方向,并量化

改进效果。而度量驱动是通过度量数据,认识和理解目标及其背后的原因,最

终作为决策的输入,影响到技术的使用,人的文化意识的改变,甚至管理层的

决策。

当基于度量做决策时,因为有数据的支撑,减少了误判的概率,并且让决

定变得更快更准确、有逻辑、易于阐述,因此不需要太多解释,也不易被反驳。

团队间的沟通也可以由度量数据驱动,使得大家避免过多的主观判断,因此也可

以减少团队之间的指责,从而改善团队的合作气氛和加强团队之间的沟通。

另外,在组织内实现度量驱动,这不仅仅是技术的改变,更重要的是文化

上的变化。每个人都需要转换观念,态度和对开发过程的理解。最终通过度量

去驱动人的思维模式的转变,进而逐渐改变整个企业的文化。另外,度量通过

数据反馈也可以降低转型过程中的不确定性,实时的度量指标可以帮助企业快

速调整提高转型的成功率。缩短交付周期找到可行的敏捷实践。形成通过度量

快速反馈和快速决策的机制,让改善可以持续发生,鼓励分享改进经验提升员

工荣誉感。最后,用流程固化有效的 DevSecOps 实践,并在流程里进行度量跟

踪和关联。从而提高研发能力与交付速度,质量和安全的关联性。

虽然度量可以为团队带来持续反馈和持续改进,并且驱动整个 DevSecOps

转型的落地,然而,大量实践证明,向开发团队引入度量,可能需要经历一个

理解、学习、踩坑,最终成功的漫长而艰难的过程,因为很多因素都会影响最

终结果,比如企业的文化、员工的意识和态度、管理层是否支持、度量的使用

方法、以及大家的工作习惯等。因此,为了更好更容易地让管理层支持和开发

团队接受度量,需要梳理并使用正确的度量指标,以及分析如何正确地使用度

量等。

周纪海

第30页

28

百家论道 LECTURE ROOM

二、DevSecOps 度量指标

前面我们提到,度量可以帮助团队发现问题和瓶

颈,并检验改进措施效果,但是不同团队所处阶段、

研发能力成熟度、面临问题的不同,导致了度量体系并

没有所谓的唯一性,因此团队需要根据自己的场景选择

合适的度量指标和方法。并且即使是在同一个公司或者

团队内,度量体系也应该是持续演进的,而不是固定不

变。虽然度量体系没有唯一性,但行业众多公司经过大

量的度量实践,也总结了一些具有普适性的研发效能度

量的考量维度 - 交付速度、交付质量和交付安全等,这

些指标的提升需要组织通过管理、技术、协作等多方面

的系统性地改进。下图列举了研发效能常见的度量指标。

关于交付效率或速度,从软件开发整个生命周期层

面的交付周期,开发周期,到需求侧的需求吞吐量,持

续集成过程中的相关的过程数据,如代码提交频率、构

建次数、构建频率、构建时长、构建成功率、构建修复

时间等,以及发布部署侧相关的指标、发布频率、发布

成功率、发布时长、发布前置时间等,都可以帮助团队

去判定研发团队是否能够做到小步提交、频繁提交,并

且当发现问题之后能否快速地响应等。

质量方面的度量又分为结果质量度量和过程质量度

量。线上或结果质量度量(比如线上故障个数、线上缺

陷密度、系统下线时长、故障平均恢复时间等)是常见

的容易被领导关注的度量指标,因为这种结果度量指标

可以很直观的体现团队对于业务交付的价值。传统的线

上度量也更多是监控提供的关于业务、应用和基础设施

的度量,这些往往是运维团队掌控的。除了结果质量度

量指标去验证和保证 DevSecOps 交付的最终质量以外,

过程质量度量更能帮助团队确保各个环节的交付质量,

以保障最终交付的质量。比如,低质量的、重复的、高

复杂度的代码会产生大量的技术负债,使得软件交付效

率无法得到有效提升,所以需要持续获取代码质量相关

的数据,持续改进代码质量。

单元测试作为开发阶段的自动化测试方案,其单元

测试用例数,单元用例通过率,单元用例覆盖率等参数

也常常作为这个阶段的标准指标,用来保证代码层面关

于函数和逻辑方面的质量。除了开发过程中的代码质量

外,另一类常常被关注的过程质量度量是与需求最相关

的缺陷。测试阶段发现的缺陷代表开发的代码并没有满

足需求里的变更要求(比如新的功能点等),尤其是与业

务关联的严重缺陷。因此,缺陷个数或密度、严重缺陷

比等度量指标通常作为开发质量保障(QA)的验收指标。

除了功能性要求,某些场景对系统或产品的性能也有着

特殊的要求,因此相关的性能度量指标(比如延迟时长、

流量负载等)也作为 QA 验收指标而变得同样重要。

前面我们讨论了交付速度和交付质量的度量,这些

更多是传统 DevOps 所关注的领域。而 DevSecOps 度量体

系不仅仅包含速度和质量,安全作为核心目标也同等重

要。目前的 DevSecOps 更多的安全左移发生在开发和测

试阶段,比如代码安全扫描、第三方安全扫描以及对于

测试环境的动态和交互式安全扫描。各种安全扫描的结

果主要总结为不同级别(高危、中危、低危等)的安全

风险和漏洞数量等指标和参数。

除了扫描出来的安全漏洞数量本身,发布阶段的时

长是 DevSecOps 团队一直关注的参数。它通常指测试通

过到成功线上部署之间的时长,包括各种审批流程的时

长,安全评审和扫描的时长,以及生产环境部署准备以

及部署本身(采用相关的部署策略,比如蓝绿部署、金

丝雀部署或者灰度部署等)的时长。其中安全评审和扫

已选择 设计 待开发 开发 待测试 测试 待发布 发布

成功发

布完成

交付周期

开发周期

发布前置时间

第31页

29

LECTURE ROOM 百家论道

描往往在整个部署阶段占了很大的比重。

传统开发模式中,如果上线前的安全评估和扫描阶

段发现了高危安全漏洞,是一定会被要求返工给开发团

队进行修复才能上线的。开发团队修复安全漏洞后,需

要再次通过整个研发流程(构建、测试、发布等)。这个

过程消耗的时间则称为返工时长,也就是返工消耗的成

本(包括人力成本和资源成本)。由于 DevSecOps 实现

了安全的左移,使得安全漏洞可以在更早阶段发现并修

复,因此减少了返工的可能性,并因此节省了相关的成

本。另外我们也需要关心相关安全事故和事件的工单数

的减少情况,代表着开发团队通过安全左移过程中的培

训,提高了自身的编码安全能力,从而最终产出更安全

的代码。

三、实践 DevSecOps 度量常见的问题和误区

虽然度量在企业推动 DevSecOps 过程中拥有巨大

的价值。然而,在实践中,度量有些时候或者在有些场

景下是比较敏感,并且可能是从上到下都在回避的一件

事。所以,在实际操作方面,需要考量加入度量指标的

时间点,并且需要考虑哪些度量指标更合理,以及使用

方式等。使用错误的度量(指标)或者错误地使用度量,

不仅起不到驱动 DevSecOps 落地让团队受益,反而可能

会起到反向效果,引发领导或者团队的不满意而不愿配

合 DevSecOps 推广。所以使用 DevSecOps 度量的第一步

是需要先了解 DevSecOps 度量在实践过程中常见的问题

和误区,从而避免团队抵制和资源的浪费。

首先,针对错误的度量指标,我们可以先从管理者

常常关注的传统的用于控制成本的人力度量指标入手,

例如资源使用率(如工时)、代码行数、缺陷数、需求数

量(故事点数量)等。最常见的就是以打卡或工时数据

进行度量——这是很多管理者最倾向于衡量的指标,因

为他们最关心的可能是手下的人到底是不是在干活和干

了多少活(是不是加班工作了额外的时间)。然而,工作

时间长就一定代表着产出高吗?另一方面,就算额外的

工作量全部是有效并且有产出的,如果只考虑个人工作

量和产出,在实际中,当局部人力资源过度优化,会造

成大量排队、等待以及频繁的工作任务切换,看上去很

高的资源利用率不但无法转化成生产力,反而会伤害端

到端的生产效率。

除了使用错误的度量指标,另一个问题是错误地使

用正确的度量指标,而这一点却是更不容易被发现和经

常被忽视的。其中一个常见的现象就是,同一个指标在

不同业务场景下的使用也应当不同。比如 DevOps 的实践

非常推崇开发过程中的单元测试,也建议将单元测试的

通过率和覆盖率作为质量门禁的度量指标之一。然而单

元测试覆盖率也不是越高越好。首先单元测试覆盖率越

高,需要的开发成本越高。另外,对于业务变化快的代

码,单元测试的维护成本也会越高。因此,对于单元测

试覆盖率的具体数字要求也应结合业务和成本来看,单

纯的追求数字没有任何意义。因此对于单元测试的覆盖

率,建议逐步进行提升,确保每次加入新代码后,单元

测试覆盖率不会下降即可。

四、实践中如何正确使用度量

前面我们列举了一些常见的使用错误的度量指标和

错误地使用度量所造成的问题。接下来,我们从度量的

各个方面(比如全局性、可视化、提醒和预警、度量的

分析、度量门禁等),分析一下如何正确地使用度量,从

而避免之前提到的误区和反向效果。

(一)度量不能用来横向对比团队

首先,度量指标的数据不能简单地进行跨团队的横

向比对,因为团队之间的业务场景不同,没有可比性。

可以进行一定程度地纵向对比,也就是和自己进行对

比,对比的是不同时间段的状况,从而梳理出团队改进

的情况。当然,纵向对比也有一定的缺陷,对于研发效

能已经很好的团队,其改进空间也就很小了,因此在同

样努力的前提下,纵向对比的改进比例很有可能比不上

基础比较差的团队的改进比例。所以,纵向对比的改进

数据需要结合现状数据一起来看,这样可以从一个综合

的比较公平的视角去跟踪和评判团队的研发效能状况。

第32页

30

百家论道 LECTURE ROOM

(二)度量需要考虑全局

另外度量需要考虑全局的指标使用情况,而不能让

某个单点度量指标给团队引导错了方向。不能聚焦某阶

段的工作输出指标,而需要聚焦整体结果产出指标。这

些指标也反映出了研发效能改进的关键点,即以端到端

的流动效率(而非资源效率)为核心。流动效率是指需

求在整个流程中跨越不同职能和团队流动的速度,速度

越快则需求交付的效率越高,交付时长越短。在实际工

作中,流动效率和资源效率需要进行协同优化,而不是

简单地只考虑其中一类。

(三)度量不能作为 KPI

度量指标不能与绩效挂钩 , 但是可作为 KPI 的参考

帮助管理者了解现状,发现问题和做出判断。因为度量

数据并不能直接并且 100% 准确地反映研发效能对产品

价值的影响,因此无法进行绝对公平的衡量,一旦作为

KPI,就会容易衍生出为了度量结果的“数字游戏”。这

时,使用度量非但起不到正面效果,还会对公司和团队

造成伤害。度量需要作为改进机会定位的风向标,确保

团队能够一起往正确的方向走,而不是简单粗暴地作为

惩罚团队的依据。

举个反面教材的例子:一个背负“需求按时完成率”

的团队,为了确保需求能按时完成,估算时留了尽量多

的 buffer, 另一方面,尽量少做一些需求,按时完成率

就容易实现。结果造成的问题是该研发团队只接了团队

容量 60% 的需求。所以,如果简单地以需求交付数量作

为 KPI,甚至将度量作为惩罚性依据,则团队有可能为

了数字和绩效,把已经比较合理大小的需求有目的性地

再次进行拆分成毫无道理的粒度。所谓上有政策,下有

对策,当团队放弃以改进为目标,而仅仅是为了以完成

任务免受惩罚为目的,就会以游戏,规避或者利己的心

态对待度量,从而使得很多度量指标被用非预期的方式

完成了。

(四)度量需要可视化

为了让度量足够引起重视进而影响人的意识从而

改变团队或者企业文化,度量的可视化是非常必要的手

段。关键的度量数据可以展示在公共区域,或者人流密

集大(比如公司入口的门厅、团队旁边等地点)或者比

较显眼的区域的大型显示屏或者投影上。展示的度量数

据需要和相关的团队甚至个人相关联一同展示。另外,

作为管理者,要经常关注大屏幕上和自己团队相关的信

息,对异常的度量数据提出质疑,并让相关团队或者人

员及时进行解决。另外,设置一定的激励机制配合度量

结果也能起到一定的积极作用。很多实践证明,度量的

可视化是改变个人意识,以及团队或公司文化的有效手

段之一。通过这种潜移默化的影响,逐渐让团队开始通

过度量指标关注研发效能,尤其是过程效能。

(五)度量需要提醒和预警机制配合使用

除了可视化,相关的提醒和预警机制也可以配合

度量一起使用,保证度量发现的问题可以及时和按时解

决。提醒和预警的方法和手段可以通过邮件、电话、短

信、微信等方式。提醒机制也可以归类为度量可视化的

一种,比如通过每天微信群的模板,列出团队每个人的

任务进度的状态,以及研发过程中各种指标的情况(代

码质量、单元测试覆盖率等),通过每天在微信群进行通

知并公开个人对应的度量指标,促使团队积极完成任务

和及时改进。

(六)分析度量数据

再有,前面提到过,度量驱动的目的包括帮助团队

发现过程中的瓶颈和评估改进的结果。因此需要对度量

数据进行分析,发现最有价值的信息,如趋势、上下文

信息等,进而帮助团队发现深层次的问题并为解决方案

提供实验数据,并且由此进行改进。比如,如果测试阶

段发现的缺陷数量过多,耗费了大量的测试资源,就要

分析缺陷的分类和数量,判断是否左移简单的测试工作

给开发(单元测试和冒烟测试)可以提高测试效率,从

而节省测试成本。那么,如何进行度量分析呢?

首先是通过抓需求梳理整个研发过程,因为需求是

贯穿研发交付过程始终的,没有之一。另外需要验证数

第33页

31

LECTURE ROOM 百家论道

据的真实有效性,才能让团队认可这个客观数据。接下

来,对大的阶段进行拆分,保证数字的合理性,比如拆

解测试周期。通过把表面问题细分到各个步骤的实际情

况下,才能搞清楚到底是哪个步骤导致的问题。最后根

据不同的视角和维度划分指标,比如划分组织级指标、

团队级指标和项目级指标。划分指标的核心由大到小,

从指标受众和试图解决的问题出发,进行层层拆解,从

而直达问题的根本原因。

(七)基于度量的质量门禁

除了通过自动化方式持续获得软件交付各个阶段所

产生的数据外,某些关键度量指标可以作为质量门禁,

集成在流水线上作为质量和安全的把控,保证产品质量

和安全,并且避免技术负债。比如高危安全漏洞、严重

缺陷、严重代码质量问题、单元测试通过率和覆盖率、

接口测试通过率等。如果结果不满足质量门禁指标的要

求,比如高危安全漏洞数大于零,则强制流水线构建失

败,分支不能进行合并或者测试结果不达标等方式阻止

流程继续执行。

(八)监控度量数据

关于应用运维端的度量,尤其是监控度量数据可以

在三个层面进行分类和可视化:业务指标、应用指标和

基础设施指标。数据分层的方法让度量更加结构化,方

便业务和开发人员理解和分析。业务指标可以检查当前

的状态是否符合要求的 SLA,使用趋势或收入。应用指

标可以检查应用组件的性能,不同服务执行的延迟及数

据增长等。而基础设施指标可以检查最底层的 CPU、内

存、硬盘和 I/O使用率的情况。要找出问题的根本原因,

需要把不同的指标关联起来。比如可以把关键指标的度

量数据图叠加起来,从上而下依次是业务、应用和基础

设施指标。分析时比如从上往下看时,可以看到 QPS 的

变化是如何影响应用性能和服务器 CPU的。从下往上时,

可以看出 I/O 的变化是如何影响 SLA。

最后,度量只是工具和手段,不是目的。度量的真

正目标是提高效能,因此不要舍本逐末。举个例子,如

果花费在度量精准度上的时间超过了收益,那就不要浪

费太多人力物力去做得那么精准了,可以换个方法从多

维角度综合参考不同地度量指标数据。另外,虽然我们

推崇量化和数字驱动,但在效能的度量上,不能过于迷

信数字,更不能一刀切式地使用度量,很多时候还是要

结合场景具体情况具体分析。

第34页

32

百家论道 LECTURE ROOM

OWASP 中国 S-SDLC CMM

项目介绍

S-SDLC CMM 项目主理人、

SDL 咨询师、S-SDLC CMM 模型主

导者。具有超过十五年的软件安

全从业经验,熟悉安全需求分析、

安全架构设计、安全编码等开发

生命周期中的安全活动,对企业

级的安全开发体系构建、落地与

实施具有丰富的实践经验。主导

参与了超过 20 家企业的 SDL 咨

询项目。在开源项目方面,曾主

导《源码工具审核基准》的研制

工作,并参与了《OWASP 安全测

试指南(第 4 版)》、《OWASP

代码审核》等书籍的译制与出版

工作。

徐瑞祝

一、创建 OWASP S-SDLC CMM 项目的背景

从团队成员收集的企业诉求来看,主要体现在几个方面:一是评估不足,

组织绝大多数情况无法客观评价自身的安全能力水平,对自身的安全开发能力

不够清楚;二是无法落地,组织的安全实践缺少经验,且多数情况下缺乏明确

的安全细则和要求,无法提供很好的落地指导;三是缺乏规划,组织内部对安

全不够重视,甚至不做安全规划,导致安全开发管理体系缺乏系统性规划。

这是我们做软件能力成熟度评估模型的背景,对于该模型的应用,乙方公

司可以用来做差距分析,企业也可以用来做自评估与构建安全开发体系的参考。

二、S-SDLC CMM 模型介绍

S-SDLC CMM 模型是一种“指导式”的软件安全开发能力成熟度评估模型。

当前业界也有一些“观察式”的模型,比如说统计一些规模较大的甲方

企业的最佳实践,将其罗列出来并分类,告诉企业哪些阶段有哪些活动值得去

做。但这种形式会有几个问题,因为并不是每个企业都适合这些活动,而且不

知道这些活动要做到什么程度,这样在实践时会给企业带来困惑,因此我们希

望提供一种“指导式”模型,可以按照最佳实践的角度去开展安全开发体系的

建设。

(一)模型概述及结构

S-SDLC CMM 模型完整定义了标准的软件安全开发流程和安全实践,从组织

的安全基础设施、安全技术能力和活动标准、软件开发全生命周期安全活动执

行、软件上线后运维安全,共计 4 个维度评价组织的安全能力水平。

1、监管:包括制定软件安全战略,以及配套安全流程、合规政策和安全培

训方面的实践;

2、能力:包括攻击模型研究、安全知识库建设以及安全活动标准建设方面

的实践;

今天给大家介绍最近我们在 OWASP 中国发布的 S-SDLC CMM 软件能力成熟

度评估模型的项目,当时主导该项目的初衷,是因为我们团队在工作中看到了

很多国内企业在软件安全能力成熟度评估以及安全开发体系建设上的诉求与痛

点,我们希望该项目可以帮助企业解决他们的问题。接下来,我会从 S-SDLC

CMM 项目的背景、S-SDLC CMM 模型介绍与 S-SDLC CMM 开源项目介绍这三个方面

来展开分享。

第35页

33

LECTURE ROOM 百家论道

3、触点:涵盖需求、设计、实现和测试等阶段的安

全活动实践;

4、运维:包括渗透测试、软件环境安全、运营支持

以及应急响应相关的实践。

模型通过划分安全域→安全子域→安全实践的三层

结构,将安全能力细化至可客观量化的执行动作,由此

得出安全实践客观的执行水平,完成对组织安全能力成

熟度的评估。

(二)成熟度级别

S-SDLC CMM 定义了 5 个成熟度级别以表示 S-SDLC

评估子域和组织能力成熟度:

1、随机、被动的安全开发过程:

第 1 级,S-SDLC 子域内少部分的安全实践通常会被

执行。但实践的执行可能未经严格的计划和跟踪,而是

基于个人的知识和努力。同时,该安全能力并未完全内

化到组织内。

2、主动、非正式的安全开发过程:

第 2 级,S-SDLC 子域内安全实践执行是经计划并被

跟踪的。同时,组织通过对安全实践进行测量来跟踪执

行情况并保持对安全活动的管理。

3、正式、规范的安全开发过程:

第 3 级,S-SDLC 子域内的安全实践按照充分定义

的过程执行。充分定义是指软件安全开发流程实践有标

准化、文档化的管理流程或经过裁剪并得到批准的一部

分。这一过程与第 2 级(计划跟踪级)的主要区别在于

安全实践的管理过程是组织级标准化、文档化的。

4、可量化控制的安全开发过程:

第 4 级,S-SDLC 子域内的安全实践经过组织级地

收集、分析和执行详细的测量活动,使组织获得对软件

安全开发流程的量化理解和预测后续执行情况的能力。

这个级别执行的管理是客观的,安全管理的质量是量化

的。这一级与第 3 级(充分定义级)的主要区别在于对

安全实践管理的定量理解和控制。

5、安全过程可持续优化,建立业界标杆:

第 5 级,S-SDLC 子域内的安全实践会基于组织长久

的业务目标建立一个针对过程有效性和执行效率的量化

目标,并围绕这一目标进行持续改进。这一级与第 4 级

(量化管理级)的主要区别在于组织存在持续的优化过

程。同时,由于安全管理过程是持续优化的,组织会实

时向行业输出安全实践和安全能力,形成组织对行业的

辐射和对外的影响力。

(三)量化维度

关于子域能力成熟度,S-SDLC CMM 定义了 3 个成熟

度级别以表示 S-SDLC 评估子域和组织能力成熟度:

1、频率:包含实践本身的发生频率、升级频率、更

新频率等。如:“对高管进行安全意识培训”实践下对高

管参加培训的频率有客观的量化要求;

2、覆盖度:指活动发生时覆盖的情况。如:“对技

术人员提供安全技能培训”实践下对“安全技能课程覆

盖的项目组成员比例”提出了要求,包括开发、测试、

产品、项目经理等参与技能培训的人员占比项目组全部

人员的比例;

3、执行质量:指企业实践执行的质量如何,一般从

活动的角色、职责、流程、输入输出等方面评判。如:

“识别可能存在的潜在攻击者”评价质量时,会针对攻

击者的识别是否从不同的角度和侧面进行识别,包括企

业外侧和内测、系统的业务侧和数据侧等,评价是否识

别得完善和系统。

(四)安全域

安全域有四个大域:监管域、能力域、触点域、运

维域。

1、监管域

包括制定软件安全战略,以及配套安全流程、合规

政策和安全培训制度以及供应链管理制度。

(1)流程与政策:主要评估组织对安全战略目标制

定、运营和量化管理的能力。包含建立统一的软件安全

战略、制定组织安全开发管理流程、建设和运营组织安

全文化、建立组织级别 SDL 量化管理体系共计 4 个方面

的实践。

(2)合规性:主要评估软件开发组织对于监管规则

的重视度,含合规性法律文件转化为安全需求这样的安

全实践。

(3)培训:安全知识的培训对于组织中的每一个人

都是至关重要的,这是做好相关实践活动的前提。“培训”

第36页

34

百家论道 LECTURE ROOM

的子域主要评估了组织对各岗位是否提供了符合岗位要求

的软件安全培训内容,以及评估了培训内容的有效性。

(4)供应链安全管理:主要是帮助企业建立正式的

制度来管理软件供应链的安全风险,该子域下面主要包

括成立软件供应链安全风险管理委员会和建立正式的软

件供应链安全管理制度两个子实践。

2、能力域

该域描述了组织在软件安全开发全生命周期中的各

种安全活动的基础设置支持能力,包括攻击模型研究、

安全知识库、安全组件、安全工具链。

(1)攻击模型:从攻击者的视角分析和研究可能存

在的攻击者、攻击模式和相关技术,以便软件开发组织

能够防患于未然。该子域下包括识别可能存在的攻击者、

建立攻击模型和技术知识库、构建攻击团队 3个子实践。

(2)安全设计方案与安全开发组件:评估软件开发

组织构建支持安全开发、安全设计和威胁分析方面的技

术知识库及开发组件的能力。

(3)第三方组件库管理:软件系统的开发会用到大

量的开源组件,不少软件开发组织在第三方组件库的管

理方面,都存在流程不完善,安全管控不足的情况,严

重影响了软件系统的安全性。因此,有必要建立内部第

三方组件库,并对组件的选择、下载、安装和更新进行

规范管理。

(4)标准与要求:为把控 S-SDLC 流程的整体质量,

需要对其中的安全活动建立相关的标准和要求,即安全

基线、安全编码规范以及代码审计等。

(5)敏感数据处理:黑客的攻击,甚至内部工作人

员的信息贩卖、离职员工的信息泄露、第三方外包人员

的交易行为、数据共享第三方的数据泄露、开发测试人

员的违规等都可能导致敏感数据泄露,因此有必要对敏

感数据予以识别,并在传输和存储过程中进行加密处理。

3、触点域

涵盖了需求、设计、实现和测试等阶段安全活动相

关的实践,其可以评价企业软件系统开发中安全活动的

落实情况。

(1)安全需求分析:需求分析阶段完成系统功能的

安全需求分析,识别可能面临的安全风险,并将安全需

求加入需求说明书里。软件安全需求分析是软件需求分

析的一个必要组成部分。安全需求与业务需求同样重要,

并能对功能需求具有约束力。

(2)安全设计:安全设计活动,包括在架构设计时

考虑系统的安全性,对系统进行威胁分析,评估系统面

临的风险,对设计方案进行安全检查和评审。

(3)安全实现:安全开发阶段包括对代码和第三方组

件进行人工和自动化的审核,落实安全编码规范的实施。

(4)安全测试:主要是为了验证安全需求分析阶段

识别的安全需求是否得到正确实现,通过设计安全测试

用例、执行安全测试用例以及对发现的安全漏洞进行跟

踪管理的方式,以确保软件系统的安全性。安全测试的

执行可以使用人工与工具结合的方式进行。

4、运维域

包括渗透测试、软件环境安全、运营支持以及应急

响应相关的实践,可以评价企业在软件系统运维中安全

活动的落实情况。

(1)渗透测试:是对软件系统进行渗透测试。可信

赖的第三方通过模拟真实黑客攻击的技术及手段对目标

网站、服务器系统进行攻击,在发现目标存在安全隐患

后给出专业的安全加固建议。

(2)软件环境:主要是遵循“默认安全”的设计理

念来保证软件环境安全。

(3)运营支持:有效的运营支持可以规范软件开发

组织的安全运营行为,降低系统受攻击的概率,提升安

全事件的应对效率,保障软件程序的安全运行。

(4)应急响应:为了有效地对安全事件的发生做出

及时的处置,软件开发组织应组建相关的应急响应团队

以及制定信息安全事件的应急预案,这样软件开发组织

在安全事故发生时也能做到有人可用,有章可循。

三、S-SDLC CMM 开源项目介绍

关于 S-SDLC CMM 开源项目,我们制作了一个网站

http://s-sdlccmm.com/,网站上有三大模块,分别是

S-SDLC CMM模型介绍、安全技术资讯和安全能力自我评测。

模型介绍详细描述了安全域 - 安全子域 - 安全实践

的层级结构关系,并且该模块功能支持下载 S-SDLC CMM

文档至您的本地进行参考阅读。安全技术资讯信息主要

以行业、技术和业界新的安全实践为主,通过有深度的

技术好文分享,引导读者思考安全技术的新走向。安全

能力的自我评测功能主要为用户提供一个简易的自我评

测工具,用于自身安全能力的评估,通过问卷形式模拟

差距分析过程得出安全能力水平和安全能力雷达图。

由于前期的团队成员相对有限,所以我们希望诸位

有志之士可以积极参与到该项目中,对该模型提出宝贵

的意见,共同完善并推动该项目的进展。

第37页

35

LECTURE ROOM 百家论道

软件安全研发建设之路

每个公司的实际情况不同,所拥有的资源以及面临的业务场景也不一样,

所以解决方案也会有一定的差异。本文分享一些软件安全研发的经验,希望可

以给各位读者带来一些帮助和启发。

一、软件安全研发流程实践

软件安全研发流程的设计,首先需要定义几个关键角色,分别是:安全团

队、产品安全负责人和常规测试团队的安全测试人员。

安全团队,以我们团队为例,除了合规相关的工作较少(主要总部在负

责),其他与软件安全相关的工作都要做,包括渗透测试、安全设计流程、安全

技术培训、安全技术积累、安全运营、安全事件调查等等。

产品安全负责人,主要的责任是把控产品迭代过程中和安全相关的工作,

保证执行到位。然后要确保安全部门的培训、任务、信息能有效传达到产品团队。

常规测试团队的安全测试人员,由于公司产品较多,安全部门资源又有

限,所以由常规测试人员来学习渗透测试和漏洞扫描,可以缓解很大一部分工作

压力。经过实践,测试团队可以胜任简单的渗透测试的工作。我们的做法是,首

先由安全团队来培训测试团队基础的测试步骤,比如如何测试权限、如何测试前

后台的参数验证等,然后写成测试案例,交给测试团队执行基本的渗透测试。这

样可以大大节省安全团队的资源,也可以对提高应用安全起到很大的作用。

(一)产品迭代中的安全工作

在产品迭代过程中,要做的任务包括安全设计流程、静态代码分析、软件

组成分析、容器镜像扫描、主机漏洞扫描及安全加固、动态应用安全测试、常

规测试人员测试基本安全测试用例、上线等。

众所周知,从研发、测试、发布到运营的不同阶段,漏洞修复成本是成倍

增长的,所以现在软件安全行业特别推崇“安全左移”,以期能够尽早发现问

题,并降低修复成本。然而很多企业的“安全左移”就是“IDE+ 静态代码分析

插件”,但其实两者并不等同,虽然“IDE+ 静态代码分析插件”确实能发现一些

问题,但也仅局限于静态代码分析能发现的问题,而像业务逻辑问题或权限问

题是无法被发现的,所以要做到“安全左移”,需要从设计阶段就考虑安全。

(二)安全设计流程

当然理论上修改任何代码都可能带来安全问题,然而评估任何代码改动是

否会引起安全问题显然是不切实际的,所以我们制定了这个安全设计流程。

OWASP 中国吉林区域负

责人,某外企安全部门负责

人,资深研发工程师。拥有

11 年软件安全和软件研发经

验,软件公司安全研发流程

和安全团队从 0 到 1 的建设

经验。

郭振新

第38页

36

百家论道 LECTURE ROOM

如上图所示,是我们设计的一套安全设计流程。迭

代刚开始,产品安全负责人需要检查本次迭代和安全相

关的一些功能,然后把这些功能挑出来,通过邮件发给

安全部门,审核该功能是否和安全相关,是否需要安全

设计文档。关于安全设计文档,有一点需要说明,并不

是所有的功能都需要安全设计文档,比如需要在页面上

加一个富文本编辑器,很显然这个功能不需要写文档去

说明开发的用处,只需要告知这个功能,由安全部门确

认之后,再邮件告知产品安全负责人哪些功能与安全相

关并且是否需要安全文档来解释该功能的作用。

安全负责人收到邮件之后,针对每个功能会创建安

全审核 Jira,然后在开发之前确认是否需要安全设计文

档,如果需要则进行文档审核以及信息提供,然后进行

开发,如果不需要则直接开发即可。开发完成之后,开

始渗透测试。在渗透测试这块也有一个分流,比如说开

发修改了权限模型,渗透测试的工作量会非常大,因为

每个 API 或每个页面可能都需要测试,这时就需要常规

测试人员的帮助。

做这套流程主要有两个目的:第一,优先挑选重要

的和安全相关的功能和逻辑,这样就可以做安全设计流

程,让开发人员提供文档,尤其在开发人员写代码之前

注意可能存在的问题。第二,即使不写安全设计文档,

也可以把较大可能产生漏洞的功能列出来,知道哪些产

品添加了哪些功能,这些功能是否更容易出现问题,是

否需要渗透测试。

开始推动这套流程时,我们发现产品安全负责人的

安全意识不足,挑不出哪些功能与安全相关。所以最初的

执行是由安全部门去挑重点的产品和功能,执行了两三个

迭代之后再给产品安全负责人进行培训,告知哪些功能与

安全相关。结合之前的数据,产品安全负责人就可以参考

这些数据在之后的工作中去挑选负责的产品是否有与安全

相关的功能。经过不断的积累,产品安全负责人的安全意

识逐步提升上来,就可以独立负责相关的工作。

二、软件安全研发工具

(一)威胁建模

Microsoft Threat Modeling Tool 是一款免费建

模工具,可以针对当前的架构图评估可能面临的安全问

题,以及对应的设计建议和缓解措施,同时该工具可以

很好的降低威胁建模的门槛。

前面说的安全设计流程的安全设计文档,只要开发

人员能把整个业务逻辑体现出来即可,说明其中可能存

在的问题以及对应的预防方法,但开发人员有时不一定

能完全在文档中体现,我们在审核文档时也会跟开发沟

通,当前业务逻辑场景下可能发生的问题,然后跟他一

(图一 安全设计流程图)

第39页

37

LECTURE ROOM 百家论道

起把这些问题都加到文档里,这样让开发在实现该功能

之前可以了解可能会存在的问题。

(二)静态代码分析(SAST)

我们使用的是 SonarQube 开源的静态代码分析工具,

可以分析漏洞、代码质量、潜在的Bug以及代码重复率等。

使用该工具的方式是将它集成到 GitLab 的 CI/CD 流

程中,每天扫描一次。扫描完后,如果有问题就会给对

应的开发人员发邮件,通知他有新的问题需要修改。

(三)软件组成分析(SCA)

在当前网络环境下,供应链攻击是我们需要面对的

重大挑战,比如像 Log4j 这种级别的漏洞肯定是越早发

现越好,而且使用不安全的组件,一直都是 OWASP Top

10 中的一个重要威胁。

我 们 使 用 的 工 具 是 OWASP 的 开 源 工 具 OWASP

Dependency-Check,可以用于识别依赖项,并且检查依

赖项中是否存在公开披露的漏洞。执行原理就是把几个

漏洞数据库下载下来,和代码组件进行匹配。

使 用 方 法 是 把 它 集 成 到 SonarQube 中, 同 时 在

SonarQube 的 GitLab 的 CI/CD 流程中添加 DependencyCheck,每天扫描一次。有问题会通过邮件形式通知开发

人员修改,结果可以显示在 SonarQube 中。

(四)容器镜像扫描

我们使用的是 Trivy,可以扫描的内容很多,包括

扫描镜像中操作系统软件包、应用程序依赖项、软件的

许可证以及配置文件中的安全问题。该工具使用很方便,

而且结果精确。

使用方式是把它集成到 GitLab 的 CI/CD 流程中,每

次打包都会扫描。另外也做了一些额外的集成,有问题

可以自动的创建 Jira 跟踪,开发人员看到 Jira 就会去

解决问题。

(五)动态应用安全测试(DAST)

DAST 基本上是每个做安全的企业首先要做的事,

我们使用过三款 DAST 工具,分别是 Acunetix(AWVS)、

Burp Suite Professional 和 OWASP ZAP,经过对比其结

果也是大同小异。

针对 DAST 比较重要的两点是,第一是扫描时要保持

登录状态,因为现在做的应用程序基本都需要登录,登

录之后才能使用里面的功能,所以没有一个登录脚本,

是不可能扫描到登录后的页面的。第二点是对于整个网

站是否扫描足够全面,也就是爬网逻辑。关于这两点,

这三款工具都没有很完美,因为每个产品用的前端技术

都不太一样,所以对于这种网站的扫描总是差强人意。

我们的做法是让测试人员把要测试的功能先清点一

遍,把收集来的请求导入到工具中再进行扫描。但局限

于上面描述的两点,没有办法将 DAST 集成到 CI/CD 流程

中,所以我们是让测试人员手动来扫描。

(六)服务器漏洞扫描和安全加固

我们并不是所有的产品或组件都使用了容器化,

有一些可能还在常规的服务器上。每一次迭代都会执

行漏洞扫描和安全加固,使用的工具是 Nessus Pro,

该工具可以花钱买也可以去官网下载免费版的 Nessus

Essentials。

(七)漏洞应急响应中心(SRC)

我们是使用 Bugcrowd 建立应急响应中心,这对安全

部门来说也是一种工作的验收,可以验证工作的开展情

况。起初我们在上线 Bugcrowd 时定的目标是让渗透测试人

员发现不了安全漏洞去努力的,但后来发现确实做不到。

我们使用 Bugcrowd 一段时间,发现的问题都是一

些老功能或老产品的问题,而且没有发现严重的问题。

如果是经过安全设计流程的新功能,基本不会有什么问

题。所以从结果来看,安全设计流程这套方法对于软件

安全有很大帮助。

三、安全团队建设

组建安全团队有两个渠道,分别是招聘和内部培

养。当然,招聘是最快最直接补充有生力量的一个方法,

但是我们公司是在二三线城市,很难招到合适的人才,

第40页

38

百家论道 LECTURE ROOM

所以我们是两条路并行,侧重于内部培养。

因为我们是一家软件研发公司,研发人员比较多,

占公司人员的一半左右,而且因为是在二三线城市,人

员留存率很高,所以培养研发人员转行到安全的操作性

更强,而且培养出来的人也完全符合自身的要求。我们

的做法是挑出来一些对安全感兴趣的人,让他们每天抽

出来一两个小时学习渗透测试和安全相关的技术,如果

合适再慢慢转到半全职或者是全职做安全。

(一)研发背景的重要性

一个没有研发背景的人,很难跟开发去讨论安全设

计流程中需要注意的问题,很难全面考虑业务逻辑中的

安全问题。我们团队有一位在国内某些 src 里做的不错

的选手,他的渗透能力很强,在内网或攻击相关的技术

都很擅长,比内部培养出来的研发人员强很多。但如果

去做安全左移或安全设计流程的工作,还是做了四五年

研发转安全的同事更好,而且面对越复杂的需求,研发

经验不足带来的弊端显现的就会越大,毕竟术业有专攻。

研发转安全还有一个好处,就是在做 Web 渗透的同

时也可以直接做代码审计。当然渗透测试人员也可以,

只是效率没那么高。其实我们内部也做了一些讨论,如

果看 20 行代码,有没有研发背景都无所谓,只要能看懂

代码就行。但是如果面对大量的代码,比如一个 20 万行

代码的产品,这时有研发背景的人做代码审计会比没有

研发背景的人好很多。

在安全团队中,如果同时有渗透测试做的很好的人

和有研发背景的人会更好。像前面提到的渗透能力很强

的同事,在资源充足的情况下,可以让他从事一些攻击

相关的研究性工作,让擅长的人做擅长的事。当然,如

果想做好安全左移,保证软件安全,那么安全团队一定

需要有研发背景的人。

(二)学习建议

不管是针对个人还是公司人才培养,如果想学习应

用安全技术,有几个比较好的资源。

第一,是 Burp Suite Web Security Academy,可

以免费注册账号使用,上面会提供 Web 安全的技术文档

和对应的 Labs,对于学 Web 相关的技术非常有帮助。

第二,推荐两个证书,OSCP 和 OSWE。OSCP,在学

习过程中可以全面了解网络攻击 / 渗透,可以补充很多

Web 安全之外的技术。OSWE,针对 Web 安全工作的锲合

度非常高,在考证过程中 80% 左右的内容都可以在以后

的工作中用到。

(三)软件安全研发人才培养

从我们内部的实际经验来看,在研发人员中培养安

全人才的成功率大概是 15:1,比如我们每次做内部安全

培训,报名 30人左右,留到最后的大概也就 2个人左右。

培训方式,首先进行渗透测试培训,然后做 Labs,

再慢慢从自己负责的产品挖掘漏洞。因为本身是研发出

身,对于自己负责的产品也很了解,有些就是自己写的

代码,所以很容易就可以找到问题,甚至有时可以找到

一些隐藏很深的问题。

安全研发人才培养成功的几点决定性因素,首先是

工作饱和度,如果一个人他有时间就会愿意多学一点,

但如果本身的工作每天都会加班到很晚,他就不会有时

间去学习安全相关的技术,这是很重要的一个因素。其

次是兴趣,兴趣是最好的老师,包括我也是因为兴趣才

走上这条道路。第三是上进心,学习一项新技术肯定需

要有自驱力,往往坚持到最后的可能就是上进心比较强

的。最后是天赋,天赋可能说起来有点虚,但是做安全

尤其是做渗透测试确实需要一些天赋,有些研发做的比

较好的人在学安全时也很努力,但就是感觉不开窍,所

以天赋也很重要。

当然,经过培训之后,这些人不一定会留在安全团

队,但是他回到自己的团队负责某一个产品的安全,对

整个公司的安全也会起到非常大的作用。

第41页

39

LECTURE ROOM 百家论道

安全与业务战略一致性的

理想与现实

网络信息安全所有关于人员的资质认证中,都会有一个核心思想:安全战

略需要为业务战略服务,安全战略需要与业务战略保持一致性。

在信息化时代,信息化是业务支撑管理体系的信息化,是管理流程的信息

化,目的是实现企业管理信息的流转。企业的 IT 部门通过购买商业软件套件

(COTS)支撑管理体系的发展,从工作流支撑的行政办公系统(OA),到财务

(ERP)、人力(HRM)、客户关系(CRM)、进销存(ERM)、产品设计与管理(PDM)、

生产制造(MES),虽然对企业的业务发展起着至关重要的作用,但主要还是通

过管理系统的执行和分析发挥价值,建立数据仓库,通过智能分析(BI)系统

辅助分析与决策。但在企业实际运作过程中,信息异步、人工录入、流于形式、

生产与管理两张皮的现象比比皆是。

业务部门对信息化部门虽谈不上怨声载道,但敬而远之,选择性忽视,有

可能成为常态。信息化尚且如此,保障信息化体系的网络信息安全部门距离业

务战略的鸿沟让安全与业务战略保持一致,未免显得过于理想。因此,网络信

息安全从业者,沉醉于技术体系的升级换代,在攻防对抗的世界中沉迷,任你

业务如何风云变幻,我谨守网络与系统底层基础安全的防护,业务与安全两不

相见,相安无事,各得其所,何不快哉。

一、数字化

数字化的解读汗牛充栋,华为在《华为数据之道》中提出了数字原生企业

与非原生企业的区别,数字作业系统是数字化的关键,在《华为数字化转型之

道》提出了华为数字化转型的 ROADS 方法论,Real-time(实时),On-denmand(按

需),All-online(在线),Diy(自制),Social(社交),对我们所提到的信息

化或者叫管理支撑系统的弊端进行体系化的变革。清华大学朱岩教授的观点是,

信息化是对内,数字化是对外,对供应链、产业链、监管机构和用户,实质上

也是支撑管理系统到生态作业系统的体系化转变。

从这个维度而言,互联网企业具有数字化原生的本质,以淘宝、支付宝为

例,淘宝实现了零售的数字化转型,用户与商家的交易过程在实时、按需、在

线、自制、社交的前提下实现了作业的信息化,为了解决支付的效率、体验以

及实现线上信用背书,催生了支付宝,当然为解决消费金融以及供应链金融诞

生的蚂蚁金服、网商银行等一系列创新,更促进了金融行业的数字化,当然与

传统金融行业的杯葛不在本文探讨范围之内。

数字化首先是业务的数字化转型,基于业务数字化的组织变革,以此为基

础的数字业务信息化,才是数字化的本质与内涵。

乐信集团信息安全中心

总监,中科院心理研究所管

理心理学博士,印第安纳大

学 Kelley 商 学 院 金 融 硕 士

(MF),香港理工大学软件理

学 与 工 商 管 理(MBA) 双 硕

士。前中国移动电子认证中

心(CMCA)负责人,OWASP 中

国广东区域负责人,CSA 大中

华区数据安全专家,网安加

社区特聘专家。关注智慧城

市,企业数字化过程中网络

空间安全风险治理,对大数

据、人工智能、区块链等新

技术在金融风险治理领域的

应用,以及新技术带来的技

术风险治理方面拥有丰富的

理论和相关经验。

刘志诚

第42页

40

百家论道 LECTURE ROOM

业务的数字化,不能仅停留在消费互联网的模式和

方法论上实现产业的业务数字化。在《数字经济:内涵

与路径》中,朱岩教授提出了“消费互联网的核心是流

量,产业互联网的核心是信任”的观点,从产业的维度

来看,不仅是消费互联网 To C,产业互联网 To B 的问

题,产业互联网的生态体系相对于消费互联网,网状结

构的复杂性不能仅用 Social(社交)来代替,我们的主

体不是谈论产业互联网。简而言之,当诸多传统行业选

择了阿里、腾讯消费互联网大佬主导数字化变革,可能

已经走了弯路。

业务数字化,从实现的角度离不开技术的进步,

云原生技术 4 个核心特性,奠定了数字化技术的基础。

DevOps,开发运维一体化,为什么放在第一位,是因为

数字化业务的本质必须是作业系统的自研,如果说管理

的标准化、体系化具有通用意义,那么作业系统代表业

务的性能、效率和独特性,是业务的核心竞争力,如果

仍是采购的商业软件(COTS),那么业务数字化这件事

首先就不成立。有人会说,自研系统当然可以实现差异

化竞争优势,但如何解决开发人员稀缺的问题?这时

ChatGPT为代表的AIGC技术的进步,让我们看到了曙光。

容器化作为从独立服务器到虚拟化的动态资源池建

设的下一站,其弹性进一步增强,虚拟机仍需要维持独

立服务器时代硬件资源的调配管理的操作系统模式,对

资源的消耗,以及持久化维持,弹性仍然受制。容器化

通过应用打包的模式,与应用的活跃程度保持一致,可

以实现资源的调用和释放的灵活性,对服务隔离、资源

弹性,以及非生产资源消耗优化,均有极大的提升。

微服务作为软件架构的颠覆性升级,实现了组织阿

米巴模式的软件架构,不再限于独立的单体软件,或子

系统与模块依赖的软件体系,而是通过拆解原子能力服

务,实现服务解耦。这种技术的进步,除了解决软件团

队规模陷阱,实现软件团队“两块披萨”的高效模式外,

对容器化的应用集成,实现快速发布奠定了基础。

持续发布是数字化业务的根本需求,为了应对市

场竞争,实现业务的灵活调整,需要数字化系统实现持

续发布,当然相对于传统产品的瀑布式开发模式,消费

互联网时代成为主流的敏捷开发已经具备了基因,结合

DevOps 的工具链,以及容器化和微服务架构,实现持续

发布能力。

相对于我们通常关注的“ABCDE”技术进步,重点阐

述了“C”云计算的云原生对数字化业务的理念和变革的

价值。当然“A”人工智能随着 AIGC 的爆火,对数字化

业务的运营自动化带来了更多的想象空间。“B”区块链

的智能合约技术在金融领域 DiFI 的大放异彩,如何在数

字化业务的自动化、契约化、去中心化中发挥作用,依

然有很大的空间,毕竟数字孪生背景下的元宇宙再造一

个宇宙,甚至超越物理宇宙的宏愿让人心向往之。“D”

大数据在数据作为除了土地、人力、资本、技术之外的

第五大要素,如何实现资源化、资产化、资本化,在理

论探索和实践领域均有突破,是数字化在数据、算力、

算法三个核心要素中的关键一化,需要另文详述。“E”

边缘计算的价值,目前仍被严重低估,5G 三大场景中

边缘计算拥有一席之地,对传统 OT 网络的替代,实现

IT、OT、CT 一体化,对传统行业的影响更甚。(限于篇幅,

此处不再展开论述,感兴趣的朋友可与笔者详聊。)

二、安全

回归到安全主体,我们要讨论的是安全战略与业

务战略如何保持一致性的问题,信息化时代,由于信息

化本身和业务并不紧密的特征,以及支撑技术能力的欠

缺,理想虽在,落地不易,而数字化的本质特征,为安

全战略与业务战略一致性落地提供了基础。

信息化时代的安全关注的是网络安全、主机安全、

系统安全、终端安全,围绕的边界也是企业边界。因此

安全厂商围绕的也是企业安全的解决方案,信息化时代

的管理系统承载,以购买的第三方信息系统套件(COTS)

为主,具备标准化、规范化、体系化的特征,另外网络

信息安全监管机构关注的也是静态的标准化安全基线的

检查,以及在系统安全基础上的红蓝对抗为主的攻防演

练。因此,大多数组织和企业的安全人员关注的是在保

第43页

41

LECTURE ROOM 百家论道

证监管合规基础上的网络信息安全,通过购买标准化的

网络信息安全产品,通过标准化的网络信息安全测评服

务,拿到标准化的安全体系认证,合规安全万事大吉,

实际安全风险带来的安全事故、应急响应,靠天吃饭。

在网络、主机、系统之外,互联网的普及,使得应

用安全也逐渐成为信息安全关注的热点,WAF、应用攻防

也逐渐被纳入网络安全管理的范畴。数字化安全首当其

冲需要关注的是研发安全,研发安全不仅是应用安全,

如果说应用安全是从攻防视角去关注应用潜在的漏洞利

用以及拦截和修复,研发安全关注的是研发过程的风险

管理和风险处置能力的建设和运营。信息系统成为数字

化业务的核心竞争力,自主开发信息系统的安全性就需

要依赖安全团队的研发安全管控能力。这个领域的创新

安全探讨比较多,从传统 S-SDLC 支撑产品瀑布研发过

程,到 DevSecOps 对 DevOps 的支持,在商业产品研发类

企业中,白盒测试(SAST)具有悠久的历史;在互联网

应用攻防领域,基于漏洞扫描和渗透测试的黑盒(DAST)

也已经成为主流工具;在数字化业务运营系统中研发安

全领域,灰盒(IAST)是目前崛起的新生势力;与 IAST

异曲同工实现在 OPS 状态防护应用运营状态防护(RASP)

产品,也已经展露头角。不过需要关注的是,如何在运

营系统中实现性能、稳定性与平衡,仍有待实践验证。

研发安全另外一个需要重点关注的问题是开源软件

的治理,开源软件带来软件领域繁荣的同时,也存在系

列问题,已经另文撰述,就不再展开。唯一需要提醒的

是,在关注组件的同时,也需要关注中间件、应用软件

与采购的商业软件一致,需要建立完整的生命周期管理

机制,对风险与漏洞进行体系化管理。

业务安全也是个复杂的问题,不同数字化业务

的业务规则、流程不同,统一实现业务安全的产品也

难以标准化,需要考虑具体业务的场景、流程,参照

MarlonDumas在《过程感知的信息系统》里面的建模模式,

实现业务过程的跟踪与处理,建立自己特色的业务安全

能力建设与运营体系。

仅从几个通用的维度来稍微展开一下业务安全的基

础防御,首先是 To C 的账号体系风险管理与控制。企业

内部账号管理体系在经历 IAM 管理的演进,已经从传统

的账号密码认证过渡到多因素(MFA),以及账号、认证、

鉴权、审计的 4A 甚至 5A 体系,再结合远程办公的终端

设备风险和网络风险从 VPN 升级到零信任,防御能力逐

步增强,但 To C 的用户账号,由于其终端不可控、网

络不可控、环境不可控、用户不可控,导致的黑灰产肆

虐,引起的爬虫爬取用户敏感信息和商业秘密信息、欺

诈、薅羊毛等系列风险,虽然业务风控体系基于业务规

则进行识别、封控和拦截,但往往基于事后的规则命中

机制亡羊补牢,难以提前防御和处理。在账号注册和关

键行为中,识别用户侧风险,是安全技术部门可以助力

业务的典型应用。结合业务安全情报、终端环境、IP、

设备识别码、行为特征、流量特征,实现前置的识别、

处置,事半功倍。

其次,是从生态的角度,关注 To B 合作伙伴的接入

和流量安全,专线和白名单的网络安全控制措施,对应

用层和业务层的安全保障难以起到作用,如何实现应用

接入生命周期的管理,实现业务的实时跟踪审计,规避

应用与数据安全的渗入效应,在实现企业安全的同时,

规避生态安全的影响,是解决 To B 安全的手段之一。另

外,数字化组织结构的变革带来的业务外包问题也不容

小觑,如何实现 To B 员工在非受控网络、非受控终端、

非受控用户的情景下,访问企业的作业系统,实现业务

安全保障,同样也是个值得探讨的课题。

仅从研发安全、业务安全的两个场景聊一下,安

全的范围与边界的变革,但涉及到安全体系和机制的变

革,更重要的是组织变革和模式变革,这个话题谈起来

并非三言两语可以说清,可能也并不是目前安全从业者

关注的话题,毕竟即使拥抱变革,也不会对遥不可及或

看起来遥不可及的事情过于关注。

不过,还是简单说几句。相对于大企业构建完整

的安全体系,实现体系化数字化安全能力的自建,中小

企业面对的其实是个两难困境,要实现业务的核心竞争

力,构建数字化业务的信息化系统,就需要针对性的自

主安全能力建设,而自主安全能力体系的建设和运营,

带来的成本增长,又难以消化解决。信息安全托管服务

(MSSP)这个概念不妨拿来借鉴与发展,企业未必全面

投资自身的数字化安全体系建设,只是需要数字化安全

保障服务,信息化时代的简单性托管服务成为鸡肋,而

数字化安全的复杂性,反而带来了机会。当然,传统的

MSSP 体系建设和运营一体化服务,难以实现资源的全

面复用和成本分担,也并不能支撑企业的数字化安全,

而结合网络安全保险以及融资租赁的网络安全金融化服

务,以及改变服务对象的网络安全保险科技就有了双赢

的机会。

安全战略与业务战略一致性,看似理想与遥远,其

实,很快理想就会照亮现实,这也是网络安全从业者不

可多得的机会。

第44页

42

百家论道 LECTURE ROOM

漫谈安全的两三事

本科毕业于西南交通大

学,硕士毕业于中南大学,目前

中南大学博士在读,具备计算机

领域专业背景和根基,是网安加

社区特聘专家。先后就职于中国

中铁五局、株洲中车时代电气股

份有限公司、广东 OPPO 移动通

信有限公司等大型集团企业,目

前任职三一重工股份有限公司信

息安全负责人,全面负责三一集

团的企业信息安全战略规划、企

业安全体系架建、安全人才队伍

建立和培养等。

孟翔巍

一、关于网络安全域实现的一些个人看法

(一)网络安全域参考模型

关于网络安全域,现在很多企业都想参考头部企业的模型来落地实施,其

关键点是通过红黄绿三个区来实践落地。

红区,该区域终端仅能访问内网核心研发系统,且外设接口均被封闭;无

互联网访问权限,有互联网访问需求时由公共机解决;进入该区域的人员,不

允许带入任何具备留痕能力的设备,包含但不限于手机、U 盘等。

黄区,该区域终端能访问内网非核心研发系统与部分办公系统,且外设接

口均被封闭,有配套流程可以进行开放;具备基础互联网访问权限,即普通查

询的 web 资源等;进入该区域的人员,在授权情况下允许带入具备留痕能力的

设备,但需要一定处理,比如有专门的安保人员会用封条将笔记本和手机的摄

像头贴起来。

绿区,该区域终端仅能访问内网办公系统,外设均处于放开状态;互联网

访问权限无限制;人员可随意进出该区域,无物理限制。

这是一个非常理想的模型,但它有一个核心规则,即从低密到高密的单向

数据流,从而保护整体的核心研发资产。该模型比较适合研发相对集中的企业。

(二)达成该模型的前置条件

从实际落地经验来看,要达成该模型有三个关键的前置条件:

物理先行。至少得把具备同类属性的人员聚合在同一个物理空间里面,这

个难度非常大,因为标杆企业在开始就把同一类人员聚集到同一个办公区,就

会简单很多。如果刚开始没有这么做,后期几乎不可能把人员聚到一起,人员

一定是交错的,这时候再进行人员办公区域调整将是一个巨大的工程量,这也

是该标准模型落实不了的原因之一。

数据单向流的可行性。这个节点得解决两个问题,一个是技术实现问题,

能否实现单向流,我当时有做过相关的工具调研,可以实现,但是部署和运维

的难度比较大。一个是规则实现问题,是不是一定能做到低密往高密流,如果

在业务规则源头上没有定义清楚,会很难实现,因为业务之间的交付已经形成

定式,要去打破这种定式,用另外一个规则去约束业务,那么对业务的效率将

造成极大的影响。

本文将以故事和经验实践的方式展示给大家,分享的内容主要有三个话

题,分别是网络安全域的实践、API 治理实践与 SOAR 的畅想与实践。本文仅为

抛砖引玉之作,希望能给大家提供借鉴,并期待与业界同仁的深入探讨。

第45页

43

LECTURE ROOM 百家论道

成本的控制。基于物理去实现这样的模型,取决

于本身物理空间的需求较大,造成较大的成本投入;其

次,物理空间规划好之后,每一块物理区域都需要一套

IDC基础设施,如何说服老板投入,这本身也是个问题。

实际上,在做安全工作的过程中都会面临说服老板

的情况,因为安全有一个重要的属性是“既不降本也不

增效”,它与企业降本增效的理念是相违背的,因此安全

工作都是通过降低安全事故的发生率去说服老板来进行

投入。

(三)纯逻辑方式实现裁剪模型

如果做不到物理先行,那就只能从逻辑上面去考

虑。不再通过物理层面区分人员,尽量把相关人员集中

在一起,从路由层面来建红黄绿区,再通过不同层面的

路由互写,也就是 ingress 和 exgress 的方式,把路由

进行输出和导入,从而实现类似物理先行那种管控状态。

但是经过试验发现这一套很难走下去,主要原因

有三个:一是运维难度非常大,人员位置的变换还能解

决,但是路由空间的配置本身就非常复杂,如果稍微有

一点业务变更,意味着路由这边要调整很多东西,运维

难度非常大;二是人员依赖性很强,这一套工作完整做

下来的人员,在很熟悉路由规则的情况,运维还是可以

搞定的,但如果人员进行了更替,意味着整体的延续性

就不好了,因为一个月都不一定能交接完,即使交接完

也需要有很长的适应周期;三是成本相对较小,这算是

一个优点,基本上就是一套网络设备加上一套安全设备。

(四)物理与逻辑相结合的方式实现裁剪模型

物理与逻辑相结合的方式,就是将物理层面定义为

类似实验室的方式,相对封闭,按照“二八原则”把最

核心的 10-20% 的人聚集到一起,然后以实验室的方式参

照前面的模型把它彻底隔离起来,建立红区,其物理和

路由层面是统一的。黄区和绿区还是用纯逻辑的方法,

通过路由层面进行隔开。相对纯逻辑的裁剪模型来说成

本会高一些,因为有物理和路由层面统一的部分,至少

会多一套设备。

而且,即使将红区摘出去,黄区和绿区的运维难度

也不小,因为红区在整体规划中的占比较小,黄区和绿

区还是占大部分。此外,对人员的依赖性依然很强,因

为它的复杂度就决定了如果出现人员交替,其连续性一

定会存在问题。所以经过一段时间的实践,随着整体覆

盖面的铺开,发现最终的目的难以实现。

(五)解决方案的探索过程

基于上面几种模型的探索,我就在思考,到底要

通过这个模型解决什么问题?我认为这个模型是尝试从

人员、终端、应用三个角度实现防攻击、防泄漏和防特

权,这是它要实现的顶层目标。

其次,参考这个模型,最大的价值点是什么?我个

人认为是从物理角度出发,解决了人、机(设备)、料(应

用)之间的问题。为何很多组织参照模型的时候落不了

地,有个最重要的原因,就是对于物理先行上有绝对的

执行鸿沟。因为在物理位置固定好的组织中,再去进行

位置的调换将是绝对达不成的工作,基本不是某个人能

决定的,牵涉的范围很大。

因此,既然物理层面落不下去,那就抛开一定的输

出点,不再考虑人的问题,转而去解决机、料的问题,

实际上就是在实现能不能访问、权限给不给的问题,而

这个问题就可以通过 SDP 来解决。

纵观SDP整体架构,其中关于用户部分有信任引擎,

可以从 IAM/PAM/4A 获取一些基础的权限数据,然后通过

一部分通道策略传输到应用代理,明确可以访问哪些应

用。经过两两组合来解决前面提到的两个核心问题,就

是本身的基础权限的源和信任引擎加到一起,信任引擎

对权限通过模型的方式去做加权,根据本地终端的环境

数据来决定给多少权限,这就解决了权限到底给不给的

问题,然后信任引擎加上代理的 porxy,解决能不能访

问的问题。

事实上 SDP 概念是基于零信任而来,被炒作了很长

一段时间,主要体现的核心价值有两个,动态鉴权与动

态授权,也就是解决权限和访问的问题。

二、关于 API 治理过程中的一些心得

关于 API 治理心得,先给大家介绍一下背景。有一

天,研发负责人找过来,说业务正在做数字化转型,要

第46页

44

百家论道 LECTURE ROOM

构建应用产品生态,想通过一个平台做 API 的生命周期

管理,问安全要不要一起联合立项?听完我很感兴趣,

因为我本来也想做治理这块的事情,但是业务不参与到

整个过程中,只靠安全来推动会遇到很大阻力。所以当

研发负责人愿意来一起建设,我们是一拍即合。

(一)安全的考虑点与业务的适配性

在请示老板意见的这段时间发生了一些状况,因为

彼此较忙中间没有太多交流,等我们第一次碰撞的时候

才发现两人的思考方向完全不同。研发负责人想的是平

台的架构、API 的管理、以及应用之间的区分等等。而

我是从安全角度出发,想的是API发布之后的权限范围、

使用协议、敏感数据加密、数据脱敏、API 认证、授权

等等。

然后研发负责人就说了,你想那么多安全需求,我

怎么去做融合,总得先要沟通梳理一下。我一想也对,

至少应该通过沟通去调研到一些内容,比如架构层设

计、技术支撑管理的流程配套、内部 API 和外部供应链

等等,这次事情也让我明白安全应该考虑到与业务的适

配性,不能只站在自己安全的角度思考问题。

(二)业务的分层方案

两周之后,业务给出了方案架构,初始的想法是内

部的 API 要管,上游的也要管,但是一个平台全部管理

的复杂度有点高,于是就有两个方向:一是就做一个平

台,将它做成两个模块,分管内外;另一个是,把平台

一拆为二,内外部分开管理。区别在于,两个平台相对

来说成本和周期更高,一个平台更简单一些;但是从从

后期管理来看,两个平台运营的成本要低一些,一个平

台运营成本则偏高。两种方式各有优劣,但是从安全的

角度来说,两个平台要比一个平台好,因为如果外部平

台万一被漏洞利用,内部平台还能用,比一个平台的安

全性更稳妥一点。

经过综合考虑,最后还是将平台一拆为二,即如图

所示的 Inbound 与 Outbound。在整个过程中,我们把

APP 分类之后,在平台中嵌入了一个流程点,就是在产

品上线时一定要把 API 发布到平台,如果有对外的交付

需求,可以把 API 在对外的网络上再做一次发布。当然

后期还在完善中,只需要一次发布就可以完成两件事。

然后,其他 APP 来调用时直接从平台调用即可,不需要

再进行 APP 之间的调用。大概整体架构和业务的实现,

安全与研发基本达成共识。

(三)安全应对与解决方案

框架与业务实现达成共识之后,我就着手考虑安全

应对与解决方案。首先是对应用进行定级,才能确定后

面 API 的范围。然后,尽量梳理清楚现有的 API 资产,

包括数量与类型。做完这两项基础工作,就开始研发。

在 Inbound 的安全工作中,首先重点肯定要有流程

配套,包括 API 的发布、使用以及随着产品的下线的生

命周期,一定要有一个配套流程。第二步,根据应用定

级和 API 资产治理的结果,确定哪些 API 需要什么样的

安全配套。第三步,梳理 API 的时候也会把一些 APP 之

间的关系梳理清楚,这时没必要把授权卡的太紧,就给

予了较为宽松的授权范围。然后,做轻量级的传输加密,

挑重点去做,保证即使发生 API 的泄露,这种基本的加

密形式也会有所保障。最后,通过一些工具对威胁进行

监控。

在 Outbound 的安全工作中,主要分为公有云和供应

链上下游两个部分。首先把使用协议做出来,将供应链

这块的使用协议推下去,风险共担。第二步,要有认证

第47页

45

LECTURE ROOM 百家论道

机制,确定哪些 APP 需要严格一些的认证。第三步,要

有严格的授权范围,要调用哪个 APP 就只能调用哪个。

第四步,重量级传输加密,只要是出去的数据都要加

密,也是为了防止数据泄露。最后,点对点消费,就是

上下游每一次抓取数据,使用完后就销毁掉,不再留存。

通过这种方法来实现安全与业务的协同,同时完成

各自的目标。

(四)API 治理心得

首先,安全不要尝试走到业务前面。安全实际上

是一个孪生技术,基本上是孪生在整个业务的成熟度上

面,因此安全的成熟度不可能高于业务,一般比较厉害

的能跟业务保持一致,比业务慢半拍也是比较合理的。

第二,先治理后技术,技术的价值是为管理服务

的。既然为管理服务,那么要做好支撑,肯定是个自上

而下的过程,如前文提到的先把应用资产治理好再去实

现技术会更顺畅。

最后,常态化运营,不要湮没建立起来的秩序,通

过流程的方式让整体更加规范化。

三、关于 SOAR 的一些畅想与实践

我对 SOAR 的理解分为三层,第一层就是业内对

SOAR 的定义,即 SOAR 是安全自动化编排,是实现自动

化安全威胁响应的能力。第二层,基于该定义我认为

SOAR 是一个技术框架,有两个关键词,即自动化响应和

编排,自动化响应其实是靠整体的技术栈来解决,编排

是靠流程来解决。基于这个理解,我认为它是在解决安

全运营最后一公里的问题,在我的团队里我更愿意称之

为“自愈”,这是我的第三层理解。

谈到自愈,此处分享一个经典剧本,相当于威胁处

置的 SOAR 过程。第一步植入,第二步潜伏等待,第三部

命令执行,当其去做 CC 回连,这时相关工具就会检测到

威胁数据,产生一些日志,然后会有一个脚本化过程,

把 CC 回连阻断掉。

基于这个剧本,我一直认为 SOAR 是一个技术框架,

这里列举了三个例子,基线管理、漏洞管理和补丁管理。

实际上,SOAR 上线之前,其他流程都是自动化,

唯独修复阶段都需要人工,无论是基线、漏洞,还是

补丁。这就是前面提到的最后一公里,也是我想推动的

方面。首先,我是把基线抽出来做,写一些修复脚本,

也就是自愈脚本,然后找了一个下发成功率最高的桩,

检验时发现该思路可行,于是就往上推。现在,基线的

SOAR 实践基本没有问题,工单从产生到整体闭环,不再

需要人工去干预。

其中,自愈脚本和桩一起做了编排,让桩能做的事

更多一点,这样的话基线流程基本实现 100% 自动化,补

丁也接近 100% 自动化,漏洞做不到 100%,但会提高自

动化率,通过这种方式把整体的SOAR体系逐步构建起来。

在实践完之后,我当时在考虑要不要做一个中台,

有两种方式,一是做成中台,把 SOAR 最后流程的人工端

点补完;二是把 SOAR 做成 SOC 的一个模块,模块之间来

调用,整体过程还是“SOC-SOAR- 桩”互相拉动的方式。

其实这两种方式差别不大,把前中台分开去看,觉得可

能逻辑更清晰一点,方便整体架构的横向扩容和收缩;

把前中台做到一起,相对来说功能更集约,前台能力更

全面。因为目标都是自愈,从底层来看,两种方式实现

流程都一样,怎么选择取决于组织的具体情况。

第48页

46

百家论道 LECTURE ROOM

OCBC 框架下企业云化 CSPM

落地思考和实践探索

某互联网公司高级安全专

家,网安加社区特聘专家,近

10 年安全行业从业经验,5 年 +

团队管理经验,长期负责企业安

全建设,探求安全体验与效率并

存的安全能力和解决方案建设。

熟悉公有云安全、数据安全、基

础安全和安全运营等领域,擅长

企业的信息安全解决方案高效落

地,并有体系规划和安全运营实

践经验。在企业安全产品方案选

型和建设(特别是数据安全)、

解决方案规划与落地、安全运营

能力体系化建设等方面具备独特

理解和全过程实践经验。

李 磊

一、CSPM 历史

(一)CSPM 的产生

很早以前,随着云市场的蓬勃发展,与云相关的概念应运而生。Gartner 敏

锐地捕获到了类似的变化,早早创立了以 C 字母打头为缩写的与云市场密切关

联的各种领域词汇,像Cloud Computing、Cloud Security Solution等。CSPM(即

Cloud Security Posture Management)是其云安全解决方案家族中的普通一员。

根据 Gartner 历年发布的“云安全技术成熟度曲线”数据,笔者粗绘了图

一 CSPM 及其关联技术成熟度炒作曲线时间轴。大约在 2017 年时,Gartner 提

出了 CSPM 一词。为什么是大约呢?因为在 2018 年 Gartner 发布的“云安全技

术成熟度曲线”中,Gartner 将 CSPM 定位在期望膨胀期,所以至少在 2017 年以

前 Gartner应该已经提出了类似概念。不过,在 2017 年或更早前的相关报告中,

并未发现 CSPM 这个缩略词。

CSPM(图一绿色字体部分)从提出到现在,短短几年,经历大起大落。当

前正处于所谓“稳步爬升恢复期”,看似一片大好。

(图一 CSPM 及其关联技术成熟度炒作曲线时间轴)

为什么要花这么长的时间去梳理 CSPM 产生的时间线呢?笔者希望通过拉开

时间的维度,来看具体是在什么样的诱因下 Gartner 提出了 CSPM 一词,这样更

有利于理解 CSPM 最初是寄希望于解决怎样的问题。

本文作为《新视角下企业云化安全治理框架 OCBC》B 基准(云产品安全基

准中安全基线子项)的纵向阐释篇,细化在云产品和服务风险管控中的一些个

人理解、思考和落地实践。

第49页

47

LECTURE ROOM 百家论道

回顾 2017-2018 年,与云相关几个重大事件有:

(1)根据《2017 年云计算行业市场发展分析报告》

数据显示,当年全球云计算巨头收入增长惊人;

(2)2017 年,中国工信部正式颁布云牌照监管政

策,让很多云厂商的合规之路顺利上岸。而且在 2018

年,BAT 云计算战略升级,云部门被提升到一个新的高

度。如阿里云事业群升级为阿里云智能事业群。全新

的阿里云智能事业群,将中台的智能化能力(包括机器

智能的计算平台、算法能力、数据库、基础技术架构平

台、调度平台等核心能力)将和阿里云全面结合。

(3)根据 ITRC 数据泄露报告内容显示,2017 年的

数据泄露事件较 2016 年增加 44.7%,达到一个创历史的

记录。同时,云上数据占 TOP 数据泄露比例为 28%,并

呈逐步上升趋势。

(4)根据统计,云上数据泄露由于云服务配置错误

的占比约为 40%,而这一趋势仍在增长。

通过这些与云相关的重大事件,可见云的发展高

歌猛进,企业云化带来高价值数据集中,但云上因为

配置问题导致的数据泄露频发。可以发现,Gartner 最

初提出 CSPM 的理念最希望解决的是 configuration of

cloud services 中的问题。

神奇的点在于,这是谁的责任?

甲方云化企业以为是云企业的问题,云厂商以为甲

方已经知道了这个是它自己的责任。

实际上,多数上云的甲方是不清楚的,很多云化的

企业或安全从业者本来是尚未准备好应对云带来的安全

变化,在如何更安全的用云和云上的责任划分存在着认

知偏差,事实上亦是如此。根据 2020 年 CISO MAG 调查

显示 ,76% 的用户认为云厂商是要为云上安全负所有责任

的。显然,这是不现实的。

作为云厂商的乙方,其实早早看透了这一点,很早

就发布了自己的“责任共担模型”。所以,我们还是再看

下它到底说了什么。

(二)云上责任共担模型

责任共担模式的出现,本质上是因为基建和服务的

提供方发生了变化。

责任共担模型是定义云服务提供者及其客户之间的

安全责任的框架。基本每家云厂商都推出了自己的责任

共担模式,但是实质的内容大同小异。笔者的理解主要

是两个点:

(1)云“基建”的安全责任属于云厂商,可以理解

为冰山下的。

(2)云“使用”的安全责任属于云用户,可以理解

为冰山上的。

我们以图二 AWS责任共担模型为例,来简要做下解释。

如果我是云用户,但是在自己的租户环境下,发

现可以通过私网方式访问到其他与我无任何业务关系

云租户的环境或资源,或者直接访问到 AWS 云环境的

Infrastructure 管控端,那这个属于漏洞,修洞的责任

或出现问题的背责方肯定是云厂商。说白了,云厂商要

为自己的基建安全性负责。

如果我是云用户,买了 AWS 的 S3,类似阿里云

的 OSS。我在 S3 中存了很多的数据,但是我却把 S3 桶

sec-data 的权限设置为 Public,造成互联网上的任何用

户都可以访问。那么,这个责任肯定是属于云用户自身

的。因为,作为云厂商提供了丰富的 Identity&Access

management 机制,而且事实上我也完全可以通过这些机

制将 sec-data 设置为 Private 来规避这个问题。其实,

这个问题本质是云用户没有做好图 2 中 Identity&Access

management。

通过这个简单的例子,其实是想表达,把云用好的

安全责任是归属云用户的。即,上述云配置的安全风险

责任是需要甲方自己关注的,甲方需要根据自己的业务

特点,使用云服务或产品的功能来安全的服务自身业务。

笔者在《新视角下企业云化安全治理框架 OCBC》一

文中,已提到云产品安全基线,本质上也是希望解决云

产品使用中的配置安全问题。

(图二 AWS 责任共担模型)

二、CSPM 介绍

(一)CSPM 定义

好了,了解以上的背景后,我们现在看一下,

Gartner 对 CSPM 的具体定义。刚看到图一时,部分读者

第50页

48

百家论道 LECTURE ROOM

可能会非常好奇,为什么讲 CSPM,还要关联带上 CWPP、

CIEM、CNAPP 等名词。因为从现在的时间看来,Gartner

自身对 CSPM 的定义也是日趋丰富和完善。

另一个希望表达的是,无论是 CSPM 抑或 CIEM、

CWPP等间都存在着关联性。这点,笔者后面会详细提到。

为免翻译带来的理解差异,笔者直接引用 Gartner

的原文最新定义:

Cloud security posture management (CSPM) consists of offerings that continuously manage IaaS

and PaaS security posture through prevention,

detection and response to cloud infrastructure

risks.

在上述的定义中,可以清晰的看到几点:

(1)CSPM 管控对象为 IaaS、PaaS,注重的是 infra

的风险

(2)CSPM 管控的是对象的 Security Posture

(3)CSPM 管控能力覆盖 prevention、detection 和

response

(4)CSPM 具备持续管控的能力

现在基本可以理解 CSPM 的定义和定位了。

这里也说下关于 CSPM 的中译,看到不少文章将其

翻译为云安全态势感知。笔者很早前看到这个翻译的时

候,最大的疑惑是既然翻译成态势,Gartner 为什么要用

Posture,而非用 situational。在相关介绍中,笔者亦发

现 Gartner 解释 CSPM 应视为一个持续改进和适应云安全

配置的过程。综合可见,CSPM 中的 Posture 是指配置,而

非态势,所以将CSPM翻译为云上安全配置管理是恰当的。

另外,从当前多数 CSPM 实现管控的原理也能看到,

其对接的是对应云管控环境中的配置审计等日志信息,

所以本质上也是配置或云产品或服务基线管控的一部分。

当然,乙方厂商在落地 CSPM 时也一直在夹“私货”,

这里我主要 CSPM 的一些通用能力。

(二)CSPM 功能

根据笔者调研来看,CSPM 一般具备如下通用能力 :

1、云服务配置风险安全检测能力。这个属于 CSPM

的最基础能力,是真正考验乙方厂商 CSPM 好坏的一个最

根本指标。同时,该能力需要能够支持自定义和调整。

2、合规检测能力。例如可以支持国际上常见的 PCI

DSS、SOC 2、GDPR、RMiT 金融标准合规检测;国内常见

的等保三级、网络合规管理检测等。

3、多云管理能力。支持跨云检测,如同时支持阿里

云、AWS、GCP 等。

4、自动修正的能力。发现了云服务配置风险,支持

自动进行修复。

5、报表能力。各种炫酷的展示等等,算是Plus项了。

当然,随着 2020 年 CNAPP 的产生,CSPM 的功能和

定位也在持续扩大。正如图一显示的那样,CSPM 出现后,

Gartner 又提出了 CIEM、CNAPP 等名词,希望更广的覆

盖云原生的安全防护。但是,确实名词太多,各名词功

能定位有重叠。笔者就与 CSPM 关联性比较高的 2 个做下

对比介绍。

三、CSPM 关联对比

(一)CSPM 与 CIEM

正如图一所示,2020 年,Gartner 又提出了 CIEM,

即 Cloud infrastructure entitlement management ,

寄希望于解决账号权限的风险。这里还是直接放下

Gartner 的原文定义:

CIEM offerings are specialized identitycentric SaaS solutions focused on managing cloud

access risk via administration-time controls for

the governance of entitlements in hybrid and

multicloud IaaS. They typically use analytics,

machine learning (ML) and other methods to

detect anomalies in account entitlements,

like accumulation of privileges, dormant and

unnecessary entitlements. CIEM ideally provides

remediation and enforcement of least privilege

approaches.

原文就不做解释了。谈下个人对 CIEM 的理解。

本质上,CIEM 关注的是身份或账号,这里的身份不

仅仅是从用户侧来看,同时还关注云基础设施和服务的

权限。通过以最小权限原则来解决身份权限过大或不当

的风险。不过,目前看到多数实现 CIEM 的商用产品,仍

是以采用事中或事后监控的逻辑来实现身份风险管理,

这本质上与甲方诉求是有差距的。

另外,更尴尬的点出现了,CSPM 其实也可以用来解

决这个问题,而且在 CNAPP 云原生应用保护平台解决方

案中,也能发现这个控制点也被揉到了 CSPM 的功能中。

所以,从这个维度上看,CIEM 的地位是略尴尬的,但是

它的重要性不言而喻,CSPM 也扛不起这个大旗,后面会

进一步解释。

百万用户使用云展网进行图文电子书制作,只要您有文档,即可一键上传,自动生成链接和二维码(独立电子书),支持分享到微信和网站!
收藏
转发
下载
免费制作
其他案例
更多案例
免费制作
x
{{item.desc}}
下载
{{item.title}}
{{toast}}