Geomys开源维护标准：构建安全可靠的软件供应链

Geomys维护标准

开源维护专业化的最重要影响之一是，作为专业人士，我们能够投入资源维护一套标准，使我们的项目更安全、更可靠。那些在志愿者身上经常被反对的承诺和开销，对于专业维护者来说应该是基本要求。

由于没有找到太多先例，为了编写Geomys维护标准，我首先调查了近期的供应链安全事件，寻找可缓解的根本原因。（顺便说一句，您可能错过了那封邮件，因为它包含了一个用于钓鱼攻击的域名，所以被标记为钓鱼邮件。哎呀。）我还征求了CI安全等各个领域专家以及其他Geomys维护者的反馈。

初稿如下，我们将在geomys.org/standard-of-care维护最新版本。它涵盖了通用维护理念、持续稳定性和可靠性、依赖管理、账户和CI安全、漏洞处理、许可证等方面。

未来，我们希望采用更多二进制透明度工具，并定期审查浏览器扩展以及授权的Gerrit和GitHub OAuth应用和令牌（仅GitHub就有四个地方需要查看！）。我们也欢迎就安全或可靠性方面有价值的补充内容提供反馈。

标准草案

我们的目标是可持续且可预测地维护我们的项目。我们能够做到这一点，得益于与客户的保留合同，但这些承诺是面向整个社区的，而不仅仅是付费客户。

范围。我们将此标准应用于由Geomys维护或共同维护的项目，包括：

• Go标准库中的crypto/...和golang.org/x/crypto/...包以及FIPS 140-3 Go加密模块（与Go团队其他成员共同维护）
• Staticcheck
• Gotraceui
• filippo.io/edwards25519
• filippo.io/csrf
• filippo.io/keygen
• filippo.io/intermediates
• filippo.io/{bigmod,nistec,mlkem768,hpke}（从标准库外部化）
• age和typage
• mkcert
• Sunlight和filippo.io/torchwood
• yubikey-agent
• bluemonday

对于我们不是唯一维护者的项目，我们优先考虑与团队其他成员良好合作。

Geomys维护者可能还有不遵循此标准的个人项目（例如mostly-harmless中的所有内容）。

代码审查。如果项目接受外部贡献，我们会审查提供给我们的所有代码。这也包括任何由LLM生成的代码。

复杂性。维护者的主要职责之一是拒绝。我们有意限制复杂性，并在考虑功能时牢记项目的目标和非目标（例如参见Go密码学原则）。

静态分析。我们在CI中运行我们自己@dominikh开发的staticcheck。

稳定性。一旦Go包达到v1，我们会在主版本内保持严格的向后兼容性，类似于标准库的兼容性承诺。

持续维护。并非所有项目都始终处于活跃开发状态（例如，有些项目可能实际上已完成，或者我们可能分批工作）。但是，除非项目明确归档或弃用，否则我们将处理新出现的问题，这些问题可能导致项目不再适用于先前有效的工作用例（例如与新操作系统的兼容性）。

依赖管理。我们不使用自动依赖版本升级工具，如Dependabot。对于我们的目的而言，它们只会造成干扰，并在生态系统有时间检测攻击之前采用新的模块版本，从而增加供应链攻击的风险。（特别是Dependabot还存在令人担忧的冒充风险，这可能导致简单的社会工程学攻击。）

相反，我们：

• 定期运行govulncheck，以获取关于实际影响我们项目的易受攻击依赖项的高信噪比通知；以及
• 使用依赖项的最新版本运行隔离的CI作业（即在运行go test之前运行go get -u），以确保我们尽早收到破坏性变更的警报，从而轻松更新到未来的安全版本，并了解依赖我们项目的潜在兼容性问题。

防钓鱼认证。钓鱼攻击是我们安全性的最大威胁，进而也是用户安全的最大威胁。我们承认，任何程度的人工谨慎都无法系统地抵御针对性攻击，因此我们对所有可能影响我们项目用户的服务使用技术上防钓鱼的认证方式。

防钓鱼认证意味着使用通行密钥或WebAuthn双因素认证，凭据存储在平台认证器（例如iCloud钥匙串）、密码管理器（例如1Password或Chrome）或硬件令牌（例如YubiKeys）中。

允许升级到影响用户的关键账户包括：

• GitHub
• 链接到Gerrit账户的所有Google账户
• CI/CD
• 电子邮件
• 密码管理器
• 通行密钥同步（例如Apple iCloud）
• Slack
• 网站托管
• 域名注册商
• DNS托管
• 软件包注册表（如果适用，尽管Go的去中心化软件包管理在很大程度上消除了这个攻击面）

如果提供严格模式（例如Google高级保护计划或Apple高级数据保护），我们会启用它。如果需要使用可被钓鱼的备用认证或账户恢复方法，我们会配置一个基于秘密的方法（例如TOTP或恢复代码），并要么删除秘密，要么承诺在不请另一位Geomys维护者审查必要情况的前提下绝不使用它。如果我们不使用TOTP，它就不会伤害我们。

我们绝不启用SMS作为认证机制或账户恢复机制，因为即使我们没有采取任何行动，SIM卡劫持也是可能的。

长期凭据。我们尽可能避免使用长期持久凭据，或者尽可能使它们不可提取。例如，我们使用git-credential-oauth而不是Gerrit cookie，并使用硬件绑定的SSH密钥与yubikey-agent或Secretive，而不是使用个人访问令牌来向GitHub进行git推送。

与防钓鱼认证不同，我们发现普遍推广短期凭据是不切实际的。值得注意的是，我们尚未找到在不使用可提取的长期凭据的情况下使用GitHub CLI的方法。

CI安全。我们在GitHub Actions工作流上运行zizmor，并且我们不使用危险的GitHub Actions触发器，这些触发器使用攻击者控制的上下文运行特权工作流，例如pull_request_target。

我们默认以只读权限且无秘密的方式运行GitHub Actions工作流。具有写权限或访问秘密的工作流会禁用所有缓存的使用（包括通过actions/setup-go等操作间接使用），以减轻缓存投毒攻击。（请注意，令人难以置信的是，只读工作流可以写入任意缓存条目，这就是为什么必须在缓存使用时缓解此问题。）

第三方访问。对于仅由Geomys维护的项目，我们避免向外部人员提供影响用户的（即推送或发布）访问权限，并公开披露任何例外情况。

如果放弃一个项目，我们倾向于将其归档并让分支产生，而不是将控制权移交给外部人员。这样，依赖者可以自行评估是否信任新的维护者。任何例外情况都将提前广泛沟通。

在任何情况下，我们都不会将先前分配给Geomys项目的域名、GitHub用户/组织或软件包名称公开发布注册。

可用性监控。我们对关键面向用户的端点（例如Go导入路径元页面）进行自动化的正常运行时间监控。

这也提供了对关键域名过期的监控，防止意外接管。

透明度日志记录。我们通过GopherWatch订阅新版本通知，以便在向Go校验和数据库发布未经授权的模块版本时收到警报。

我们使用Cert Spotter或Silent CT等工具监控关键域名（例如我们的Go导入路径的根域）的证书透明度日志。我们还在这些域名上设置CAA记录，将证书颁发限制在运营所需的最小CA集合。

漏洞处理。我们记录每个项目的官方漏洞报告机制，鼓励协调漏洞报告，并感谢安全研究人员的工作。

我们遵守最多90天的禁运期，并且在漏洞细节公开之前，不向与修复无关的人员分享这些细节。（付费客户无法访问私人漏洞细节。这是为了履行我们对开源项目各利益相关方的责任，并承认这些细节通常不属于我们分享的范围。）

一旦漏洞公开，我们确保它被包含在Go漏洞数据库中，并带有准确的归属和元数据，包括CVE编号。

如果记录的漏洞报告机制无响应，可以通过发送电子邮件至security@geomys.org获得升级路径。

许可证。我们使用宽松的、众所周知的许可证：BSD-3-Clause、BSD-2-Clause、BSD-1-Clause、0BSD、ISC、MIT，或（较不优选）Apache-2.0。

免责声明。这不是具有法律约束力的协议。您对项目的使用继续受其各自许可证和/或您与Geomys的合同控制，除非明确指定，否则不包括本文档。
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）

公众号二维码

公众号二维码