开源安全基金会（OpenSSF）正式 成立于 2020 年 8 月 3 日。本文将讨论 OpenSSF 创立的初衷，它成立之初六个月内的成就，以及它未来的愿景。

（LCTT 校注：原文发表于 2 年前， 但时至今日仍然有一些值得了解的信息。）

全世界都在推行开源软件（OSS）理念，所以开源软件的安全也至关重要。为了提升开源软件的安全性，业界已经做了大量工作，并取得了一些成果。这些成果包括：Linux 基金会的 核心基础设施计划 Core Infrastructure Initiative （CII）、GitHub 安全实验室的 开源安全联盟 Open Source Security Coalition （OSSC）和由谷歌以及其他公司创立的 联合开源软件计划 Joint Open Source Software Initiative （JOSSI）。

显然，如果这些成果合为一体，软件行业将发展得更加顺利。这三项成果在 2020 年合并为“旨在促进开源软件安全性的、由各行业巨头主导的跨行业联盟”。

OpenSSF 的确受益于这种“跨行业联盟”；它有几十个成员，（按字母顺序）包括 Canonical、 GitHub、谷歌、IBM、英特尔、微软和红帽。联盟的理事会成员还包括安全社区个人代表，这些个人代表是那些不能以企业名义作为联盟成员的个人。该联盟也创造了一些便于人们合作的组织结构：建立一些活跃的工作组，这种工作组确定（并公布）它存在的价值，其中的成员应当就该组织的技术愿景形成一致意见。

但是这并不重要，除非它们有实际成果。当时虽然处于早期，它们也确实取得了一些成果。它们发布了：

• 安全软件开发基础课程：在 edX 平台上有 3 门免费课程，旨在教授软件开发人员软件安全方面的知识。这些课程注重实际操作，任何开发人员都可以较轻松地学习，而不是那些需要耗费大量资源的理论或案例。开发人员也可以付费参加测试，从而获得认证，表明自己掌握了这些课程地内容。
• 安全评分卡：为开源项目自动生成“安全分数”，帮助用户进行信任、风险和安全方面的决策。
• 关键性分数：基于一些参数，为开源项目自动生成关键性分数。临界分数可以让人们对世界上最重要的开源项目有更好的理解。
• 安全度量仪表盘：这是较早时候发布的成果，它结合安全评分卡、CII 最佳实践和其他数据来源，提供与 OSS 项目有关的安全和支持信息的仪表盘。
• OpenSSF CVE 基准测试：基准测试由超过 200 个历史上的 JavaScript/TypeScript 漏洞（CVE）的脆弱代码和元数据组成。这将帮助安全团队评估市场上的各种安全工具，使他们能够用真实的代码库（而不是合成的测试代码）确定误报和漏报率。
• OWASP 安全知识框架：与 OWASP 的合作成果，它是一个知识库，包含了带检查清单的项目和使用多种编程语言的最佳代码样例。它还提供针对开发者如何使用特定的语言编写安全代码的培训材料，以及用于实际操作的安全实验室。
• 2020 年自由/开源软件贡献者调查报告：OpenSSF 和 LISH 发布了一份报告，其中详细说明了对开源软件贡献者的调查结果，并以此为依据，研究和确定提高 OSS 安全性和可持续性的方法。一共调查了 1200 名受访者。

现有的 CII 最佳实践徽章 项目已经与 OpenSSF 合并，将继续升级。现在项目有很多中文译者，翻译为斯瓦希里语的工作也在进行中，项目也进行了很多小改进，详细阐明获得徽章的要求。

2020 年 11 月举行的 OpenSSF 大会讨论了 OpenSSF 正在进行中的工作。最近，OpenSSF 有这些工作组：

• 漏洞披露
• 安全工具
• 安全最佳实践
• 对开源项目安全漏洞的识别（重点关注指标仪表盘）
• 对关键项目的保障
• 数字身份认证

除了持续更新已发布的项目，未来可能的工作还包括：

• 为减少重复工作，在多种技术指标中确定哪些是重复和关联的安全需求。这就是作为领导者与 OWASP 协作开发，也称为 通用需求枚举 Common Requirements Enumeration （CRE）。CRE 旨在使用一种公共主题标识符，将标准和指南的各个部分联系起来，这种公共主题标识符的作用是令标准和方案制定者高效工作，令标准使用者能搜索到需要的信息，从而使双方对网络安全有相同的理解。
• 建一个网站，提供对安全度量仪表盘的免安装访问。再次强调，这将会提供各种来源（包括安全计分卡和 CII 最佳实践）的数据的简单展示。
• 开发对关键 OSS 项目的识别功能。哈佛大学和 LF 已经做过一些识别关键 OSS 项目的工作。未来一年内，他们会改进方法，添加新的数据来源，从而更好地进行鉴别工作。
• 资助一些关键的 OSS 项目，提高它们的安全性。预期将关注那些财力不足的项目，帮助这些项目提升整体性能。
• 识别和实现已改进和简化的技术，用于数字签名的提交和对身份的校验。

跟所有的 Linux 基金会项目一样，OpenSSF 的工作是由其成员决定的。如果你对大家所依赖的 OSS 安全有兴趣，你可以访问 OpenSSF 网站并以某种方式加入它们。参与的最好方式是出席工作组会议——会议每隔一周就举行，而且非常随意。通过合作，我们可以有所作为。欲了解更多信息，可以访问：

https://openssf.org

作者：David A. Wheeler Linux 基金会开源供应链安全总监

本文 首次发表于 Linux 基金会网站。

via: https://www.linux.com/news/open-source-security-foundation-openssf-reflection-and-future/

作者：The Linux Foundation 选题：lujun9972 译者：cool-summer-021 校对：wxy

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

作为一个偏爱 在桌面电脑上使用 Linux，并鼓励使用开源软件的人，你可能期待就标题中提出的问题得到一个响亮的肯定回答。

然而，我并不打算仅限于讨论开源软件的优点。让我们一起探索更多观点！

在本文，我计划分享我关于开源软件是否安全的思考，以及哪些事情与开源软件的安全性相关。

为什么你需要关注开源软件是否安全？

不论你是使用 Linux 系统还是使用其他类型的操作系统，你都会在某种程度上（直接地/间接地）被开源软件所包围。

举个例子，大多数专有软件工具依赖于某种形式的开源库来保证其正常工作。

此外，各种规模的公司（包括谷歌、微软和 Facebook）依赖开源软件或者以某种途径向开源社区贡献资源是有原因的。

因此，开源软件的安全性是有必要了解的。

有关开源软件安全性的迷思

虽然有多种理由证明开源软件在安全性方面的缺陷，然而其中一些实际毫无意义。

任何人都可以查看并恶意利用开源软件代码

是的，开源软件代码对于任何人都是可访问的。但是你可以查看代码并不意味着你可以利用它。

不现实。

即使任何人都可以复刻（或者拷贝）该软件，原始软件也不能轻易地被修改使用。

通常，项目维护人员（或者维护团队）管理代码仓库，并且接受来自贡献者的提交。开源软件代码在接受之前会被审查。没有人可以就这样劫持代码。

不论是开源软件还是闭源软件，攻击者都需要付出努力来利用软件中的代码漏洞或者添加恶意代码。

没有专职团队，安全性无从谈起

很多人相信如果开源软件没有专职人员或者专职团队，维护软件安全性是困难的。

恰恰相反，由于各种各样类型的贡献者的加入与离开，开源软件获得了来自更大范围的开发者的更多关注。

他们可能比由专有软件所聘用的少数开发者更能够发现安全问题。

一些来自 Mozilla 等同类公司的项目拥有自己的专职团队来高效处理安全问题。同样的，大部分成功的开源项目拥有大量的资源用于保障安全性。

因此，开源软件的生态系统是安全性的组合包。即使没有专职团队，开源项目也可以得到来自各类贡献者的帮助，他们中的一些很大程度上是有利可图的，这有助于他们投入更多的精力。

开源软件是安全的，以下是原因

既然我们已经澄清了这些有关开源软件安全性的迷思，让我重点展示一下开源软件是如何处理安全问题的。

换句话说，开源软件在安全性上的优势。

请不要忘记，开源软件的优势也是 Linux 比 Windows 更好 的一些原因。

更多的眼晴关注开源软件代码

不像专有软件，（对开源软件的）代码访问并不局限于少数几个开发者。

一些开源项目甚至可能拥有数以万记的开发者可以查看代码、审查它们并标记和修复其中的安全性问题。

相比闭源软件，这给予了开源项目拥有快速识别问题并尽快修复它们的能力的优势。

不仅仅限于拥有更多的开发者，企业通常也会参与他们所使用的开源项目。当他们这样做的时候，他们也会查阅代码并审查它们。

这提供了另一条外部审查的途径，而这可能有助于提升开源软件的安全性。

反之，就闭源软件而言，数量有限的开发者可能并不能找出所有种类的安全问题。而且他们可能需要花费更长的时间来一一修复发现的问题。

社区决定安全问题的优先级

闭源软件的开发者可能在处理什么问题和什么时候解决问题等方面有某些限制或者优先等级。

而如果是开源项目，贡献者社区可以自行决定优先级，并自行安排他们想解决的问题以及决定合适修复问题。你不需要依赖于供应商的决定或者按照他们的指示来解决一个安全问题。

着手处理和修复安全问题的决策在开源软件项目中更加透明和灵活。因此，它可以被证明是更有效的，并为你带来以下三个益处：

• 透明度
• 不依赖供应商
• 更快的安全更新

开源软件不是防弹的，以下是原因

虽然在某些情况下，开源软件可能在安全性上具有优势，然而仍有一些因素影响它。

承认这些问题的存在是很重要的，据此，企业或者个人可以就开源软件的安全情况做出更好的决定。

并无足够的眼睛来审查代码和不确定性

即使开源软件代码可以被全世界的开发者自由访问，项目没有足够的贡献者/开发者彻底审查开源代码的可能性仍然存在。

既如此，我们不能对开源软件的同行审查抱有极高的信心，因为它恰好缺失了这一点。

开源软件可能“声称”拥有最高的安全性因为它们是开源的。在没有足够的开发者致力于该项目时，这是一种误导。

同样，我们也无从得知有多少开发者在查看/检查代码，也不知道代码的检查进行到什么程度了。

举例而言， 心脏出血漏洞 Heartbleed 是在一个被广泛使用的项目（OpenSSL）中引入了 2 年以后才被发现的。

软件责任与问责

对于个人用户这可能并不重要，但是开源项目通常并无任何保证。

因此，如果一家公司使用它，它们必须自行承担任何由该软件使用造成的数据丢失与损坏。

这告诉你，没有什么是 100% 安全和没有漏洞的。无论有多少眼睛聚焦在代码上或者贡献者的技术多么精湛，总会存在某种形式的风险，无论是安全风险还是数据丢失。

这告诉我们一个现实：开源软件并非防弹的。

开源软件有其更高安全性的优势，但是...

就安全性而言没有什么优胜者。不论是闭源还是开源，当涉及安全问题时都适用同一套原则。

有很多外部因素可以影响软件安全性，而其中很多因素并不依赖于源代码。

必须以某种形式监控代码，以保证安全。

是的，开源道路提供了闭源软件所不具备的优势，但是这并不意味着开源软件是防弹的。

你对开源软件安全状况有何思考？你又是否认为开源软件比专有软件解决方案更好呢？

提前感谢你在下面的评论中提出的宝贵意见。

via: https://news.itsfoss.com/open-source-software-security/

作者：Ankush Das 选题：lujun9972 译者：CanYellow 校对：wxy

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

华为开发者的补丁将一个内核函数的速度提升了 715 倍

正在开发中的 Linux 6.2 合并了华为开发者雷镇的一个补丁，将 kallsyms_lookup_name() 的查找速度提高了 715 倍。该函数用于根据名字查找一个符号的地址，能用于查找内核符号表中的任何符号。新的改进将算法复杂度从 O(n) 改进为 O(log(n))，极大地提升了查找速度，只是要多耗费一些内存。Linux 内核社区将此补丁评价为“Linux 的圣诞节礼物”。

消息来源：phoronix

老王点评：可喜可贺！顺便说一句，在 Linux 6.1 LTS 中，华为再次以内核补丁数排名第一。

X.org 紧急发布补丁，WayLand 也没逃开

这六个漏洞与 X.Org 服务器扩展中的安全问题有关，是围绕堆栈溢出、使用后释放、越界访问等类似问题，可能导致本地提权和远程代码执行。X.Org 服务器连夜发布了相关补丁。依赖于 X.Org 服务器核心部分的 XWayland 也同样受影响，随之发布了新的补丁。

消息来源：Phoronix

老王点评：老化的代码，可能存在很多潜在的漏洞。但是 Wayland 依然受影响是我没想到的。

谷歌发布开源软件安全漏洞扫描器

谷歌宣布推出 OSV-Scanner，这是一个免费的漏洞扫描器，可以在整个软件供应链中自动发现和修补漏洞。它声称这是最大的社区可编辑的开源漏洞数据库。OSV-Scanner 使开发者能够自动将代码和依赖关系与已知的漏洞列表相匹配，并确定是否有补丁或更新。去年，谷歌推出了开源漏洞（OSV）模式和 OSV.dev 漏洞数据库服务。

消息来源：Venture Beat

老王点评：开源软件漏洞管理是一个重要的、正在发展的市场，谷歌的这些服务瞄准的就是这个市场。

林纳斯定律 Linus's Law 即“ 只要有足够多的眼睛关注，任何漏洞都无处隐藏 given enough eyeballs, all bugs are shallow ”。那么林纳斯定律是如何应用于开源软件安全的呢？

这篇文章讨论 Linux 对开源软件安全的影响。

开源软件的一个常被赞扬的优点是它的代码能够被任何人审查（安全专家通常称之为“代码审计”）。然而，如果你真的去问很多开源软件用户他们上一次检查代码是什么时候。你大概只能收获他们茫然的眼神或者是喃喃的低语。此外，对于一些相当大型的开源应用，有效地审查每一行代码也是困难的。

根据上述这些稍显不安的事实，我们不得不思考：如果没有人察看这些代码，它是开源还是闭源真的有关系吗？

你应该相信开源吗？

计算机爱好者倾向于作出认为开源软件比其他软件更加安全的传统假设。我们通常不会讨论这意味者什么：比较的基础是什么（比什么“更”安全？），或者上述结论是如何得到的。这是一个危险的陈述，因为它表明只要你将一些东西称之为“开源”，它就自动如魔法般地继承了更高的安全性。这不是开源，事实上，这正是开源安全非常反对的。

除非你已经亲自审计并理解了软件代码，否则就不应该假定一个应用程序是安全的。一但你做到了这一点，就可以给予它 终极信任 ultimate trust 。终极信任 不是对计算机而言的，而是对你本人而言的，至少在这一应用程序被渗透攻击之前，你信任它是因为你选择了相信它是安全的。

使用者本人是唯一可以对软件代码给予终极信任的人，因此任何人想要获得这样的享受都必须亲自审查代码。相信其他人的话是不管用的。

在你已经亲自审计并理解了软件代码之前，你对一个应用程序给予的最大信任度是一个范围，可以是从 根本不信任 到 相当信任 之间。然而我们并没有一个关于信任程度的标准对照表，这是一个你必须亲自做出的个人选择。如果你已经从非常信任的人那里听说了一款应用程序是安全的，那么你可能会更信任这个软件，而不是信任那些你没有得到信任建议的东西。

然而，因为无法审计专有（闭源）软件代码，你不可能给予它 终极信任。

林纳斯定律

现实很骨感，并不是每个人都是程序员，同时也不是每个程序员都有时间检查数以万计的代码行。因此如果你没有亲自审查代码，你就只能选择（一定程度上）相信那些 亲自 审查了代码的人。

那么，有哪些人会审查代码呢？

林纳斯定律声称 只要有足够的眼睛关注，任何漏洞都无处隐藏，然而我们并不知道多少双眼睛是“足够”的。请不要低估这一数量，应用程序往往经过了远超你想象数量的人员审查。原始开发人员以及后续开发人员显然清楚他们自己写下的代码，不过开源软件往往都是团队成果，开源时间越长，阅读了代码的开发人员越多。新加入的开发人员也必须回顾项目代码的核心部分，因为他们必须学习基础代码以加入新的功能。

同时，为了使开源软件能够在 Linux 发行版上可用，负责开源软件打包分发的开发人员会加入多个项目。有时一个应用程序可能会在不熟悉项目代码的情况下打包，但是大多数时候，开源软件打包人员都是熟悉所打包的项目代码的。这不仅仅是因为他们不想在他们不信任的软件上签名，还由于他们可能不得不修改代码来使得程序能够正确编译。漏洞报告人员和漏洞修复人员一般也是熟悉代码库的，因为他们需要尝试解决小到运行异常，大到程序崩溃的问题。当然，一些漏洞报告人员不是通过亲自审查项目代码，而是通过关注明显未按预期工作的现象，无意中揭示了代码漏洞。系统管理员通常都是通晓用户依赖的重要应用软件的代码的。最后，还有一些安全研究人员，他们专门深入代码内部以揭露潜在的漏洞。

信任与透明

很多人先入为主的认为大型软件的审计是基本不可能的，因为它由数以万计的代码行组成。不要被软件运行所需的代码量欺骗了。我们不需要真的阅读数以万计的代码行。代码是高度结构化的，可被利用的代码漏洞仅仅只是其中的一行，不过它通常影响软件的全部功能。

当然，也有例外。有时仅仅一个系统调用或者链接一个有缺陷的库文件就可能引入一系列漏洞。幸运的是，多亏安全研究人员以及漏洞数据库所扮演的积极角色，这些错误相对而言是容易发现的。

一些人指着错误追踪系统，比如 通用漏洞披露 Common Vulnerabilities and Exposures （CVE）网站，并推断开源软件显而易见是不安全的。毕竟已经向公众公开了大量的安全风险，涉及许多开源项目。但是不要被数据欺骗了。只是因为我们看不到现闭源软件的漏洞，并不意味着闭源软件中不存在漏洞。事实上，已经有很多针对闭源软件的漏洞攻击提出了，闭源软件也是存在漏洞的。区别在于开发者（以及用户）可以查看开源软件的 所有的漏洞 从而降低漏洞的影响。这是扩大对开源软件信任的系统机制的一部分，却正是闭源软件软件所缺少的。

对于任何代码而言，可能永远没有“足够的眼睛”来发现漏洞，但是开发社区越壮大、越多样化，越有机会发现和修复代码中的缺陷。

信任与人

在开源社区中，参与同一项目的众多开发者已经发现“不安全”的漏洞，却保持沉默的的可能性是微乎其微的，因为人们很少同意以这样的方式合谋。我们已经看到了在应对 COVID-19 的过程中，人类的行为是如何不一致了，在这里也一样：

• 我们都发现了漏洞（病毒）。
• 我们知晓如何避免它传播（待在家里）。
• 然而病毒还是在持续传播，因为总是有一个或者多个人偏离了消减疫情的计划。

开源软件中的漏洞也一样，如果有人发现了漏洞总会公之于众（当然，我们说的是“假如”能够发现）。

然而就专有软件而言，有很大可能参与项目的众多开发者即使注意到不安全的漏洞却仍然保持沉默，因为专有模式依赖于薪水。如果一个开发者将漏洞泄漏出来，他可能只是伤害了该专有软件的声誉，进而降低软件的销售额；或者，在更糟糕的情况下，他可能因此而丢了工作。开发人员拿着薪水秘密地研究软件，往往不会谈论其缺陷。如果你曾经是一名开发者，你可能曾经签署过 NDA （LCTT 译注： 保密协议 Non-Disclosure Agreement ），也被培训过商业秘密的重要性，等等不一而足。专有软件鼓励在面对严重的秘密缺陷时保持沉默，更多时候甚至是强制要求沉默。

信任与软件

不要信任未经你审计的软件。

如果你必须相信未经你审计的软件，那么选择相信已经面向那些更有可能将软件缺陷公之于众的开发者公开代码的软件。

开源软件并没有比专有软件继承更高的安全性，但是修复它的系统得到了更好的规划、实施和人员配置。

via: https://opensource.com/article/21/2/open-source-security

作者：Seth Kenlon 选题：lujun9972 译者：CanYellow 校对：wxy

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

可根据自然语言指令进行《我的世界》游戏的 AI

英伟达最近发布的一篇论文，披露了其为《我的世界》游戏训练的通用 AI 代理 MineDojo。研究人员给它输入了 73 万个 YouTube 视频（转录了超过 22 亿字），抓取了 7000 个维基网页，以及 34 万个 Reddit 帖子和 660 万条评论。人们可以用高级自然语言告诉 MineDojo 代理在游戏中做什么。不同于其它为电子游戏开发的 AI，它们往往只擅长特定的任务，研究人员开发了一个可扩展的训练框架，能够成功执行各种开放式任务的通用代理。

消息来源：Ars Technica

老王点评：能根据自然语言进行游戏，这距离通用 AI 更进一步了。

GPT-3 可以写押韵的诗歌和歌词

OpenAI 宣布了 GPT-3 的一个新模型，人们发现它可以生成押韵的歌曲、打油诗和诗歌，而这是 GPT-3 以前无法产生的水平。用机器生成诗歌并不新鲜，甚至早在 1845 年，发明家们就已经在想办法通过自动化来写出有表现力的诗句。但是，专家们特别指出，GPT-3 的最新模型可以将有关各种主题和风格的知识整合到一个能写出连贯文字的模型中。

消息来源：Ars Technica

老王点评：AI 甚至可以写押韵的诗歌，比那些下三路诗歌强了不止一点。

API 安全漏洞成为大量泄露数据的重要风险

恶意行为者利用 2021 年 12 月披露的一个 API 漏洞，获得了超过 540 万 Twitter 用户的数据。报告称，在过去 12 个月里，95% 的企业在生产用的 API 中遇到了安全问题，20% 的企业由于 API 中的安全漏洞而遭受数据泄露。API 攻击的一个不幸的现实是，这些系统的漏洞提供了对前所未有的数据量的访问。

消息来源：Venture Beat

老王点评：API 是一道通向内部的门，而设计一个完善安全的 API 的重要性，往往被人忽视。

欧盟允许在飞行中使用智能手机

欧盟委员会已经根据最现代的标准调整了关于移动通信的立法。在欧盟范围内，航空公司将能够在其飞机上安装最新的 5G 技术，允许乘客像在地面上一样使用他们的智能手机和其他连接设备。5G 覆盖将通过在飞机上安装一个所谓的 “微蜂窝” 来实现。

消息来源：Slashdot

老王点评：手机真的影响飞行安全吗？

96% 下载的脆弱的依赖关系是可避免的

据一份软件供应链状况报告，对软件供应链攻击的数量在过去的三年里增加了 742%。根据该报告，每月下载的脆弱的依赖关系多达 12 亿个。其中，96% 的下载有一个安全版本。此外，68% 的受访者确信他们的应用程序没有使用脆弱的库。然而，在对企业应用程序的随机扫描中，68% 的人在其开源软件组件中存在已知的漏洞。

消息来源：Venture Beat

老王点评：说到底，安全不仅仅是上游开发者的问题，更多是下游使用者的问题。

72% 的美国员工希望将简单重复的工作交给 AI

根据一项调查，72% 的美国员工会将发票管理、审计和简单的报告等工作任务委托给 AI，以便他们能够专注于使他们在工作中成长的任务。调查还发现，比起年长的工人，更多的 Z 世代对 AI 帮助他们工作感兴趣。

消息来源：Venture Beat

老王点评：这是大势所趋，其实我们身边也逐渐有了越来越多的 AI 接管的工作。