Package Trust
Public trust source for Starkscan npm SDK, CLI, and MCP packages.
Loading documentation content…
Public trust source for Starkscan npm SDK, CLI, and MCP packages.
Use this page before installing Starkscan npm packages in agents, CI, or production services.
This page is the public trust source for Starkscan packages. The canonical engineering repository is private, so package README files, homepage metadata, and agent-facing metadata should link here instead of sending users to a private GitHub URL. Public package manifests should omit repository metadata until a public source repository or mirror exists.
Machine-readable source for agents:
public-client-surface-matrix.json
LLM-readable source:
/llms.mdx/docs/build/package-trust/index.mdx
There is no single npm badge that should be treated as a security certification. The production-grade trust model is layered:
@starkscan npm organizationrepository tradeoff is resolvedFor beta users, use the alpha channel only when you can tolerate package updates.
For production agents, pin a smoked exact version such as:
npx -y @starkscan/[email protected]
npx -y @starkscan/[email protected] doctor
npm install @starkscan/[email protected]alpha currently points to 0.1.0-alpha.1. latest currently points to the
stable fail-closed placeholder 0.0.0, not the alpha prerelease. Use the
exact 0.1.0-alpha.1 version or the explicit @alpha tag only.
If 0.1.0-alpha.1 regresses, roll back by pinning the prior alpha explicitly
and rerunning the same smoke checks before putting it in an unattended agent:
npx -y @starkscan/[email protected] doctor
npx -y @starkscan/[email protected] doctor
npm install @starkscan/[email protected]Keep MCP and CLI on the same package version. The MCP launcher depends on the
matching CLI package, so mixing @starkscan/[email protected] with a different
CLI version is not a supported rollback shape.
| Package | Public channel | Trust status |
|---|---|---|
@starkscan/sdk | alpha | 0.1.0-alpha.1 is published, imports under Node ESM, and passed live status smoke with STARKSCAN_BASE_URL=https://starkscan.co/api. |
@starkscan/cli | alpha | 0.1.0-alpha.1 is published with bundled native artifacts, manifest/checksum verification, and live status / doctor smoke with STARKSCAN_BASE_URL=https://starkscan.co/api. |
@starkscan/mcp | alpha | 0.1.0-alpha.1 is published, delegates to the exact matching @starkscan/cli version, and passed live doctor smoke with STARKSCAN_BASE_URL=https://starkscan.co/api. |
The current package trust fields live under packageTrust in
public-client-surface-matrix.json.
Agents should read this section as policy, not marketing copy:
public-client-surface-matrix.json are the public source of truth.@starkscan.X-Request-Id, route class, host, and command.Trusted Publishing is the preferred CI publish path because it removes long-lived npm publish tokens from GitHub Actions. It is not the same control as npm provenance.
There is one important private-repository constraint: npm documents that
GitHub trusted publishing requires npm CLI 11.5.1 or newer and that the package
repository.url must match the exact repository URL string used for
publishing/provenance verification. Normalization differences such as
git+https://... versus https://github.com/... can break verification.
Starkscan package manifests intentionally omit repository while the canonical
engineering repo is private, because npm package pages should not send public
users or agents to a private source URL.
npm provenance is stronger but has a public-source constraint. npm documents that provenance generation is not supported for private repositories, even for public packages.
Until Starkscan has a public source mirror, changes repository visibility, or
chooses to expose the private repo URL in repository, use manual passkey-backed
publishes for alpha and do not treat missing Trusted Publishing or missing npm
provenance as a package integrity failure. The production target remains
tokenless CI publishing, but the source-link decision must be explicit first.
Current Starkscan state:
0.1.0-alpha.1 is published on the alpha dist-taglatest dist-tag points at the stable fail-closed placeholder
0.0.0, not the alpha prerelease0.1.0-alpha.1 and latest resolves to 0.0.0id-token: write for the future Trusted Publishing pathlatest0.1.0-alpha.0, which is the current prior
alpha rollback target when pinned and smoke-tested explicitlySTARKSCAN_BASE_URL=https://starkscan.co/api and the beta API-key contractThe release workflow attests SDK and native CLI artifacts before npm packaging. This gives maintainers a build evidence trail for artifacts. Public users should use this page, npm package metadata, and the machine-readable matrix as their public trust entrypoint unless a public source mirror is introduced.
Socket is a package-risk and supply-chain scanner. It is useful as an external signal for dependency risk, maintainer/package metadata, and malware-style patterns, but it is not a formal audit certificate.
Package pages:
If Socket is unavailable behind a browser challenge, npm and GitHub release evidence remain the primary trust sources.
OpenSSF Scorecard and the OpenSSF Best Practices badge are good repository posture signals. They should be added as repository-level launch hardening, not as per-package certification.
For the current private-repository setup, OpenSSF signals belong on the internal maintainer checklist. The public package trust path should stay honest: npm identity, exact package version, checked tarball contents, CLI checksum verification, Socket as a risk signal, and this public docs page.
STARKSCAN_* env vars and keep API keys in the agent secret store.npx @starkscan/*@alpha in an unattended production loop without
a version allowlist.X-Request-Id, and route class when reporting a bug.latest as a convenience tag only after the package is explicitly
promoted out of alpha.Before promoting any package channel beyond alpha:
latest does not point at an alpha prerelease.