一个文档与跟踪项目，目标是让包管理系统更加安全。关于我们见到的一些相关问题的粗略列表，请参见问题。
| 语言 | 名称 | 层级 | 控制项 | Packman 负责人 | Packman 页面 |
|---|---|---|---|---|---|
| JavaScript | npm | 1 | npm | ||
| Ruby | RubyGems | 1 | rubygems | ||
| Python | PyPi | 1 | pip/pypi | ||
| Java | Maven Central | 2 | maven central | ||
| Java | Android Central | ? | |||
| .Net | NuGet | 2 | nuget | ||
| Docker Hub | Docker | 1 | |||
| Golang | go get | 1 | golang | ||
| PHP | Composer | ? | |||
| Cocoa | Cocoa Pods | ? | |||
| Swift | Swift Package Manager | 1 | swiftpm | ||
| Rust | Cargo | 2? | rustcargo |
以下各节将更详细地描述上表引用的每项控制。
强身份验证意味着系统要求：
由于能够向包管理器推送新代码是一项强大的功能，因此必须确保无法通过猜测维护者密码来轻易完成。实现 MFA
为满足此要求，包管理器必须有一种接收社区安全信息的途径，以及处理此类反馈的流程。发布一个公开邮箱（如 security@），并配合确保反馈被捕获和响应的机制，即可满足此要求。
软件包本身可能会识别问题，或被通知问题。平台应支持包维护者报告存在安全问题的版本，并且：
软件包必须以某种方式与众所周知的公共仓库（bitbucket.org、github.com）中的显式代码版本（一个标签？）绑定。
当软件包更新时，应通知该软件包的所有维护者。
当软件包中发现安全问题时，应有一种方式让消费者检查这些问题。这可以是一个命令，允许消费者检查已知问题。
开发者应该能够对其代码进行签名。当他们签名时，包管理器应验证签名，并提供一种将这些签名分发给软件包消费者的方式。
包管理器提供一种验证所下载软件包完整性的方法。
无 - 未进行完整性验证 部分 - 使用较弱的方法进行完整性验证* 是 - 使用足够安全的方法进行验证
平台可以提供静态代码分析，以主动识别重要库中的潜在问题。
平台可以跟踪软件包所依赖的库（上游软件包）中的漏洞，并在存在漏洞时通知维护者。
包管理器不应在安装软件包时运行代码。
包管理器不应收集使用该依赖的项目的信息。
包管理系统应提供项目角色指南，其中应包括继任计划和积极参与的条款。
包管理系统维护者应设有审查项目角色的流程，以确保维护者保持活跃。
库的消费者应能够标记他们对特定库的兴趣或认可，以便确保构建只使用他们以特定方式标记的库。例如，标记为已进行代码审查。
包管理器提供一定控制，以防止身份验证凭据 / 令牌 / 会话作为软件包内容的一部分被泄露。
无 - 不存在任何控制，需要用户自我保护 部分 - 插入注释 是 - 凭据 / 令牌要么被阻止发布，要么通过发布软件包触发的自动化方式被撤销。应通过某种方式通知用户已采取行动。
| 控制项 | 第 1 级 | 第 2 级 | 第 3 级 |
|---|
| 强身份验证 | ☐ | ☑ | ☑ |
| 推送制品时需要 MFA | ☐ | ☑ | ☑ |
| 安全联系人 | ☐ | ☑ | ☑ |
| 软件包可通知安全事件 | ☐ | ☑ | ☑ |
| 代码包与源代码绑定 | ☐ | ☑ | ☑ |
| 防止凭据被发布 | ☐ | ☑ | ☑ |
| 更新通知 | ☐ | ☑ | ☑ |
| 代码签名 | ☐ | ☐ | ☑ |
| 完整性验证 | ☐ | ☐ | ☑ |
| 代码分析（静态） | ☐ | ☐ | ☑ |
| 代码依赖分析 | ☐ | ☐ | ☑ |
| 包管理器不运行代码 | ☐ | ☐ | ☑ |
| 包管理器不收集信息 | ☐ | ☐ | ☑ |
| 项目角色指南 | ☐ | ☐ | ☑ |
| 项目角色审查 | ☐ | ☐ | ☑ |
| 账户级库标记 | ☐ | ☐ | ☐ |
