亚马逊云科技开发者社区为开发者们提供全球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、活动与竞赛等。帮助中国开发者对接世界最前沿技术，观点，和项目，并将中国优秀开发者或技术推荐给全球云社区。如果你还没有关注/收藏，看到这里请一定不要匆匆划过，点这里让它成为你的技术宝库！

近几年，开源已经成为组织或者企业软件开发的重要策略之一。

在 Gartner 2019 年发布的报告《Technology Insight for Software Conposition Analysis》中称，2019 年至少 96 % 的代码库包含开源代码。Redhat 在 2021 年《The State of Enterprise Open Source》中就提到，当年已有 90 % 的企业 IT 负责人正在使用开源工具，未来几年内采用开源软件的组织将增长至 75 %。Sonatype 2022 年的《State of the Software Supply Chain》也提到：仅在 2022 年一年，包括 Java、JavaScript、Python 和 .NET 在内的四大生态系统下载量将超过 3 万亿次。

尤其让我感到震撼的是来自世界上最大的代码托管平台 GitHub 于 OCTOVERSE 2022 的一组数据：截止到 2022 年，已经有 9400 万 开发者活跃在 GitHub ，同时也有 90% 以上的公司在使用 GitHub。从这两个数字我们可以看出，GitHub 这个世界上最大的代码托管平台已经被开发者和软件公司们广泛的使用。更重要的是，在 2022 年开发者们共计提交了 4.13 亿次开源贡献，这意味着开源生态成长至今，已经具有一定的规模。

Technology Insight for Software Conposition Analysis blog.sonatype.com/gartner-the...
The State of Enterprise Open Source www.redhat.com/en/enterpri...
State of the Software Supply Chain www.sonatype.com/state-of-th...

开源软件正面临着严峻的安全挑战

正是因为开源代码如今的广泛使用，并具有一定的规模。开源软件也正面临着前所未有的严峻的安全挑战。这些安全挑战自于开源本身的属性，比如：

可访问性：相对于而传统软件的源代码的私有性，开源软件的源代码公开可访问,使其更易受到研究与攻击。
依赖关系复杂：开源软件存在错综复杂的依赖关系，要确保一个应用程序所依赖的全部开源组件的安全修补是异常困难。这需要专门的工具与流程来支撑。
新技术管理难度：新技术常首先通过开源软件出现，而新技术也意味着新的安全问题，这给开源软件安全带来更大难度。需要尽早识别新技术安全风险。

有些安全挑战来自于开源的不断发展，比如：

漏洞管理挑战：随着开源软件项目数量越来越大，涉及的技术范围也越来越广，各类漏洞及其修复版本变得极其困难。这需要社区与企业共同努力。
社区协作不足：是目前开源安全的另一个实际存在的问题和挑战。
持续支持难以保障：当一个开源项目结束后,其安全支持和维护也难以持续保障,这会产生较长时间的安全隐患。这需要社区与企业共同制定长期支持策略。

也正是开源代码本身的特性，以及其发展规模所带来的安全隐患，用传统意义上的安全手段进行防护和管理既不够敏捷，也缺少有效的工具。

亚马逊云科技如何突破开源软件带来的安全隐患

对于使用开源，贡献开源的亚马逊云科技来说，也面临一样的挑战。亚马逊云科技突破开源带来的安全挑战依靠独特的企业文化、有效的管理手段以及在开源项目中的安全实践。

独特的企业文化

亚马逊云科技如今面向构建者提供 200+ 服务的安全运行，面向开发者提供数十种安全的开源工具以及面向开源社区不断贡献开源项目并为这些开源项目的安全不断进行迭代，这一切离不开亚马逊独特的文化。

在亚马逊，有一种独特的员工组织方式，用以优化组织的创新和执行力，这就是 "两个比萨饼团队"，意即保持在两个披萨就能让队员吃饱的小规模团队。

我们知道 2021 年安全领域一个头条新闻就是广为流传的 Log4j 漏洞。在 2022 年 2 月的 ISC 安全大会上，Pulse Survey 问卷调查显示，52% 的团队花了数周或者一个月的时间来补救 Log4j 的问题，48% 的团队为了及时应对，放弃了周末或者是假期来实施补救工作。

而亚马逊云科技 Lambda 团队已经在 3 天内部署了一个补丁，以减轻对 Java 运行时的影响。虽然 Lambda 本身不包括 Log4j，但该补丁有助于减少用户的漏洞，不需要做出任何改变，就可以将用户置于完全保护的进程中。正是 Lambda "双pizza" 团队的及时响应帮助使用者快速响应了问题，避免问题的扩散。

有效的管理手段

亚马逊独特的企业文化为亚马逊云科技构建应用安全奠定了坚实的基础。"两个比萨饼团队"团队的敏捷性同时体现在开发团队的"配置"方式和他们去中心化的安全管理手段。

在开发过程中，对比传统的安全管理模式，去中心化的安全管理手段是将产品团队进行拆分，并在每个拆分的团队中配置安全专家。同时在每个包含安全专家的产品团队中设置安全卫士以及基线安全控制。并将生产上线前，安全测试和审核阶段的威胁模型前移到每个产品团队的开发过程中。

安全专家进驻到每个产品团队，让安全专家了解开发的整个流程，便于故障的快速排查和处理，在每个开发阶段设置安全卫士和基线安全控制有利用更细颗粒度的安全防护。将威胁模型后移大大加快了测试时间，缩短了应用上线的周期。

开源项目中的安全实践

亚马逊的安全文化与其在开源领域的发展起着深远影响，从大家熟悉的、全面提供内置安全的 Bottlerocket，Firecracker，到上个月发布的用于交付应用程序授权策略，实现细颗粒度访问控制的开源语言和 CDK---Cedar，以及基于 Rust 框架,用于构建重播物理内存快照的模糊测试器，以提高效率并减少模糊测试多种类型目标复杂性的 snapchange。

让我们通过几个具体的开源项目，来看亚马逊云科技的安全实践：

Open Cybersecurity Schema Framework (OCSF)

OCSF 由亚马逊云科技联合 CrossRef、牛津大学、SANS 和 Splunk 等于 2020 年 10 月共同创建。OCSF 提供了用于描述安全工具功能的数据模式的初始集合，为实现网络安全工具和实践的互操作性和协作打下了基础。它为网络安全社区提供了一个全面而具有影响力的开源框架。做为 OCSF 的创始成员之一，亚马逊云科技不仅仅联合贡献了这个开源项目，还实现了：

开源多个 OCSF schema。例如：亚马逊云科技发布的 Amazon SecurityFinding 数据模式，用于表示亚马逊云科技的云产品与服务的安全调查结果。该 schema 已被 OCSF 采纳,成为 Vulnerability schema 的一部分。亚马逊云科技还开源了其他如 ComplianceCheck、SecurityHubIntegrations 等 schema。
提供了验证 schema 工具。亚马逊云科技开发了一个名为 SchemaDefinitions 的开源工具，用于验证符合 OCSF 规范的 JSON schema 文件。该工具被广泛用于检验 OCSF 的 schema 标准并确保高质量。
深度整合 OCSF。亚马逊云科技在多项产品与服务中广泛采用 OCSF 的 schema，如 SecurityHub、GuardDuty、Macie 等。这使得亚马逊云科技客户可以更加容易消费和分析来自 OCSF 的标准化数据。同时亚马逊云科技也将自己的数据输出按 OCSF 标准格式化，方便与其他工具集成。
亚马逊云科技提供文档及培训。亚马逊云科技开发了丰富的文档来详细介绍 OCSF 框架及各个 schema，并提供了视频与在线培训课程。这大大降低了 OCSF 详情的学习成本，推动更广大的安全社区了解和采用 OCSF。

亚马逊云科技在技术、社区、内容等多方面对 OCSF 提供了广泛而深入的支持与推动。OCSF 框架的发展离不开亚马逊云科技这样的行业影响着提供的各种资源与影响力。同时，亚马逊云科技采用 OCSF 也使自己的产品与服务在网络安全数据领域具有更好的互操作性与扩展性。

Bottlerocket

开发者常常会遇到只在 Linux 系统上运行容器的生产场景，这种场景并不总是需要一个完整的 Linux 发行版。他们更需要一个特定于容器、仅提供必要软件包的 Linux 系统，轻量级的操作系统也可以减少了部署时间。

2020 年 3 月 10 日，亚马逊云科技正式推出 Bottlerocket，它不是常规 Linux 发行版，如 Ubuntu，Fedora，而是一套用于托管 Linux 容器的新型专用操作系统。它不仅仅优化了系统部署的时间和对底层资源的占用，最关键的是，极简的系统将会带来强大的内置安全：

Bottleroket 仅包含托管容器必需组件，最大限度地减少攻击面；
它使用只读的文件系统，在启动时通过 dm-verity 检查其完整性，来帮助防止基于 rootkit 的攻击；
没有 SSH、解释器（例如 Python）、Shell，使得攻击者将更难在系统当中寻找驻留点。

Firecracker

Firecracker 是帮助开发者实现"创新简化"的另一个开源项目。

在 Firecracker 推出前，开发者告诉我们，当所有的容器都必须使用某个共享的操作系统内核时，现有的容器不能在应用程序之间实现充分的隔离，安全问题很难解决。于是就有了 Firecracker 的开源项目。

Firecracker 一种使用 KVM 的新型虚拟化技术。可以在不到一秒的时间内在非虚拟化环境中启动轻量级微型虚拟机 (MicroVM)，充分利用传统虚拟机提供的安全性实现工作负载间的隔离。每个 Firecracker 的 microVM 仅使用大约 5.24 MB 的内存。这意味着单个虚拟 CPU 上可以运行数千个 Firecracker 的 microVM。

KVM

en.wikipedia.org/wiki/Kernel...

Firecracker 使得上层计算融入了潜水艇隔离仓的安全理念。如果 Serverless 服务是共享操作系统内核，那事实上是没有严格的安全隔离，不同租户使用共享 OS 内核就会有数据泄漏的隐忧。而 firecracker 通过 microVM，使得每个 Lambda 都在独立的 microVM 执行环境中运行，每个 Lambda 的 microVM 执行环境在 Lambda 的生命周期内使用，然后被销毁，不留下痕迹。这样可以保证：

每个函数计算在一个或多个专用执行环境中运行。
每个执行环境承载一个并发调用，但在同一函数的多个串行调用中就地重用。
执行环境在硬件虚拟化虚拟机 (microVM) 上运行。microVM 专用于 Amazon 账户，但可以由账户内跨功能的执行环境重复使用。
MicroVM 被打包到亚马逊云科技拥有和托管的硬件平台 (Lambda Workers) 上。执行环境永远不会跨功能共享，并且 microVM 永远不会跨亚马逊云科技账户共享。

使用 Rust 提高开发的安全性

对于开发者来说，对于底层资源的控制力，意味着开发效率和资源利用率。而安全性则是开发语言的另外一个关键维度。两者都很重要，但是两者确很难兼得。

控制力维度来说，C++ 是一门底层语言，离底层资源最近，因此开发者对底层资源调用拥有最大的控制力，可以直接管理内存、指针，因此它的性能也最强。同时是一门支持低级内存访问的语言，如果开发者没有严格遵循内存安全的最佳实践，很容易产生内存错误，是相对不太安全的。

而对于抽象程度更高的 Python 语言来说，通过强大的库生态系统，可以轻松完成各种功能开发，同时有 GC（Garbage Collection，即垃圾回收）自动内存管理机制，安全级别相对于 C++ 来说，要好很多。但难以获得对底层系统的精确控制，性能也相对较弱。

Rust 在控制力和安全性之间达到良好的平衡。相对于 C++ 来说，Rust 提供了一定的抽象，通过安全性保障让开发者无需过度关注底层细节，但有需要时，也可以通过 unsafe 块获得更高的控制力。

Rust 语言有严格的内存安全性保证，通过最终变量、借用检查器、所有权系统等手段防止大多数安全漏洞的产生，而内存破坏问题是公共漏洞披露系统 (Common Vulnerabilities and Exposures) CVE 安全漏洞的 68% 之根本原因。Rust 语言严格的内存安全性保证，防止大多数安全漏洞的产生，因此是编程语言中安全性较高的。

亚马逊云科技的开发团队使用 Rust 完成了多个重要服务的构建，包括 Firecracker、Bottleneck、Cedar 等，同时也致力于 Rust 开发经验的总结和向更多开发者推荐。自 2019 年起亚马逊云科技就作为 Rust 项目的赞助商提供资金支持；从 2020 年开始直接招聘 Rust 语言的维护者和开发者; 从 2021 年起成为 Rust 基金会的创始成员，参与 Rust 项目的组织建设与治理。

亚马逊坚信：领导者应具备创新能力和持续改进能力。他们需要不断创造价值与变革，并使每个系统和流程在结束时变得比最初找到它时更加理想和完善。

这是对待开源项目的态度，也是亚马逊云科技对待安全的理念。您也可以观看这一部分的视频演讲：

请持续关注 Build On Cloud 微信公众号，了解更多面向开发者的技术分享和云开发动态！