Security

Private packages need policy, not just private tarballs.

PackagePass treats every install, publish, token, grant, and version change as an authorization event. That gives teams a clearer security story for internal libraries, customer SDKs, and generated code.

policy check

{
  "subject": { "type": "customer", "slug": "globex" },
  "resource": { "type": "package", "name": "@acme/payments" },
  "action": "package:install",
  "decision": "allow",
  "reason": "active grant"
}

Default posture

Controls built around least privilege.

Vendor review is easier when package distribution is backed by concrete controls instead of broad trust claims.

Token hashes

API, install, publish, and CI tokens are stored as SHA-256 hashes, with an optional server-side pepper.

Artifact storage

Published tarballs are stored by PackagePass in the configured tarball object bucket, not served from source repos.

Integrity metadata

Each package version stores tarball size, SHA-1 shasum, and SHA-512 npm integrity metadata.

Authorized registry reads

Registry metadata and tarball downloads require package:install before PackagePass serves package data.

Token storage

Tokens are generated once for the caller and stored as SHA-256 hashes with an optional server-side pepper.

Artifact storage

Published package tarballs are written to the configured tarball object bucket and referenced by stored object keys.

Release integrity

Each version records tarball size, SHA-1 shasum, SHA-512 integrity, dist-tags, and version status.

Registry authorization

Package metadata and tarball routes authorize package:install before returning packuments or tarball bytes.

Audit retention

Audit retention is enforced by plan: Free 7 days, Team 30 days, Business 180 days, and Enterprise by review.

Buyer proof

Specific enough for engineering review.

Lead with practical controls, not generic trust language. The audience needs to know how PackagePass protects installs, publishes, generated packages, and customer-specific SDK access.

version metadata

{
  "packageName": "@acme/payments",
  "version": "4.8.1",
  "tarball": {
    "size": 24831,
    "shasum": "a9993e364706816aba3e25717850c26c9cd0d89d",
    "integrity": "sha512-..."
  },
  "status": "active"
}

audit event

{
  "type": "grant.created",
  "actor": { "type": "user", "display": "devex@acme.com" },
  "packageName": "@acme/payments",
  "resource": {
    "subject": { "type": "customer", "slug": "globex" },
    "actions": ["package:install"]
  }
}

Current trust controls

Package access is evaluated per subject, resource, and action.
Tokens are stored as hashes, not plaintext token values.
Tarballs are stored as object-bucket artifacts with checksum and npm integrity metadata.
Registry metadata and tarball requests require package:install authorization.
Audit retention is enforced by the active billing plan.

Grant conditions currently enforce expiration with expiresAt. Environment, IP allowlist, and version-range conditions are stored as metadata until those checks are added to the policy engine.

Roadmap, not current controls

Provenance attestations for build IDs and source commits.
Package signatures and npm registry signing endpoints.
SBOM storage and release attestation formats.
Enforced IP allowlists, environment conditions, and version-range grant conditions.

To report a security issue or ask for an implementation review, email michael@sedrino.com.