pharn-ci runs inside other people's CI. The GitHub Action runs with the pull-requests: write permission to post a sticky PR comment, and it reads files and diffs from the repository it checks. That makes its integrity, and the integrity of its release tags, part of the product. We welcome coordinated disclosure of any vulnerability in this repository.

Status: pharn-ci is pre-1.0. Only the latest release and main receive security fixes.

• The GitHub Action (action.yml, packages/action): runs in a consumer's workflow with their GITHUB_TOKEN. It makes no network calls except to the GitHub API and, only when the policy input is auto or required and the job grants id-token: write, one GET /api/v1/policy to the app-url origin (https only, default https://pharn.dev) to read the org policy and, unless the upload input is never and only when the job grants id-token: write, the upload of the run to pharn.dev: two POST requests to the same origin and one PUT of the redacted report.json and meta.json to a signed storage URL it names (upload: never turns that off). It has no telemetry.
• Input parsing (packages/core): lcov, Cobertura XML, unified diffs and the config file are untrusted input, parsed by hand-written parsers. A crafted file must not crash, hang or exhaust memory in the consumer's CI.
• The CLI (packages/cli): reads files and runs git in the working directory.
• Release integrity: packages/action/dist is committed and must match a build of the sources (CI fails if it is stale), and consumers pin exact release tags such as pharn-dev/pharn-ci@v0.5.0, or their commit SHA. Tags matching v* are never moved or deleted (enforced by a ruleset), and releases are cut from verified main commits (docs/RELEASING.md). Release tags are unsigned lightweight tags, so the full commit SHA, not the tag, is what a consumer can verify.

pharn-ci has a single maintainer, who is also the only code owner (.github/CODEOWNERS). Every control in this repository that needs a second person is therefore procedural, not enforced:

• Merges. The main ruleset requires one approving review from a code owner, but GitHub does not let an author approve their own pull request. Pull requests, including ones written with AI coding agents, are merged under the maintainer's account using the ruleset's admin bypass (pull_request mode). No second person reviews them.
• Releases. The release environment's required reviewer is the same maintainer, who approves their own release; prevent_self_review is off, because turning it on with one reviewer would block every release.

What still holds without a second person, because GitHub enforces it for the admin too:

• no direct push, force-push or deletion on main; changes land only as signed, squash-merged commits with linear history;
• the bypass skips the approval only: a pull request cannot merge until all six required checks pass (ci, with its stale-dist check; Action pins; gitleaks; CodeQL's Analyze (javascript-typescript); and the two Socket Security checks);
• third-party actions pinned to commit SHAs; v* tags that nobody can move or delete; immutable releases, cut only from a verified main commit by a job that installs nothing.

Plan: when a second maintainer joins, add them to .github/CODEOWNERS and as a reviewer of the release environment, set prevent_self_review: true on that environment, and stop using the admin bypass for merges (then remove it from the main ruleset). Until then, treat a pharn-ci release as reviewed by one person, and pin the commit SHA you have checked.

The security design, with each mitigation tied to the test that enforces it, is in docs/THREAT-MODEL.md; what pharn-ci does not guarantee is in docs/LIMITS.md.

pharn-ci has no backend of its own in the Action. Everything it reads stays on the runner, and everything it writes goes to your own GitHub: the PR comment, the job summary, the step log and a file in RUNNER_TEMP. Two things go to Pharn, and both only when the job grants id-token: write: the org policy request, which sends an OIDC token and the repository name, and the run upload, which sends the redacted report.json and meta.json of the run (rows below). The table describes the GitHub Action; the CLI makes no network calls and prints to your terminal.

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

Report privately through GitHub private vulnerability reporting. The report stays confidential and embargoed until a fix ships.

Please include, as far as you can:

• The type of issue (e.g. token exposure, path traversal, command injection, denial of service, supply-chain).
• The package and source file(s) involved.
• The affected version, tag, branch or commit.
• Step-by-step reproduction instructions and a proof of concept, if you have one.
• The impact: how an attacker might exploit the issue, and what they would gain.

• 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, coordinate disclosure timing with you, and credit you in the advisory unless you ask to remain anonymous.

• Leaking or misusing the consumer's GITHUB_TOKEN, or writing anywhere other than the PR comment and job summary.
• Path traversal or arbitrary file read or write through lcov, Cobertura, diff or config input.
• Command injection through the CLI's git calls or the Action's inputs.
• A crafted input that crashes, hangs or exhausts memory in the consumer's CI.
• Any way to publish, alter or substitute a release artifact, move a v* tag, or ship a packages/action/dist that does not match the sources.
• A new runtime dependency introduced unnoticed.

• Vulnerabilities in third-party dependencies that an upstream patch fixes. Please report those upstream.
• Issues that require the attacker to already control the CI runner or the consumer's workflow.
• Social engineering, or attacks requiring physical access to a machine.
• Denial of service that does not exploit a specific vulnerability.

1. Pin the Action to a commit SHA, not only to a tag (release tags are not signed), and keep permissions: minimal (contents: read, plus pull-requests: write only if you want the PR comment). Grant id-token: write only if you want the org policy and the run upload: with it the Action fetches the policy and, with the default upload: auto, sends the redacted report and run metadata to pharn.dev. A same-repository pull request can edit the workflow that grants it, so protect .github/workflows/ with CODEOWNERS and required reviews (docs/THREAT-MODEL.md, residuals 26 and 27).
2. Do not run it on pull_request_target. That event runs in the base repository's context with a write token. Its default checkout is the base branch, so the PR cannot be measured, and checking out the PR head to measure it would run fork code with that token. pharn-ci reports the diff as unavailable instead (DIFF_UNAVAILABLE) and never advises checking out the PR head. Two safe routes: run pharn-ci on pull_request (fork PRs get the job summary only), or, to get the comment on fork PRs too, run your tests on pull_request, upload the coverage file and PR number as an artifact, and run pharn-ci in a second workflow on workflow_run with the pr-number and head-sha inputs (see the README). That run reads the PR through the GitHub API, checks out and runs no PR code, and fails when the artifact does not match the tested commit.
3. Review the report before acting on it; it is derived from untrusted PR content.

Thank you for helping keep pharn-ci and its users safe.