• 写在前面

• 准备威胁建模

• 组建虚拟团队

• 四个阶段的结构化思考

• 车联网威胁建模例子

• 1、我们在做什么？为车辆登记功能创建系统模型

• 2、会出什么问题？识别功能威胁

• 3、我们要怎么做？确定威胁的优先级并选择缓解措施

• 4、我们做得足够好吗？评估威胁建模过程的有效性

• 附录

• 威胁建模模板

• 参考资料

AWS教你如何做威胁建模

写在前面

    最近的“AWS re:Inforce 2022”介绍了众多的安全、身份和合规的产品和服务，笔者整理亚马逊相关资料一步一步介绍威胁建模环节该怎么做。

    这里严厉批评某些公司所谓的“轻量级威胁建模”，其实本质就是需求表格的自查，不要指望技术同学用简单的checklist就能做，想轻量级那就不是威胁建模！

    因为威胁建模的本质是----“有经验的安全专家和业务团队关于威胁的头脑风暴”，欢迎自动化、欢迎复用、欢迎标准流程，但威胁建模活动一定是以沟通、协作和以人为主导的专业知识为中心的。

准备威胁建模

组建虚拟团队

    威胁建模需要听取多种不同观点和经验才能进行，每个团队成员的意见都需要重视，最终在安全、交付、业务之间取得权衡。不能仅仅是安全和技术参与，checklist，卡点反而是阻碍威胁建模效果的瓶颈。具体来说需要五个角色：

• 威胁建模专家：是一次威胁建模活动的主导者，经验丰富、洞察威胁建模的过程和控制讨论边界，这个主持人、教练、顾问要参与一线，最终总结材料文档，平时同时兼职攻击者和防守者两个角色。

• 攻击者：发现设计类安全缺陷，类似于沙盘方式设身处地从攻击角度进行头脑风暴。

• 防守者：避免安全防御措施过度设计，设计威胁控制措施。

• 开发人员：主力模块开发者或者系统架构师，有了解当前服务具体如何设计和实现的背景，负责清楚明白威胁和缓解措施。

• 产品经理：类似于交付经理，避免安全措施导致产品需求无法实现，达到安全、效率和体验的平衡。

威胁建模的四个阶段

    通过在不同的阶段尝试结构化思考回答四个问题：

1. 我们在做什么？

参与者：全部虚拟团队成员

交付和设计更安全的软件

2. 会出什么问题？

参与者：攻击者、开发者

STRIDE助记符、内部人员风险、OWASPTop10、数据安全风险、组织内部的威胁列表

3. 我们要怎么做？

参与者：防守者、开发者、产品经理 

代码控制方案、引入纵深防御、借助云服务的安全措施，评估改进后的方案不影响需求。

4. 我们做得足够好吗？

参与者：威胁建模专家，开发人员

威胁建模是对风险的分析，这个判断是否足够好的阶段区分：

1. 威胁建模专家审核威胁已经“足够全”，认可缓解措施；

2. 开发者交付缓解措施，进行再次code review；

3. 威胁建模专家评估验收标准，根据威胁建模的结果引入安全测试、结项；

4. 威胁建模专家归档建模结果、更新知识库，整合各项缓解措施到平台级别的安全基线中，与SDLC工具深度集成。

注册功能威胁建模例子

    接下来以在AWS上的一个车联网服务解决方案为例解答如何创建系统模型和威胁模型，以及评估模型的有用性。车联网解决方案通常包括物联网车辆、驾驶员、车辆登记、遥测数据等多种模块，这是一个复杂的系统，所以要分解到功能、应用服务模块进行建模，而不是一开始为整个系统创建威胁模型。

    本次的例子拆分到story维度，简化为“作为⻋队经理，我想注册现有的物联⽹连接⻋辆以使其投⼊使⽤。”，具体场景技术设计上，⻋队经理将使⽤标准 Web 浏览器访问 Web ⻔⼾、进行⾝份验证，并能够将新⻋辆注册到系统中并投⼊使⽤。

1、我们在做什么？为车辆登记功能创建系统模型

1.1、首先将准备创建数据流图表示上述车辆登记功能的元素，以及它们之间的数据流。

    需要的工具就可以是白纸、白板，或者是draw.io或者PlantUML。根据上述系统设计图中了解到系统以AWS Amplify托管前端静态资源，Amazon Cognito集成做身份验证，由 AWS Lambda 和 Amazon API Gateway 提供的基于 REST 的 API，后端通过DynamoDBTable和S3进行存储。

1.2、绘制系统元素、数据流和信任边界

    在元素之间，通过绘制箭头来表示数据如果通过车辆登记功能流动，箭头的方向就是数据流的方向，对于http、rpc请求意味着必然会向调用者返回响应，不必添加返回箭头，存储和查询可以是单向的。

1.3、绘制信任边界

    确定车辆注册功能的哪些区域和元素组可以被认为是同等受信任的，化为同一信任域，在每个区域周围绘制虚线框来显示信任边界的未知，并添加标签来显示信任域的用途，以下绘制完成的车辆注册功能数据流图。

2、会出什么问题？识别功能威胁

    开始你的威胁建模头脑风暴，没有错误的答案，我们的目标是尽可能完整得涵盖可能的威胁，不预设可能已经会被缓解的威胁。

2.1 使⽤ STRIDE-per-Element 查找对⻋辆登记功能的威胁

    每个元素，即人类参与者、外部实体、流程、数据存储和数据流可以被对应到不同的STRIDE威胁。

2.1.1 外部实体的威胁由于是注册功能，所以有外部实体User，从上述的STRIDE-per-Element图表中，我们看到会有 Spoofing（欺骗）和 Repudiation （否认）威胁，这里不再详述。

2.1.2 对Process的威胁：

欺骗:进程的⾝份欺骗是指与其连接的每个元素，比如在同Amazon S3通信时可以假装（欺骗）为Lambda的身份，恶意连接数据库。

篡改：如果进程的代码、配置或执行环境（如内存空间）以意想不到的⽅式被修改，则可能会篡改进程。考虑如何篡改⻋辆登记功能中的流程。例如是否可以向 Lambda 函数提供输⼊以修改函数的行为？

否认：Lambda 函数是否可以在不⽣成审计跟踪条⽬的情况下删除存储桶对象，从⽽不归因于执行了该操作？

信息泄露：Lambda 函数如何返回对错误 S3 对象的引⽤？

拒绝服务：⾮常⼤的对象是否会导致 Lambda 函数出现问题？

权限提升：车辆注册一般不存在普通用户和管理的区别，这里忽略威胁。

2.1.3 对数据存储的威胁：数据存储可能面临篡改、信息泄露和拒绝服务的风险。

拒绝：如果系统设计中没有对系统日志进行存储，应该不会有拒绝威胁。 否认：系统本身没有日志记录，所以没有否认威胁。

泄露泄露：恶意人员如何从DynamoDB 表中读取数据，或读取存储在 Amazon S3 存储桶内的对象中的数据？

拒绝服务：恶意人员如何从 Amazon S3 存储桶中删除对象？

2.1.4 数据流：当数据流过可能被恶意破坏的通道时比如共享⽹络、中间人，该数据可能会在传输过程中被修改。

信息泄露：当敏感数据流经不被认为是完全可信的⽹络（如共享⽹络）时，该数据可能会泄露给⾮预期的接收者。

拒绝服务：数据流也可能是拒绝服务威胁的⽬标，通常表⽰为影响连接的事件，例如⽹络隔离事件或严重的数据包丢失，阻⽌⽤⼾与 API Gateway 通信。

2.2、确定优先级

    检查完威胁是否存在重复或者漏过的情况后，通过估算与影响相比的缓解成本来分高、中、低优先级，威胁发生的影响*可能性=风险程 度，OWASP Risk Rating Methodology提供类似于DREAD的风险判断方法。

3、我们要怎么做？确定威胁的优先级并选择缓解措施

    通过一些安全设计原则和最佳实践将⻛险缓解资源集中在特定服务的威胁上。采用一些基础的安全服务如AWS IAM、CLoudWatch Log、CloudTrail、SecurityHub、KMS、加密SDK等。

    如果不能解决，选择是减轻⻛险、接受⻛险或将两者结合起来。 如果由于缓解的成本或复杂性⽽⽆法合理缓解⻛险，那么接受⻛险是唯⼀的选择，无论风险大小时，接受风险要取得上级的审核，不同管理层对安全的态度是不一样的。

4、我们做得足够好吗？评估威胁建模过程的有效性

    威胁建模是一项“安全社交活动”，结尾通过以下问题思考威胁建模过程对组织的有效性：

    1、我们知道我们在做什么吗？--是否有合适的资源、工具、流程、文化来执行威胁建模？

    2、我们知道会出什么问题吗？--发现的威胁数量是否符合预期？发现的威胁是否⽐预期的更多、相同或更少？

    3、我们做了什么？--缓解措施是否充分缓解了发现的威胁？

    4、我们执行得好吗？--威胁建模过程是否可以改进？能否真正改进了“车辆登记功能”的安全性？今后是否会为其他功能模块进行威胁建模？

    总而言之，威胁建模是一项投资——在笔者看来，这是一项很好的投资，因为与以后发现威胁相比，在功能的设计阶段发现和缓解威胁可以降低缓解的相对成本。随着时间的推移，持续实施威胁建模也可能会改善组织的安全状况。

附录

威胁建模模板

1、威胁假设

2、威胁模型

参考资料

1. https://www.youtube.com/watch?v=Yt0PhyEdZXU&ab_channel=AdamShostack

2. https://github.com/adamshostack/4QuestionFrame

3. https://www.youtube.com/watch?v=GuhIefIGeuA&ab_channel=AWSEvents https://github.com/michenriksen/drawio-threatmodeling

4. https://owasp.org/www-community/Application_Threat_Modeling

5. https://owasp.org/www-community/OWASP_Risk_Rating_Methodology

前言

    随着 DevSecOps 概念的逐渐推广和云原生安全概念的快速普及，研发安全和操作环境安全现在已经变成了近两年行业非常热的词汇。在研发安全和应急响应的日常工作中，每天都会收到大量的安全风险信息，由于目前在系统研发的过程中，开源组件引入的比例越来越高，所以在开源软件治理层面需要投入很多精力。但是由于早期技术债的问题，很多企业内部在整个研发流程中对使用了哪些开源组件，这些开源组件可能存在严重的安全隐患等相关的问题几乎是没有任何能力去收敛，所以多年前的 SCA（Software Composition Analysis 软件成分分析）技术又重出江湖，变成了这一部分风险治理的神器。本文主要探讨的范围是利用 SCA 技术实现对开源组件风险治理相关能力的建设与落地。

    SCA 概念其实出现很久了，简单来说就是针对现有的软件系统生成粒度非常细的 SBOM（Software Bill of Materials 软件物料单）清单，然后通过风险数据去匹配有没有存在风险的组件被引用。目前市面上比较出色的商业产品有 Synopsys 的 Blackduck 、Snyk 的 SCA 、HP 的 Fortify SCA 等，开源产品有国内悬镜的 OpenSCA 。但是通过对这些产品的调研和分析后发现，这些产品由于诸如风险数据库完整度、与现有研发流程耦合程度、性能和社区支持不完整等原因，不能很好地融入企业内部的研发流程，但是这一部分能力在企业内部对于SDL工作而言又是不可或缺的能力。所以企业内部的信息安全团队需要结合业务团队的需求，安全团队自身对于风险的理解，企业内部的研发流程现状和现有的技术与数据能力、应用成本和 ROI 等现状和问题进行综合考虑，打造自己的 SCA 能力，从而帮助业务团队多快好省地解决软件供应链层面上的信息安全问题，安全团队也可以更好地对组件风险问题进行全局视角下的治理。从上面的内容大家也许听出来了，在企业内部建设 SCA 能力的过程中会涉及到很多的产品和运营方面的问题，诸如跨部门协作、系统稳定性、业务和安全部门对于风险的定义不一致等问题。本文主要介绍 SCA 能力在企业内部实际落地的过程、遇到的问题以及对 SCA 技术的看法和展望，旨在为业界提供一个可以参考的解决方案和范本。

安全视角下的研发风险

    在企业内部的信息安全团队看来，很多企业内部实际上在整个研发流程当中遇到的风险面实际上是蛮多的，通过对于各种攻击面的梳理和分析之后，实际上在研发流程中被经常提及的风险主要包含以下三类。

通用漏洞风险

    在组件安全层面上，首先遇到的问题，也是最容易发现的问题就是漏洞问题，造成的影响也十分直观，可以导致系统因为恶意的利用导致出现非预期的功能，进一步破坏系统的完整性和可用性。根据 2021 年 Synopsys 放出的软件供应链相关的数据显示，开源代码仓库中至少存在一个漏洞的仓库占整体开源仓库的比例从 2016 年的 67% 上升到了 84%，至少存在一个高危漏洞的代码仓库占全部仓库的比例从 2016 年的 53% 上升到了 60%，最高的时候是 2017 年，这一数字是 77%。

    而根据 2020 年 Snyk 发布的另一份开源组件与供应链安全的报告显示，漏洞的数量仍然需要提高警惕，XSS 漏洞仍然占据数量榜首，紧随其后的是命令执行类漏洞，这些漏洞会严重影响系统的稳定性。

    在上述所罗列出来的风险当中，当注意力集中到恶意包（Malicious Packages）上时，我们可以发现该类型的风险是 2019 年度上升幅度最快的威胁之一，这也引出了下面的问题。也就是软件供应链相关的风险。

供应链相关的风险

    开源组件的生产-构建-发布过程其实是与企业内部常规的系统研发上线的流程是一致的，简单来说可以抽象成下图中的样子：

    开源软件作者完成代码编写后 push 到源代码管理平台（GitHub、码云、Gitlab私服平台）等，然后在 CI/CD 平台上发起构建编译打包的流程，在这个过程中，CI/CD 平台会从组件依赖平台（Sonatype Nexus 私服或是 MVNRepository 官方源）上获取需要依赖的包，在 CI/CD 平台完成打包/镜像封装过程后，通过项目分发平台分发到生产环境上，更为现代的方法是直接拉取 Docker 镜像做部署，完成系统的上线。

    这个过程看似简单，但是实际上环节还是有不少的，我们把每个环节拆解来看，实际上每个环节都是会有很多风险的，如下图所示：

• IDE 插件投毒：为了更高效率地开发软件，开发人员往往会在自己的IDE当中引入各种各样的插件来提升自己的开发体验与效率。这个是一件非常正常的事情，但是往往软件开发人员没有足够的安全意识，导致自己的IDE中可能会安装了一些有问题的组件，甚至 IDE 本身也出现了供应链投毒的情况，这种 case 多到数不胜数，比较出名的是2021年5月份 Snyk 披露的一份安全报告中显示攻击者在 VSCode 的插件市场发起了投毒行为，一些有问题的扩展是“LaTeX Workshop”、“Rainbow Fart”、“在默认浏览器中打开”和“Instant Markdown”，所有这些有问题的扩展累计安装了大约 200 万次，此次事件所造成的影响是非常广泛的。
• 提交缺陷代码：在软件开发环节，开发人员因为水平、安全意识的诸多原因，往往会在开发过程中引入漏洞，这本身是一件十分正常的事情，但是对于开源软件而言，因为几乎是所有人都可以向开源项目提交代码，并且通过审核后就可以merge进项目，所以总会有不怀好意的人故意引入有问题的代码，比较典型的 case 是2021年4月，明尼苏达大学 Kangjie Lu 教授带领的研究团队因故意向 Linux 引入漏洞，导致整所大学被禁止参与 Linux 内核开发。除开道德问题，这种风险实际上有可能因为审核的疏忽导致风险直接被引入。
• 源代码平台被攻陷：其实 Git 平台本身由于保护不当，也有极大的概率被攻陷，虽然说攻陷GitHub这种平台本身不太现实，但是有很多开源项目都是自己搭设的Git平台，再加上一些众所周知的原因，Git平台本身缺乏保护是一件很大概率发生的事情，在2021年3月，PHP 的官方 Git 就遇到了类似的case，由于 PHP 官方 Git， PHP 团队在 git.php.net 服务器上维护的 php-src Git 仓库中被推送了两个恶意提交。攻击者在上游提交了一个神秘的改动，称其正在"修复排版"，假装这是一个小的排版更正，并且伪造签名，让人以为这些提交是由已知的 PHP 开发者和维护者 Rasmus Lerdorf 和 Nikita Popov 完成的。所以Git平台的安全保护本身也是需要提高重视的。
• 代码branch被篡改导致打包结果不一致：由于开源项目的 Git 仓库是向所有人开放的，有些攻击者会尝试新建不同的 branch 植入代码然后进行发布，这样虽然编译过后的包带有CI/CD平台的签名，但是仍旧会引发严重的安全隐患，早在2019年的 DEFCON 会议上，就有安全研究员就发现了WebMin的1.890在默认配置中存在了一个很严重的高危漏洞，1.882 到 1.921 版本的 WebMin 会受到该漏洞影响。但奇怪的是，从 GitHub 上下载的版本却未受到影响，影响范围仅限于从SourceForge下载的特定版本的WebMin，后来经过调查后发现，是代码仓库没有添加分支保护机制出现了问题，引发此类安全风险。
• CI/CD 体系被攻陷：在前面如果我们完成了代码完整性检测的话，如果流程没有被篡改或者构建平台运行正常，一般情况下出现问题的几率很低，但如果 CI/CD 平台和前面的 Git 一样被恶意篡改或是破坏，结果必定会出现安全隐患，SolarWind 事件就是由于这一原因导致的，攻击者在 CI/CD 过程中嵌入了后门，通过了签名校验，再通过 OTA 分发补丁之后导致出现了让人震惊的供应链攻击事件。
• 不安全组件引入：在依赖引入的过程中，如果引入了有问题的组件，则相当于引入了风险，这也是目前最典型的供应链攻击手段，通过我们对各个源的安全调查和分析后发现，投毒的重灾区在 Python 和 NodeJS 技术栈（一个原因是因为前端的挖矿已经很成熟，容易被黑产滥用，另外一个原因是Python的机器学习的库相当丰富，加上机器学习配套的计算环境性能强悍，导致挖矿的收益会比入侵普通IDC主机更高）。由于例子相当多，在这里就不一一列举了。
• 外部 CI/CD 流程构建：因为 CI/CD 平台有时候不能满足需求，或开发者出于其他因素考量，会使用非官方的 CI/CD 进行构建，而是自己上传打包好的 jar 或者 docker 镜像来部署，更有甚者会同时把打包工具链和源代码一起打包上传到容器实例，然后本地打包（极端情况下，有些“小可爱”的依赖仓库都是自己搭建的 Sonatype Nexus 源管理系统）。因为很多开源软件的使用者不会去做 CI/CD 的签名校验（比如说简单匹配下 hash），导致这类攻击时有发生。早在2008年的时候，亚利桑那大学的一个研究团队就对包括 APT、YUM 在内的 Linux 包管理平台进行了分析和研究，发现绝大多数源都不会对包进行校验，这些包随着分发，造成的安全问题也越来越广泛。
• 直接部署有问题的包：有些打包好的成品在使用的时候，因为没有做校验和检查，导致可能会部署一些有问题的包，最典型的例子是 Sonatype 之前披露的 Web-Broserify 包的事件，虽然这个包是使用了数百个合法软件开发的，但它会对收集目标系统的主机信息进行侦查，所以造成了相当大规模的影响。

过维护期的组件

    在实际的生产环境中，有很多的开发者使用的运行时版本、组件版本以及 CI/CD 平台版本都是已经很久未更新的。虽然说站在安全的角度上讲，我们希望所有的系统都用上最新版本的组件和中间件，但是事实情况是，基于业务自身的规划迭代、大版本改动较多容易引发兼容性问题导致升级迁移成本过高等诸多原因，使得落地这件事情就变的不是那么容易。为了让安全性和易用性达到平衡，企业内部往往会妥协到通过其他手段收敛攻击面并且建立旁路的感知体系，保证除了安全问题可以及时发现和止损。但是长久看来引入过时版本的组件会引发诸多问题：

• 维保问题：因为开源社区的人力和精力有限，往往只能维护几个比较主要的版本（类似于操作系统中的 LTS 版本，即 Long-Term Support，长期支持版本是有社区的长期支持的，但是非 LTS 版本则没有），所以一旦使用过时很久的版本，在安全更新这一部分就会出现严重的断层现象，如果出现了高危漏洞，官方不维护，要么就是自己编写补丁修复，要么就是升级版本达到长痛不如短痛的效果，要么就是像一颗定时炸弹一样放在那里，祈求攻击者或者蓝军的运气差一点。
• 安全基线不完整：随着信息安全技术的发展和内生安全的推动，版本越新的安全组件往往会 secure by design，让研发安全的要求贯穿整个研发设计流程。但是早期由于技术、思路、攻击面的局限性，这一部分工作往往做了跟没做一样。感触特别深的两个例子一个是前几年 APT 组织利用的一个 Office 的 0day 漏洞瞄准的是 Office 中一个年久失修的组件，这个组件可能根本连基本的 GS（栈保护）、DEP（数据区不可执行）、ASLR（内存地址随机化）等现代的代码安全缓解机制都没有应用。熟悉虚拟化漏洞挖掘的同学们可能知道 QEMU/KVM 环境中比较大的一个攻击面是QEMU模拟出来的驱动程序，因为QEMU/KVM 模拟的驱动很多都是老旧版本，所以会存在很多现代化的安全缓解技术没有应用到这些驱动上面的情况，从而引入了攻击面。其实在开源软件的使用过程中也存在类似的情况，我们统称为使用不具备完整安全基线的开源软件。
• 未通过严谨的安全测试：现在的很多开源组件提供商诸如Sonatype会在分发前进行一定程度的安全检测，但是时间越早，检测的范围越小，换句话说就是，组件越老出现的问题越多。毕竟之前不像现在一样有好用的安全产品和安全思路，甚至开发的流程也没有嵌入安全要求。而这样就会导致很多时候新发布的版本在修复了一个漏洞的同时又引入了一个更大的漏洞，导致风险越来越大，越来越不可控。

    综上，在安全团队的视角看来，风险无处不在。但是在一个非安全业务的安全公司，往往业务对于风险的理解和要求与安全团队可能大相迳庭。

业务视角下的安全研发风险

    实际上在业务同学看来，他们也十分重视信息安全的相关工作，有些公司的业务技术团队甚至成立了专门的安全团队来协助研发同学处理安全相关的问题。可见业务不是排斥甚至抵制安全工作，而是缺乏合理化和可操作的安全指导，导致业务同学不知道我们有什么风险。在实际的组件风险修复过程中，我们也收到了很多业务同学的反馈和吐槽。总结起来有以下几种情况：

• 兼容性问题：在推动以版本升级为主要收敛手段的风险修复中，业务提出最多的质疑往往是兼容性问题，毕竟稳定性对于业务是非常重要的，所以一般情况下我们在推动升级的时候，往往会推送安全稳妥且稳定性最高的修复版本，作为主要的升级版本。但这种问题不是个例，每次遇到此类型推修的时候，业务都会问到类似问题。考虑到本文篇幅原因，这里就不展开讲具体的策略和方法。
• 安全版本的问题：和上一个问题类似，业务同学在引入组件的时候往往也会考虑安全性问题，但业务同学由于缺乏很多安全知识，导致自己对于“安全版本“的判断会有一定出入，所以业务同学会把这个问题抛给安全同学。但是安全团队也不能100%正确回答这个问题，因为开源组件这么多，我们不能像 Google、微软这种财大气粗的公司一样把市面上所有的组件安全性全都分析一遍，所以一般只能现用现查。这一来一去，会拉低这一部分的质量和效率。所以这一部分的需求也是重要且很急迫的。
• 追求“绝对安全”：有些业务同学会直接问你，我到底该怎么干，我才能安全地用各种组件？话虽直接，但是能够体现出背后的问题——安全的尺度和评价标准不够透明。提升安全的可量化并且追求标准透明也是非常急迫的，考虑到这是一个运营的问题，在此就不展开叙述了。
• 合规问题：很多业务会不了解开源协议导致不小心违反了开源协议的约束，引发法务问题。

    从实际情况来看，业务同学并不是不想做安全，很多时候是缺乏一个有效的机制，告诉他们引入的软件依赖是否安全，需要完成那些操作和配置才能让开源组件用着安全。作为安全工程师而言，我们需要站在业务的立场上去设身处地想想，这些问题是不是真的不能被解决。由于业务和安全双方都有关于组件安全相关的需求，恰好 SCA 这项技术可以很好地满足业务和自身的需求，所以在整个 SCA 建设的过程中，我们需要不断去挖掘这些需求。

SCA 建设的过程

    SCA 其实并不是一项很先进的技术，只是在现代的研发过程中随着流程的标准化、组件的丰富化、开源社区的活跃以及开发成本的降低等诸多原因，使得一个项目中纯自己写的代码占整个项目中全部代码的比例越来越低了。也就意味着供应链的问题产生的影响会越来越大，随着 DevSecOps 的火爆，重新带火了 SCA 这一传统的技术。

    根据很多企业内部的实践以及业界对于 SCA 技术的理解，我们认为 SCA 比较核心的功能有以下几点：

• 软件资产的透视：企业内部需要对所有的应用系统引用了哪些组件这件事情有着非常清晰的认知，在考虑尽量多的情况下覆盖绝大多数的场景（业务应用系统、Hadoop 作业等数据服务、Puppet 等运维服务等），并且研究他们的开发流程，分析哪些阶段可以引入 SCA 能力做风险发现。
• 风险数据的发现：现在是一个数据爆炸的时代，安全团队每天需要关注的安全风险信息来源五花八门，但是需要尽可能多地去收集风险相关的数据，并且做上下文整合，使之可以自动化和半自动化地运营起来。但仔细想一下，除了追求风险数量，能否更进一步追求更强的实效性，达到先发制人的效果？通过企业内部多年的安全威胁情报能力建设，同时追求实效性和可用性的双重SLA是可行的。除此之外，需要关注的风险不能仅仅局限于漏洞和投毒这两个场景，还需要对开源软件的基线信息也进行收集。
• 风险与资产关联基础设施的建设：以上的两个方向是在数据维度的需求，考虑 SCA 落地不单单是信息安全部门的事情，实际落地过程中需要与业务自己的质量效率团队、运维团队建立良性的互动机制，让安全能力深入到业务，所以需要建设相关的基础设施去实现核心API能力的建设，对业务赋能。虽然听上去很简单，但实际上开发的东西可能是 UDF 函数，也可能是某些分析服务的插件，甚至可能是CEP（Complex Event Process复杂事件处理，一种应用于实时计算的分析技术）的规则。
• 可视化相关需求：既然有了风险，安全团队及业务相关团队的同学除了自己知道之外，还需要让负责系统开发相关同学也知道风险的存在，并且要及时给出解决方案，指导业务完成修复，同时安全团队也需要通过获取运营数据知道风险的修复进度。

    正所谓罗马不是一日建成的，虽然现在确定了 SCA 建设需求和建设的方向，但是落地起来的话仍然需要分阶段完成。正如建设其他的安全子系统一样，安全团队需要按照从基础数据/SOP 建设到平台化系统化的建设来完成整个 SCA 能力的落地。所以在实际操作过程中，应该将整体建设分成三个阶段进行：

第一阶段：数据盘点与收集，在项目建设前期，信息安全团队应当和企业内部的基础架构相关的团队，完成企业内部基础组件的数据资产盘点，旨在从基础技术和信息安全的视角实现对研发技术栈、研发流程链路的摸排，在合适的位置进行数据卡点获取相关数据，完成对资产数据的采集。另一方面，信息安全部门在现有的威胁情报经验和数据上，对组件数据进行数据封装和整合，建立一个单独的开源组件风险数据库，旨在收集来自于全量互联网上披露的风险，方便与后面的资产数据进行联动。

第二阶段：SOP（Standard Operating Procedure，标准运营流程）和概念验证建设，信息安全团队通过自己的漏洞修复经验进行SOP的固化，通过不断地调优，完成一个通用的漏洞修复 SOP，通过实际的演练和概念验证（PoC，即Proof-of-Concept）证明该 SOP 可以在现有的技术条件下很好地完成风险修复这一部分工作。同时结合 SOP，对之前收集的资产数据和风险数据进行查漏补缺，完成对数据和数据链路的校验工作，保证系统高可用。在这个阶段，SCA 的服务提供方需要开放部分的核心API给部分业务的质量效率团队，帮助进行测试并收集使用反馈，让其融入自己的风险治理环节。

第三阶段：平台化及配套稳定工作的建设：当 SOP 初步成型并且完成了概念验证之后，应当需要建设对应的平台和子系统，让这一部分工作脱离手动统计，使其接近 100% 线上化。得益于内部 SOC 的模块化设计，可以在现有的平台上轻松构建出 SCA 相关的子系统，完成能力的数据。针对终端用户可视化风险这一问题，SCA 子系统会提供核心的 APIs 给面向研发同学端的 SOC 平台完成风险信息的同步。为了保证服务的高可用，后续还会建设配套的数据链路检查机制，不断完善数据可用性。

    一些比较重要的工作如上图所示。三个阶段完成之后，SCA 的能力大概就建设好了，但在建设过程中，安全团队需要考虑很多东西。笔者个人认为如果说安全厂商的安全产品和服务可以被认为是问题解决的分子的话，甲方安全团队的工作更多的是做大做全分母，要把各种情况都考虑面面俱到，才能保证风险不被遗漏。

    首先来说在资产建设方面，企业内部的安全团队、质量效率团队以及数据平台团队等存在研发流程的技术团队，需要配合完成自己所辖的 CI/CD 系统数据和数据服务构建数据的采集工作，同时也在为IDE插件团队提供了 SCA 的 API，完成了从代码开发环节到应用上线环节的数据采集。但是我们在应用这一部分数据之后发现了很多问题，除开数据本身质量和准确度不谈（不谈不代表重要，相反这一部分很重要，后面会介绍这一部分），按照前面提到的场景，还会有很多额外场景，比如说业务在灰度了一部分之后就忘掉了还没灰度完，导致一个服务下面只修复了一部分机器，再比如有很多的“小可爱”会绕过企业本身的 CI/CD 流程进行部署操作（有些甚至还是自己人）。为了考虑到这些额外的情况，我们应该从主机的粒度重新考虑这件事情，也就是说通过主机实例（docker容器、虚拟机、物理机）本地的 HIDS agent ，完成文件信息、进程信息、环境变量、shell-log 等信息的分析，确定主机实例修复完毕了。这样我们就建立了一个构建链路-主机维度的数据正反校验机制，理论上讲主机端 HIDS agent 覆盖度和存活率都达标的话，我们几乎可以得到一份详细的软件资产的数据（当然数据不准、延迟这些问题是肯定还会有的），详细的落地核心工程和结构关系看下图：

    在数据确定覆盖的差不多的时候，我们需要通过数据总线传递给数据仓库和计算引擎，完成数据的交叉和分析工作，得出的结果便是存在哪些风险和风险进度。在这里实时引擎一方面需要承担增量资产数据的分析，另一方面也会保存很多聚合的 CEP 规则进行分析。离线引擎则是完成存量风险的周期性发现和治理工作。

    讨论完资产数据的采集之后，我们来谈论风险数据的收集。早在威胁情报体系化建设阶段，组件漏洞情报就作为基础安全情报应用场景下漏洞情报的一个子集一直存在，但由于之前局限于“漏洞=风险”的观念，导致实际执行过程中只存放了组件漏洞相关的风险信息，在综合评估完现有的需求和实际情况之后，发现当前组件漏洞数据，只能承担一部分研发安全风险的治理工作，而像对于供应链投毒、开源组件基线情况等其他类型的风险数据，由于当时还没有数据能够提供成熟的能力输出给业务方使用，经历过充分的讨论和调研之后，决定将组件相关的漏洞数据独立出来，并且新增采集供应链安全的其他风险数据，重新建立一个组件安全相关的数据库，完成风险数据的存储和应用。通过结合自身威胁情报的实践和业界关于组件风险收集的最佳实践来看，打算从5个维度实现对组件相关的风险进行收集和存储：

• NVD/CNVD/GitHub-GHSA 等通用漏洞数据库：这个是基本操作，旨在收集漏洞风险，结合漏洞实际情况进行人工和研判。
• 开源组件提供商的 Jira、Commit、Release 和 Bugzilia 等 Pull-Request 相关的数据：通过获取相关的数据，结合自研的 NLP（Natural Language Process，自然语言分析）分析引擎对内容进行倾向性判断，过滤并输出安全相关的信息，然后组织人工或自动化研判，通过实践发现可以大幅度提前发现风险（笔者在 ISC2019 上曾经阐述过风险发现前置的必要性和落地经验）。
• 组件专用风险库：经过我们对于漏洞数据相关的调研，诸如 Github 和 Snyk 这些机构会有专门的组件风险库对外提供，通过获取并分析这些信息，经过加工后可以得到可用性极高的组件风险库，可按需研判。
• 软件风险相关的新闻资讯和 RSS 订阅：这类源主要是解决 0day 和被 APT 组织在野利用等特殊披露的漏洞，同 Pull-Request 数据一样，该类型的绝大部分风险数据都是需要通过NLP分析引擎进行情报数据分析，进一步进行情感推断后才达到可用标准。
• 手动录入：也是常规操作，虽然采集了很多类型的风险，但的确受限于供应链攻击的多种多样和发展，所以不可能考虑的面面俱到，所以仍旧需要手动接口补充需要运营的风险。但安全团队仍希望将手动录入的风险占全部风险的比例，控制到一个合理的范围，保证这部分能力不会因为运营人员的问题（如经验不足、离职等）而导致能力的闪崩性缺失。

    通过上面的信息，我们发现这里面绝大部分数据都是非结构化的，换句话说就是不可以直接拿来使用，需要处理（异构数据、自然语言数据）后才可以使用，所以我们在处理时会引入 NLP 分析引擎并且对漏洞风险数据打标后（主要工作是添加 RepoID 用来和资产数据联动），才可以向下传递给数据引擎和 APIs 。（从威胁情报数据建设的角度来看，2019 年前后，基础安全相关的威胁情报实现了结构情报和非结构情报约为 1:1 ，现在非结构的情报数据远高于结构化的情报数据，这也越来越接近于设计的目标），具体的落地核心工作内容和关系结构如下图所示：

    在风险信息处置环节，实时计算引擎和离线引擎的作用与资产数据处理的时候是一致的，主要解决增量和存量的问题。同时考虑到业务自身会有自助排查风险的需求，SCA 平台也会提供一些核心的 APIs 给业务方。

    在开始着手建设这些数据相关的基础设施时，需要提出一些建设指标，防止一些关键的功能因为平台本身的问题，导致服务大规模不可用。在资产方面，目前资产数据库的基础设施可以支持 TB 级别资产数据的检索能力，返回时间不超过 100 毫秒；而在风险数据建设方面，目前覆盖了共计 10 个技术栈（包含主流的 Maven/Gradle、PyPi、NPM、SPM、APT/Yum、CocoaPods 在内）共计约 59 万条风险数据，更新周期在两小时以内，通过计算引擎可以和资产数据进行快速匹配，节省了将近 95% 的受影响资产排查时间，大大提升了运营效率。

    在匹配规则建设方面，因为数据来源较多且杂乱，通过自研的NLP分析引擎进行大规模的训练和处理数据之后，可以统一到一个比较固定的数据结构里面，在打标处理后可以实现和资产数据的高效联动。鉴于 NLP 模型的训练过程和训练方法不属于 SCA 建设过程中比较重要的技术，所以本文中不会展开叙述详细的训练过程和情感推断训练过程。除了资产信息关联之外，风险数据库可以同时实现对 CVSS（即 Common Vulnerability Scoring System，即通用脆弱性评分系统）的匹配，及时推送满足 CVSS 影响范围（这里不是指 CVSS 分数，而是指 CVSS 的描述表达式）的漏洞信息，提醒安全运营的同学关注相关风险并及时进行研判。

    对于风险的基线数据，目前基线建设数据没有一个相对完整的参考标准，但是 Google 推动成立的 OpenSSF基金会（Open Source Security Foundation，在 Google 等互联网企业和美国政府的推动下成立的开源组件安全基金会）在 2021 年下旬发布的 ScoreCard 功能是一个很好的参考标准，结合同样是 OpenSSF 推出的 AllStar 基线检测工具，可以完美补充组件基线相关的数据。

SCA 建设中遇到的问题

    在 SCA 建设过程中，实际上并不是一帆风顺的，总结一下困难的地方，有以下几个方面：

• 漏洞-资产关联规则缺乏一个成熟且有效的行业标准：在 SCA 领域，目前没有一个成熟的可以匹敌 NVD 相关的生态环境，在 NVD 体系下，有用来描述漏洞信息的 CVE ，有描述资产影响范围的 CPE（Common Product Enumunation），有描述攻击路径的 CAPEC（Common Attack Pattern Enumeration and Classification），还有描述风险类型的 CWE（Common Weakness Enumunation），但是在组件安全领域，由于各家公司的基础设施建设成熟度和技术选型差异巨大，所以没有一个可用的完整生态可以做到开箱即用，所以我们需要基于现有的技术架构和基础设施来设计自己的规则，同时推广这套标准在安全运营工作中落地。
• 数据质量与数据链路的可靠性：数据质量和可用问题是自打立项开始一直到后期运营都会出现的问题，问题可能来自于上游采集逻辑不完备或采集错了的原因，还有数据链路不稳定导致写入计算引擎出现大批量丢失的问题，还有数据链路没有检查机制导致不知道具体问题出在哪里，甚至由于使用的数据分析技术栈的原因，导致打过来的数据是错乱的，错乱的数据有可能会影响CEP规则的准确性和有效性。这当中的有些问题不是偶发的，甚至有些问题是在真实应用的场景下仍旧会高频出现，所以建立一个长效的数据拨测机制和数据污点追踪能力是必要且必须的。
• 风险数据的数据结构与准确度：由于在风险数据中引入了过多的来源，且大量引入了机器学习和NLP技术把非结构化数据转换成结构化数据，考虑到模型训练的精度、训练样本数据、训练网络等问题，导致平台提取出来的漏洞信息很多时候会有一定的出入，并且由于风险情报数据比较依赖上下文和实效性，所以需要在各方面做取舍，这个问题其实和数据的问题一样，不是一朝一夕能解决的，需要大量的实践运营和拨测机制case by case地去推动解决。
• CI/CD管制与非标准资产的治理：这一方面实际上与 SCA 落地的关系不是很大，但是拿出来的原因是 SCA 本身是一个需要强关联研发流程的能力，好的 SCA 平台除了可以提供标准化的APIs和GUI让用户快捷操作，同时也需要兼容非标准的发布流程和上线标准，这就是为什么除了主要的几个技术栈之外仍旧覆盖了一些偏小众的技术栈，如C#/Powershell的NuGet、ErLang的Hex包管管理等。
• 资产透视深度：这一部分其实是 SCA 核心能力的体现，从理论上讲，SCA 是有能力分析诸如FatJar这种开源组件嵌套的jar包，但实际上受制于数据质量和技术能力，往往无法分析到一个非常细的粒度，所以这一部分需要去设计一个MTI（maximum tolerate index在这里表示可接受的最粗分析粒度）指标去指导相关的设计。

SCA 技术未来的展望

    在建设过程中，我们参考了很多公司和商业产品对于组件风险分析和治理的最佳实践，翻阅了大量与软件成分分析技术以及软件供应链安全治理相关的论文文献、公开的专利以及企业的博客。其中 OpenSSF 基金会的一些研究成果让人印象深刻。在2021年6月份 OpenSSF 发布 SLSA （Supply chain Levels for Software Artifacts，即软件供应链安全等级）之后，围绕 SLSA 这一套标准陆续发布了很多有助于我们分析的数据服务和产品，比如准 SCA 产品 Open Source Insight，漏洞风险库 OSV（Open Source Vulnerabilities，开源组件风险数据），软件安全基线检查工具 AllStar 和 ScoreCard，开源组件风险奖励计划 SOS Rewards（可以理解为是开源组件的漏洞奖励计划）。可以初步看到未来 SCA 的建设路线一定是三个方向：追求足够细粒度的资产和风险透视能力，风险的主动识别能力和开源软件的基线检查能力。换句话说，SCA如果想做到足够有效，需要覆盖从软件开发到上线的所有环节，包括代码完整性、流程完整性和基线巡检功能，都会需要 SCA 的核心能力。

    除了 SCA 提供的风险透视能力，在整个DevSecOps环节，安全团队、质量效率团队、运维团队和业务团队需要非常默契的配合，大家各司其职共同解决研发方面的风险，在这其中，安全团队能够提供的，除了风险数据和修复建议之外，还需要提供一些对应的基础设施帮助业务团队更高效地处置风险。扩展到整个开源软件风险治理方面，也可以给大家一个 cheatsheet 做参考。

    当然想要做到以上所有的项目，实际上对于企业的基础架构和基础设施有一定的要求，但好在目前开源社区对于供应链安全治理提供了一些安全的解决方案，诸如国外由 OpenSSF 或者商业公司牵头设计开发的一系列工具链，如 ChainGuard.dev，SigStore，Anchore 等，当然国内也有很多优秀的开源解决方案。可以在进行一定修改之后，集成到现有的基础架构中。

    考虑到安全的对抗属性在里面，SCA 工具如果融合进企业内的研发流程中，必然会引发很多对抗 SCA 检测的路子，况且在调研过程和实际处置过程中，绕过固有研发流程的情况是比较常见的，所以后续在继续建设 SCA 能力的过程中会逐步加入对抗的检测和加固，防止漏网之鱼。

结语

    以上为在整个 SCA 能力建设过程中的一些想法和实践，在建设 SCA 能力的过程中，通过与各团队的协同工作和沟通，了解了很多业务对于组件安全方面的想法和真实需求，通过需求得出需要建设的能力，在技术方案落地中，企业内部部署的很多安全产品，诸如HIDS Agent和RASP等，可以从主机的角度去反向验证建设的过程是否正确。SCA 能力的落地离不开安全团队与业务团队的配合。实际上在 SCA 的建设过程中，我们如果再往更深层次去看，会发现诸如闭源软件、开源软件的跨架构、跨编译器的识别、其他载体（比如容器镜像、软件成品）的安全分析等，这些技术挑战对于实际企业内落地 SCA 能力而言还是蛮高的，考虑到目前的解决方案还停留在 PoC 阶段，故不在本文中提及。

    如果抛开整个落地的过程，考虑到各家在基础设施、核心技术栈、主机信息监控能力的参差不齐，所以必定会有不能落地的地方。而站在安全服务提供商的角度上看，SCA 相关的产品未来建设的过程中可能需要更加轻量化和开放协同化。所谓轻量化，是指产品的核心功能可以在脱离基础设施多种多样的前提下，能够稳定高效的去提供核心能力，做到很好地与客户的研发流程完美衔接，从调研结果来看，目前市面上所有的 SCA 产品，基本上都存在一个架构设计比较重的问题，不能很好去融入现有的CI/CD流程。所谓开放协同化是指，可以通过多种方式去和其他的安全产品和安全能力提供数据的共享机制，实现与其他安全设备在数据上的联动，互相补齐对应的风险发现能力，做到简洁和高效。

    以上是我们对 SCA 能力建设过程当中的想法。从长远的角度看，我们是希望从源端建立起一套完整的零信任供应链风险管控体系，覆盖从引入-开发-编译-部署-使用的全生命流程，做到真正意义上的 secure-by-default，从纵向来看，我们需要在研发流程的框架下尽可能全的理清整个系统的 SBOM 级的数据依赖情况，同时从横向来看，我们还需要保证目前收集到的组件相关的风险数据和极限数据所覆盖的技术栈足够的全面和准确。恰好这两部分能力是 SCA 能力中比较核心的两个能力，也就说明了 SCA 能力这是这一体系当中比较重要的一环，可以为整个体系提供一套完整的知识库，为后续供应链风险检测逻辑提供一套完整的数据。最后，特别感谢质量效率团队、基础技术团队、到店事业群技术部餐饮的测试团队在整个 SCA 能力建设过程中提供帮助和建议。

    如有兴趣探讨，可联系 美团SRC 运营同学索要原作者的微信，可以继续讨论。

参考文献

• https://www.gartner.com/reviews/market/software-composition-analysis-sca
• https://snyk.io/blog/visual-studio-code-extension-security-vulnerabilities-deep-dive/
• https://www.reddit.com/r/HobbyDrama/comments/nku6bt/kernel_development_that_time_linux_banned_the/
• https://www.bleepingcomputer.com/news/security/phps-git-server-hacked-to-add-backdoors-to-php-source-code/
• https://portswigger.net/daily-swig/webmin-backdoor-blamed-on-software-supply-chain-breach
• https://www.mandiant.com/resources/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor
• https://blog.sonatype.com/open-source-software-is-under-attack-new-event-stream-hack-is-latest-proof
• https://www.cs.arizona.edu/sites/default/files/TR07-02.pdf
• https://www.microsoft.com/security/blog/2020/07/20/open-source-security-managing-risk-software-composition-analysis/
• https://www.microsoft.com/security/blog/2020/01/16/introducing-microsoft-application-inspector/
• https://csrc.nist.gov/CSRC/media/Projects/cyber-supply-chain-risk-management/documents/C-SCRM_Fact_Sheet_Draft_May_25.pdf
• http://go.anchore.com/rs/603-AEB-887/images/Anchore%20Software%20Bill%20of%20Materials%202021.pdf?mkt_tok=NjAzLUFFQi04ODcAAAGD5M9YCkwNcfKEavmNJ2xAVSBbU6YN6NBY7Er1PH6DD81eqWLXigqRla69Zy3jJFDbhLmPe4t4iMiTwcOm648mXy2ytLVplQi5Tg0tIQ
• https://csrc.nist.gov/Projects/cyber-supply-chain-risk-management
• https://opensource.googleblog.com/2021/06/introducing-open-source-insights-project.html
• https://security.googleblog.com/2021/06/announcing-unified-vulnerability-schema.html
• https://www.techrepublic.com/article/google-stakes-new-secure-open-source-rewards-program-for-developers-with-1m-seed-money/
• https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html
• https://cloud.google.com/docs/security/binary-authorization-for-borg
• https://research.google/pubs/pub49962/
• https://security.googleblog.com/2021/08/allstar-continuous-security-policy.html
• https://therecord.media/google-open-sources-allstar-a-tool-to-protect-github-repos/
• https://security.googleblog.com/2021/07/measuring-security-risks-in-open-source.html
• https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html
• https://snyk.io/open-source-security/
• https://github.com/CycloneDX/specification
• https://blog.chainguard.dev/4-key-sigstore-takeaways-recap-of-twitter-space-with-kelsey-hightower/
• https://blog.chainguard.dev/slsa-vs-software-supply-chain-attacks/
• https://www.whitesourcesoftware.com/resources/research-reports/the-state-of-open-source-vulnerabilities/
• http://oss.x-lab.info/github-insight-report-2020-en.pdf
• https://www.sonatype.com/resources/white-paper-state-of-the-software-supply-chain-2020
• https://www.trustar.co/blog/making-sense-of-unstructured-data-using-nlp
• https://github.com/XmirrorSecurity/OpenSCA-cli
• https://github.com/murphysecurity/murphysec-jetbrains-plugin
• https://patents.google.com/patent/US8627270B2
• https://patents.google.com/patent/US8473894B2
• https://patents.google.com/patent/US9141378B2
• https://medium.com/sigstore

首家网络安全主题博物馆

    为了传播和发展网络安全行业文化，“网络安全博物馆”微信小程序于2022年3月28日上线试运营。

    今后，作为首家专注于网络安全的线上博物馆，将以端正客观，详实准确的态度为读者们展示广大安全从业者数十年间在网络安全行业艰苦创业，呕心沥血的奋斗历史。

    重点通过图文讲解的形式介绍在数据安全、关键信息基础设施安全、新兴领域安全、产业安全等领域的蓬勃发展历程。

    长按下方图片、扫描二维码或者搜索微信小程序 “网络安全博物馆” 即可体验，敬请关注！

“网络安全博物馆”小程序功能介绍

小程序目前提供的展馆主题有：

主题展览：介绍网络安全行业发展的阶段性进展；

代码考古：展示有颠覆性影响的经典恶意病毒，安全防护软件的经典代码或者漏洞演示；

安全人物：专栏通过人物简历的方式，讲解国内外网络安全行业的传奇人物；

历史上的今天：每天不定期更新“历史上的今天”所发生的代表性安全事件；

公众号：以微信公众号《安全乐观主义》提供统一客户服务功能；

预约讲解：以专职导游（也就是作者我一个人，哈哈）形式，在预约成功后可通过微信语音讲解一起畅游参加安全专题活动。

首页截图

    博物馆内容还在不断充实丰富中，欢迎有兴趣参与贡献的读者们联系我，大家共建内容社区~

• 如何设定合理的安全工作指标

• 1. 指标和愿景、目标的联系

• 2. 指标要有明确的价值

• 3. 指标匹配现阶段工作重心

• 4. 指标要同整体规划一致

• 5. 指标必须是可衡量的

• 6. 指标要有反向验证手段

• 7. 指标并不一定要达成

• 8. 最重要的是指标要说人话

• 参考资料

如何设定合理的安全工作指标

  你和你的团队是做什么的？产出是什么？实现路线是什么？怎么衡量做的好和坏？你在朝着什么方向前进？

  设定指标能规划工作，衡量进展，防止出现工作偏差，但在年初工作中怎么制定一个合理的指标体系是个颇为头疼的事情，笔者以安全行业的特点做了一些阐述，希望可以同广大读者一起探讨交流。

1. 指标和愿景、目标的关系

    愿景是团队的长期希望，为了实现伟大的愿景拆分了具体目标，达成目标需要用指标对各个子任务进行拆解量化产出。  

    目标往往是一个预期结果，不是有效的指标，指标对了目标是自然会达成的，单独统计目标没有价值。不要将目标等同于指标。  

  愿景和目标是指出工作的整体的方向，而且愿景和目标在指标统计周期并不一定会达成。如果首先混淆了愿景、目标和指标三者的关系，那么指标设定的逻辑出发点就会被质疑，接下来思考都是错的。

  举个例子，Google安全的整体愿景是"让用户使用互联网更安全"，Google Project Zero的目标是"让攻击者更难发现和利用安全漏洞"，那么具体团队的技术指标会是高危漏洞发现数，修复率、平均修复时间、漏洞挖掘产品覆盖率等。Google Project Zero设定的量化指标不会包含"攻击者漏洞利用时间和成本是否增加"这一项。

  再举个例子，如果安全团队的愿景是"做国内领先的安全团队"，目标是"不出现颠覆性的安全风险"，指标应该是完成Hvv任务、严重安全漏洞及时止损、规则覆盖率xx%等。当然团队的目标也可以设定为"顺利完成hvv任务"，那么也可以有对应的细分指标为这个目标服务，而不是直接将"顺利完成hvv任务"放在指标项中。

2. 每个指标都有明确的价值

  指标的设定以目标为前提，必须以明确的结果为导向，而不是描述过程行为，指标"以终为始"，做正确的事，而不是正确的做事。

  比如在设定指标要有明确有达成、改善、降低、提升的判断，而不是使用解决、参与、负责、上线，覆盖这样的模糊的、过程性的描述字眼。

  比如一项指标的是"第三方组件扫描率80%"，完成了又如何呢？那你应该达到多少呢？为什么不是79%，为什么不是81%呢？这件事的意义应该是"引入开源组件风险得到显著降低"，一定要说清指标背后带来的安全效果。

3. 指标匹配现阶段的工作重心

  为了体现技术和专业能力在不同时期的提升，指标在不同场景下要侧重实际状况。

  同一个安全工作，从分工方面要区分安全开发、安全治理、安全运维等侧重点，做运营的指标不要和做开发的指标放在一起，虽然大家是为了处理一样的安全风险。

  同一个安全工作，指标要和不同发展阶段的工作相结合：刚起步的工作在于调查研究，摸清状况，探索实践；常态化运营的工作在于优化流程，保证效果，数据积累。切忌贪大求全眉毛胡子一把抓最后都做不完。

  同一个安全工作，对于不同职能团队是有倾斜的。比如常用的一个指标--漏洞修复延期率，实际情况是业务不修你也没有办法，业务团队的指标不包括你的安全业绩，这时候要把和业务相关的和安全自己做的事情拆分开来，不然写个你基本无法掌控的一个指标，没法对结果负责。

4. 指标要同整体规划一致

  各小团队的指标导向要为整体大目标服务。如果今年安全部门的战略是"迁移上云的安全防护"，那么工作重心要向云相关的整体指标倾斜。如果主题是"降本增效"，那么要体现通过技术实现能效提升等关键动作。

  举个反向的例子，如果部门的目标是"尽快搭建安全团队，完成安全防护"，你的指标里却有一项是"节约xx成本"，谁让你省钱来着？？！这是个与规划背离的指标。

5. 指标必须是可衡量的

  将安全作为一门科学，有量化才能有改进。"好"，"坏"，"高中低","达成"都是虚词，指标要有数据量化，可是有些指标确实难以量化怎么办呢？把不能量化的量化也是一种能力。运营型的通过合理的周、月、季度周期自动化统计，建设型的通过项目管理指标量化。

  量化的分子分母要准确，分母找全才能说明结果的正确性。举个简单的例子：职场电脑杀毒软件覆盖率100%，看起来挺好的，但是细问起来这里的职场是否包括外包场地？答案是没包括，为什么没包括？没意识到或者没法统计，这样就因为视野盲区设定了一个虚假的分母，对完成工作是有损害的。

  量化不仅仅需要百分比，也需要绝对数量。举个例子：WAF的接入率为100%，但是实际只有10个域名接入了，其他域名排除在计划中，如果这里分母实际是公司的全量域名才比较合理。

6. 指标尽量有反向验证手段

  通过寻找反向指标来验证事情做得好和坏。反向指标有时候很难找到，找不到就算了，在寻找反向指标的时候可以加深对做事的理解。

  举个例子:SDL团队的漏洞发现率应该和SRC运营的外部漏洞提交数互为反向指标。如果SRC没有高危漏洞提交，不能说明漏洞扫描修复做得好，也许是运营投入不给力，吸引不到优秀的黑客发现风险。反过来如果SRC收到了大量的高危漏洞，并不能说明SRC运营给力，而是SDL没有关注此类风险。

  一个比较极端的例子是，安全讲师要达成"安全意识考试合格率"，那么蓝军要有"经过培训后攻击成功率"指标，显示经过安全培训的人员，仍然可以被蓝军用高超的社工技术欺骗。这个案例太卷了现实估计没有，本质是为了剖析真实的原因，持续改进团队整体工作。

  寻找反向指标时一个常见的错误是采取同一个团队的同一份数据源。比如做弱口令治理，用hydra通过采集的密码字典收敛弱口令，设定修复率100%。这个合理的反向指标不能选取未来hydra还能不能复查出来，要换个技术手段，比如域控弱口令审计策略、红蓝演练之类的数据源。

7. 指标并不一定要达成

  不论是OKR还是KPI，指标的锚点是目标，目标一般采取SMART原则--Specific（明确）、Measurable（可衡量）、Achievable（可达成）、Relevant（相关）和Time-bound（有时限）制定。本身已经涵盖设定有挑战的的目标，如果指标都轻易达成了，说明当初目标设定不合理-过低或者过高。指标完不成也是正常的。

  当然实际情况是在绩效考核的时候，你能达成就更好了，可以在指标模板加一列标注该指标属于承诺型还是期望型。

8. 最重要的是指标要说人话

  如果一件事情不能简单说清楚，那么说明你没有想清楚。我们制定的指标看起来要有审美的能力，衡量指标好坏的标准在于是否优雅简洁。花里胡哨列了复杂的数学统计公式不是做数学题，拿出来一两个关键指标就行，其他的都是辅助数据说明逻辑正确。

  说人话的另一个好处是指标并不仅仅给技术同学看，给CISO、合作方汇报的时候，可以清晰明白安全整体是什么水位，重点在关注什么。

参考资料

• https://googleprojectzero.blogspot.com/2022/02/a-walk-through-project-zero-metrics.html
• http://www.woshipm.com/pmd/67599.html
• https://vipread.com/library/item/2610/%e5%ae%89%e5%85%a8%e5%ba%a6%e9%87%8f%ef%bc%9a%e6%9e%84%e5%bb%ba%e4%bc%81%e4%b8%9a%e5%ae%89%e5%85%a8%e8%af%84%e4%bb%b7%e4%bd%93%e7%b3%bb%e4%b9%8b%e8%b7%af

• 什么是互联网革命下的新型工人阶级

• 技术加速社会的隐忧

• 技术和资本的双重剥削

• 技术并不等同于生产力

• 远程工作是典型案例

• 技术工人既关注技术，也关注人

• 技术工人宣言

• 行动策略：警惕-认识-对抗-改变

• 结语

    随着全球经济进入结构化调整的转型期，普惠式的红利已经逐步消退，需求和资源之间的紧张引发的内卷焦虑等社会问题加剧，产业工人应正确对待增长的社会成本和心理压力，提升自我修养。

互联网革命下的新型工人阶级

    大约在18世纪之后，社会经过了工业革命和政治革命的洗礼，大量的农村富余劳动力从农村转移到城市，而二战后的互联网革命产生大量科技创新资源被资本掌握，行业工人迫于生存，又被从二三线城市驱使转移到新一线和头部城市，委身于垄断性的巨头，与数字经济飞速发展相对的是一系列棘手的新型问题不断浮出水面。

    近年来在新时代互联网农民工群体爆发了996.icu项目、消极“躺平”反抗内卷、灵活就业人员对劳动保障权益的诉求、外包与正式员工的绩效、待遇、劳动报酬矛盾、政府对互联网反垄断限制、网络安全与漏洞风险的异军突起，技术工人面临的现实问题迫切需要科学的理论和框架指导。

    全球网络安全与信息化产业工人争取自身的权力和限制资本家的活动从没有停止过，将影响着新的技术革命主义的产生，这不意味的政治制度的改变，但是决定着劳资关系和技术价值的整个发展。

资产阶级是指占有社会生产资料并使用雇佣劳动的现代资本家阶级。 

无产阶级是指没有自己的生产资料，因而不得不靠出卖劳动力来维持生活的现代雇佣工人阶级。 

生产资料就是由生产工具和劳动对象。举个例子，在资本主义国家中，一位在知识密集型产业公司上班的员工，其工位、电脑、网络资源、账户，包括员工自己都是生产资料，掌握生产资料的阶级就是统治阶级（压迫者），被统治阶级（受压迫者的工人阶级）则往往没有掌握生产资料。

技术加速社会的隐忧

    在全球资本浪潮的裹挟下，“技术加速主义”的激进思想基本占据社会发展主导地位，其片面夸大了技术在社会发展的作用，忽视了技术对人类的幸福感、获得感的“异化”。资本的逐利本性需要科技的不断吞噬其他的资本，资本加持的科技使得人们经“科技-社会-生活”的飞轮不断加速。快节奏社会给个人情感带来了的内卷、躺平、空虚、Pua等多种影响。

log4j的漏洞发生，更大规模的公司希望拥有更强的安全技术，通过更快的得到应急安全保障，从而获取更多的剩余价值，逼迫技术人员提高自动化编排效率，用比应急fastjson 更快的技术为资本服务。

但是与之相对，使用了更好的技术栈的初创企业（go语言等），最终无需在安全方面花费额外的沉没时间和市场成本，扩大竞争优势。

技术和资本的双重剥削

    在如今的技术资本体系下，产业技术人员承受着技术和资本的双重剥削。资本家是资本的奴隶，资本本身需要不断自我增长。IT产业的财富积累依然来自于资本家对剩余价值的剥削。

    早期通过对工人的劳动时间进行榨取，而在数字时代，资本的获利增值方式更为隐蔽，往往披着遵守严格的劳动作息和细致周到的员工福利的外衣，但是本质是借助技术力量将知识管理者由体力劳累推向头脑劳累状态。

    即使生产力和劳动效率提升了，但是剩余价值并不一定提到提升，提高剩余价值的办法一般是延长工作时间和增量劳动强度。

    在充分竞争环境下，劳动报酬增加的真相在于一个人随着时间的推移生产力提升（成为领域专家），那么资本通过貌似合理的“等价交易”普调工资的方式，要求付出更多的劳动，从而将劳动异化为非自愿（被社会和生活加速）的生存手段，攫取再多的资本，

举个例子：一家房地产的员工通过努力工作建造了质量更好的房子，工资涨了，同时质量更好的房子也更贵了。

快递员通过更努力的工作提高配送效率，但是系统压榨的配送要求更高了。逼迫快递员提升劳动强度不断适应机器和算法，最终沦为算法的奴隶。 

劳动者每天要做的工作是不断增多的，除了要完成日常工作，需要创造额外利润来榨取剩余价值，没有资本增值，老板会由资本阶级滑落为手工业者或者无产阶级。

技术并不等同于生产力

    产业工人同生产工具和劳动对象一起构成生产力。“科学技术是第一生产力”，并不代表技术就是生产力，在体制、机制以及思想观念等方面还存在许多阻碍科技与经济结合的不利因素。资本是生产力提升的最大受益者，资本实现对资源的持续掠夺需要持续的消费场景，创造不断的消费欲望。

    技术总是带着满足人类需求的目的出现，但是实际上只不过是掩盖资本逐利的一种手段而已，技术工人明知不可，但是不能停下脚步。

直播带货的技术问题不在于卖得东西性价比如何，在于无中生有创造了消费需求。

再举个例子，路由器、电脑配置、操作系统往往不是因为真正功能失效而被替代，往往是因为“延保”、“配置不足”、“新的功能”而被更换，所以APP越来越大，手机越来越卡，产品功能越加越多。

    元宇宙是技术资本主义开辟的新殖民地，但是只有像元宇宙等新的增长点出现，资本才能继续循环增加下去。

远程工作是典型案例

远程工作看似美好，但是让工作侵占了生活，BeyondProd让企业更安全，但是客观上也提升了资本私有财产的获利效率。

”时间就是金钱“，”知识就是力量“。这两句是典型的资本观察视角。以往我们认为掌握更多知识，勤奋劳动获取更多的财富是幸福，其实拥有时间才是幸福。

    资本主义的发展虽然带来了残酷的剥削，但客观上也解放产业工人的身体。比如通过采矿远程视频监控系统，无需亲临一线承担工伤风险。

    但是请你看一下马克思同志在资本论里的名言：“机器消灭了工作日的一切道德界限和自然界限.....竟变为把工人和家属的全部生活时间转化为受资本支配的增殖资本价值的劳动时间的最可靠手段”。

    远程工作本身是社会中技术发展和数据生活加速的集中体现。好消息是随着远程会议、VR、协作管理系统等技术和管理手段的发展，远程工作体现了旧的生产关系，不再适应新的生产力的关系。社会生产力的发展决定生产关系的变化，而生产关系又反作用于生产力，对生产力的发展起到促进或阻碍的作用。远程工作本身为资本服务，又将埋葬资本。

技术工人既关注技术，也关注人

    新时代的技术工人怎么改变让社会更美好呢？技术不能代替人成为全部的生产资料，产业工人要掌握技术社会的领导权，笔者简单写几条信条作为技术工人的自我修养。

技术工人宣言

• 要加强网络空间思想引领

    贯彻落实习近平总书记在网络安全和信息化工作座谈会上的重要讲话精神，加快完善国家信息化标准体系，充分发挥标准对推进技术融合、业务融合、数据融合的引领和支撑作用，进一步增强我国信息化发展能力，提升经济社会信息化应用水平。

• 尊重商业，保障知识权益，联合资本

    理解开源社区，也支持商业闭源方案。

    技术本身无罪，与资本结合才称为榨取剩余价值的工具，大数据可以，大数据杀熟不可以。

    暂时不得以破坏生产工具生产资料、罢工、使用落后技术、泄露商业机密等手段隐蔽或直接对抗资本家。

• 技术不作恶

案例：据报道，天才黑客Flanker被拼多多辞退应该是因为其不愿意从事“黑客攻击”，而他被开除前任期即将满5年，届时将有权获得该公司价值上亿的股票。

    不得将技术用于破坏人权、恶意商业竞争。

    不能使用公司资源进行挖矿、通过技术手段探测内部员工隐私等。

• 网络空间隐私和数据权力平等

    尊重用户赋予选择安全的自由,网络安全法、数据安全法、个人信息保护法相继制定，共同构建了中国数据信息安全保障、发展利用、有序流动的法律体系

• 技术无国界，但是技术人员有国界

案例：工业和信息化部网络安全管理局通报称，阿里云公司发现阿帕奇（Apache）Log4j2 组件严重安全漏洞隐患后，未及时向电信主管部门报告，未有效支撑工信部开展网络安全威胁和漏洞管理。

经研究，现暂停阿里云公司作为上述合作单位 6 个月。暂停期满后，根据阿里云公司整改情况，研究恢复其上述合作单位。

行动策略：警惕-认识-对抗-改变

    实施技术工人宣言并不能仅仅在一个行业、一个区域、一家公司发生，因为在快速变化的社会中，每家组织都受到另一个领域的深刻影响，此外每家组织的发展情况都大致相同，需要逐步警惕技术社会的陷阱，逐步认识到技术资本社会和生活的关系，随后产生行动改变世界。

结语

    历史是最好的检验工具，伴随着互联网资本主义的发展而逐渐壮大的互联网劳动阶级则充当了资本主义制度掘墓人的角色，反映时代特色的思想将被保留下来。

    笔者愿意将这些作为信条的草案，同大家广泛探讨并随时增补，欢迎留言参与评论。

Why 关注BeyondProd

• 想象的业务
• 真实的业务
• 云原生时代的挑战
• 面临的难点和挑战

Which 架构选择

• Google基础架构安全设计
• Google技术沙盘
• AWS安全设计

What BeyondProd的关键技术

• mTLS > Mutual Transport Layer Security
• 全程票据方案详解
• 仍需要工程化解决的问题
• Resource of ByeondProd

HOW 打个广告招人

安全乐观主义：谷歌提出的BeyondProd，不同的公司叫做平台安全、IDC内的零信任、基础设施安全、IaaS安全等，本文是笔者依据经验，整理各家公司的一些实现架构和关键技术作为抛砖引玉的材料，希望大家对这个领域多加以交流。

1. 不要学习业界最佳实践

2. 安全方案保持超前，不接地气

3. 表面省钱，什么都坚持自研

4. 安全研发不懂安全，研发安全不懂研发

5. 喜欢简单重复，避免自动化

6. 以安全自High为中心，避免“客户至上”

7. 安全建设的上限是蓝军的下限

8. 全体躺平，让有责任感的成员占少数

9. 坚持做“自下而上”的安全

10. 做临时方案，避免做长期正确的事情

如果你想让一个信息安全团队做得一年比一年差，我这里有一些忠告建议，可以帮助你搭建一个失败的安全建设团队，请一定要按照以下十条建议去做，否则你的安全将建设得越来越好。

不要学习业界最佳实践

要让安全团队倒闭首要建议是看到各种安全会议眼花缭乱的PPT就抄在自己团队的规划里，牢记零信任、切面安全、内生安全、DevSecOps等一个都不能少。要成功让一个安全团队倒闭，就要坚持不研究业界更高体量公司的最佳实践，只局限于参与同等水平或者更小体量公司的视野。要照抄其他公司安全方案，少去思考为什么做这么做，背景是什么，有没有更好的路线，尽可能从自己的失败中学习教训，而不是参考别人的经验：）

安全方案保持超前，别接地气

一方面要不对标，一方面要确保你的安全方案是安全自以为是的，就强制覆盖到全公司，保持自己的安全方案照搬到另外一家公司也可以，不要考虑所在公司的实际情况，只考虑当前安全技术对自己岗位能力的匹配度。哪怕是超前的安全方案，只要是“面向简历有利”的安全方案都可以推行。

表面省钱，什么都坚持自研

保持“谋杀”团队成员职业生涯的法宝是让他去自研一个夕阳产品，而实际自己就几个人，几条枪，不是专业研发，也没啥专利，坚持让当前宝贵的人力去做所谓的自研，千万不要用手头的预算购买成熟的商业产品，别把人投入到更有价值的岗位上去，因为这样会少安全会议谈论的资本。

安全研发不懂安全，研发安全不懂研发

要让做安全产品开发的小伙伴一点儿不懂安全，保持合作的高昂成本。做防御产品的技术人员要一点也不懂实际的安全价值，只管按照开发文档去实现功能，别去考虑实际的安全场景。

做产品安全的小伙伴要是攻击队出身，最好没有认证鉴权加密的安全基本功，和业务对接安全时要照搬安全编码规范和测试指南，不要去考虑开发细节，给出僵硬的修复指导，让一线研发自己去查资料。

喜欢简单重复，避免自动化

重复机械的活动让团队成员心理更有稳定感，建立喜欢重复5遍以上的手工劳动的文化，排斥做自动化的开发，保持安全是个经验活动，而不是软件工程科学。

以安全自High为中心，避免“客户至上”

安全团队没有客户，只考虑自己安全圈里的技术对抗，千万不要将各个业务团队视为自己的客户，业务不配合安全是业务的价值观有问题。安全和业务要做到零和博弈，有你没我，有我没你，不要做安全工程师考虑客户服务，不要做赋能业务，要沉迷于领域内的安全攻防技术。

拿着安全的锤子看啥都是钉子，做出来个安全产品就套用到各个业务模型，哪怕自己已经不适合serverless、大数据、微服务的产品，依然要套用起来，花大力气让业务进行改造适配，而不是思考自己的产品是不是能给业务带来收益。

安全建设的上限是蓝军的下限

要妥协于蓝军，安全团队要保持被蓝军牵着鼻子走的节奏，坚持眉毛胡子一把抓去修复蓝军发现的问题，case by case的去解决，而不是区分优先级去耐心建设。以一年一度的护网为最高目标，没被打穿就是我们建设的好，被打穿就解释说是视野范围内的问题。

全体躺平，让有责任感的成员占少数

团队中虽然要有勤恳的老黄牛式员工，明星员工，但要保持新员工能力低于团队50%水平，持续让有责任感的员工跑路。让团队里做攻击的小伙伴占大多数，将工时作为绩效指标。保持“向上管理”的能力，建立安全是个风险管理，安全哪怕做的更好、更差都没啥用的价值观导向。

坚持做“自下而上”的安全

千万不要“自上而下”给予顶层设计和资源支持，让安全工程师自发地做出视野范围内的事情。哪怕是方向错了，只要大家努力了，人人有事干，事事有人管，就达到了安全团队存在的要求。另一个要领是领导说啥就干啥，忘记了是国家和人民托付给我们做安全，大老板是中央网络安全和信息化领导小组组长。

做临时方案，避免做长期正确的事情

濒临倒闭的信息安全团队牢记自己是“临时工”，自扫门前雪，哪管事后洪水滔天，假装努力解决眼前的问题，掩耳盗铃地选择性地做简单容易拿绩效的事情，满足于做临时解决方案，千万不要复盘，反对举一反三，避免做长期而正确的事情。

如果读者有更好的办法可以让安全团队垮掉，欢迎关注微信公众号，私信作者一起交流。

• What  将安全性和可靠性结合

• Why 错把“DevSec”当成“DevSecOps”

• How Secure Your Ops

• 安全混沌工程-Security  Chaos Engineering

• 韧性-Resilience

• 无接触-No Touch

• When 对待安全的观念需要立刻改变

• 参考资料

What  将安全性和可靠性结合

  业界不少关于DevSecOps实践的文章，大都是一些静态代码检查、被动扫描器、安全框架和SDK、域名上线卡点之类的介绍，这些文章不约而同地避开了软件的维护、运维阶段。实践DevSecOps的第一个误区就是错把“DevSec”当成“DevSecOps”，缺少持续运营的运维\交付阶段，仅将安全向开发人员左移是选择做一件简单的事，而不是正确的事。

  开发人员通常不是安全工程师，安全团队通常没有开发人员。两个团队都没有资源或技能来满足对方的需求，安全不仅仅是安全和研发两个团队的责任，需要每个工程师参与，笔者认为安全工作不应该仅仅从保障不出事的角度，而是要站在为业务带来发展的正向价值的高度去思考，DevSecOps以关注代码开始，以部署和运维开始循环，Deploy、Operation阶段的安全性也很重要。

  是时候谈谈安全和可靠的融合了，可靠性和安全性不可分割，没有安全性，就不可能获得安全性；而没有可靠性，安全性就是不完全，不巩固的。运维、交付阶段的安全运营领域将是未来5到10年DevSecOps行业的主战场，而国内阿里、腾讯早已经布局这方面的人员和技术积累。

Why 错把“DevSec”当成“DevSecOps”

  实践DevSecOps，很多人第一步就做错了--错把“DevSec”当成“DevSecOps”，忽视Ops阶段的安全性，定义持续安全性区分两个团队：一个是开发和工程团队，另一个是运维/发布团队，折腾开发人员是安全团队的一项传统技能，安全的偏见认为SRE就是做申请机器，打补丁的事情，其实现在SRE的角色已经完全不同，虽然没人愿意去折腾SRE，但是我们不能妥协，工作哪能不严格呢？和和气气怎么能把工作搞好，实现变革是需要付出代价的。

只关注dev的sec，不关注ops阶段的sec，主要体现在四个方面：

  建设的思路受限于过去的经验。对于云原生项目、微服务、大数据、SaaS的项目，仅通过安全团队的web、移动应用安全审查，并说“安全审核通过，可以上线发布了”是不够的，谈到应用安全其实是指狭义的研发安全，好像以为主机系统安全、部署安全、运维安全、基础设施安全领域和自己没有什么关系，安全的手不能伸得太长，可是现在未来是“基础设施即服务”（IaaS）、”配置即服务“的趋势，不能仅仅关注代码维度了，要关注产品的全部生命周期。以供应链攻击威力，并不仅仅是code。数据显示开发人员使用39% 的时间用于管理 DevOps 基础设施。

  以供应链攻击为例共有以下8个攻击环节，但是如果关注研发安全，只能覆盖其中4个代码技术层面，忽略下图中的A、B、G、H场景。

重新审视供应链攻击的大盘

  选择做当前的事，不着眼于长远。当前的问题是仅在需求、设计和开发实施的阶段考虑安全性，对于业务视角来说，企业安全本身就是一个正在进行的项目，要注意整个安全能力的交付过程，而这项工作随着企业软硬件的发展永远不会完成。我们总是可以做些事情来减少未来漏洞带来的风险和影响。

  安全工程化要求不高。我们总是以为公司的安全隐患是研发人员写的代码引入的，实际对于一次全链路攻击，利用代码安全漏洞仅仅是入口边界，提权、抓hash、未授权等横向渗透后果其实和开发人员没什么关系。现在能力大都集中在主要是防入侵而已，防范删库跑路不少公司是做不到的。花了很大精力去做长尾工作的扫描、修漏洞、告警能力，安全投资的回报已经不足，为什么不真实关注建设的短板呢？当然有些黑、白盒安全运营的能力是“看上去”比较成熟，挑战不大，本质上我们没有提出更高的要求，我们不仅要鼓励devsec的从10到100，也要鼓励secops的从0到1，1到10。

  忽略人的因素。是人就会犯错误，我们只能缩减问题发生的影响，永远不能完全解决问题。除了关注技术和流程，人的Operation因素是影响DevOps效果的最大变量。

  ESG对北美对私营和公共部门的IT和网络安全专业人员进行的调研显示，48%的组织故意将易受攻击的代码推送到产品中，说明工具流程虽然能检出，但是人去主动忽略放行。

  还有个最近的例子，我们能否真正解决”删库跑路“问题？字节最近通过”传字节跳动实习生删库，公司通报为重要事故“事件回答：不能。

How Secure Your Ops

  DataOps、MLOps 和AIOps，可以统称为Operations（Ops\运维）阶段。SRE 可以帮助团队在发布新功能和确保用户可靠性之间找到平衡。SRE(或者是DevOps工程师)关注的稳定性和安全所关注的安全性问题，在解决思路策略、技术实现、对人的要求都是一致的，但现状是安全和SRE的沟通协作还远远不够，在下图中显然大家做的更多事情是偏左，右侧的技术栈的安全熟练度不高。

  我们永远无法理解我们自己的系统，但安全还没跟上这个道理，总是喜欢规范统一，现在构建的分布式系统如此复杂，以至于没有谁能够说明其整个运行本质，系统不安全是常态，应急响应流程存在不足是常态，防微杜渐、严防死守的观念已经不适应现在行业发展。新的挑战面前，怎么去把事情继续做好？需要不断开阔自己的思路，往前看的同时也往后看，关注Ops领域。业界已经有一些实践作用于安全和可靠性领域：

安全混沌工程-Security  Chaos Engineering

  红蓝对抗方式是一种偏向传统的思维，显而易见其不足之处在于：一、攻击者总是能发现缺陷，蓝队总是能收到告警，说不清到底有多少工作要做；二、虽然少数优秀的执行团队可以做到以周、月度为周期演练，频度仍然严重不足；三、不透明、不可重复实验、过程不可控，缺少持续的反馈。如果说红蓝的定位是”发现建设存在哪些问题“，安全混沌工程则关注”建设这些问题的优先级“。

  当我们面临一个复杂规模的业务系统时，出现安全漏洞几乎是必然事件，没有安全问题是偶然现象。不管你花多少精力进行漏洞修复，出现0day几乎是必然事件；不管你组织多少安全培训，员工点击钓鱼系统几乎是必然事件；不管你做多少风险感知能力，入侵行为发生快于阻断是必然事件。

  根据《IBM Security 2020 Cost of a Data Breach Report 》52%的数据泄露是因为恶意代码攻击，23%的原因是人的犯错，25%的原因是系统故障。安全混沌工程通过观测应急响应、安全控制措施验、基线监控、风险发现等技术手段解决后两类问题，占比共达到48%！

  将安全视为故障需要运维和安全共同进行改善，安全混沌工程通过快速检测服务是否健壮、安全、有足够的韧性、能否容忍意外的安全事件来提高企业安全架构的实用性。

韧性-Resilience

  发生安全事件的第一步应该做什么？恢复业务正常运行进行止损。组织需要建立面对性能和安全威胁时，有效保持系统弹性和恢复的能力。今年RSAC大会探讨的韧性其实已经超越了安全的范畴，是踏踏实实的软件工程。韧性要求安全工作不仅仅重视拿结果，也重视过程阶段的成熟，引入了控制降级、冗余、弹性设计、隔离、自动缓解和恢复的概念。

无接触-No Touch

  恶意用户（或者攻击者）尝试破坏系统、中断系统来影响服务可用性，我们必须将”人的因素“装在”笼子“里。想象一下，一位研发人员通过配置管理下发了一个错误的配置引起了软件变更，但是这个时候是不是绕过了code review和代码扫描流程，是不是应用安全应该关注的事？SDL亦或是DevSecOps的职责是产品安全或者应用安全整体，不应该是止步于研发安全。

  举个例子，怎么阻止高权限的运维人员私自开放公网ip到线上？No Touch通过审核每一次变更必须通过自动化、软件校验风险因子、可审计的备用措施来实现”提高生产安全性、避免中断“，被背后代表着需要落地大量安全原则，比如最小权限、前置安全检查策略、安全代理、审核、关注人和机器之间、机器和机器之间的交互。

  参考AWS的“Humans and Data Don’t Mix”，这方面需要建设工具链很多，出成绩的前景很大。

When 对待安全的观念需要立刻改变

  笔者从不相信DevSecOps，指导所在领域建设的思路只有基础设施强制安全和极致自动化两个概念，DevSecOps这个名词的作用仅仅是说服合作伙伴达成协作而已：）DevSecOps就是妥协、战斗、妥协的循环，需要耐心，智慧和说服力。

  总而言之，需要通盘关注组织内复杂的IT和研发流程，适当平衡安全防护架构选型和架构的合理性，保证技术安全的领先性，不至于三五年被淘汰，平时针对安全做好计划并应对持续性威胁，而不要去保证100% 安全性。

  从现在开始重新理解DevSecOps的持续安全性，立即行动起来吧！

参考资料

https://www.researchgate.net/publication/335922038_Security_Chaos_Engineering_for_Cloud_Services https://www.freebuf.com/articles/security-management/275605.html

https://security.tencent.com/index.php/blog/msg/150

https://devops.com/survey-shows-mounting-devops-frustration-and-costs/

https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html

• web安全已死

• Security Mesh

• 可靠与安全性 SRS

• 蓝盒 TMAST

• 权限和访问控制 IAM+

• 数据类应用的安全性 Data Appsec 

• 基础架构安全 BeyondProd

• 并不仅仅是默认安全，强制安全 Enforce Security

• 安全访问代理 Access Security Broker

• 可证明的安全性  FVS，Formal Verification

• 应用编排和安全响应 DOAR

Web安全已死

从基础的信息化阶段，到移动互联网，到产业互联网、物联网，以至于未来的人工智能化大发展，产业技术的发展促使应用安全领域近年来逐步受到越来越多的重视。我们必须意识到传统的web安全技术已经逐步落实，应用安全行业在下一个时间将会有巨大的变革。

SDL还是DevSecOps？应用安全人员前景怎样？未来应用安全市场需求究竟在哪？现在的建设是否满足未来的需求？

近日，安全乐观主义在研判分析近几年网络安全政策、学术、技术和产业发展的现状，预测出应用安全领域十大发展趋势，并为安全圈抢先发明对应的新名词：）

趋势1：Security Mesh

微服务和混合云打破了基于边界的安全模型，Security Mesh理念是指重新定义网格之间异构的信任关系，这同时也将影响现有的集中安全软件类研发和部署，各项安全控制措施将拆分为紧靠业务的微服务体系。

趋势2：可靠与安全性 SRS

Secure and Reliable Systems成为创新企业对安全运维提出的最低要求，无意的可靠性故障和有意导致的安全漏洞被视为同一类风险，这意味的应用安全人员的职责需要改变。原有的系统安全工程师、应用安全工程师、开发工程师技能模型进一步得到合并并催收出此类新安全岗位，Security Chaos Engineer，安全混沌工程师岗位应运而生。（笔者似乎是国内第一位踩坑的安全人员......）

趋势3：蓝盒 TMAST

蓝盒指代Threat Modeling Application Security Testing威胁模型驱动的应用安全测试。TMAST将成为既黑盒DAST、白盒SAST、灰盒IAST后，应用安全的又一主流安全测试方法。

趋势4：权限和访问控制 IAM+

自从越权漏洞成为了各大SRC的主流高危漏洞后，人和技术的技能栈没有跟上攻防趋势的发展，IAM+提供了可理解的身份，身份验证和访问控制，任何系统都应该能够识别谁有权访问哪些资源，尤其是在资源高度敏感的情况下，企业的强烈需求加速为市场领域创新者提供红利。

趋势5：数据类应用的安全性 Data Appsec

安全是数据的共享是数据开发、利用和增值的重要一环，除了传统的数据安全继续发展以外，应用安全领域也将关注数据处理类服务的创新应用如大数据任务、BI、函数服务、边缘计算、算法的安全性评估和建设。

趋势6：基础架构安全 BeyondProd

基础服务具备种类多、结构复杂、体系结构复杂等特性，随着传统应用安全领域将从“轻管控、重检测、快响应”发展到“轻检测，重基础，自动响应“，具体参考BeyondProd、Istio项目白皮书（可恶，这个英文单词被谷歌先抢了）。

趋势7：并不仅仅是默认安全，强制安全 Enforce Security

内生、默认安全还不够。仅在设计和开发阶段都考虑安全性是不够的，对于软件生命周期来说，安全本身就是一个正在进行的项目，而这项工作永远不会完成，软件的韧性，抗摧毁性得到重视。强制安全的预期目标是确定性地降低未来漏洞的风险和影响。

趋势8：安全访问代理 Access Security Broker

ASB理念是检测和预防的关键技术，类似于将使用者关在盒子里，更多的代理功能将应用在各个用户、云服务、存储之间，提供了大量检测、分析、记录。增加个代理对于安全好处多多。

趋势9：可证明的安全性  FVS，Formal Verification

可形式化证明的安全性理论与方法研究预计得到业界重视，可被数学方式证明的安全产品、安全架构在关键基础设施将得到重视，并同安全智库形成“产、学、研”结合的新风向。安全建设的指标会是什么？不再是漏洞数量、修复比例、产品是否建设、蓝军case覆盖度的感性概念，而是转换为网络安全学科公理的证明。

趋势10：应用编排和安全响应 DOAR

数据分析驱动的应用安全将进一步提升自动化能力，并集成到研发流程，统称为Develop Orchestration、Automation, and Response ，自动化的工具辅助安全人员从审核、运营中脱离出来，开始精细化管理安全场景，形成短期应急响应，中期安全持续改进，长期安全变革提供动力。

如果你有什么新的想法，欢迎同小编留言交流哦~

• 简介

• Google 如何帮助保护客户数据

• 应急响应

• 团队架构

• 应急响应流程

• 识别

• 协调

• 处置

• 完成

• 持续改进

• 总结

• 参考资料

简介

为客户数据维护安全的环境是 Google Cloud 的首要任务。Google 通过一个业界领先的信息安全操作体系来保护客户数据，该操作体系将严格的流程、世界一流的团队以及多层信息安全和隐私基础架构进行了有机结合。本文重点介绍 Google 管理和响应的原则性方法。

在 Google 的整个安全和隐私计划中，应急事件响应是一个重要方面。谷歌制定了严格的应急响应管理流程。该流程详述了影响客户数据机密性、完整性或可用性的任何潜在突发事件的操作、上报、缓解、解决和通知方法。

在 Google，应急响应是指 Google 安全体系遭到入侵，从而导致 Google 管理或控制的系统上的客户数据遭到意外或非法破坏、丢失、更改、未经授权的披露或访问。Google 会采取措施解决数据和系统面临的可预见威胁，但应急响应不包括未破坏客户数据安全的失败尝试或活动，包括失败的登录尝试、ping、端口扫描、拒绝服务攻击以及防火墙或联网系统上发生的其他网络攻击。

Google 如何帮助保护客户数据

客户数据的安全至关重要，而数据安全有赖于 Google 与客户的协作。Google 负责保护底层的云端基础架构和服务的安全，而客户在 Google 云端基础架构之上进行构建时，要保护其应用、设备和系统的安全。Google 为客户提供指导和多种安全功能，以实现 Google 水准的安全做法：

• 身份和访问权限管理
• 默认对静态数据和传输中的数据进行加密，无需客户执行任何额外操作
• 多重身份验证，包括防网上诱骗的硬件第二重安全密钥
• 广泛的网络安全选项，包括虚拟私有云 (VPC) 和共享 VPC、软件即服务 (SaaS) 和平台即服务 (PaaS) 解决方案的内置 DDoS 防护，以及将上述机制用于基础架构即服务 (IaaS) 解决方案的选项
• 详细的审核日志

首先基础架构和基础设施，包括技术、人员、流程保证可以大规模支持漏洞管理，并尽量使得无需为客户带来额外的工作量。谷歌披露安全建设的五大安全原则如下：

1. 基础设施安全

   基础架构的安全是Google的核心竞争力。安全性不应该是事后或者偶尔为之的措施，而是日常工作不可或缺的一个部分。

2. 数据生命周期

   谷歌并不仅仅关注数据存储保护这一领域，而且关注收集、发现、同意、访问、保护、清除、导出等完整的生命周期。这也是Google推行全球https化和安全DNS的动力。

3. 认证授权访问控制

   定义有权访问和授权内容的身份策略、识别访问是否正常，检测并做出响应。

4. 应用安全

   Google平台自身的安全性（GPC、Gmail、Brog），和产品的安全性（Android、chrome）。

5. 运营管理和审计

   ”人的因素“，围绕构建Google整个运营体系的安全性和风险管理，包括如何操作管理后台、如何运行基础架构设施。

如需详细了解 Google 如何保护 Google Cloud 的安全，请参阅《Google 基础架构安全设计概述》这篇文章和相关的 NEXT '18 安全演示，或访问 Google Cloud 安全网站。

Google 为客户提供他们在 Google Cloud 上使用的各种服务的可见性；客户可以使用 Google Workspace 安全中心来预防、检测和解决 Gmail、云端硬盘、设备、OAuth 和用户帐号中出现的问题。同样地，对于 GCP，客户可以使用 Cloud Security Command Center 来了解其组织中的资源、漏洞、风险和政策的相关数据。

在客户一方，他们必须正确配置安全功能以满足其自身需求，安装软件更新，设置网络安全区域和防火墙，并确保最终用户保护好自己的帐号凭据，不会向未经授权方公开敏感数据。

下图显示了Google的云安全共享责任模型，说明了客户与 Google 各自的责任如何随客户对代管式服务的利用程度而变化。随着客户从本地解决方案转向 IaaS、PaaS 和 SaaS 云计算产品，Google 将负责管理整个云服务的更多环节，客户的安全责任则随之减少。技术上将安全防御划分为16个层次，统一的理念是--”纵深防御、默认情况下支持大规模的防御“。

应急响应

Google 的事件响应计划由许多专业职能部门的专家级应急事件响应人员管理，以确保每个响应都能很好地适应每个突发事件所带来的挑战。根据突发事件的具体性质的不同，专业响应团队可能包括：

• 云端突发事件管理
• 产品工程
• 站点可靠性工程
• 云端安全和隐私
• 数字取证
• 全球调查
• 信息检测
• 安全、隐私和产品顾问
• 信任与安全
• 反滥用技术
• 客户支持服务

这些团队的主题专家会以各种方式参与其中。例如，突发事件指挥官协调事件响应，如有需要，数字取证团队将检测正在进行的攻击并进行取证调查。产品工程师会努力限制对客户的影响，并提供解决方案来修复受影响的产品。法律团队会与相应安全和隐私团队成员合作，实施 Google 的证据收集策略，与执法部门和政府监管机构合作，也会就法律问题和要求提供建议。客户支持人员响应客户的询问和请求，为他们提供更多信息和帮助。沟通始终是应急响应中很重要的部分。

在2020年，谷歌就尝试招募内部在安全有兴趣的工程师一起参与到应急响应流程中来，通过培训、值班、共享信息让应急响应能力开放出去，这样做的好处是集合经验智慧，也方便全球跨时区值班，最终部分参与的志愿工程师甚至可以完全胜任指挥官的角色。

团队架构

同SRE的流程一样，谷歌宣布突发事件时，会指定一名突发事件指挥官来协调应急事件响应和解决方法。突发事件指挥官会从不同的团队中选择专家组成一支响应团队。典型的响应架构如下图所示。突发事件指挥官会将管理突发事件不同方面的责任委派给这些专业人员，并管理从事件宣布到关闭的整个过程。下图描述了应急事件响应期间各种角色的关系及其各自职责。

应急响应流程

每个应急响应都具有特殊性，应急响应流程的目标是保护客户的数据，尽快恢复正常服务，并满足监管和合同合规要求。简单看Google 的应急事件响应计划的流程如下：

识别

及早准确地识别突发事件是强有力的突发事件管理的关键。这一阶段的重点是监控安全性事件，以检测和报告潜在的应急响应。

Google 的突发事件检测团队采用先进的检测工具、信号和提醒机制，以便及早发现潜在突发事件的端倪。

Google 的突发事件检测来源包括：

• 自动化网络和系统日志分析：网络流量和系统访问的自动分析有助于识别可疑、滥用或未经授权的活动，并将相应情况上报给 Google 的安全员工
• 测试：Google 的安全团队使用渗透测试、质量保证 (QA) 措施、入侵检测和软件安全审核来主动扫描安全威胁
• 内部代码审核：源代码审核可发现隐藏的漏洞、设计缺陷，并验证是否实现了关键安全控制
• 针对特定产品的工具和流程：尽可能根据团队职能采用相应自动化工具，以增强 Google 在产品级层检测突发事件的能力
• 使用异常检测：Google 采用多层机器学习系统，来鉴别用户在各类浏览器、设备上的活动，以及进行的应用登录和其他使用事件是否出现异常
• 数据中心和/或工作环境服务安全提醒：数据中心的安全提醒会扫描可能影响公司基础架构的突发事件
• Google 员工：Google 员工会检测异常情况并进行报告
• Google 的漏洞奖励计划：Google 拥有的浏览器扩展程序、移动应用和网页应用中可能存在影响用户数据机密性或完整性的技术漏洞，这些漏洞有时由外部安全研究人员报告

协调

收到突发事件报告时，值班响应人员会审核并评估突发事件报告的性质，以确定它是否属于应急响应，并启动 Google 的应急事件响应流程。

一旦突发事件得到确认，它将被移交给突发事件指挥官，该指挥官将评估事件的性质并实施相应协调响应。在这一阶段，响应包括完成突发事件的分类评估，在需要时调整其严重程度，并启用所需应急事件响应团队，由相应操作/技术主管审核具体情况并识别需要调查的关键区域。谷歌会委派一名产品主管和一名法律主管，就如何响应做出关键决策。突发事件指挥官将指派相关人员开展调查并收集事实。

Google 响应的许多方面取决于严重程度评估结果，该评估以应急事件响应团队收集和分析的关键事实为根据。这些事实可能包括：

• 给客户、第三方和 Google 造成危害的可能性
• 突发事件的性质（例如是否会导致数据被破坏、被访问或变得不可用）
• 可能受影响的数据的类型
• 突发事件给客户使用该服务造成的影响
• 突发事件的状态（例如突发事件是否已被隔离、仍在持续或已得到控制）

随着新信息的不断获得，突发事件指挥官和其他主管会在整个响应过程中定期重新评估这些因素，以确保为 Google 的响应已分配适当的资源和紧急程度。会造成最严重影响的突发事件将被指定为最高严重程度。响应中还将指定一名沟通主管，负责与其他主管一同制定沟通计划。

处置

在这一阶段，重点是调查根本原因，限制突发事件的影响，解决当前的安全风险（如有），在补救过程中实施必要的修复，以及恢复受影响的系统、数据和服务。

受影响的数据将尽可能恢复到其原始状态。根据特定突发事件的具体情形，Google 可能会视情况采取许多不同的步骤来解决特定事件。例如，要重建问题的根本原因或识别对客户数据的影响，可能需要进行技术或取证调查。如果数据发生意外更改或被破坏，Google 可能会尝试利用 Google 的备份副本重建数据。

补救的一个关键方面是当突发事件影响客户的数据时通知客户。整个突发事件过程中，将对关键事实进行评估，以确定突发事件是否影响了客户的数据。如果有必要通知客户，突发事件指挥官将启动通知流程。沟通主管将根据产品和法律主管的意见制定沟通计划，通知受影响的客户，并于通知后在谷歌的支持团队的帮助下响应客户请求。

Google 致力于提供及时、清楚且准确的通知，其中包含应急响应的已知详情、Google 为缓解潜在风险已采取的措施，以及 Google 为解决相应突发事件建议客户采取的措施。谷歌将尽最大努力提供突发事件的详尽情况，以便客户可以评估并履行自己的通知义务。

完成

在成功补救和解决应急响应后，应急事件响应团队将评估从突发事件中吸取的经验教训。如果突发事件引发了关键问题，突发事件指挥官可能会启动事后分析。在此过程中，应急事件响应团队会审查突发事件的原因和 Google 的响应，并识别需要改进的关键区域。在某些情况下，这一过程需要与不同的产品、工程和运营团队进行讨论，并开展产品改进工作。如果需要后续工作，应急事件响应团队会制定行动计划以完成相应工作，并指派项目经理领导长期工作。在补救工作结束后，突发事件将被关闭。

持续改进

在 Google，谷歌努力从每次突发事件中吸取教训，并实施预防措施，以避免未来突发事件的发生。

从突发事件分析得出的富有实用价值的洞见有助于谷歌改进自己的工具、培训和流程，以及 Google 的整体安全和隐私数据保护计划、安全政策和/或响应工作。总结得出的重要教训还有助于相关工作的优先级安排和更出众产品的构建。

Google 的安全和隐私专业人员会审查公司针对所有网络、系统和服务的安全计划，不断加以改进，并为产品和工程团队提供针对特定项目的咨询服务。他们将部署机器学习、数据分析和其他新技术，以监控 Google 网络上的可疑活动，解决信息安全威胁，执行常规安全评估和审核，并聘请外部专家定期开展安全评估。此外，谷歌的全职团队（称为“Project Zero”）致力于向软件供应商报告 bug，并将其归档到外部数据库，以防范定向攻击。

Google 会定期开展培训和宣传活动，推动安全和数据隐私方面的创新。专门的应急事件响应员工将接受取证和证据处理相关培训，包括使用第三方工具和专有工具。谷歌还将针对关键区域（例如存储敏感客户信息的系统）执行应急事件响应流程的测试。这些测试会考虑各种场景（包括内部威胁和软件漏洞），有助于谷歌为安全和隐私突发事件做好充足准备。

作为 ISO-27017、ISO-27018、ISO-27001、PCI-DSS、SOC 2 和 FedRAMP 计划的一部分，Google 将对各类流程进行定期测试，以便为谷歌的客户和监管机构提供在安全性、隐私保护和合规性控制方面的独立验证。

总结

如上所述，Google 拥有世界一流的应急事件响应计划，提供以下关键职能：

• 基于行业领先技术构建的流程，专用于解决突发事件，并经过优化，能够以 Google 的规模高效运营
• 开创性监控系统、数据分析和机器学习服务，可以主动检测并控制突发事件
• 配备众多专门主题专家，可随时分派以响应任何类型或规模的应急响应
• 及时通知受影响客户的成熟流程，符合 Google 在服务条款和客户协议方面的承诺

保护数据安全是 Google 业务的核心。谷歌将持续对整体安全计划、资源和专业知识进行投资，使谷歌的客户能够在突发事件发生时依赖谷歌的有效响应，保护他们的数据安全，并持续满足客户对 Google 服务高可靠性的期望。

参考资料

https://www.youtube.com/watch?v=tz5ggxqEOos&ab_channel=GoogleCloudTech 

https://www.youtube.com/watch?v=NhyRtgDpiC0

https://www.infoq.cn/article/w1ldnnzvglcaohkxcfpp

https://www.sdnlab.com/22984.html 

https://www.secrss.com/articles/5328

https://services.google.com/fh/files/misc/data_incident_response_2018.pdf?hl=zh-cn

前言

开源软件具有开放、共享、自由等特性，在软件开发中扮演着越来越重要的角色，也是软件供应链的重要组成部分。根据Gartner调查显示，99%的组织在其 IT系统中使用了开源软件。而来自Sonatype公司的一项调查则显示，在参与调查的3000家企业中，每年每家企业平均下载 5000个开源软件。

开源代码的使用大幅度提高软件研发效率、缩短上市时间、降低开发成本，但是开源软件中存在的大量缺陷、甚至安全漏洞也一并进入了软件部署包，为软件带来巨大的安全风险。

根据国外安全机构的调研报告显示，企业应用代码超过80%来自第三方资源库或第三方组件，97%的java程序至少存在1个已知安全漏洞，而由第三方代码缺陷导致的信息泄露漏洞占比高达72%。

而国内企业的应用系统也存在同样的问题，比如漏洞频发的Fastjson库，攻击者可利用其反序列化漏洞，远程命令执行入侵到企业服务器，通过服务器执行命令，危害性极大。类似的还有jackson、shiro、Struts2,、OpenSSL等。

为了解决这类问题，软件成分分析（SCA）应运而生。

SCA

什么是SCA

SCA，Software Composition Analysis，软件成本分析是一种对二进制软件的组成部分进行识别、分析和追踪的技术。

2019年，Gartner在报告中把SCA纳入AST技术领域范围，从而形成了包含SAST、DAST、IAST和SCA的应用软件安全测试技术体系，并正式发布了有关软件成分分析（SCA）的技术洞察报告。其中，对软件成分分析技术进行了准确定义：软件成分分析产品通常在开发过程中对应用程序进行分析，以检测开源软件组件是否带有已知的漏洞，例如具有可用安全补丁程序的过期库，以及需要相应授权许可（法律风险）的商业软件或第三方产品。

SCA致力于确保企业软件供应链的安全，从而支撑安全的应用程序开发和组装。

为什么要做SCA

调查显示，平均每个应用有七成以上的代码通过调用第三方组件实现，然而大部分用户对于第三方组件存在的安全问题并未重视起来，因此，解决软件成分中第三方组件的安全问题迫在眉睫，软件成分分析（SCA，Software Composition Analysis）应运而生。

在2013年OWASP发布的OWASP-TOP-10中，风险清单添加了2013-A9“使用含有已知漏洞的组件”风险，其实该风险早在2010-A6“安全配置错误”风险中即有所提及，但随着时间的推移，在开发过程中越来越多的应用直接使用带有已知漏洞的组件部分，因此成为了一类单独的风险持续至今。

SCA致力于解决什么问题

• 应用第三方组件中的已知漏洞。 第三方组件中本身存在的漏洞，攻击者可以利用这些已知的漏洞，对应用系统进行攻击破坏。
• 第三方组件的软件许可问题。 这方面主要是分析调用的第三方组件的许可证类型。目前，国际公认的开源许可证共有80多种。有的许可证对软件的使用方式几乎没有限制，用户几乎不用关心需要承担的责任，但是也存在一些限制性比较强的许可证，如果不小心调用，可能会带来较大的法律风险和知识产权的损失。
• 第三方组件中的恶意代码问题。 这方面的问题不算普遍，但是危害也比较大。风险的来源主要是在非正规渠道获取被篡改的第三方组件，或使用了恶意开发者提供的第三方组件，未经确认就引入开发的业务系统中会带来极大风险。
• 引用版本过旧的第三方组件。版本过旧从表面来看，跟安全好像关系不大，但是仔细想想，比较老旧的第三方组件有可能会存在一些未知的、开发者没有公布的、且已修复的0day，所以这方面可以当作是不重要不紧急的风险来对待。

怎么做

第三方组件其实需要我们像对待业务资产一样的程度去重视。梳理下来针对这块的管控主要有以下几种方式：

定期在项目中检查引用的第三方组件

这是性价比非常高的方式，可以直接解决项目中实际存在的问题。在开发或测试阶段主动对所用到的组件进行定期安全检查，分析出引用的组件名称及版本，梳理出来该项目第三方组件清单，将这些信息在开源或商业的漏洞数据库中进行匹配，发现问题及时整改。目前市面上基本所有的SCA类工具都具备该能力。主流的做法是分析引用的三方组件名字、版本、MD5等，通过匹配漏洞库中组件和漏洞的对应关系确定引用的第三方组件是否有漏洞，这种做法简单有效，能够解决大部分问题，适用于场景广泛。

但是讲个题外话，这种做法并未实际检测漏洞是否在现应用中真实存在。例如某第三方组件确实存在已知漏洞，但是代码实际引用并未引入该风险，这就增加了安全部门与开发部门的矛盾，安全说你这个有漏洞，得换新版本，但是开发说我并没有用那个功能呀，不行你验证给我看。。。

对第三方组件库进行安全巡检

一般开发团队针对不同的编码语言，都会维护相应的开源组件库，比如Java语言常用的maven组件库，通过定期盘点组件库中组件的名称及版本，针对梳理出来的组件信息，比照开源或商业的漏洞数据库，盘点出当前组件库中组件的安全信息，形成一个组件安全信息库，定期对不安全的组件进行清理或升级。

1day漏洞应急

每当有第三方组件安全漏洞信息披露出来的时候，针对前面已梳理出来的各项目第三方组件清单，可以立即做出判断，了解自己的应用是否调用该1day漏洞组件，是否受此次漏洞披露的影响。

从源头卡住不安全组件的入口

这里主要是针对第三方组件入库时做一个检测，检测内容包括三方组件完整性、安全性、合规性。完整性是指校验即将入库的组件MD5，主要是为规范第三方组件来源渠道，避免下载到被篡改的三方组件。安全性是指检查即将入库的组件是否存在许可证或漏洞问题。合规性是指检查即将入库的组件开源许可证是否适用当前开发项目。

借助工具实现检测维护的自动化

如果想要识别组件库以及项目中的第三方组件及其版本号，并且还要对其进行细致的匹配排查，工作量是非常巨大的，如果没有自动化的帮助，仅仅依靠人工的话，几乎是不可能完成的任务。所以借助工具实现自动化是有必要的。目前已经有不少工具能帮我们完成这一工作，下面梳理一下目前的各类工具。

有哪些SCA工具

开源SCA工具

目前有一些开源的工具专门针对软件成分分析这块提供检测能力，例如OWASP的Dependency-Check和Dependency-Track。大多数开源工具专注于识别带有漏洞组件或版本过旧的第三方组件，并且漏洞库来源比较单一，例如大部分漏洞库来源于公网上公共的漏洞库，并且开源工具对于开源许可证的检测基本不支持（前面提到的Dependency-Track未来版本会支持开源许可证检测）。开源项目在一定程度上可以节省成本，但是在后期支持，以及定制化开发上肯定是比不上成熟的商业软件。

商业SCA工具

针对SCA的专项商业工具往往功能比较齐全，包含针对第三方组件的完整性、安全性和合规性检测的同时，能提供较多的接入方式，例如与组件库的对接，与代码仓库的对接，同当前开发流程的对接。能接受一定成本投入的用户最好选用成熟的商业解决方案。国外能提供这方面方案的有Checkmarx的CxSCA，新思的Black Duck等，国内能提供这方面的方案有默安的MoreSec SCA（因为Gartner有上榜，所以放前面），开源网安的SourceCheck等。当然相比国外发展了多年的方案，国内目前正处于起步阶段，需要大家给点时间。

与AST工具集成

AST工具集成SCA的能力一般也都是商业工具才有的，与AST工具集成有得天独厚的优势。做开发安全AST就是绕不过去的坎，所以在做AST测试的时候，顺带着就可以把SCA做了，省时又省力，但是缺点是与AST工具集成的SCA只能随项目走，不具备从源头治理的能力，简单来讲就是专业度不够。目前针对应用安全检测的工具可以分为三类，SAST、IAST和DAST。DAST不用说了，明显不可能支持集成SCA能力，IAST和SAST由于都是从代码层面分析应用漏洞，所以是具备集成软件成分分析的条件的，国外的SAST和IAST厂商目前没见过有集成SCA能力，这块主要以国内厂商为主，例如默安的IAST、SAST，开源网安的IAST、SAST。以上信息都是从各厂商官网获取，具体实现如何不做评价。

如何评估一款工具是否适合自己

想要评估一款工具是否适合自己，其实最需要考虑的就是当前的开发流程是什么样的，其次是评估哪些节点去做这个事情比较合理。整体要围绕自己的真实需求去寻找。主要有以下几个点做参考：

1、大方向上，没预算的用户选开源，正在做AST工具选型的选带有SCA功能的AST就可以，预算充足的或是对SCA管控需求比较强的就加一个商业SCA专项工具。

2、能否与DevOps工具链做自动化集成，无论当前开发模式是瀑布、敏捷还是DevOps，都要将这个作为一个评估项，因为DevOps是趋势，保不齐哪天就转了。工具链的集成包含组件库工具的集成、代码仓库的集成和持续集成工具的集成。

3、能够提供API供自有流程平台做集成，这一点对自有流程平台的用户很重要，简单开发就能接入自有平台。

4、能否检测开源许可证问题，这一点虽然是标配，但是有些方案就是不具备这方面的能力。

5、同等条件下，选择漏洞库来源丰富的，最好是那种有接入商业漏洞库的方案。

结束语

在这个以效率为王的时代，第三方组件虽然为高速迭代的业务系统开发带来了极大的便利，但是同时也引入的较大的风险，只有做好三方组件的管控，才能避免为业务带来安全性问题。

安全乐观主义点评：由cnbird鸟哥分享的一份介绍Google BeyondProd实现的ppt，笔者遗憾没有现场听到具体的内容，ppt下面的“安全乐观主义点评”字样为小编的发散思考，并不代表鸟哥大佬原始观点。

安全乐观主义点评：ppt分为四个章节，介绍了云原生环境下的安全风险、Google的基础信任机制、BeyondProd实践以及实现技术细节。

安全乐观主义点评：咦！攻守之势异也。攻防两端，当具备完成基础的技术能力之后，将由传统被动挨打转移到主动防御建设阶段。从防御的层层积累，到检测、溯源、审计手段的多样化。将分布在各个角落的数据、安全态势、应急措施统一整合起来（安全切面乱入）。将原来的基于漏洞管理转换为应急的全面复盘，每次修复行动都增强了企业安全现状的全貌。由人工跟进漏洞到全自动化编排处理，自动化的前置条件是资产完全、流程完全、自动化手段完成。从红黑对抗的起点从找到漏洞，到规范化模拟ttps阶段，增强效果。从一味对标最佳实践，贪大求全的安全建设到以攻防演练为核心，从安全效果反推建设进度和成本。在不具备完全剔除攻击者的情况下，采取合理有效监控和观察手段，及时止损。从依据黑客行为特征到完全依赖白名单到基于行为的动态智能检测。依据云原生的架构治理内部服务，由以往的ip、主机重新定义身份信息，并给予认证鉴权。以往的devsecops等依赖于兴师动众的手段，迁移到基础设置提供安全标准能力，不仅仅是默认安全，更是基础架构安全，不给研发人员犯错的机会。

安全乐观主义点评：防止替换boot固件的攻击手段，谷歌从全球采购服务器，Titan 安全密钥采用一块硬件芯片，其中含有 Google 设计的固件，可验证密钥的完整性。这有助于确保密钥未曾遭受物理篡改。

安全乐观主义点评：要面对如何艰苦的形势，才需要具备这样的安全性？

安全乐观主义点评：热迁移、热补丁是技术的要点，带来的收益很高。为了最大化的安全防护，谷歌还对KVM的核心代码进行了如Fuzzing、静态分析、手工核查等一系列安全测试。

安全乐观主义点评：发布系统经常出现的问题是调度和隔离风险。由于谷歌在全球不同的region使用同一个主干仓库，brogmaster要验证每一次的发布方才可以访问指定的代码仓库、传输链路也要加密。CI、CD的制品分发时，也要加密和具备身份验证。多租户间执行任务，要实现各pipeline隔离策略，线上线下环境网络和数据隔离。

安全乐观主义点评：首先有统一的身份审批流程，说明具备了集中的策略扫描、资源角色定义、身份认证机制。具体在物理层面为主机创建身份还不够，为进程创建证书，进程的颗粒度表示具备BAB的能力，只有经过brog发布的服务，才能被访问和运行，结合实际，就是不再担心如下场景：内部员工（或攻击者）通过到具体的某个合法服务，自己部署一个拖库脚本任意访问线上数据库。通过brog发布的代码，一定是经过仓库负责人codereview，然后经过自动化的单测和白盒扫描服务。第二。主机证书是上面服务验证的核心，丢失怎么办？采取轮转的方式缩短暴露的间隔。workload，可以理解为不同的微服务负载，下面将会详细讲到。另外的亮点是实现了人的验证。如果一个合法员工需要进行线上数据的调试、安全调查怎么办呢？不能直接启动ide调试，和beyondcorp联动，在访问数据的grpc凭据附带个人的service account，只有在验证权限列表才能访问最终服务，20分钟失效。

安全乐观主义点评：传统的防护是防止外来攻击，而云原生的零信任是动态的，对服务间的数据传输进行身份标识和验证（不默认开启加密），避免在内网攻击者可以扩散开来。不再基于网络边界进行防护，而是每次都验证身份。传统的基于ip身份验证，但是云环境下，ip动态更新，缩扩容频繁，甚至一个ip背后有多个服务，一个ip，只能表示一层身份，不能表示数据链路调用关系。ip要求服务必须具备运行在主机或者硬件上，但是抽离真正需要防护的服务，就给了serverless应用、大数据作业、分布式应用也提供认证的可能性。传统的安全要求对每个应用进行加固，符合owasptop10、数据安全隐私之类种种制度，而且互相之间没有通过资源策略进行联系。构建和审核，有个Jenkins+sonar已经够用，但是云要求责任统一，有集中性的安全审核和视角。不仅仅要求自己可信，更要求服务调用间证明自己可信。云+互联网的方式服务发布频率快速，有了更快的响应、诊断、恢复、隔离的可能性。传统的攻击，是获取主机权限，然后提权为root。但是在负载之间的隔离，假设入侵了Google的系统，后面会面临着什么，从之前Google Borg生产环境安全来看容器最上层是跑的Google的各种业务，包括Gmail、Adworks、AdSense等，一旦Google的Portal、产品等存在高危漏洞直接进入Google Borg管理的容器中，首先要面对的第一层gVisor（详见Google生产环境安全）沙箱的安全保护，突破这层需要的知识包括，第二层是各种Namespace，包括Network Namespace、Pid Namespace等，要突破这层需要的知识包括内核提权、Google Borg容器逃逸漏洞；第三层是CGroups主要是资源的控制；第四层是Capablitiy的权限控制，需要详细了解各种Capablity的特性，对Linux内核极其了解，第四层就是文件系统层，有账号的安全保护，需要寻找Linux内核的漏洞来进行权限提升；另外Google在RPC调用上也使用了类似强制访问控制的机制，对IP进行限制、调用方的权限进行严格限制、对RPC通信协议进行加密、进行微服务级的安全控制，想渗透整套系统的难度可想而知，需要大量的对抗经验，储备各种安全漏洞，对整个Google的系统非常熟悉，才可以进行艰难的横向移动和权限提升。如果尾随google员工进入办公网，会被检测客户端设备是否可信，看该设备不是公司发行的笔记本网络，或者它的证书已经过期，设备会被分配一个非常有限的访问控制权限的网络，同时后台被校验容许访问的api，权限是24小时。

安全乐观主义点评：Beyondprod的最佳参考对象是istio，全链路鉴权这里提到的euc tickets就是全程票据。建设的核心是alts，验证的身份由证书实现，证书通过titan提供，对应用是透明的，不存在窃取证书的风险。在后端服务的每次请求前，都会匹配service access policy是否符合权限模板。具体的逻辑为：实施多方授权（MPA）为敏感数据的请求作出访问决策；速度限制、与开源第三方目标系统的兼容性。隔离的逻辑是三个策略：统一物理和逻辑隔离架构，将物理安全和网络安全对应，在Google的生产环境中，类似于BeyondCorp的设计，生产服务之间的身份验证植根于基于每台计算机凭据的机器对机器信任中。Google的生产环境不会信任未经授权的设备上的恶意植入；隔离了加密密钥，之前的提到的titan，是容许在本地密钥上使用ACL，以防止远程攻击者解密数据。即使攻击者可以访问加密数据（通过内部破坏或渗透），也可以防止解密；时间隔离：尽快的替换密钥，即使它们没有被泄露。

安全乐观主义点评：GFE，可以参考google next 2020大会介绍的armor、anthos。注意核心的内部服务只鉴权，不加密，可能是基于性能考虑。自研的ssl实现，可以参考下Amazon的s2n。

安全乐观主义点评：alts ，可以看到笔者的上一个文章介绍从gRPC安全设计理解双向证书方案，这里谈到了很多架构设计的原则。BeyondProd的基础就是由alts是实现的，付出的代价是，谷歌必须维护一套复杂的，符合各个国家数据加密要求的，灵活调度全球idc服务的证书系统，如果证书有问题，也要具备降级能力。这个证书的体系是从主机硬件芯片到应用层各个协议都支持的能力。开发者不需要关系如何适配身份体系，如何加白，都是由数据权限（使用AWS或GCP Identity＆认证和授权决策的策略框架 访问管理类IAM产品）自动判断。

安全乐观主义点评：据说alts开始时，还没有tls1.3，所有更灵活，但是只能适用于谷歌内部。mTLS单独指双向 TLS 身份验证：即使用 mTLS 时，客户端和服务器（或另一个客户端）在 TLS 握手期间提供证书，互相证明身份。alts是具体的技术的实现。认证和鉴权方面，通过tls中的namespace认证身份。加密方面，证书天然的加密机制不再说。握手消息，不用隐藏对端通信服务的来源（虽然你有nmap扫描到了服务，但是不能建立通信）。密钥泄露伪装攻击是指获取了证书就可以冒充身份了吗？理论上是可以的，猜测谷歌还有别的访问模型进行安全管控。

安全乐观主义点评：运行公共信任的CA使用商业机构提供的HSM，采用nsjail隔离第三方代码，fuzz安全漏洞报告厂商。签发和认证时使用了多个独立的日志记录系统，通过逐个比较两个系统来确保一致性。

安全乐观主义点评：brogmaster是核心，攻击获取了master的私钥，就可以伪造发布的应用，所以定时更换。用k8s举个的例子：在一个应用发布时，master使用机器主私钥对一个docker进行签名，容许发布应用，master对一个应用镜像仓库创建主证书和私钥，获取签名。master验证docker是否有权限运行这个特定的应用镜像。发起rpc请求时，使用应用镜像的证书标识对外身份。这个例子中，master指代brogmaster，docker指代运行应用的客户端，应用镜像仓库指代workload。实现的效果是:只有经过brogmaster发布的可信的工作负载，才能运行在可信的客户端上。否则，这个客户端不仅仅运行不起来，而且对外通信会失败。

安全乐观主义点评：一、A和B两个微服务之间交互，a有accout为A_servie,B的account为B_service，二、双向认证策略mtls，只容许a访问B，不容许A访问C。三、同时mlts基于alts实现加密。四、每一步带上用户的票据，实现全程票据方案

安全乐观主义点评：传统的内部微服务之间，内网之间无防火墙acl，api网关方案也不可行。由grpc支持各个语言，无开发接入工作量。

安全乐观主义点评：业务团队职责：从个人、服务、资源维度合理审批、及时二次通知、审核、fido。安全团队职责：审计申请记录，观察异常服务调用，3FA

安全乐观主义点评：这里没有提如何进行完整性校验，传统的ak、sk通过摘要的方式验证一致性，证书可以通过公钥加密消息体，私钥+协商算法解析，从通信链路层实现rpc协议的整体加密

安全乐观主义点评：票据在mtls的rpc报文之间传递cuis是票据服务的核心，eut具备原始的认证授权信息，每个入方向的服务，用这个票去cuis验票，不需要鉴权则透传票据。contact服务解密eut，查看是否有地址簿数据权限，调用地址簿服务放回用户数据。解决的问题是：防止遍历：不能直接伪造大量的用户票据；防越权，每个下游服务都去票据服务中心获取授权；缩小攻击范围:B服务沦陷了，但是由于没有A阶段的票据，不能访问C的服务。不能解决的问题：重放攻击，因为票据是有有效的，除非有销毁机制；性能问题，验票环境是瓶颈；需要稳定性：ABC服务都需要支持票据能力，一旦一个环境丢票，用户请求就中断。极大的复杂性：ABC服务都有改造支持在rpc或者http协议中和票据中心有验票逻辑，cuis会有复杂的权限模板，模板要写清ABC各个环节需要的详细权限。

安全乐观主义点评：不要有这个BeyondProd的锤子就到处寻找钉子，不同的安全需求决定了组织所处的安全现状，对应不同的建设手段。

安全乐观主义点评：小编将持续跟踪，分享BeyondProd相关材料。

• 序言

• 安全需求

• 安全方案

• 敏感数据加密传输

• 认证

• 鉴权

• 数据完整性和一致性

• 证书的基本原理

• 单向证书

• 双向证书

• gRPC安全机制

• SSL/TLS认证

• GoogleOAuth2.0

• 自定义安全认证策略

序言

网络安全领域在攻和防对抗规模群体已经成熟，但是两端从业者对于安全原理掌握程度参差不齐，中间鸿沟般的差距构成了漏洞研究领域的主战场。笔者“三省吾身”，在工作中会犯错误把一些加密、认证、鉴权的概念和实现方案搞混，尤其是加解密涉及算法和公私钥机制的概念不深入细节。

最近的几个影响颇大的安全漏洞，Apache Shiro 权限绕过漏洞、CVE-2020-14882weblogic 绕过登录、微软ZeroLogon，这些漏洞原理的共同点都是和基本的安全算法、认证鉴权方案缺陷有关。也许未来的漏洞攻防将转移到安全基础领域的对抗，从业人员除了要求推进安全方案的必要性，涉及安全建设的可用性更为重要，所以特此开专栏系列，为大家普及一些安全基本功。

本文主要通过介绍gRPC的双向认证方案，理清证书领域的知识。

安全需求

RPC是一种技术思想，实现有阿里的 Dubbo/SOFA、Google gRPC、Facebook 的 Thrift，实现时的远程通信规范和协议可以用RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。这种服务间通信机制为企业内部各系统、模块之间的微服务和接口之间互相调用，RPC实现需要考虑安全性，RPC 调用安全主要涉及如下三点：

1. 个人 / 企业敏感数据加密：例如针对个人的账号、密码、手机号等敏感信息进行加密传输，打印接口日志时需要做数据模糊化处理等，不能明文打印；

2. 对调用方的身份认证：调用来源是否合法，是否有访问某个资源的权限，防止越权访问；

3. 数据防篡改和完整性：通过对请求参数、消息头和消息体做签名，防止请求消息在传输过程中被非法篡改。

安全方案

常见的安全攻防重视rpc协议的反序列漏洞，但是如果业务方问道如果做以上的安全需求，SDL同学就傻眼了，正确的做法是区分加密传输、认证、鉴权、数据完整性和一致性四个方向：

敏感数据加密传输

基于SSL/TLS的通道加密

当存在跨网络边界的 RPC 调用时，往往需要通过 TLS/SSL 对传输通道进行加密，以防止请求和响应消息中的敏感数据泄漏。跨网络边界调用场景主要有三种：

1. 后端微服务直接开放给端侧，例如手机 App、TV、多屏等，没有统一的 API 网关/SLB 做安全接入和认证；
2. 后端微服务直接开放给 DMZ 部署的管理或者运维类 Portal；
3. 后端微服务直接开放给第三方合作伙伴 / 渠道。

除了跨网络之外，对于一些安全等级要求比较高的业务场景，即便是内网通信，只要跨主机 /VM/ 容器通信，都强制要求对传输通道进行加密。在该场景下，即便只存在内网各模块的 RPC 调用，仍然需要做 SSL/TLS。

使用 SSL/TLS 的典型场景如下所示：

通道加密的的实现技术难度稍大，对性能有损耗，定制化程度高，但是效果显著，建设收益明显

针对敏感数据的单独加密

有些 RPC 调用并不涉及敏感数据的传输，或者敏感字段占比较低，为了最大程度的提升吞吐量，降低调用时延，通常会采用 HTTP/TCP + 敏感字段单独加密的方式，既保障了敏感信息的传输安全，同时也降低了采用 SSL/TLS 加密通道带来的性能损耗，对于 JDK 原生的 SSL 类库，这种性能提升尤其明显。

它的工作原理如下所示：

通常使用 Handler 拦截机制，对请求和响应消息进行统一拦截，根据注解或者加解密标识对敏感字段进行加解密，这样可以避免侵入业务。

采用该方案的缺点主要有两个：

• 对敏感信息的识别可能存在偏差，容易遗漏或者过度保护，需要解读数据和隐私保护方面的法律法规，而且不同国家对敏感数据的定义也不同，这会为识别带来很多困难；
• 接口升级时容易遗漏，例如开发新增字段，忘记识别是否为敏感数据。

认证

内部 RPC 调用的身份认证场景，主要有如下两大类：

• 防止对方知道服务提供者的地址之后，绕过注册中心 / 服务路由策略直接访问 RPC 服务提供端；
• RPC 服务只想供内部模块调用，不想开放给其它业务系统使用（双方网络是互通的）。

身份认证的方式较多，例如 HTTP Basic Authentication、OAuth2 等，比较简单使用的是令牌认证（Token）机制，它的工作原理如下所示：

工作原理如下：

• RPC 客户端和服务端通过 HTTPS 与注册中心连接，做双向认证，以保证客户端和服务端与注册中心之间的安全；
• 服务端生成 Token 并注册到注册中心，由注册中心下发给订阅者。通过订阅 / 发布机制，向 RPC 客户端做 Token 授权；
• 服务端开启身份认证，对 RPC 调用进行 Token 校验，认证通过之后才允许调用后端服务接口。

鉴权

身份认证可以防止非法调用，如果需要对调用方进行更细粒度的权限管控，则需要做对 RPC 调用做鉴权。例如管理员可以查看、修改和删除某个后台资源，而普通用户只能查看资源，不能对资源做管理操作。

在 RPC 调用领域比较流行的是基于 OAuth2.0 的权限认证机制，它的工作原理如下：

OAuth2.0 的认证流程如下：

• 客户端向资源拥有者申请授权（例如携带用户名 + 密码等证明身份信息的凭证）；
• 资源拥有者对客户端身份进行校验，通过之后同意授权；
• 客户端使用步骤 2 的授权凭证，向认证服务器申请资源访问令牌（access token）；
• 认证服务器对授权凭证进行合法性校验，通过之后，颁发 access token；
• 客户端携带 access token（通常在 HTTP Header 中）访问后端资源，例如发起 RPC 调用；
• 服务端对 access token 合法性进行校验（是否合法、是否过期等），同时对 token 进行解析，获取客户端的身份信息以及对应的资源访问权限列表，实现对资源访问权限的细粒度管控；
• access token 校验通过，返回资源信息给客户端。

步骤 2 的用户授权，有四种方式：

• 授权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

需要指出的是，OAuth 2.0 是一个规范，不同厂商即便遵循该规范，实现也可能会存在细微的差异。大部分厂商在采用 OAuth 2.0 的基础之上，往往会衍生出自己特有的 OAuth 2.0 实现。

对于 access token，为了提升性能，RPC 服务端往往会缓存，不需要每次调用都与 AS 服务器做交互。同时，access token 是有过期时间的，根据业务的差异，过期时间也会不同。客户端在 token 过期之前，需要刷新 Token，或者申请一个新的 Token。

考虑到 access token 的安全，通常选择 SSL/TLS 加密传输，或者对 access token 单独做加密，防止 access token 泄漏。

关于oauth作为安全基本功系列今后还会有专栏。

数据完整性和一致性

RPC 调用，除了数据的机密性和有效性之外，还有数据的完整性和一致性需要保证，即如何保证接收方收到的数据与发送方发出的数据是完全相同的。

利用消息摘要可以保障数据的完整性和一致性，它的特点如下：

1. 单向 Hash 算法，从明文到密文的不可逆过程，即只能加密而不能解密；
2. 无论消息大小，经过消息摘要算法加密之后得到的密文长度都是固定的；
3. 输入相同，则输出一定相同。

目前常用的消息摘要算法是 SHA-1、MD5 和 hmac，MD5 可产生一个 128 位的散列值。SHA-1 则是以 MD5 为原型设计的安全散列算法，可产生一个 160 位的散列值，安全性更高一些。hmac 除了能够保证消息的完整性，还能够保证来源的真实性。

由于 MD5 已被发现有许多漏洞，在实际应用中更多使用 SHA 和 hmac，而且往往会把数字签名和消息摘要混合起来使用。微信支付、阿里云调用是大家常用的签名机制，注意消息摘要不是加密，不是加密，不是加密。

证书的基本原理

目前使用最广的 SSL/TLS 工具 / 类库就是 OpenSSL，它是为网络通信提供安全及数据完整性的一种安全协议，囊括了主要的密码算法、常用的密钥和证书封装管理功能以及 SSL 协议。注意SSL和TLS有不同的历史和标准，HTTPS的意思是HTTP +SSL/ TLS，现在的安全方案一般是tls实现，SSL标准正被淘汰。只是因为沿袭历史称呼，所以经常混用两次名词， SSL被发现存在过 POODLE, DROWN协议算法本身的漏洞，注意区分大名鼎鼎的心脏滴血漏洞Heartbleed是OpenSSL的实现TLS和DTLS的心跳处理逻辑时有bug，而不是利用SSL/TLS协议本身的缺陷。

单向证书

https是大家最熟悉的单项证书方案，由浏览器、ca中心、服务端三方实现。单向认证的过程，客户端从服务器端下载服务器端公钥证书进行验证，然后建立安全通信通道。单向认证流程中，服务器端保存着公钥证书和私钥两个文件，整个握手过程如下：

1. 客户端发起建立HTTPS连接请求，将SSL协议版本的信息发送给服务器端；
2. 服务器端将本机的公钥证书（server.crt）发送给客户端；
3. 客户端读取公钥证书(server.crt)，取出了服务端公钥；
4. 客户端生成一个随机数（密钥R），用刚才得到的服务器公钥去加密这个随机数形成密文，发送给服务端；
5. 服务端用自己的私钥(server.key)去解密这个密文，得到了密钥R
6. 服务端和客户端在后续通讯过程中就使用这个密钥R进行通信了。

双向证书

双向通信流程，客户端除了需要从服务器端下载服务器的公钥证书进行验证外，还需要把客户端的公钥证书上传到服务器端给服务器端进行验证，等双方都认证通过了，才开始建立安全通信通道进行数据传输。

1. 客户端发起建立HTTPS连接请求，将SSL协议版本的信息发送给服务端；
2. 服务器端将本机的公钥证书(server.crt)发送给客户端；
3. 客户端读取公钥证书(server.crt)，取出了服务端公钥；
4. 客户端将客户端公钥证书(client.crt)发送给服务器端；
5. 服务器端解密客户端公钥证书，拿到客户端公钥；
6. 客户端发送自己支持的加密方案给服务器端；
7. 服务器端根据自己和客户端的能力，选择一个双方都能接受的加密方案，使用客户端的公钥加密后发送给客户端；
8. 客户端使用自己的私钥解密加密方案，生成一个随机数R，使用服务器公钥加密后传给服务器端；
9. 服务端用自己的私钥去解密这个密文，得到了密钥R
10. 服务端和客户端在后续通讯过程中就使用这个密钥R进行通信了。

整个双向认证的流程跑通，最终需要五个证书文件：

• 服务器端公钥证书：server.crt
• 服务器端私钥文件：server.key
• 客户端公钥证书：client.crt
• 客户端私钥文件：client.key
• 客户端集成证书（包括公钥和私钥，用于浏览器访问场景）：client.p12

生成这一些列证书之前，我们需要先生成一个CA根证书，然后由这个CA根证书颁发服务器公钥证书和客户端公钥证书。

证书实现的核心是加密，但是也可以被用来做认证，比如istio实现展示了如何用双向证书解决身份、通讯安全，：服务器身份（Server identities）被编码在证书里，但服务名称（service names）通过服务发现或 DNS 被检索。安全命名信息将服务器身份映射到服务名称。身份 A 到服务名称 B 的映射表示“授权 A 运行服务 B“。在双向 TLS 握手期间，客户端Envoy做了安全命名检查，以验证服务器证书中显示的服务帐户是否被授权运行目标服务。

gRPC安全机制

谷歌提供了可扩展的安全认证机制，以满足不同业务场景需求，它提供的授权机制主要有四类：

• 通道凭证：默认提供了基于 HTTP/2 的 TLS，对客户端和服务端交换的所有数据进行加密传输；
• 调用凭证：被附加在每次 RPC 调用上，通过 Credentials 将认证信息附加到消息头中，由服务端做授权认证；
• 组合凭证：将一个频道凭证和一个调用凭证关联起来创建一个新的频道凭证，在这个频道上的每次调用会发送组合的调用凭证来作为授权数据，最典型的场景就是使用 HTTP S 来传输 Access Token；
• Google 的 OAuth 2.0：gRPC 内置的谷歌的 OAuth 2.0 认证机制，通过 gRPC 访问 Google API 时，使用 Service Accounts 密钥作为凭证获取授权令牌。

SSL/TLS认证

用go语言显示下服务端和客户端的调用过程:

服务端使用了证书文件

func main() {
    lis, err := net.Listen("tcp", port)
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }
    // create the TLS credentials from files
    creds, err := credentials.NewServerTLSFromFile("../cert/server.crt", "../cert/server.key")
    if err != nil {
        log.Fatalf("could not load TLS keys: %s", err)
    }
    // create a gRPC option array with the credentials
    opts := []grpc.ServerOption{grpc.Creds(creds)}
    // create a gRPC server object with server options(opts)
    s := grpc.NewServer(opts...)
    pb.RegisterSimpleMathServer(s, &rpcimpl.SimpleMathServer{})
    reflection.Register(s)
    if err := s.Serve(lis); err != nil {
        log.Fatalf("failed to serve: %v", err)
    }
}

客户端使用

func GreatCommonDivisor(first, second string) {
    // create the client TLS credentials
    creds, err := credentials.NewClientTLSFromFile("../cert/server.crt", "")
    // initiate a connection with the server using creds
    conn, err := grpc.Dial(address, grpc.WithTransportCredentials(creds))
    if err != nil {
        log.Fatalf("did not connect: %v", err)
    }
    defer conn.Close()
    c := pb.NewSimpleMathClient(conn)
    a, _ := strconv.ParseInt(first, 10, 32)
    b, _ := strconv.ParseInt(second, 10, 32)
    ctx, cancel := context.WithTimeout(context.Background(), time.Second)
    defer cancel()
    r, err := c.GreatCommonDivisor(ctx, &pb.GCDRequest{First: int32(a), Second: int32(b)})
    if err != nil {
        log.Fatalf("cound not compute: %v", err)
    }
    log.Printf("The Greatest Common Divisor of %d and %d is %d", a, b, r.Result)
}

GoogleOAuth2.0

gRPC 默认提供了多种 OAuth 2.0 认证机制，假如 gRPC 应用运行在 GCE 里，可以通过服务账号的密钥生成 Token 用于 RPC 调用的鉴权，密钥可以从环境变量 GOOGLE_APPLICATION_CREDENTIALS 对应的文件里加载。如果使用 GCE，可以在虚拟机设置的时候为其配置一个默认的服务账号，运行时可以与认证系统交互并为 Channel 生成 RPC 调用时的 access Token。

自定义安全认证策略

参考 Google 内置的 Credentials 实现类，实现自定义的 Credentials，可以扩展 gRPC 的鉴权策略。

• 简介

• 使用介绍：

• Q&A

对象存储介绍:对象存储服务是云厂商提供的一种海量、安全、低成本、高可靠的云存储服务，适合存放任意类型的文件。容量和处理能力弹性扩展，多种存储类型供选择，全面优化存储成本。方便业务在任何时间、任何地点、任何互联网设备上进行上传和下载数据。

简介

Lucian（中文名卢锡安）是一款开源的跨平台网站管理工具

    不同于市面上其他远控工具，虽然支持各项协议的远控如dns、https、tcp、smtp层出不穷，但是一、各种对Cobra Strike 、冰蝎、恶意dns的流量检测技术逐步完善，从协议的隐蔽性和对抗性来说还远远不够；二、云环境下的渗透测试的目标环境会设置严格的安全组或者在vpc内，不能对外出入流量；三、出入的流量均会经过云安全厂商的检测，存在暴露风险。

    这款新工具的特点在于：

1. 基础http协议基于云厂家内部的对象存储，绕过对外连接的安全检测机制
2. 对象存储支持全球网络，速度快，在使用内部的endpoint时可以无对外流量产生
3. 使用云bucket作为数据和命令的跳板作为中转，无需cc服务器，保护安全测试人员

适配国内外主流云厂家的应用场景，已经实现的功能有：

1. 支持windows、linux、mac系统，只要系统上有jdk1.6到jdk12均可运行
2. 支持多种对象存储协议：亚马逊S3\阿里云OSS\腾讯COS
3. 内存编译内存运行，无payload文件落地
4. 全链路https、数据通过Head和put协议走header包发送，隐蔽性高
5. 支持java调用jni方式执行shell（慎用，不兼容的情况下会导致jvm崩溃从而掉线）
6. 上线主机数量无限制，后台支持操作命令详细记录

使用介绍：

1. 安全测试工程师在靶机上编译和运行加载器SennaLoader，当然也可以直接执行java命令运行已编译好的class\jar文件,或者反序列化直接打入这个class。

   

2. 加载器从远端下载payload文件Lucian，进行实时内存编译和内存运行（这时候远端的payload文件可以销毁了~）

3. 自动化执行随机间隔心跳和响应命令的功能，启动上线

   

4. 安全测试工程师配置相应的对象存储地址

   

5. 从远端读取上线主机列表，下发命令、Lucian获取到要执行的命令，执行上报结果

6. 安全测试完成，执行-k命令，进行卸载删除,程序自毁

   

   

Q&A

问：这个工具和蚁剑、冰蝎，哥斯拉有什么区别？

答：这不是一个webshell管理工具，是用java写的rat，提供了一种新的中转通道思路，本质还是基于http的。

问：需要目标系统什么环境，一定要安装jdk吗？

答：不需要jdk（java开发套件），需要java（java运行环境），只要能执行java命令即可，javac的功能是为了无需考虑目标机器的java版本，一次执行成功。你也可以编译为jar包、打包为exe直接运行。

问：对象存储ak、sk需要什么权限？

答：需要对bucket下的对象的读写权限，为了避免泄露内置的ak、sk，自己搭建bucket的可以设置为公共读写。最好填入你在渗透测试过程中发现的业务自身的ak、sk访问业务bucket，endpoint填内网域名如https://oss-cn-regionid-internal.aliyuncs.com，流量更隐蔽。

问：github地址？

答：https://github.com/Ramos-dev/OSSTunnel

问：嗯，还有呢？

答：工具主要面向于合法授权的渗透测试安全人员以及进行常规操作的网站管理员。任何人不得将其用于非法用途以及盈利等目的，否则后果自行承担并将追究其相关责任！

• 安全切面是什么

• 来源于编程概念

• 以Spring Security示例

• 安全领域的切面

• 解读

• 能解决什么？

• 难点在什么？

• 切面安全的未来是Security Mesh

安全切面是什么

来源于编程概念

    在实际企业架构中，业务拥有mvc层次：web接入访问、业务实现处理、数据持久化，各个阶段都需要考虑到应用安全措施。

    但是如果在开发的后期才考虑安全的问题，就可能陷入一个两难的境地：一方面，应用存在严重的安全漏洞，无法满足用户的要求，并可能造成用户的隐私数据被攻击者窃取；另一方面，应用的基本架构已经确定，要修复安全漏洞，可能需要对系统的架构做出比较重大的调整，因而需要更多的开发时间，影响应用的发布进程。

    正确的做法从应用开发的第一天就应该把安全相关的因素考虑进来，并在整个应用的开发过程中，这个时候安全sdl、devsecops都仅仅局限于研发安全。面向切面的编程防御理念提供了这样改造的可能。

    切面的理念是一个编程的范式，在面向过程，面向对象的历史长河中，逐步出现了切面思维。比如安全人员调试漏洞查看线程堆栈报错信息，就是一个典型的面向切面场景。

以Spring Security示例

    下面以目前成熟的，使用了切面理念的spring security框架演示，如何为业务保驾护航建立无需考虑具体的通用日志、安全审计等需求，无需每个功能点都自己实现安全能力，大概进行合理配置和接入，就实现了安全管控。

    用户名username参数未严格过滤输入输出，页面需要进行xss过滤处理，原始的做法是安全基于esapi提供安全sdk进行改造，在编程模式上属于耦合在类方法级别。编码在输出的位置过滤特殊字符。检查对每个输出点进行esapi.securityhtml(username,output)。

    在切面的理念之上，可以改造为由业务定义接入从数据库取出来的username资源和方案数据

 <bean id="userDetailsService"
    class="org.springframework.security.core.securityXSS..JdbcDaoImpl">
    <property name="dataSource" ref="dataSource" />
 </bean>
 <sec:securityXSS>
    <sec:sec-provider user-service-ref="userDetailsService" />
    <if:acttrackcallback waf="waf.seccurity.com" />
    <if:acttrackcallback audit="log.security.com" />
 </sec:securityXSS>

项目中定义资源使用的url地址，完成。

<sec:http>
    <sec:intercept-url pattern="/**" access="ROLE_USER" />
    <sec:form-login />
    <sec:logout />
 </sec:http>

安全领域的切面

    在上面的Spring Security 示例中，并不是各种配置xml的行为就是表示应用了切面，而是背后的esapi.securityhtml(usernam,output)方法替换改造为由org.springframework.security.core.securityXSS.jdbc.JdbcDaoImpl是切面的关键，采用面向切面的软件安全架构思路来进行安全切入，具体编程方法可以预编译、运行时动态代理或者注入的方式等，实现在不修改源代码的情况下给程序动态添加安全功能。

    这样下来安全防御体系的理念不再是单点的防御，形成了重新定义如何获取数据，如何贴合业务，如何部署安全措施的防御框架。

    重新结合上图理解下安全切面需要关注的实现技术：

切面（Aspect）:定义安全的切入点和通知对象，形成成熟的安全产品和机制。

连接点（Joint Point）:指被’感知‘到的安全事件、方案、对象、服务、业务数据。这个概念类似于rasp的hook点，sql审计的对象。

切入点 （Pointcut）：对连接点进行全部操作的定义，对于需要安全看护的点进行环绕增强。需要对数据透视能力，如arms、tlog、链路跟踪、EagleEye，workload之间的访问、授权、认证、加密，MOSN。

通知（Advice）:对拦截到连接点之后要执行的处理。基于智能计算和处理实现管控，包含安全从业人员的日常工作应急的原则+soar等。

代理（Proxy）：对目前服务进行安全能力的增强。如日志记录，性能监控，异常处理、熔断限流这样的非核心功能，单独被抽取出来，与业务代码分离，横切在核心业务代码之上。实现形式是多样如sidecar、proxy、gateway。

解读

    在云原生、物联网、移动互联网、微服务体系、数据安全、AI安全的时代，单独的安全能力不再能由安全团队自己独立完成，必须融入到整体技术体系内，同时要剥离业务复杂，实现安全自主性。安全建设的特点是基于当前企业IT技术架构能力，但是需高于架构视野高标准建设安全能力，完成安全治理。

    理解切面防御的关键在于明白它不是安全防御的目标，而是建设的过程和手段。虽深入业务逻辑，但是各自独立发展，整体安全目标依然是“实现治理感知攻防和审计的安全目标。”和零信任、纵深防御等理念并不冲突。我们的日常工作可以说很多都是在做切面安全防御。

    传统的塔防、河防安全防御侧重静态，名词，状态，组织，数据，载体是空间；切面防御侧重动态，动词，行为，调用，算法，载体是时间空间。切面一定需要代理，有了代理好处多多。

能解决什么？

安全建设能力

    通过安全切面理念把安全能力系统化地融入到技术基础设施和应用服务的内部，同时保持安全响应能力与复杂业务逻辑的结构，形成独立的功能切面，安全既在应用内部，它又是解耦的。比如dauth身份认证的实现就是一个很好的例子。

业务可见

    支持从业务方面透视已完成的全方位的安全治理工作。系统足够复杂，防守方会不知道有多少资产，在大体量的组织内，业务复杂性得像一个分布式操作系统，一点点的技术负债就会导致安全管控能力的严重缺失。我们不自觉的，已经在做很多从切面的日常处理工作，如数据安全治理、操作审计、RBAC。

链路跟踪

    获取全链路信息是切面安全的核心。由于是融入到整个系统内部的，所以安全可以获得大量的这种真实的、完整的、细致的数据来建设异常检测能力、攻击阻断能力，跨应用追溯能力和沙箱隔离能力。这个思路是目前所有甲方的痛点。采集业务方流量数据的稳定性、可靠性、实时性很重要，考虑到应用内外部两部分数据的流动性和量级，属于很难做到但是重要的事情，有余力的可以看下。

方法论

    因为外挂落后了，内生搞不动了，所以那就平行吧。建立一套和业务相交织且平行的安全层，让安全能够深入业务逻辑，实现细致的观测和攻防。能够不依赖于业务代码更新，进行安全治理。

难点在什么？

    安全系统自身的安全性。就像Spring Security看起来很美，但是如果背后的shiro组件出现漏洞，会导致认证绕过漏洞。没有完美的体系，软件是迭代引进的，名为高内聚低耦合，但是安全组件如果“打铁不能自身硬”，自己就会变为攻击者的高价值目标。

    技术难度大。对公司的安全建设来说，干的活还是一样。还得是一步一步解决安全漏洞，逐步进行加固，该响应急的还是得应急。要实现“数据降维视角”，比如通过对调用链路的还原，实现安全内视和追溯，通过代码节点信息，分析和定位的应用内部更精细化的角色信息，需要基础设施整齐划一。安全团队在基本功都具备了的情况下，才有能力寻求新理念打动老板。给出个能不能干成的简单判断标准：没有service mesh，就搞不定。

    非一日之功。不仅需要足够的知识，还需要一定的内部资源，可能并不适合能力不足的团队，不依赖业务能独立安全空间做事情 ，同时具备这样的业务平衡能力和建设时间，几乎是不可能的事情。

切面安全的未来是Security Mesh

    从上面的描述中可以看到新架构解决旧架构中的哪些问题，能否在进一步深入呢？

    切面防御的初心是现实中遇到的问题：一、由大量的微服务构成的分布式应用架构也会增加运维、调试、数据可见、和安全管理的复杂性；二、如果说一台服务器可以在宿主机部署检测进程异常调用，在服务级别的业务docker容器中，安全难以再强加于业务；三在互联网公司应急不能像Google一样实现极致的快速发布。

    在业务的服务架构中，一般可以分为数据面和控制面。在和安全接触的点既然要避免外挂式的安全，折中的方案是做业务面和安全控制面的切入，这个说法就被称为切面安全。

    Goolge把安全和sre统称为SRS，BeyondProd把安全做没了，同样可以把面向切面的作为安全生态的基础架构当做临时解决方案给做没了，让切面的思路扩展为终极目标：Security Mesh。（笔者自己发明的安全新名词，留言轻喷）

    Security Mesh的目标是让安全切面落地的新理念，解决容器和云原生时代的安全挑战，是保障新基建的安全运营基础设施服务。

    Security Mesh概念总结为：作为专用的安全基础设施层，提供提供安全的、快速的、可靠地服务间通讯和资产服务发现，与实际应用部署一起但对应用是透明的，实现了源到服务的安全性，数据链路追踪，热补丁，一系列的完备安全功能

• 网络安全和隐私保护是公司的最高纲领

• 安全支撑组织架构

• SDL实践

• 需求

• 设计

• 开发阶段

• 上线前测试时

• 应急响应

• 供应链安全

• 白盒代码扫描

• 目标

• 建设

• 运营层面

• 代码权限管控

• 安全专家

• 参考资料

浅谈华为SDL实践

    谈华为安全，缺一漏万，笔者认为其是在SDL领域国内最强的公司，其建设的难点也同互联网公司迥然不同，在于历史债务如何处理，如何做工程化，下面简单介绍下软件安全能力建设的部分。笔者希望华为可以更多分享一些安全设计的机制、内部的PSIRT运营、全球网络隐私合规、商业安全工具平台、对客户提供的安全解决方案等。以下内容均基于网络公开信息，笔者已脱敏处理：）

网络安全和隐私保护是公司的最高纲领

    年初华为有任正非签发文《全面提升软件工程能力与实践，打造可信的高质量产品------致全体员工的一封信》，这是一篇最被安全界低估的文章，十年后再看此文的历史地位会堪比亚马逊老板贝佐斯发出的服务化宣言，彻底改变了IT行业。安全圈已经被“以攻促防”思维主导太久了，要转变观念变外挂安全为内生，就得看看华为倡导的扎实的安全工程思想：

安全性（Security）产品有良好的抗攻击能力，保护业务和数据的机密性、完整性和可用性。

韧性（Resilience）系统受攻击时保持有定义的运行状态，包括降级，以及遭遇攻击时快速恢复的能力。

隐私性（Privacy）遵从隐私保护既是法律法规的要求，也是价值观的体现。用户应该能够适当地控制他们的数据的使用方式。信息的使用政策应该是对用户透明的。用户应该根据自己的需要来控制何时接收以及是否接收信息。用户的隐私数据要有完善的保护能力和机制。

可靠性和可用性（Reliability& Availability）产品能在生命周期内长期保障业务无故障运行，具备快速恢复和自我管理的能力，提供可预期的、一致的服务。

    要转变观念，追求打造可信的高质量产品，不仅仅是功能、特性的高质量，也包括产品开发到交付过程的高质量；要从最基础的编码质量做起，视高质量代码为尊严和个人声誉；要深刻理解架构的核心要素，基于可信导向来进行架构与设计；要重构腐化的架构及不符合软件工程规范和质量要求的历史代码；要深入钻研软件技术，尤其是安全技术；要遵守过程的一致性；要改变行为习惯，追求精品；将通过变革形成一套适应上述变化的流程、组织与考核机制。

    互联网公司不要盲目追随DevSecOps文化，只有扎扎实实为用户交付安全的软件，才能从源头上解决安全问题。华为和互联网公司有什么不同呢？它所使用的技术除了云计算、大数据领域外，还会有SDN、5G、IoT，但是和互联网公司一样面临自己（和客户的）攻击面扩大，防护边界模糊、数据泄露风险、隐私保护的问题，华为在网络安全遇到的挑战更甚，面向产品的安全做得也不算差，安全方面专利超过1000件，加入CSA、TCG、TC260等多个安全标准组织、 获10+个主席/副主席安全组织席位。在国际市场上安全方面的应对措施无可挑剔。

安全支撑组织架构

  还记得，之前怼BBC记者的安迪·帕迪吗？他曾是负责网络安全的白宫高级官员，如今身为华为美国的首席安全官，他的上司John Suffolk是华为全球网络安全和隐私官，曾担任英国政府首席信息官。华为在全球有7个研发团队，此外还有两个专门投入安全研究的实验室。其中谢尔德实验室负责面向未来的安全技术的研究，未然实验室对攻防、渗透、漏洞挖掘、情报积累负责，还有云安全，2012都有安全实验室。不得不佩服华为竟然让外国人当安全大boss，对国外人才的开放透明精神彰显文化自信。

SDL实践

  华为是卖产品的，所以主要风险从单产品到集成解决方案系统越来越复杂，以前单产品交付，只要关心安全需求问题、设计和开发引入的问题；逐步多产品交付除了要关心单产品的漏洞外，更要关注产品间的安全依赖，比如从网元到网管系统到本地维护终端到系统集成；后来为用户提供解决方案时，要解决业务功能漏洞、引入的标准化的技术、组件漏洞，设计层面的可信边界扩大、风险增加。华为的是SDL方面的老师，交付的大数据、云、IoT都要端到端有对应的安全解决方案，从初始概念到产品设计、开发、测试、生命周期管理，每个阶段产品的安全性都得到较好的实现：

需求

在产品概念阶段时，聚焦目标市场（如欧美、国内、俄罗斯）、客户（如终端、家庭用户），行业（如如基站、消费者、安防、云）的安全需求形成需求基线，识别产品需要交付的网络安全需求。

设计

设计阶段遵循安全设计原则和设计规范，开展产品安全架构和特性设计。

这个时候微软的威胁建模体系还是可靠的：

开发阶段

    以安全基线、规范、标准、指导书为基准，关注配置管理、交付安全、第三方软件安全是华为进行安全技术检查的checkpoint。遵循安全编码规范，并进行代码的安全扫描和人工检视，确保代码的安全质量。具体措施有安全编码规范里的安全培训、安全SDK、开发中的交叉review、核心代码组织专家开展专项检查、编译时使用安全编译选项。下面会详细讲到。

上线前测试时

    内部专职安全测试团队提前识别产品安全问题，并通过独立第三方对产品进行安全验证和渗透测试，确保产品交付的安全。内部构建安全测试用例库和安全测试平台，确保安全测试能力统一，降低漏测率，自动化执行安全测试用例，提升测试效率。

应急响应

    上线后有对外通过PSIRT建立预警流程，对内通过工单跟踪解决。PSIRT负责接受、处理华为产品和解决方案相关的安全漏洞，同时华为PSIRT是公司对漏洞信息进行披露的唯一出口。内部漏洞由ctr处理。

供应链安全

    产品使用开源/第三方软件之前必须申请，发布前必须通过认证和审核，以确保来源可靠使用可追溯。第三方组件具备产品组件用途反查的能力，发现安全漏洞可迅速查找到关联产品。二进制溯源能力要求对线上版本的二进制，在指定镜像，指定源码下可以编译出来具备一致性。

白盒代码扫描

    《全面提升软件工程能力与实践》中提到“代码就像是高楼大厦的一砖一瓦，没有高质量的代码，可信的产品就是空中楼阁。我们要优化并遵循公司各种编程规范，遵从架构与设计原则，熟练使用各种编程库和API，编写出简洁、规范、可读性强、健壮安全的代码”。虽然近年华为因为美国禁令被Synopsys公司限制了不能再采购coverity，但是类似芯片，已经在代码扫描方面提前布局投入了足够多的资源。

    华为公司做安全编码的对标对象是什么呢？是谷歌、阿里、腾讯等国际大厂的安全编码质量规范，20亿美元的研发投入，高标准目标极其依赖于软件工程能力。下面来具体看下怎么实现累计支持7万亿行代码，日均扫描5万项目，扫描次数13万次，日均扫描313亿行代码，平均每小时扫描百万行，平均误报率小于10%的最佳实践：）

目标

   从目标可以看到华为的思考，目前华为的商业安全工具能力已经将部分的能力移植到华为的devsecops平台，白盒扫描是各项安全措施中效果最快的，但是软件安全没有银弹，根据gartner的报告，代码检查只能发现20%的安全漏洞，SAST和DAST共能发现40%的漏洞。规则是基于已知的策略的限制，或者依赖于功能业务逻辑不能发现问题，笔者认为也许阿里的PRECFIX是未来白盒扫描的方向。

建设

    如果说BAT将pmd、p3c、coverity、foritify视为单独的工具，华为建立的自研平台更类似于sonarqube的能力，工程经验是很值得大家学习的，扫描方面做了如下拆解：

    规则方面支持owasp topN,CWE编码问题、GDPR风险排查、NVD已知漏洞排查。扫描架构如下：

    防误报模型是为了提高缺陷修复的效率，所以对误报类增加了屏蔽处理自动继承、AI自动屏蔽、代码自动修复、智能修复建议。

运营层面

    上图中其他文字介绍基本上大家都懂，但是有个3*3运营是什么呢？

    华为的员工有点像亚马逊，由一群并不是天才的软件工程师构成，虽然早期开发电信级的软件，也有使用cppcheck、checkstyle、cpplint这样的工具类代码检查功能。但是在这时候安全检查工具依赖于新员工入职时的口口相传，具体配置的规则在各个不同的bg、产品线是不同的，而这样原始的技术栈在编译构建完，再跨模块进行审查需要花费大量的时间，这也是SDL太重了的通病，3*3运营体系应运而生。

    3*3体系是指3级检查：IDE检查、门禁级检查、版本级检查。对开发人员在编码、入库、持续集成阶段对检测速度和能力的要求不同，在不同的阶段配置不同的检测规则，较好地兼顾了对检测时间和检测能力的要求。华为是同互联网公司不同的，现在开发的产品可能需要数年时间才面市，所以有时间在最后的大版本发布时，进行全面全量的检测。

    3层运营:产品、产品线、公司层。产品做具体产品的规则集，例行的工单、缺陷修复，产品线有制定产品线的规则要求，搭建运营平台和人员沟通机制，公司层负责构建总体的代码检测能力，规定，通过数据和服务，实现工具、规则的可视化运营。在扩展性方面，类似于Google的Tricorder，支持插件、引擎的、DSL的多项扩展，为云核、无线、网络等产品线提供能力。

代码权限管控

安全专家

    安全是奢饰品，没有钱搞什么SDL，华为专门针对安全的岗位配备了安全SE，简单贴一下JD看下要求吧，要点是华为拥有一大批这样的安全专家。职责描述：

1. 对软件版本安全设计质量负责，负责产品安全特性的分析与设计，对非安全特性的安全性设计进行把关。
2. 对公司及产品线下发和本产品/解决方案发生的安全设计问题组织分析排查，避免问题重犯。
3. 负责公司安全设计要求传递、安全漏洞应急响应技术分析。
4. 负责本产品/解决方案的安全设计能力提升，对特性SE开展安全设计培训。

任职要求：

1. 熟悉安全设计流程和安全设计原则、典型安全架构。
2. 精通安全设计及威胁分析工具使用，熟悉常见的安全威胁及对应的消减方案。
3. 安全知识全面，具备安全管理，安全协议，密码算法，认证管理，会话管理、身份管理、隐私保护、可信计算相关能力。
4. 具备安全漏洞影响分析、漏洞挖掘、漏洞修复能力。

参考资料

http://xinsheng.huawei.com/cn/index.php?app=forum&mod=Detail&act=index&id=4134815 https://www.guancha.cn/politics/2019_05_27_503288.shtml

• 不要神化国外的安全建设

• Twitter的苦衷

• 要解决的问题

• 设计安全方案的原则

• 访问控制架构

• 注意事项

不要神化国外的安全建设

安全做的不差的NetFlix（参考Netflix的DevSecOps最佳实践），因为财报不理想最近股价大跌，Twitter有高危漏洞但是股价并未受影响，更加说明了笔者的论断：企业业务发展远比安全风险给股价带来的长期影响重要.....

此类漏洞举一反三TSRC（参考企业安全建设 丨 当我们在谈论推特安全事件时，我们在谈论什么？）给出的解决办法是一、内部系统需要零信任；二、权限类收敛采用框架集成全链路票据，数据操作层集中验票的，想来在腾讯完全落地有难度，也不能让Twitter快速解决问题。笔者看到Twitter内部这么久还没闭环，作为美国股市精神股东真替他们捉急。：）

根据最新的媒体报告，Twitter认为此次漏洞原因是”公司检测到了一次协同式社交工程攻击，发动者成功锁定了一些具有访问内部系统和工具权限的Twitter员工。黑客利用这些访问权限控制了许多知名账号和密码，之后便使用其账号发布关于比特币的动态。“，属于内部的人为失误\蓄意破坏\信息窃取这一类风险。上一次出类似的事情是前亚马逊工程师Paige Thompson 被指控利用工作方便来访问Amazon云服务上的Capital One服务器。

Twitter的市值只是1/48个谷歌，1/2个百度，市值决定安全的投入，不能盲目崇拜国外科技公司的安全建设。从历史反复漏洞披露的信息看到，Twitter内部存在不少历史安全问题。黑客简单社工后即可完全控制内部系管理统，利用内部权限可以控制用户Twitter账户，无审核机制，直接修改邮件重置密码，用户信息无隐私保护和数据脱敏。

Twitter的苦衷

Twitter案例中关键突破点是内部系统的高权限被社工或收买了。内部应用通常会涉及敏感数据或功能，例如用于生产系统的调试面板、账户管理系统或具有敏感公司数据的数据流和机器学习模型。Twitter安全性做的不好，是因为：

一、现有的商用防护方案又难以覆盖，传统的基于网络、员工身份的隔离方案完全不适用。不能仅仅将这些内部应用程序通过防火墙隔离，网络隔离仍然有可能会被意外配置暴露在公网，而且外部攻击者仍可通过XSS+CSRF或SSRF组合拳攻击，或者通过内网环境中已经隐藏攻击者（黑客或内部人员）。

二、这类问题一般并视为运维安全和办公网安全和开发安全的三者责任间。与生产环境相比，内部应用程序通常会被安全团队有意无意的忽略，安全团队反馈的吐槽是两个大问题：这类系统太多了，属于历史遗留问题；开发语言多样，没有统一的解决方案。

三、安全人员不足：Twitter的安全招聘信息已经挂了两个月了，看来还是缺人惹的祸。

要解决的问题

所以说现在的攻防趋势是技术上直接攻击越来越难，黑客转而关注间接从内部获取权限，并不仅仅遵循从internert-dmz-db存储的方式，走向了internert-内部用户或内部系统-信任关系-db存储。线上的生产环境经过了白帽子反复蹂躏，基本做到了符合安全基线，背后的开发语言、应用框架、资产管理是相对完善的。但是内部的私搭乱建，各种员工机器的的CI|CD系统，重要的内部服务系统，就有五花八门的开发语言，技术和风险了。

设计安全方案的原则

风险是普遍了，问题是需要复盘的。假设我们要防御类似于Twitter这样的攻击，需要安全建设的理念是：

• 不是ServiceMesh架构不能照搬lstio方案
• 防御方案应该是可扩展的，并且兼容后端的技术栈。
• 结合软件开发和发布流程
• 设计出色的技术解决方案还不够，落地才是
• 应用防御措施时，安全团队和开发项目组都需要参与进来

访问控制架构

以上是成形的架构。具体的解决办法是分为五步走：

1. 设置中间层代理，以往员工直接单独访问内部系统进行操作，危害性参考有：无网络隔离直接访问内部系统 里面可能包含未脱敏信息 缺少鉴权机制 这时候加个访问层的代理是解决问题的第一步。加入代理的好处多多，可以收敛入口，设置网络隔离，访问系统管理。一切的机制是在隔层的代理上做，代理的形式可以是api网关、统一portal。
2. 传输层加密。在准备推进代理的时候，不用等系统开发完成，可以调研引入全链路的tls进行传输层的加密。这里的理由有两个：Twitter这样和客户隐私强相关的企业，必须要防止内部网络层的窃听，每一层的安全措施都要做到底。借鉴google自研的ALTS，参考https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security?hl=zh-cn  或者FaceBook的方案 https://engineering.fb.com/security/service-encryption/ ，保证应用传输的安全，借用pki证书或者Kerberos机制可以用来表示服务的身份模型，而且具备极强的架构伸缩性。
3. 做到访问的统一收口，基于代理开发sso+u2f的机制做到访问的统一收口，逐步梳理系统让加入此机制。u2f机制一定层面上杜绝密码猜解、调用、离职员工访问的途径，后续添加FIDO等零信任访问控制措施。
4. 收敛员工的使用新版浏览器，前后端加入监控，日志，埋点，行为检测等功能，由运营风险分析（ORA）团队处置审计。
5. 代理添加通用CSRF保护（添加SameSitecookie标志）和XSS保护（Content-Security-Policy标头+随机数），设置内网waf。比如攻击者有个xss，可以使用csrf获取内部系统信息，这个时候在代理层设置csrf策略，对防护者成本极低，内部应用也无感知，但是收敛面向内部高权限人员xss的危害收益极高。内网的waf听起来会受到的接入阻力较多，但是内网场景固定，干扰项少，实际上内网waf的误报会很少，没有很多的噪音。

注意事项

拍脑袋出具安全方案不是问题，落地有防护效果才是，以下是几个要注意的点：

1. 安全需联合技术团队合作开发维护代理层，并在出现问题随时响应。有数字取证，安全工程或隐私工程方面的技术经验很重要，有维护高可用、系统稳定性运营经验的团队更重要！
2. 基于存量系统增加安全防护系统首先要考虑可维护性，可用性高于安全性，一定要避免出case。
3. 在不影响业务运营的时候同步进行开发和部署。理想情况下，如果代理服务器出现故障，背后存在关键系统，会阻止正常工作，假设如果代理后面有堡垒机，则如果代理发生故障，将再也无法再登录堡垒机故障排除......
4. 推进的节奏不用全面收敛，优先关注高危的风险。 如何确定要收敛的风险范围做到不遗漏呢？内部多打就好了。
5. 向上管理。这个框架可以帮助确定Twitter距离谷歌的差距在哪里，未来的安全投资方向是什么。有基于事件驱动的安全不可怕，没有将策略传达给高级管理层才可怕。笔者这里提供个简单的示例，点击可右移滑动：