凭借广泛的语言支持，Graudit 可以让你在开发过程中的审计你的代码安全。

测试是软件开发生命周期（SDLC）的重要组成部分，它有几个阶段。今天，我想谈谈如何在代码中发现安全问题。

在开发软件的时候，你不能忽视安全问题。这就是为什么有一个术语叫 DevSecOps，它的基本职责是识别和解决应用中的安全漏洞。有一些用于检查 OWASP 漏洞的开源解决方案，它将通过创建源代码的威胁模型来得出结果。

处理安全问题有不同的方法，如静态应用安全测试（SAST）、动态应用安全测试（DAST）、交互式应用安全测试（IAST）、软件组成分析等。

静态应用安全测试在代码层面运行，通过发现编写好的代码中的错误来分析应用。这种方法不需要运行代码，所以叫静态分析。

我将重点介绍静态代码分析，并使用一个开源工具进行实际体验。

为什么要使用开源工具检查代码安全？

选择开源软件、工具和项目作为开发的一部分有很多理由。它不会花费任何金钱，因为你使用的是一个由志趣相投的开发者社区开发的工具，而他们希望帮助其他开发者。如果你有一个小团队或一个初创公司，找到开源软件来检查你的代码安全是很好的。这样可以让你不必单独雇佣一个 DevSecOps 团队，让你的成本降低。

好的开源工具总是考虑到灵活性，它们应该能够在任何环境中使用，覆盖尽可能多的情况。这让开发人员更容易将该软件与他们现有的系统连接起来。

但是有的时候，你可能需要一个功能，而这个功能在你选择的工具中是不可用的。那么你就可以选择复刻其代码，在其上开发自己的功能，并在你的系统中使用。

因为，大多数时候，开源软件是由社区驱动的，开发的速度往往是该工具的用户的加分项，因为他们会根据用户的反馈、问题或 bug 报告来迭代项目。

使用 Graudit 来确保你的代码安全

有各种开源的静态代码分析工具可供选择，但正如你所知道的，工具分析的是代码本身，这就是为什么没有通用的工具适用于所有的编程语言。但其中一些遵循 OWASP 指南，尽量覆盖更多的语言。

在这里，我们将使用 Graudit，它是一个简单的命令行工具，可以让我们找到代码库中的安全缺陷。它支持不同的语言，但有一个固定的签名集。

Graudit 使用的 grep 是 GNU 许可证下的工具，类似的静态代码分析工具还有 Rough Auditing Tool for Security（RATS）、Securitycompass Web Application Analysis Tool（SWAAT）、flawfinder 等。但 Graudit 的技术要求是最低的，并且非常灵活。不过，你可能还是有 Graudit 无法满足的要求。如果是这样，你可以看看这个列表的其他的选择。

我们可以将这个工具安装在特定的项目下，或者全局命名空间中，或者在特定的用户下，或者任何我们喜欢地方，它很灵活。我们先来克隆一下仓库。

$ git clone https://github.com/wireghoul/graudit

现在，我们需要创建一个 Graudit 的符号链接，以便我们可以将其作为一个命令使用。

$ cd ~/bin && mkdir graudit
$ ln --symbolic ~/graudit/graudit ~/bin/graudit

在 .bashrc （或者你使用的任何 shell 的配置文件）中添加一个别名。

#------ .bashrc ------

alias graudit="~/bin/graudit"

重新加载 shell：

$ source ~/.bashrc # 或
$ exex $SHELL

让我们通过运行这个来检查是否成功安装了这个工具。

$ graudit -h

如果你得到类似于这样的结果，那么就可以了。

图 1 Graudit 帮助页面

我正在使用我现有的一个项目来测试这个工具。要运行该工具，我们需要传递相应语言的数据库。你会在 signatures 文件夹下找到这些数据库。

$ graudit -d ~/gradit/signatures/js.db

我在现有项目中的两个 JavaScript 文件上运行了它，你可以看到它在控制台中抛出了易受攻击的代码。

你可以尝试在你的一个项目上运行这个，项目本身有一个长长的数据库列表，用于支持不同的语言。

Graudit 的优点和缺点

Graudit 支持很多语言，这使其成为许多不同系统上的用户的理想选择。由于它的使用简单和语言支持广泛，它可以与其他免费或付费工具相媲美。最重要的是，它们正在开发中，社区也支持其他用户。

虽然这是一个方便的工具，但你可能会发现很难将某个特定的代码识别为“易受攻击”。也许开发者会在未来版本的工具中加入这个功能。但是，通过使用这样的工具来关注代码中的安全问题总是好的。

总结

在本文中，我只介绍了众多安全测试类型中的一种：静态应用安全测试。从静态代码分析开始很容易，但这只是一个开始。你可以在你的应用开发流水线中添加其他类型的应用安全测试，以丰富你的整体安全意识。

via: https://opensource.com/article/20/8/static-code-security-analysis

作者：Ari Noman 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Linux 基金会宣布成立 OpenSSF

OpenSSF 是一个跨行业的协作，通过构建一个具有目标计划和最佳实践的更广泛的社区，将领导者聚集在一起，以提高开放源码软件的安全性。它结合了 CII（核心基础设施倡议）、GitHub的开放源码安全联盟和其他开放源码安全工作。OpenSSF 打算托管各种开源技术倡议，以支持世界上最重要的开源软件的安全，所有这些都将在 GitHub 上公开完成。

来源：LFAPAC

拍一拍：开源软件的安全问题已经需要越来越多重视。

Netcraft 7 月全球 Web 服务器调查报告发布

大部分主要服务器 7 月在站点总数上都有所增加，其中 Apache 增长了 980 万个站点，微软和 nginx 分别增长了 540 万和 250 万个站点。nginx 在域名方面增长最明显，共涨了 200,000，微软丢失了 110 万个域，Apache 丢失了 99.8 万，也使得 nginx 在该指标上的领先地位更进一点加强，现在它已经拥有约 3000 万个域，占有 29.8％（+0.27 pp）的市场份额。

来源：开源中国

拍一拍：NGINX 还是一如既往的占有优势。

JavaScript、Ruby 和 Java 是间接依赖中存在缺陷最多的生态系统。

开源项目中的绝大多数安全漏洞都存在于间接依赖关系中，而不是存在于直接加载的组件之中。

“汇总所有生态系统的数字后，我们发现间接依赖中存在的漏洞数量是直接依赖的三倍以上。”Snyk 的应用安全顾问 Alyssa Miller 在接受讨论 Snyk 的《2020 年开源安全状况报告》的采访时说。

该报告研究了漏洞如何影响 JavaScript（npm）、Ruby（RubyGems）、Java（MavenCentral）、PHP（Packagist）和Python（PyPI）生态系统。

Snyk 表示，项目内部加载的主要组件所依赖的依赖库，受到了 86% 的 JavaScript 安全漏洞、81% 的 Ruby 漏洞和 74% 的 Java 漏洞的影响。

Snyk 认为，公司在扫描他们的主要依赖项是否存在安全问题时，如果不能探索其完整依赖树的多个层次，会导致发布或最终运行容易受到不可预见的缺陷影响的产品。

但是，虽然安全缺陷在 JavaScript、Ruby 和 Java 中普遍存在，但在 PHP 和 Python 中却不是这样，绝大多数缺陷都存在于直接依赖关系（主要组件）中。当然，这是有原因的。

“老实说，我发现这更多取决于生态系统内部本身的开发方法。”Miller 说。“尤其是 Java 和 Node.js 项目，似乎比其他生态系统更重地利用了依赖性。特别是，当你看到 Node.js 生态系统的庞大规模时，从其他包构建或利用关键功能的包是非常正常的。”

“询问任何 Node.js 开发人员，他们都可能会遇到这样的事，即在 npm 试图拉取所有必要的依赖关系时，等待很长时间才能打开一个项目，”Miller 补充说。“我们最喜欢的一个例子是一个 80 行的 Java 应用程序，指定了 7 个依赖关系。然而，当你走完整个依赖树时，你会发现有 59 个子依赖，突然间，80 行代码变成了 74 万行。”

“正如我们喜欢给它起的绰号，这种‘陌生人的危险’，是一些重大安全漏洞的根本原因，也是造成软件供应链安全复杂化的关键原因，”Miller说。

少量的缺陷会造成了巨大的影响

但 Snyk 团队并不只是看这些缺陷在开源生态系统中的位置，还看它们是什么类型的缺陷。

另一个有趣的发现是，2019 年发现的大部分新安全漏洞都是跨站脚本（XSS）缺陷，尽管数量很多，但这些缺陷只影响了一小部分实际运行的项目。

相反，在去年发现的所有缺陷中，有二十几个原型污染缺陷的影响最大，影响了超过 11.5 万个不同的开源项目，可能还有更多的私有项目也受影响。其中，jQuery 和 LoDash 的原型污染缺陷影响最大，因为这些框架是目前应用最广泛的 JavaScript 开发工具集。

但是，Snyk 团队在报告中还指出了另一个不寻常的地方，即“恶意软件包”被列为他们去年在项目中发现的第二大最常见的安全问题类型。这指的是故意出于恶意创建的开放源代码库，或者是开发人员帐户被黑并且代码中毒的库。

根据 Snyk 的说法，去年，被黑的或恶意的软件包是开源生态系统中第二大最常见的安全问题来源。“这些绝大多数（超过 87％）来自 npm （JavaScript）软件包，” Miller 说。

去年的安全问题不那么严重，但也不值得庆祝

此外，Snyk 还指出，他们在所扫描的所有五个生态系统中发现的缺陷数量下降了 20％。

“很难确定（它们因为什么下降），”Miller 说。“以我这种永久安全怀疑论者来说，这可能只是自然的退潮和流动的一部分。然而，在乐观的一面，我们确实看到了社区的一些关键变化，这可能意味着这不仅仅是这一年的异常值。”

“例如，我们看到所报告的跨站点脚本（XSS）漏洞比任何其他漏洞类型都多，它们只影响了我们当年扫描的总项目中的一小部分。这表明，XSS 可能不会影响到使用率更高因而更成熟的项目，这意味着人们可能更多关注安全编码技术方面。”

“此外，我们的调查显示，整个社区的态度开始将软件安全视为开发团队和安全团队（甚至在某种程度上是运营团队）之间的共同责任，”Miller 说。

“这种合作的改善无疑可以帮助推动围绕安全代码和安全使用开源包的更好的意识和战术措施。”

“我在安全领域工作了 15 年，我当然还没有准备好宣布某一年是事情出现转机的标志，但你可以认为这是一个趋势，我们将继续观察，看看未来几个月和整个 2020 年的情况如何。”

关于开源社区总体安全状况的其他见解，Snyk 的完整报告可在这里下载。

via: https://www.zdnet.com/article/more-than-75-of-all-vulnerabilities-reside-in-indirect-dependencies/

作者：Catalin Cimpanu 译者：wxy 校对： wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

华为否认提交给 Linux 内核的不安全补丁 HKSP 来自官方

上周有华为工程师为 Linux 内核提交了一个内核强化补丁 HKSP（华为内核自我防护Huawei Kernel Self Protection），不过在代码检查后，该补丁被发现存在安全漏洞。根据 ZDNet 的消息，华为已经在周一的一份声明中表示，尽管该项目的名称中使用了“华为”，并且该项目是由其一名顶级安全工程师开发的，但华为并未正式参与 HKSP 项目。华为同时也表示，该项目代码从未在任何正式的华为产品中实际使用过：“这只是个人用于与开源社区 Openwall 进行技术讨论的演示代码。”

来源：开源中国

硬核老王点评：本来是一个普普通通的代码质量问题，但在有些人解读之下却浮想联翩。不过，个人项目冠名华为这样的行为在该公司是允许的吗？

阿里云自研数据仓库 AnalyticDB 再捧 TPC 全球冠军

5月14日，TPC 官网正式公布，阿里云自研的 AnalyticDB 通过了TPC-DS全流程测试，将前世界纪录的性能提升了29%，并把单位成本降低了三分之二，成功夺得全球数据仓库的桂冠。

来源：CSDN

硬核老王点评：似乎对阿里云热衷于得到各种比赛的冠军已经有点麻木了。

腾讯受益于疫情收入大涨

新冠病毒疫情带动“宅经济”发展，中国最大的游戏和互联网巨头腾讯控股周三公布，首季度净利按年增长 6%，而按非国际财务报告准则（Non-GAAP）净利增幅更达29%，内地防疫家居隔离带动其网络游戏及网络广告收入增长。然而，随着内地各地陆续复工复产，腾讯预期，游戏的用户使用时长及游戏内消费活动将大致回复正常水平，但公司相信，游戏行业已从结构上扩大了其长期受众及吸引力。

来源：solidot

硬核老王点评：虽然不能说游戏是邪恶的，但是一家公司因为这种情况带来的这种收入大涨，怎么也感觉有点不对味。当然，曾经有信誓旦旦不做游戏的公司最终也是投资了游戏行业，其实想想公司都是为牟利而生的，也就不足为怪了。只希望这些公司在牟利的同时不要忘记社会责任感。

Deno 1.0 发布

Deno 是作者 Ryan Dahl 在 Node 之后的又一大作，它是一个新的运行时，用于在 Web 浏览器之外执行 JavaScript 和 TypeScript，其采用 Rust 编写而成。Deno 试图提供一个独立的工具来快速编写复杂功能的脚本，它将始终是单个可执行文件。就像 Web 浏览器一样，它知道如何获取外部代码。在 Deno 中，单个文件可以定义任意复杂的行为，而无需任何其它工具。Ryan Dahl 认为过去他在设计 Node 时犯了一些错误，包括安全性、构建系统、package.json、node\_modules、index.js 等等，并表示 Node 存在的种种不足导致有许多严重问题且不可回避，当前 JavaScript 和周围的软件基础架构已经发生了巨大的变化，值得进行简化，于是他重新设计了 Deno 这门脚本语言。

来源：开源中国

硬核老王点评：确实 Node.JS 在取得成功的同时，也暴露出之前的一些先天不足。这个值得期待。

最冷清的应用商店：Windows 10 商店

无论是 iOS 还是 Android，系统内置的应用商店都门庭若市。然而在 Windows 10 上，情况却截然不同——自带的应用商店门可罗雀，时至今日，绝大部分用户在 Windows 10 中安装软件的主流方式，依然是自行下载软件安装，Windows 10 商店似乎已然是一个鸡肋般的存在。

来源：太平洋电脑网

硬核老王点评：这样比起来，Linux 桌面的应用商店（软件中心）或许更被用户所接受。

CreepRank 算法帮助谷歌 Play 商店剔除了 813 款 Android 蠕虫应用

据悉，来自纽约大学、康奈尔科技学院、以及 NortonLifeLock（原赛门铁克）的学者们，对这些蠕虫软件展开了深入的分析。这里提到的蠕虫，特指不具有完整的间谍或追踪功能的移动 App 。即便如此，别有用心的开发者仍可借此对用户展开间接追踪、骚扰、欺诈或威胁他人。研究团队开发的 CreepRank 算法，能够识别移动 App 中疑似的蠕虫行为，然而对每款 App 进行打分。

来源：cnBeta.COM

UCloud 发布物联网边缘网关 IoT Edge，实现边云协同

用户可以将 UIoT Edge 运行系统直接安装到符合要求的 X86、ARM 硬件网关。该系统实现了子设备数据的采集、解析、清洗、加工、缓存，本地场景的实时控制与联动，可广泛应用于工业制造、能源电气、智慧社区、物业楼宇、智能农业、新零售等领域。UIoT Edge 边缘网关提供子设备接入、函数计算、消息路由、一键部署/远程运维和本地 Web Portal 五大功能。目前，UIoT Edge进入公测阶段。

来源：UCloud

Linux 与 Windows 10 相比的一个优势是它更安全，但是 Linux 系统并不是绝对可靠的， 美国国家标准技术研究院 （ National Institute of Standards and Technology ） （NIST）的 国家漏洞数据库 （ National Vulnerability Database ） （NVD）的最新数据似乎证实了这一点。

Windows 中的安全缺陷更少

根据其数据，在 1999 - 2019 年期间，Debian Linux 是所有操作系统中带有安全漏洞最多的一个。在此期间，在 Debian Linux 中报告了 3067 个漏洞，在 Ubuntu 中报告了 2007 个漏洞。另一方面，Windows 7 受到了 1283 个漏洞的困扰，在 Windows 10 中才发现了 1111 个漏洞。

从历史上看，Windows 并不是为安全而设计的，但是从 Windows XP 开始微软更加重视 Windows 的安全性，在 Windows XP 中就包括了各种安全功能和强大的防火墙。为了应对日益增长的安全性问题，微软还开始给 Windows 更新更多的安全性和隐私功能，但是 Windows 的一个主要目标仍然是为大多数个人和商用计算机提供了动力。

另外，对于更早的 Windows 7 而言这个数字实际上要低于 Windows 10。例如，在 2019 年，Windows 7 中发现了 250 个安全缺陷，而 Windows 10 中发现了 357 个安全缺陷。

重要的是要知道，计算机上的许多漏洞都是由硬件组件（例如芯片组和驱动程序）引起的，而不是由操作系统本身引起的。 许多 Windows 漏洞都是针对企业的，因此，某些漏洞可能不会对最终用户造成不良影响。

不过，值得注意的是，Debian Linux 表示其社区通常会在几天内修复该漏洞。另一方面，Windows 用户有时必须等待一个月。

整体微软产品线安全缺陷最多

但是回溯这整整 20 年来看，这些数据所描述的景象更加完整。在查看整个公司的产品时，微软产品的安全缺陷比任何其他公司都要多。自 1999 年以来，微软产品总共发现了 6814 个漏洞。以下是前 5 名：

1. 微软：6814 个安全缺陷
2. 甲骨文：6115 个安全缺陷
3. IBM：4679 个安全缺陷
4. 谷歌：4572 个安全缺陷
5. 苹果：4512 个安全缺陷

Android 的安全缺陷数量持续霸榜

近年来，在所有技术产品中，安全缺陷数量逐年保持稳定高位的是谷歌的 Android 操作系统。根据该数据报告，Android 在 2019 年、2017 年和 2016 年是所有操作系统中安全缺陷最多的一个。只有在 2018 年，Android 才从冠军席位上临时掉下来一次，当年 Debian GNU/Linux 的安全缺陷更多。在 2019 年，Android 凭借着 414 个安全缺陷位居榜首，而 Debian Linux 以 360 个安全缺陷“夺得”亚军，而 Windows 10/Windows Server 2016&2019 以 357 个安全缺陷“屈居”季军。

以下是历年来安全缺陷最多的产品：

也许最令人担忧的趋势是，随着操作系统和其他软件产品变得越来越复杂，漏洞在最近 20 年中才有所增加。1999 年，仅报告了 894 个技术漏洞。而在 2019 年报告了 12174 个技术漏洞，增长了 14 倍以上。

不过，对此数据的解读，Android 发言人发表了以下声明：

“我们致力于提高透明度，并每月发布有关 Android 中已解决的问题的公共安全公告，以加强生态系统的安全性。我们不同意这样的观点，即衡量操作系统中已解决的安全问题的数量来表示平台的安全性。这实际上是 Android 生态系统按预期工作的开放性的结果。”

Ref：softpedia.com，fastcompany.com，windowslatest.com

在默认的情况下，网站的安全性还不足够。

在过去的几年里，寻找一个只以 “http://…” 开头的网站变得越来越难，这是因为业界终于意识到，网络安全“是件事”，同时也是因为客户端和服务端之间建立和使用 https 连接变得更加容易了。类似的转变可能正以不同的方式发生在云计算、边缘计算、物联网、区块链，人工智能、机器学习等领域。长久以来，我们都知道我们应该对存储的静态数据和在网络中传输的数据进行加密，但是在使用和处理数据的时候对它进行加密是困难且昂贵的。可信计算（使用例如 受信任的执行环境 Trusted Execution Environments TEEs 这样的硬件功能来提供数据和算法这种类型的保护）可以保护主机系统中的或者易受攻击的环境中的数据。

关于 TEEs，当然，还有我和 Nathaniel McCallum 共同创立的 Enarx 项目，我已经写了几次文章（参见《给每个人的 Enarx（一个任务）》 和 《Enarx 迈向多平台》）。Enarx 使用 TEEs 来提供独立于平台和语言的部署平台，以此来让你能够安全地将敏感应用或者敏感组件（例如微服务）部署在你不信任的主机上。当然，Enarx 是完全开源的（顺便提一下，我们使用的是 Apache 2.0 许可证）。能够在你不信任的主机上运行工作负载，这是可信计算的承诺，它扩展了使用静态敏感数据和传输中数据的常规做法：

• 存储：你要加密你的静态数据，因为你不完全信任你的基础存储架构。
• 网络：你要加密你正在传输中的数据，因为你不完全信任你的基础网络架构。
• 计算：你要加密你正在使用中的数据，因为你不完全信任你的基础计算架构。

关于信任，我有非常多的话想说，而且，上述说法里的单词“完全”是很重要的（在重新读我写的这篇文章的时候，我新加了这个单词）。不论哪种情况，你必须在一定程度上信任你的基础设施，无论是传递你的数据包还是存储你的数据块，例如，对于计算基础架构，你必须要去信任 CPU 和与之关联的固件，这是因为如果你不信任他们，你就无法真正地进行计算（现在有一些诸如 同态加密 homomorphic encryption 一类的技术，这些技术正在开始提供一些可能性，但是它们依然有限，这些技术还不够成熟）。

考虑到发现的一些 CPU 安全性问题，是否应该完全信任 CPU 有时自然会产生疑问，以及它们是否在针对其所在的主机的物理攻击中具有完全的安全性。

这两个问题的回答都是“不”，但是在考虑到大规模可用性和普遍推广的成本，这已经是我们当前拥有的最好的技术了。为了解决第二个问题，没有人去假装这项技术（或者任何的其他技术）是完全安全的：我们需要做的是思考我们的威胁模型并确定这个情况下的 TEEs 是否为我们的特殊需求提供了足够的安全防护。关于第一个问题，Enarx 采用的模型是在部署时就对你是否信任一个特定的 CPU 组做出决定。举个例子，如果供应商 Q 的 R 代芯片被发现有漏洞，可以很简单地说“我拒绝将我的工作内容部署到 Q 的 R 代芯片上去，但是仍然可以部署到 Q 的 S 型号、T 型号和 U 型号的芯片以及任何 P、M 和 N 供应商的任何芯片上去。”

我认为这里发生了三处改变，这些改变引起了人们现在对 机密计算 confidential computing 的兴趣和采用。

1. 硬件可用：只是在过去的 6 到 12 个月里，支持 TEEs 的硬件才开始变得广泛可用，这会儿市场上的主要例子是 Intel 的 SGX 和 AMD 的 SEV。我们期望在未来可以看到支持 TEE 的硬件的其他例子。
2. 行业就绪：就像上云越来越多地被接受作为应用程序部署的模型，监管机构和立法机构也在提高各类组织保护其管理的数据的要求。组织开始呼吁在不受信任的主机运行敏感程序（或者是处理敏感数据的应用程序）的方法，更确切地说，是在无法完全信任且带有敏感数据的主机上运行的方法。这不足为奇：如果芯片制造商看不到这项技术的市场，他们就不会投太多的钱在这项技术上。Linux 基金会的机密计算联盟（CCC）的成立就是业界对如何寻找使用加密计算的通用模型并且鼓励开源项目使用这些技术感兴趣的案例。（红帽发起的 Enarx 是一个 CCC 项目。）
3. 开放源码：就像区块链一样，机密计算是使用开源绝对明智的技术之一。如果你要运行敏感程序，你需要去信任正在为你运行的程序。不仅仅是 CPU 和固件，同样还有在 TEE 内执行你的工作负载的框架。可以很好地说，“我不信任主机机器和它上面的软件栈，所以我打算使用 TEE，”但是如果你不够了解 TEE 软件环境，那你就是将一种软件不透明换成另外一种。TEEs 的开源支持将允许你或者社区（实际上是你与社区）以一种专有软件不可能实现的方式来检查和审计你所运行的程序。这就是为什么 CCC 位于 Linux 基金会旗下（这个基金会致力于开放式开发模型）并鼓励 TEE 相关的软件项目加入且成为开源项目（如果它们还没有成为开源）。

我认为，在过去的 15 到 20 年里，硬件可用、行业就绪和开放源码已成为推动技术改变的驱动力。区块链、人工智能、云计算、 大规模计算 webscale computing 、大数据和互联网商务都是这三个点同时发挥作用的例子，并且在业界带来了巨大的改变。

在一般情况下，安全是我们这数十年来听到的一种承诺，并且其仍然未被实现。老实说，我不确定它未来会不会实现。但是随着新技术的到来，特定用例的安全变得越来越实用和无处不在，并且在业内受到越来越多的期待。这样看起来，机密计算似乎已准备好成为成为下一个重大变化 —— 而你，我亲爱的读者，可以一起来加入到这场革命（毕竟它是开源的）。

这篇文章最初是发布在 Alice, Eve, and Bob 上的，这是得到了作者许可的重发。

via: https://opensource.com/article/20/1/confidential-computing

作者：Mike Bursell 选题：lujun9972 译者：hopefully2333 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出