Security
Security at Package Broker
Report a vulnerability, review the token model and audit log, and check where your deployment stores data. You operate the registry and choose its deployment controls.
Reporting a vulnerability
Report a vulnerability through GitHub private vulnerability reporting. Open the repository’s Security tab and choose Report a vulnerability. Do not open a public issue for a security problem. The policy promises an acknowledgement within five working days.
GitHub private vulnerability reporting · security@package.broker
You can also report by e-mail. The same address accepts questions about this page.
Include the affected package and version or commit, the runtime (Cloudflare Workers or Node), steps to reproduce and the impact you see.
The repository, CLI, both runtimes, first-party plugins and generated build manifest are in scope. Third-party registries and findings requiring a compromised deployment master key or database write access are outside the policy’s scope.
Security policy (SECURITY.md) · Machine-readable disclosure policy
Token model
Token kinds identify the principal. Scopes are read, write and full. Scope checks and grants constrain each request; a token does not grant rights beyond its principal’s access.
| Kind | Principal | Project binding | Maximum life |
|---|---|---|---|
pb_pat_ | A user | Selected projects, or all projects allowed by the user’s grants | Configured personal-token limit |
pb_svc_ | A service principal | One project; organization-wide creation requires organization administration rights | Configured service-token limit |
Use read scope for installs in CI. Choose write for publishing operations or full for token-eligible API operations only when the principal’s grants allow them. Session-only actions still require a session.
Re-authentication is required before token creation. Revoking a token applies on the next request.
The operator configures maximum lifetimes separately for personal and service tokens. Both limits default to 365 days; the configurable ceilings are 365 days for personal tokens and 3,650 days for service tokens.
Audit log
Audit events are stored in the application database. Sealed rows form a SHA-256 hash chain; the API can list events and return the chain head. The chain can reveal changed rows when checked against a trusted head hash.
An administrator with database write access can rewrite a chain. Retain head hashes outside the database when you need an independent comparison.
Where data lives
On Cloudflare Workers, a deployment using D1 stores metadata there and a deployment using R2 stores artifacts there. Provisioning accepts a jurisdiction for D1 and R2 and checks it against existing resources. Choose storage placement when you create those resources.
On Node, you choose the host and persistent storage. For Docker, the application database uses the mounted data volume.
Storage placement does not determine where requests to package sources or external services are processed. Assess storage and outbound requests separately.
Security and data residency · Provisioning jurisdiction checks
What the operator owns
You deploy Package Broker. Use this division of responsibilities when reviewing your deployment.
| Area | Package Broker provides | The operator owns |
|---|---|---|
| Identity | OIDC sign-in and grants to identity provider groups or e-mails | Identity provider, groups, offboarding and multi-factor policy |
| Tokens | Project binding, scopes, expiry and revocation | Lifetime settings, CI secret storage and rotation, service principal grants |
| Audit log | Stored events and a sealed hash chain | Retention and independent storage of head hashes |
| Data location | D1 and R2 jurisdiction inputs during provisioning | Cloudflare resources, storage placement, Node host and volumes |
| Deployment master key | Encryption of source credentials using the deployment key | Key storage, access, backup and rotation |
| Backups and upgrades | Self-hosted Workers and Node runtimes | Taking and testing backups, applying updates and checking release notes |
| Network exposure | Application access checks | TLS, hostnames, firewall and any identity gateway policy |
Support and maintainers
Package Broker has one maintainer during the pre-release phase. Governance records how decisions are made and how contributors become reviewers and maintainers.
Ask general questions in GitHub Discussions or by e-mail. Report security problems through the private disclosure routes above.
Release status
Package Broker 2.0 has no tagged release yet. Reports against the main branch are accepted.