A documentation and tracking project with the goal of making package management systems more secure.
| Language | Name | Tier | Controls | Packman Lead | Packman Page |
|---|---|---|---|---|---|
| Javascript | npm | 1 | npm | ||
| Ruby | RubyGems | 1 | rubygems | ||
| Python | PyPy | 1 | |||
| Java | Maven Central | 2 | maven central | ||
| .Net | NuGet | 2 | nuget | ||
| Dockerhub | Docker | 1 | |||
| Golang | 1 | golang | |||
| Rust | Cargo | 2? | rustcargo |
- Tier 1: The lowest level of maturity. Consider this untrusted.
- Tier 2: Basic controls in place.
- Tier 3: Very secure.
| Control | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
| Strong Authentication | ☐ | ☑ | ☑ |
| MFA To Push Artifacts | ☐ | ☑ | ☑ |
| Security Contacts | ☐ | ☑ | ☑ |
| Packages Can Notify of Security Issues | ☐ | ☑ | ☑ |
| Code package tied to source code | ☐ | ☑ | ☑ |
| Update notifications | ☐ | ☑ | ☑ |
| Code signing | ☐ | ☐ | ☑ |
| Code analysis (static) | ☐ | ☐ | ☑ |
| Code Dependency Analysis | ☐ | ☐ | ☑ |
| Package Manager Does Not Run Code | ☐ | ☐ | ☑ |
| Package Manager Does Not Collect Info | ☐ | ☐ | ☑ |
| Project Roles Guide | ☐ | ☐ | ☑ |
| Project Roles Review | ☐ | ☐ | ☑ |
| Account Level Library Tagging | ☐ | ☐ | ☐ |
The following sections describe each of the controls referenced in the above table in more detail.
Strong authentication means that the system requires:
- Complex passwords (> 10 chars with symbols,numbers,etc. or > 16 chars)
- Is resistant to brute forcing through lockouts
- Has password change notifications
- Supports only short sessions
Since being able to push new code to a package manager is a powerful function, it is important to know that it cannot be easily done by guessing a maintainer's password. Implementing MFA
To satisfy this requirement, the package manager must have a way to receive security information from the community and a process for handling such feedback. A published email such as security@, together with a mechanism to ensure that the feedback is captured and responded to would satisfy this requirement.
Packages may themselves identify issues or be notified of issues. The platform should support a way for a package maintainer to report a release with a security issue and:
- Potentially remove it from the package source
- Flag for update
Packages must somehow be tied to an explicit version of code (a tag?) in a well known public repository (bitbucket.org, github.com).
When packages are updated, all maintainers for that package should be notified.
When security issues are identified in a package, there should be a way for a consumer to check for those. This could be a command that allows the consumer to check for known issues.
It should be possible for developers to sign their code. When they do, the package manager should verify the signatures and provide a way for those to be distributed to consumers of the package.
The platform can provide static code analysis to proactively identify potential issues in important libraries.
The platform can track vulnerabilities in libraries the package depends on (upstream packages) and notify maintainers when that is the case.
The package manager should not run code on package install.
The package manager should not collect information about the project using the dependency.
The package management system should have a guide for roles on a project which should include a succession plan and terms for active engagement.
The package management system maintainers should have a process for reviewing the roles on projects to ensure the maintainers are active.
Consumers of libraries should be able to tag their interest or approval in a specific library so that they can ensure that builds only use libraries they have tagged in certain ways. Eg. marked as code reviewed.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent