Skip to content

Security: jaredwray/cacheable

SECURITY.md

Security Policy

We take security seriously and work to keep this project up to date. If you discover a security vulnerability, please report it privately so we can investigate and ship a fix before the issue becomes public.

Reporting a vulnerability

Please use one of the following private channels — do not open a public issue, pull request, or discussion for security concerns:

  1. Preferred: open a private report via GitHub's Privately reporting a security vulnerability flow on this repository's Security tab.
  2. Email: send the details to me@jaredwray.com. If the issue is urgent, include [SECURITY] in the subject line and we will respond as soon as possible.

When reporting, please include as much of the following as you can:

  • A description of the vulnerability and its impact.
  • Steps to reproduce, or a proof-of-concept.
  • The affected version(s) and platform.
  • Any suggested remediation, if you have one.

We will acknowledge receipt, work with you on a coordinated disclosure timeline, and credit you in the advisory once a fix is published unless you ask to remain anonymous.

How this repository is secured

This repository follows the defense-in-depth hardening checklist; progress is tracked in DEFENSE_IN_DEPTH.md. Measures currently in place:

  • All changes land through pull requests — direct pushes to main are blocked, and merging requires passing status checks (test, test-22, test-24, test-26, zizmor).
  • Tags can only be created by repository admins; published GitHub Releases are immutable (assets and tags cannot be changed after publish).
  • Workflow runs from outside collaborators always require maintainer approval, and only allowlisted GitHub Actions can run.
  • CI workflows default to read-only contents: read permissions; generated output is never committed back from CI; every action is pinned to a full commit SHA; Socket Firewall (sfw) wraps pnpm install; workflows are security-linted with zizmor on every PR.
  • npm publishing authenticates with OIDC trusted publishing configured stage-only on each published package (GitHub Actions → jaredwray/cacheable → workflow release.yml). There are no npm tokens in Actions secrets, and packages disallow tokens. CI packs tarballs and stages them with pnpm stage publish; Drydock reviews staged releases; a maintainer promotes with 2FA. The release job needs a passing Aikido scan-release.
  • GitHub and npm maintainer accounts use phishing-resistant 2FA (passkeys / hardware keys).
  • pnpm is pinned via packageManager (pnpm@11.5.1), and the lockfile is committed.
  • Dependencies install through pnpm with a 7-day cooldown on new versions, lifecycle scripts blocked by default, and trustPolicy: no-downgrade.
  • There is no .github/dependabot.yml.
  • Codespaces and Cursor Cloud Agents install through Aikido Safe Chain; package-manager shims must not be bypassed.
  • Socket reviews every dependency change; Aikido scans every build.
  • .github/CODEOWNERS names owners for /.github/, /.cursor/, /.devcontainer/, and /scripts/.

There aren't any published security advisories