A documentation and tracking project with the goal of making package management systems more secure. See issues for a very rough list of a few of the related issues we have seen.
| Language | Name | Tier | Controls | Packman Lead | Packman Page |
|---|---|---|---|---|---|
| Javascript | npm | 1 | npm | ||
| Ruby | RubyGems | 1 | rubygems | ||
| Python | PyPi | 1 | |||
| Java | Maven Central | 2 | maven central | ||
| Java | Android Central | ? | |||
| .Net | NuGet | 2 | nuget | ||
| Dockerhub | Docker | 1 | |||
| Golang | go get | 1 | golang | ||
| PHP | Composer | ? | |||
| Cocoa | Cocoa Pods | ? | |||
| Swift | Swift Package Manager | ? | |||
| 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 | ☐ | ☑ | ☑ |
| Prevents Credential from Being Published | ☐ | ☑ | ☑ |
| Update notifications | ☐ | ☑ | ☑ |
| Code signing | ☐ | ☐ | ☑ |
| Integrity Verification | ☐ | ☐ | ☑ |
| 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.
Package manager provides a method for verifying the integrity of the downloaded package.
None - no integrity verification is done Partial - integrity verification is done using a weak method* Yes - Verification is done using a sufficiently secure method
- we need want to define this.
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.
The package manager provides some control to prevent the authentication credentials / token / session from being leaked as part of the package contents.
None - no control is present and the user is to protect themselves Partial - insert comment Yes - credentials / tokens are either blocked from publication or are revoked through an automated way triggered by publication of a package. Users should be notified in some way that action has taken place.