pantoken

pantoken provides an upgrade path to current releases rather than maintaining older release lines. Published packages follow semantic versioning through Changesets and include per-package changelogs describing changes. Breaking changes require a major version. The project also maintains a generated compatibility manifest and lifecycle-aware shims for removed upstream tokens, documenting replacements and planned removal points. If a future upgrade requires manual migration, its changelog and release notes will document the changed interfaces and required steps.

managed via github issues.
https://github.com/thedannywahl/pantoken/issues

No vulnerabilities reported.

https://github.com/thedannywahl/pantoken/blob/main/SECURITY.md#vulnerability-response-process

https://github.com/thedannywahl/pantoken/blob/main/CONTRIBUTING.md#coding-standards

pantoken automatically enforces its coding standards using FLOSS tools. Oxfmt, Oxlint, TypeScript, ESLint/TSDoc, Stylelint/cssdoc, and markdownlint run through the project’s ready:all gate and GitHub Actions workflows. The checks run on every pull request and push to main, and contributions must pass them before merging.

https://github.com/thedannywahl/pantoken/blob/main/.github/workflows/ci.yml

No native binaries are being generated.

No build or installation system included.

No build or installation system included.

pantoken’s build is repeatable. Dependencies and upstream sources are pinned, generators use deterministic ordering, and build artifacts do not embed timestamps. Two complete uncached workspace builds produced identical SHA-256 hashes for all 478 generated and compiled files.

there is no installation / uninstallation of software produced by pantoken.

there is no installation / uninstallation of software produced by pantoken.

pantoken uses the conventional Node.js/pnpm installation workflow. Cloning the repository and running pnpm install installs dependencies for the entire workspace, including the build, test, lint, type-checking, and documentation tools. pnpm run ready then builds all project results and runs the complete test and validation environment.

https://github.com/thedannywahl/pantoken/blob/main/pnpm-lock.yaml

pantoken monitors dependencies through GitHub Dependabot security alerts and updates, plus weekly Renovate checks covering package dependencies, the lockfile, and SHA-pinned GitHub Actions. Snyk provides an additional dependency vulnerability scan. Vendored token and icon outputs retain upstream version and commit provenance and are regenerated from monitored dependencies. Known exploitable vulnerabilities are upgraded or pinned to patched versions; findings determined to be inapplicable must be documented as such.

Externally maintained software components are declared through standard package manifests, centrally versioned in the pnpm workspace catalog, and resolved by the lockfile. Renovate and Dependabot identify updates, which can be applied through ordinary dependency-version changes and validated by the complete build and test gate. The Pendo CSS is maintained as pantoken source following its original port rather than tracked as an external convenience copy. Remaining externally sourced files are static font and brand assets, not reused software components.

Pantoken uses current, supported APIs in its implementation. Automated linting, type checking, testing, and dependency-update tooling help detect obsolete interfaces. The demo runner uses the modern asynchronous Clipboard API by default; its isolated use of the legacy execCommand("copy") API is only a compatibility fallback when the modern API is unavailable. Deprecated design-token aliases documented by the project are maintained intentionally for consumer migration and do not represent use of deprecated runtime APIs.

GitHub Actions runs the project’s CI workflow on every push to the main branch and on every pull request. The workflow builds the workspace and executes the automated test suites for all packages using vp run -r test. Test success or failure is reported through GitHub Actions, and an aggregate CI gate fails when any required job fails or is cancelled.

An audit of bug fixes made during the last six months found that more than 50% are covered by targeted automated regression tests. Covered cases include DTCG prototype-pollution handling, SVG arc processing, web-component command and spacing behavior, theme-specific component styles, CSS syntax inference, missing-file and missing-baseline handling, npm publication safeguards, and changelog parsing. These tests are part of the test suite executed by GitHub Actions on every pull request and every push to the main branch.

Pantoken’s automated test suite uses Vitest with V8 coverage. The repository enforces a minimum statement-coverage threshold of 85%, and Codecov currently reports approximately 95% coverage. Coverage is measured automatically in CI and falls above the required 80%.

Pantoken’s written contribution policy requires contributors to add or update automated tests for every behavioral change, including major new functionality. Contributors must also run the project’s unit-test suite before pushing their changes.

This is documented in CONTRIBUTING.md under "Making changes" — step 3 says "Add or update tests for any changed behaviour."
https://github.com/thedannywahl/pantoken/blob/main/CONTRIBUTING.md

Linting is a required blocking job in CI — the lint job must pass for ci-gate to succeed, and ci-gate is a required branch protection check. Warnings aren't advisory; they block merge.

https://github.com/thedannywahl/pantoken/blob/main/.github/workflows/ci.yml — the lint job and ci-gate aggregator.

Pantoken implements secure-design principles appropriate to its function and threat model. The project documents its trust boundaries and limitations, validates potentially dangerous structured-data keys, prevents path traversal in file-serving code, uses regular expressions designed to avoid excessive backtracking, and minimizes runtime reliance on external resources. Its CI and release design uses scoped permissions, pinned actions, automated security checks, short-lived OIDC publishing credentials, and npm provenance. Automated tests cover these security-relevant controls.

No cryptographic functionality in the software produced by the project

Pantoken is a design-token transformation and distribution system, not a cryptographic library, and it does not implement or expose cryptographic algorithms. Any cryptography used by npm, GitHub, HTTPS, or the underlying runtime is supplied and managed by those external systems.

Pantoken does not process or store authentication credentials or private cryptographic keys. Credentials used by external repository and publishing infrastructure are managed separately by GitHub Actions and npm OIDC and are not part of Pantoken’s configuration, runtime, or published APIs.

Pantoken does not implement or expose network communications. It operates on local design-token inputs and generated outputs. Any HTTPS, Git, npm, CDN, or publishing communication is performed by external package managers, development tools, or hosting services and is outside Pantoken’s software implementation.

Pantoken does not implement or expose network communications. It operates on local design-token inputs and generated outputs. Any HTTPS, Git, npm, CDN, or publishing communication is performed by external package managers, development tools, or hosting services and is outside Pantoken’s software implementation.

Pantoken does not implement or expose network communications. It operates on local design-token inputs and generated outputs. Any HTTPS, Git, npm, CDN, or publishing communication is performed by external package managers, development tools, or hosting services and is outside Pantoken’s software implementation.

Pantoken does not implement or expose network communications. It operates on local design-token inputs and generated outputs. Any HTTPS, Git, npm, CDN, or publishing communication is performed by external package managers, development tools, or hosting services and is outside Pantoken’s software implementation.

Pantoken cryptographically protects releases using GitHub immutable-release attestations and npm/Sigstore provenance attestations. The documented verification process explains how users can verify GitHub release tags and assets with the GitHub CLI and npm package signatures and provenance with npm audit signatures. Both mechanisms use keyless or platform-managed signing, so no long-lived Pantoken private signing key is stored on a public distribution site.

https://github.com/thedannywahl/pantoken/blob/main/SECURITY.md#verifying-releases

Important Pantoken version tags are protected by GitHub immutable releases. Each immutable release automatically receives a cryptographically verifiable attestation containing its release tag and target commit SHA, and the associated tag cannot subsequently be moved or reused. Users can verify a tag and release with gh release verify, following the project’s documented release-verification process.

https://github.com/thedannywahl/pantoken/blob/main/SECURITY.md#verifying-releases

Pantoken uses hardening mechanisms applicable to its TypeScript/JavaScript architecture. It ships no native executable code requiring compiler or linker hardening and runs within the memory-safe Node.js or browser runtime. Defense-in-depth controls include sandboxed iframes for executable demonstrations, non-shell child-process execution, securely created temporary directories, path containment for file serving, null-prototype objects for generated data, frozen mappings, and HTML attribute escaping. These controls limit the impact of defects even when other validation fails.

Pantoken provides a formal security assurance case covering its published packages, generated outputs, CLI, documentation tooling, and release process. It defines the project’s threat model and trust boundaries, explains how secure-design principles apply to its architecture, and maps common implementation weaknesses—including prototype pollution, path traversal, command injection, markup injection, ReDoS, dependency compromise, and release tampering—to concrete controls and repository evidence. It also documents residual risks without presenting planned controls as implemented.

https://github.com/thedannywahl/pantoken/blob/main/ASSURANCE.md

CodeQL uses the security-extended query suite, which specifically targets common vulnerability classes (injection, path traversal, prototype pollution, etc.) for JavaScript/TypeScript.

https://github.com/thedannywahl/pantoken/blob/main/.github/workflows/codeql.yml

The project produces no software written in memory-unsafe languages. All source is TypeScript/JavaScript.