Skip to main content

Security

How Bestax protects its supply chain, how you can verify what you install, and where to report a vulnerability.

What you install is what we built​

The packages released through CI — @allxsmith/bestax-bulma, create-bestax, bestax-migrate, bestax-mcp and @allxsmith/eslint-plugin-bestax — carry npm provenance: every version in the supported release lines below carries a signed attestation generated at publish time that links the tarball on the registry to the exact source commit and the public CI run that built it. (Versions older than those lines predate provenance and have none — another reason staying current is the supported posture. A package's very first version can also be a placeholder published by hand to create the name, which no laptop can attest; those are superseded by the first CI release.) Releases authenticate to npm via OIDC trusted publishing (short-lived, per-run tokens), so there is no long-lived npm token that could leak and be used to push a rogue release.

Only the latest release line of each package receives security fixes (currently bestax-bulma 5.x, create-bestax 4.x, bestax-migrate 2.x, bestax-mcp 1.x, and eslint-plugin-bestax 1.x). Releases are fully automated from main via semantic-release, so the newest published version is always the patched one — staying current is the supported posture. See SECURITY.md for the full policy.

Verify it yourself​

  • Provenance on npmjs.com — the package pages for @allxsmith/bestax-bulma, create-bestax, bestax-migrate, bestax-mcp and @allxsmith/eslint-plugin-bestax each show a Provenance section linking an attested version to its source commit and build.
  • npm audit signatures — in projects installed with the npm CLI, run it to check registry signatures and provenance attestations for every package in your tree, Bestax included. (It's an npm command — for pnpm or yarn projects, rely on the lockfile guidance below and the provenance UI on npmjs.com.)
  • Lockfiles — commit your lockfile and install with a frozen/ci install (npm ci, pnpm install --frozen-lockfile) so your builds resolve exactly what you reviewed. Bestax's own CI does the same.

How the repository is protected​

The monorepo applies defense-in-depth against supply-chain attacks:

  • Dependency install scripts are blocked by default. pnpm only runs install/postinstall scripts for an explicit allow-list of native builders — any dependency outside that short list can't execute code at install time.
  • A 3-day dependency cooldown. By default, versions published less than 3 days ago refuse to install, which defeats the common pattern where a hijacked package's malicious release is yanked within hours. (The dev-only prettier formatter is the one pinned exclusion.)
  • Isolated node_modules. pnpm's isolated linker makes undeclared (phantom) dependencies fail loudly instead of silently resolving.
  • Frozen-lockfile CI. Build and release jobs install with --frozen-lockfile; the only exception is the React 18/19 compatibility matrix, which deliberately re-resolves React for testing and never publishes.
  • SHA-pinned GitHub Actions. Every third-party action is pinned to a full commit SHA, so a moved tag can't inject code into the pipeline.
  • CodeQL, dependency review, and Dependabot. Code scanning covers the TypeScript sources and the workflow files themselves; a dependency-review gate blocks PRs that introduce dependencies with known advisories; grouped Dependabot PRs keep the tree current on a weekly cadence.

OpenSSF assessments​

Two OpenSSF programs cover this repository, and both publish their results publicly:

  • OpenSSF Best Practices — bestax holds the passing badge. The questionnaire behind it covers the documented contribution process, vulnerability reporting, automated testing, static analysis, secure delivery, and unique versioning with release notes. Every answer is public and cites the evidence in this repository, so each claim can be checked against what is actually here rather than taken on faith.
  • OpenSSF Scorecard — an automated scan that runs weekly from .github/workflows/scorecard.yml and publishes to the public viewer. It reads branch protection, pinned dependencies, token permissions, code review, signed releases, and known vulnerabilities straight out of the repository and scores them.

Both badges are at the top of the README and of the README of each published package. The npm package pages pick them up on each package's next release.

Reporting a vulnerability​

Please report privately — don't open a public issue:

You'll get an acknowledgment within 48 hours, and we aim to triage and confirm within 7 days; the full disclosure process is in SECURITY.md.