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.
Table Of Package Management Systems
|Language||Name||Tier||Controls||Packman Lead||Packman Page|
|Java||Maven Central||2||maven central|
|Swift||Swift Package Manager||?|
Tiers and Controls
- 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|
|MFA To Push Artifacts||☐||☑||☑|
|Packages Can Notify of Security Issues||☐||☑||☑|
|Code package tied to source code||☐||☑||☑|
|Prevents Credential from Being Published||☐||☑||☑|
|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||☐||☐||☐|
Detail About Controls
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
MFA To Push Artifacts
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
Security Contacts and Process
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 Can Notify of Security Issues
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
Code Packages Tied to Source Code
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.
Consumer Check Status of a Package
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.
Code Analysis Static
The platform can provide static code analysis to proactively identify potential issues in important libraries.
Code Dependency Analysis
The platform can track vulnerabilities in libraries the package depends on (upstream packages) and notify maintainers when that is the case.
Package Manager Does Not Run Code
The package manager should not run code on package install.
Package Manager Should Not Collect Information
The package manager should not collect information about the project using the dependency.
Project Roles Guide
The package management system should have a guide for roles on a project which should include a succession plan and terms for active engagement.
Project Roles Review
The package management system maintainers should have a process for reviewing the roles on projects to ensure the maintainers are active.
Account Level Library Tagging
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.
Prevents credential from being published
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.