Skip to content

Security: pharn-dev/pharn-oss

Security

SECURITY.md

Security Policy

PHARN is an audit-grade methodology — taking security seriously is part of the brand, not an afterthought. We welcome coordinated disclosure of any vulnerability in this repository.

Supported versions

PHARN ships as .claude/ files fetched at install time, not as an installed runtime. We patch security issues against the latest released version only; the single source of truth is the SKILLS_VERSION file.

Version Supported
Latest
< Latest

Installed skills are SHA-pinned — you do not receive fixes automatically. Your installed version is recorded in pharn.config.json; compare it against SKILLS_VERSION and run npx pharn@latest update to pick up security fixes.

Reporting a vulnerability

Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests.

Instead, report privately through one of these channels:

  1. GitHub Security Advisories (preferred) — use private vulnerability reporting to open a confidential report. No email is exposed and the report stays embargoed until a fix ships.
  2. Email — if you cannot use GitHub advisories, email support@pharn.dev with [PHARN SECURITY] in the subject.

Please include as much of the following as you can — it speeds up triage:

  • The type of issue (e.g. prompt injection, path traversal, secret exposure, supply-chain).
  • Full paths of the file(s) involved (skill, hook, runner, rule, or template).
  • The location of the affected code (tag/branch/commit or a direct URL).
  • Any configuration required to reproduce.
  • Step-by-step reproduction instructions.
  • Proof-of-concept, if you have one.
  • Impact — how an attacker might exploit the issue.

Response timeline

  • Initial acknowledgement — within 3 business days of your report.
  • Preliminary assessment and severity — within 7 days.
  • Resolution target — critical issues within 30 days; other issues within 90 days.

We will keep you informed throughout, coordinate disclosure timing with you, and credit you in the advisory unless you ask to remain anonymous.

Scope

PHARN ships markdown, frontmatter, stdlib-only Node .cjs hooks, and stdlib-only .mjs audit runners — no transpile, no bundled runtime dependencies. Security-relevant surfaces follow from that shape.

In scope

  • Prompt-injection vectors in skills, lenses, grillers, verifiers, or agent definitions that could bypass intended agent behavior or the constitution.
  • Path traversal or unintended file-system access in the .cjs hooks (privacy-shield, constitution-guard, the Stop gates) or the .mjs audit runners.
  • Secret or PII exposure — gaps in privacy-shield redaction, or guidance that would lead a user project to leak secrets/PII.
  • Supply-chain issues in how audit runners spawn external tooling via npx/child_process.
  • Logic in the executable carve-out (.cjs hooks, .mjs runners, review-ledger.cjs, cross-model-review) that could be abused.

Out of scope

  • Vulnerabilities in user-authored skills, lenses, or rules scaffolded into a user's own project.
  • Vulnerabilities in third-party AI providers (Claude, or a configured cross-model provider).
  • Issues in vendor libraries the docs reference (Stripe, Drizzle, Supabase, etc.) — report those upstream.
  • Social engineering, or attacks requiring physical access to a user's machine.
  • Denial of service that does not exploit a specific vulnerability.

Security best practices for users

PHARN's privacy-shield and constitution-guard hooks are defense-in-depth, not a guarantee. When using PHARN:

  1. Review AI-generated code before you run or merge it — that is the methodology's whole point.
  2. Keep the privacy-shield and constitution-guard hooks enabled; they redact PII and block constitution violations at the tool boundary.
  3. Run npx pharn@latest update regularly to pick up fixes — installed skills are SHA-pinned and do not update themselves.
  4. Review dependencies that generated code introduces.
  5. Keep the cross-model review pass off unless you have vetted the configured provider. PHARN ships no default cross-model provider; the pass is opt-in, off by default, and bring-your-own-key — the security of whichever provider you configure is your responsibility.

Acknowledgements

We appreciate the security research community. Anyone who reports a valid issue in good faith will be credited in the resulting advisory.

Thank you for helping keep PHARN and its users safe.

There aren't any published security advisories