我们很高兴与大家分享，OpenSSF总经理Brian Behlendorf今天在美国众议院科学、空间和技术委员会作证。布莱恩的证词分享了开源安全基金会和更广泛的开源软件社区为提高开源软件的安全性和可信度而正在进行的工作。
布赖恩的书面发言稿链接如下 这里.
作者：Caleb Brown和David A. Wheeler，代表确保关键项目工作小组
今天，我们很高兴地宣布，最初的原型版本的 包装分析项目这是一个OpenSSF项目，旨在解决识别流行的开放源码库中的恶意软件包的挑战。在短短一个月的分析中，该项目发现了超过 200 上传至PyPI和npm的恶意软件包。
软件包分析项目旨在了解开源软件库中的软件包的行为和能力：它们访问什么文件，连接什么地址，运行什么命令？该项目还跟踪软件包行为方式随时间的变化，以确定以前安全的软件何时开始出现可疑的行为。这项工作旨在通过检测恶意行为，告知选择软件包的消费者，并向研究人员提供有关生态系统的数据，从而提高开源软件的安全性。尽管该项目已经开发了一段时间，但在根据最初的经验进行了广泛的修改之后，它最近才变得有用。
我们检测到的绝大多数恶意软件包都是依赖性混乱和错别字攻击。我们发现的软件包通常包含一个简单的脚本，在安装过程中运行，并调用关于主机的一些细节。这些软件包很可能是安全研究人员的作品，他们在寻找bug赏金，因为大多数软件包除了机器的名称或用户名之外，并没有渗入有意义的数据，而且他们没有试图掩饰自己的行为。尽管如此，这些软件包中的任何一个都可能对安装它们的不幸受害者造成更大的伤害，因此，软件包分析为这些类型的攻击提供了一种反措施。
参与这个项目有很多机会，我们欢迎任何有兴趣为未来目标作出贡献的人。
- 检测包装行为随时间变化的差异。
- 自动处理包装分析的结果。
- 储存包裹本身，因为它们被处理为长期分析。
- 并提高管道的可靠性。
查阅我们的 GitHub项目 和 阶段性成果 以获得更多的机会，并随时参与到我们的活动中来。 OpenSSF Slack.这个项目是OpenSSF的努力之一。 保障关键项目工作组.你还可以探索其他OpenSSF项目，如 SLSA 和 淘宝网这些措施超越了包装本身的安全，解决了整个供应链的包装完整性。
作者。达斯汀-英格拉姆（谷歌），雅克-切斯特（Shopify）。
软件库是任何一个开源生态系统的重要组成部分：它提供了一个可信的中央渠道来发布、存储和分发开源的第三方软件给所有消费者。几乎每一个软件生态系统都存在软件包索引和软件包管理器，它们有许多相同的目标、功能和威胁。
但是这些资源库和相关的工具都是独立开发的，多年来它们之间很少有知识共享。这意味着同样的问题被反复解决，而且大多是孤立的。随着提高这些关键资源库的整体安全性变得越来越重要，这些资源库之间的协作和知识共享也变得非常重要。
今天，我们宣布成立保障软件库工作组，这是一个社区合作，重点是软件库、软件注册处和依赖它们的工具（如软件包管理器）的维护者，包括系统、语言、插件、扩展和容器系统等各个层面。
我们召集了许多对许多开源生态系统至关重要的软件库的主要维护者、贡献者和利益相关者参加该小组，其中包括Java、Node.js、Ruby、Rust、PHP和Python。
这个工作组提供了一个分享经验和讨论共同问题、风险和威胁的论坛。它还提供了一个合作环境，以便在引进新的工具和技术方面保持一致，以加强和保护我们各自的软件库，例如 淘宝网.
你可以在我们的网站上了解更多关于工作组的目标。 储存库 和 包机，通过公众号加入我们的会议 OSSF日历或在以下网站找到我们 OpenSSF Slack 在#securing_software_repos频道。如果你维护或运营任何类型的软件库系统，请加入进来吧
作者。Brian Behlendorf，OpenSSF，和Robin Bender Ginn，OpenJS基金会
今天，我们很高兴地宣布，Node.js是第一个得到OpenSSF的支持的开源社区。 α-Omega项目.Alpha-Omega将投入$30万，以加强Node.js安全团队和漏洞修复工作，直到2022年的剩余时间，重点是支持更好的开源安全标准和实践。
开源软件项目Node.js无处不在，从NASA到Netflix，人们对用Node.js构建的产品和服务给予了很大的信任。但许多社区主导的JavaScript项目缺乏时间、人员和专业知识，无法采取全面的安全措施。很少有依赖Node.js的公司对该项目做出回馈。我们希望这能激励更多依赖Node.js的组织也参与到其安全工作中。
这项援助将减轻Node.js项目维护者的压力，他们在努力实现稳定和安全的代码库的同时，还受到了市场对新功能的需求的压力。具体来说，这将从NearForm和Trail of Bits引入安全工程资源，以支持Node.js技术指导委员会，帮助分流报告，管理安全版本，广泛提高Node.js的安全性，并鼓励在整个行业的JavaScript项目中实施最佳实践。
Node.js带有很高的 临界值得分 根据OpenSSF的行业安全专家制定的参数，其影响力和重要性。在全球19亿个网站中，几乎有98%的网站使用了JavaScript，根据OpenSSF的研究，这是一种顶级的编程语言。 红魔 和 GitHub.Node.js--服务器端的JavaScript--在2021年被下载超过20亿次。它在整个行业中无孔不入，在现代应用程序中使用了相当一部分。
我们两个人（Robin和Brian）都对这次合作以及为OpenSSF和OpenJS社区树立榜样的前景感到兴奋。
Log4Shell、SolarWinds Compromise、Heartbleed--近年来，网络安全漏洞已经成为家喻户晓的名字。这些问题给企业带来了数十亿美元的预防和修复成本，但同时它们也变得越来越普遍。事后对漏洞做出反应是有用的，但还不够；这样的反应不能在第一时间保护用户。相反，安全需要在软件发布之前就被植入其中。不幸的是，大多数软件开发者不知道如何做到这一点。
为了缓解这一问题，并改善从开发人员到运营团队到最终用户的网络安全培训机会，开源安全基金会（OpenSSF）已经与Linux基金会培训和认证部门合作，发布了一个新的免费在线培训课程。 开发安全软件.完成课程并通过最终考试的人将获得有效期为两年的结业证书。
本课程面向软件开发人员、DevOps专业人员、软件工程师、网络应用程序开发员以及其他对学习如何开发安全软件感兴趣的人，重点介绍即使资源有限也可以采取的实际步骤，以提高信息安全。目标是使创建和维护的系统更容易被成功攻击，减少攻击成功后的损失，并加快反应速度，以便迅速修复任何潜在的漏洞。
本课程首先讨论了网络安全的基础知识，如风险管理的真正含义。它讨论了如何将安全作为系统需求的一部分来考虑，以及你可以考虑哪些潜在的安全需求。然后，它集中讨论了如何设计安全的软件，包括各种安全设计原则，这些原则将帮助你避免坏的设计并接受好的设计。它还考虑了如何确保你的软件供应链的安全，也就是说，如何更安全地选择和获取重复使用的软件（包括开源软件）以提高安全性。
该课程还关注关键的实施问题和实际步骤，你可以采取这些措施来对抗最常见的攻击。接下来讨论如何验证软件的安全性，包括各种静态和动态分析方法，以及如何应用这些方法（例如，在持续集成管道中）。它还讨论了更专业的话题，如如何开发威胁模型的基础知识和如何应用各种加密能力。课程内容反映了我们与edX提供的安全软件开发项目，但只是一门课程，而不是三门。
自定进度的课程可以在大约14-18小时内完成，并包括测试所学知识的小测验。完成后，参与者将收到一个数字徽章，证明他们已经成功完成了所有必要的课程作业，并学会了相关材料。这个数字徽章可以被添加到简历和社交媒体资料中。
今天报名 来开始提高你的网络安全技能和实践!
曾经有一段时间，我们惊叹于开源用户和贡献者社区的全球性，当时从以.nz或.jp或.cl.结尾的地址收到问题或补丁是一种兴奋，或者听说你的软件在梵蒂冈或国际空间站运行。如今，一个开源项目越受欢迎，其用户和贡献者社区就越有可能跨越各大洲和文化。
运行良好的开源项目认识到这一事实，并经常采取一系列步骤来建立其全球用户和贡献者基础。这些步骤可能包括一些基本的步骤，如确保用户界面中的Unicode和8-bit-clean文本处理，通过资源包提供本地化，或翻译文档。还有一些人意识到要跨越人力和文化的鸿沟，所以他们投资于发展当地的用户社区和支持论坛，或者让核心维护者飞到他们可能无法到达的会议上发言。最难的，但可能也是最重要的是，项目要关注用户成为参与者和贡献者的途径，从论坛和邮件列表到定期的电话会议，都可能在无意中给不在同一时区和使用其他沟通方式的人造成障碍。
在OpenSSF，我们才刚刚开始这个旅程。到目前为止，绝大多数活跃的贡献者都在美国，还有一小部分在欧洲和澳大利亚。然而，我们希望通过OpenSSF的不同指南、规范、服务和软件接触到的人是全球性的，而且我们知道各地也有潜在的贡献者。为了支持这一点，你会看到我们开始优先考虑一些事情，比如将会议转移到全球范围内更方便的时间；投资于我们工作产品的翻译；以及将更多的虚拟（以及最终的面对面）会议集中在全球观众身上。
3月24日星期四，香港时间上午11点（也是英国标准时间上午8点30分，新加坡时间上午11点，日本、韩国12点，澳大利亚下午2点），我们将举办 一个向亚太受众介绍OpenSSF的虚拟活动.David Wheeler、Julian Gordon和我将与来自Wipro的VM Brasseur一起概述我们正在做的事情以及该地区的人们如何参与。如果你有兴趣，请来参加。
如果你认为我们还可以做其他事情来提高全球的可及性，不要犹豫，请加入OpenSSF Slack，我们很想听到你的意见。
谢谢!
- 卜睿哲
作者: 最佳实践工作小组, Laurent Simon (Google), Azeem Shaikh (Google), and Jose Palafox (GitHub)
今天，开放源代码安全基金会的两名成员。 谷歌 和 GitHub伙伴们正在合作发布 记分卡V4它的特点是有一个新的GitHub动作，增加了安全检查，并扩大了对开源生态系统的扫描范围。
计分卡项目于去年启动，作为一个自动化的安全工具，帮助开源用户了解他们所使用的依赖关系的风险。虽然世界上运行的是开源软件，但许多开源项目 从事至少一种危险的行为-例如，没有启用分支保护，没有钉住依赖，或没有启用自动依赖更新。记分卡使得在使用一个软件包之前对其进行评估变得很简单：对一行代码进行扫描后，会对每个单独的安全做法返回从0到10的分数（"检查今天，GitHub发布了 "记分卡"（Scorecards），为项目的安全状况打分，并为项目的整体安全性打分。今天发布的Scorecards GitHub Action使开发者比以往任何时候都更容易保持他们的安全态势。
帮助开发者
记分卡 GitHub工作流行动
以前，记分卡需要手动运行，以判断一个项目的变化如何影响其安全性。新的 记分卡 GitHub行动 将这一过程自动化：一旦安装，Action 就会在任何仓库变更后运行 Scorecards 扫描。维护者可以在GitHub的扫描仪表板上查看安全警报，并对变更带来的任何危险的供应链做法进行补救。
如上例所示，每个警报包括风险的严重程度（低、中、高或关键），问题发生的文件和行（如果适用），以及修复问题的补救步骤。
一些重要的开源项目已经采用了记分卡行动，包括 特使, 无发行, 连署, 芦笙, kaniko.该行动是免费使用的，可以通过以下方式安装在任何公共资源库上 这些方向.
新支票
我们不断地增加新的安全检查，以帮助开发者评估他们项目的风险。这个版本增加了许可证检查，它检测项目许可证的存在，以及 危险的-工作流程检查。 它可以检测到危险的使用 pull_request_target 的触发和风险 GitHub工作流程中的脚本注入.危险工作流程是第一个具有 "关键 "风险等级的Scorecards检查，因为这些模式非常容易被利用--有了这些工作流程，一个拉动请求就可以把被破坏的代码引入项目。新的Scorecards检查通知用户在他们的项目中存在这些漏洞，并提供补救指导以修复该问题。
扩大数据可用性
Scorecards团队每周都会对一组关键的开源项目进行扫描，在任何时候都能创建整个开源生态系统的安全快照。在过去的几个月里，我们已经将扫描的规模从5万个项目增加到100万个项目，这些项目根据其直接依赖的数量被确定为最关键的项目，提供了一个更详细的生态系统视图，并加强了供应链的安全性，因为用户看到其依赖的覆盖面有所改善。有了Scorecards V4，每周的扫描现在反映了每个资源库的0-10评级表，而不是以前版本的通过-失败的结果，为数据增加了更多的颗粒度。扫描结果可通过Scorecards网站公开。 API 而在 OpenSSF度量仪表板 和 开源洞察力 伙伴网站。
壮大社区
自我们最初推出以来，由于不断扩大的记分卡社区，我们一直在改进我们的代码库。2021年，我们的独特贡献者增加到40多人，平均每周提交16次以上（总计860次），并关闭了270个问题。我们热烈欢迎新的贡献者；请查看以下列表 良好的初学问题 如果你想加入这个行列。
这里有几个采用记分卡的项目的例子。
"kaniko是一个流行的Kubernetes开源容器镜像构建器，所以维护仓库和代码库的安全是非常重要的。ossf/scorecard Github Action为我们解决了这个问题，并持续监控仓库。它的安装时间不到5分钟，并迅速分析了版本库，确定了使项目更安全的简单方法"。
- 普里亚-瓦德瓦。 卡尼科
"我们依靠distroless中的记分卡来确保我们遵循安全开发的最佳实践。安全的源码和配置意味着我们所有的用户都能得到更安全的基本图像。"
- 阿普-贡丹。 无分销商
"Scorecards为我们提供了在Envoy项目中快速测试新依赖关系的能力。我们发现这是一个很有价值的步骤，可以审查已知属性的新依赖关系，我们已经将记分卡整合到我们的依赖关系接受标准中。机器可检查的属性是健全的安全流程的一个重要组成部分"。
- 哈维-图赫。 特使
加强供应链
我们预计2022年将是对供应链安全的重要性认识不断提高的一年。如果你的新年愿望是更密切地关注你的项目安全，使用计分卡GitHub行动是开始的最简单方法之一。只是 安装 在你的存储库上的工作流程，并遵循补救说明来解决滚动的问题。每一个渐进的改进都有助于为每个人加强开源生态系统。
今天是Linux基金会与公共部门组织交往历史上的一个重要时刻。白宫召集了开源开发者和商业生态系统的一个重要部门，以及许多美国联邦机构的领导人和专家，以确定开源软件供应链中存在的挑战，并就如何减少风险和加强复原力交流意见。
在这次会议上，Linux基金会和开源安全基金会（OpenSSF）代表他们的数百个社区和项目，强调了集体的网络安全努力，并分享了他们在公共和私营部门与政府合作的意向。
Linux基金会执行董事Jim Zemlin说："保护关键基础设施包括保护运行其银行、能源、国防、医疗保健和技术系统的软件。当一个广泛使用的开源组件或应用程序的安全受到损害时，每个公司、每个国家和每个社区都会受到影响。这不是美国政府特有的问题；这是一个全球性的问题。我们赞赏美国政府在促进更加关注开源软件安全方面的领导力，并期待着与全球生态系统合作，以取得进展。特别是 开放的SSF 是我们应对广泛的开源软件供应链挑战的关键举措，听到我们的工作被其他与会者确定并认可为进一步合作的基础，我感到非常振奋。"
开源安全基金会的执行董事Brian Behlendorf评论说："在今天的会议上，我们分享了一组关键的机会，在这些机会中，如果每个人都做出足够的承诺，我们就可以对保护和改善我们的软件供应链安全所需的关键努力产生实质性的影响。开放源码生态系统将需要共同努力，进一步开展网络安全研究、培训、分析和修复在关键开放源码软件项目中发现的缺陷。这些计划得到了积极的反馈，并有越来越多的人集体承诺要采取有意义的行动。在最近的log4j危机之后，公共和私人合作的时间从未如此紧迫，以确保开源软件组件和它们所流经的软件供应链表现出最高的网络安全完整性。"
布赖恩继续说："通过努力，如我们的工作小组在 最佳实践, 识别关键项目, 衡量标准和记分卡, 项目Sigstore以及即将宣布的更多信息，OpenSSF已经对今天会议上讨论的许多关键领域产生了影响。我们已经准备好进一步推动这些努力，并欢迎这次对话和进一步的此类对话可能带来的所有新参与者和资源"。
作为一个整个职业生涯都在从事开源软件（OSS）工作的人，我认为 Log4Shell的争夺 (一个全行业的四级火灾，以解决一个严重的漏洞。 阿帕奇Log4j 包）是一个谦卑的提醒，提醒我们还有多远的路要走。开放源码软件现在是现代社会运行的核心，就像公路桥梁、银行支付平台和手机网络一样关键，现在是开放源码软件基金会开始像它一样行动的时候了。
像Apache软件基金会、Linux基金会、Python基金会等组织，为他们的开放源码软件开发者社区提供法律、基础设施、营销和其他服务。在许多情况下，这些组织的安全工作资源不足，在制定标准和要求以减少重大漏洞的机会方面受到束缚，因为他们害怕吓跑新的贡献者。太多的组织没有运用筹集到的资金或制定流程标准来改善他们的安全实践，并且不明智地倾向于代码的数量而不是质量。
"像这样行事 "会是什么样子？以下是开放源码软件基金会可以做的几件事，以减轻安全风险。
- 建立一个组织范围内的安全团队，接收和分流漏洞报告，以及协调对其他受影响项目和组织的回应和披露。
- 通过CI工具执行频繁的安全扫描，以检测软件中的未知漏洞，并识别依赖关系中的已知漏洞。
- 对关键代码进行不定期的外部安全审计，特别是在新的重大发布之前。
- 要求项目使用测试框架，并确保高代码覆盖率，这样，没有测试的功能就会被阻止，而未被充分利用的功能就会被主动淘汰。
- 要求项目删除已废弃的或脆弱的依赖关系。(一些Apache项目 不易受到Log4j v2 CVE的影响。，因为他们仍在使用Log4j v1，它有已知的弱点，并且自2015年以来没有得到更新！)
- 鼓励并最终要求使用SBOM格式，如 SPDX 以帮助每个人更容易、更迅速地跟踪依赖关系，从而使漏洞更容易被发现和修复。
- 鼓励并最终要求维护者展示对安全软件开发实践基础知识的熟悉程度。
其中许多被纳入了 CII最佳实践奖章这是将这些内容编入一个客观的可比较的指标的首次尝试之一，这一努力现在已经转移到OpenSSF。OpenSSF还发布了一个 为开发人员提供的关于如何开发安全软件的免费课程，以及 SPDX最近已被公布为ISO标准.
上述做法都不是要给开发者更多的报酬，或者将资金从软件的用户直接输送给开发者。不要误会我的意思，开源开发者和支持他们的人应该得到更多的报酬，并在总体上得到更多的赞赏。然而，如果说如果你把更多的钱塞到他们的口袋里，他们就会写出更安全的代码，这对大多数维护者来说是一种侮辱。同时，可以说，当每一个下游用户都认为这些做法已经到位，并且是由其他人支付的时候，就会发生公地悲剧。
应用这些安全实践并提供解决这些问题所需的资源，是人们越来越期待基金会为其社区所做的事情。基金会应该开始为他们的托管项目和成熟项目制定安全相关的要求。他们应该从利益相关者那里筹集所需的资源，为他们最关键的项目进行定期的付费审计，为他们所有的项目提供扫描工具和CI，并在一个跨项目的安全团队中至少有一些付费的工作人员，这样就不会把时间紧迫的反应留给个别志愿者。从长远来看，基金会应该考虑提供资源，以便将 关键项目或代码段转为内存安全的语言，或为更多的测试提供资金悬赏。
阿帕奇软件基金会似乎在很多方面都做得很好，让我们来明确一下。尽管在感恩节假期前被通知，他们的志愿安全团队与Log4j的维护者合作，并迅速作出反应。Log4j在其CI管道中也有近8000个通过的测试，但即使所有这些测试也没有抓住这个漏洞可能被利用的方式。一般来说，Apache项目根本不需要有测试覆盖率，更不用说运行SAST安全扫描或主持第三方审计，这些都可能发现这个问题。
许多其他基金会，包括Linux基金会主办的基金会，也在努力做这一切--这不容易通过许多基金会对代码质量的自由放任理念来推动，而且第三方的代码审计和测试也不便宜。但为了可持续发展，减少对更广泛的社区的影响，以及更有弹性，我们必须做得更好。我们必须一起做这件事，因为对开放源码软件的信任危机影响到我们所有人。
这就是OpenSSF的作用，也是当初吸引我加入这个项目的原因。在新的一年里，你会看到我们宣布一系列新的倡议，这些倡议建立在我们一直以来为开源社区的安全 "提高底线 "所做的工作之上。我们做到这一点的唯一方法是开发工具、指导和标准，使开源社区的采用得到鼓励和实用，而不是繁琐的官僚主义。我们将与其他开源项目和基金会合作，并向他们提供资助，以帮助他们改善他们的安全游戏。如果你想密切关注我们正在做的事情，请在以下网站关注我们 推特 或 以其他方式参与.要想了解我们迄今为止的工作情况，请阅读我们在《世界日报》上的报道。 Linux基金会年度报告，或观看我们最近的 市政厅.
希望2022年能减少四级警报的火灾。
卜睿哲
Brian Behlendorf是Linux基金会的开源安全基金会（OpenSSF）的总经理。他是Apache集团的创始成员，该集团后来成为Apache软件基金会，并担任该基金会主席达三年之久。
