How to report a security vulnerability in powershell-lsp, what is in scope, and what to expect after you report. For the full trust and supply-chain posture (downloads, pinned hashes, SBOM, provenance, signing status, allow-listing), see TRUST.md.

Security fixes are issued for the latest released version only. This is a single-maintainer project (see TRUST.md); backporting to older releases is not promised. Upgrade to the latest release to receive security fixes.

Please do NOT open a public GitHub issue for a security vulnerability. Public issues disclose the problem before a fix is available.

Report privately through GitHub Private Vulnerability Reporting, which is enabled on this repository:

• Go to https://github.com/manderse21/claude-powershell-lsp/security/advisories/new (the repository Security tab -> Report a vulnerability), and file a private advisory. Only the maintainer can see it; we can discuss and fix it before any public disclosure.

When you report, please include as much as you can:

• a description of the vulnerability and its impact;
• the affected version (and platform / PowerShell host, if relevant);
• step-by-step reproduction, a proof-of-concept, or the offending code path;
• any suggested remediation.

In scope -- the code in this repository and what it does at runtime:

• the plugin hook scripts (scripts/*.ps1) and shared library (scripts/lib/*.ps1);
• the first-run bootstrap: the download, SHA-256 verification, and vendoring of the pinned dependencies (ensure-pses.ps1, ensure-pssa.ps1);
• the per-session daemon, its named-pipe IPC, and the diagnostics surface;
• the release tooling (SBOM generation, provenance) under release/.

Out of scope -- report these to their own projects:

• PowerShell Editor Services and PSScriptAnalyzer themselves (Microsoft open-source dependencies this plugin downloads). Report upstream: PowerShellEditorServices and PSScriptAnalyzer. A flaw in how this plugin downloads, verifies, or invokes them is in scope; a flaw inside them is not.
• Claude Code itself and its plugin/hook mechanism. Report to the claude-code project.
• Findings that require an already-compromised local machine or administrator access (the plugin runs with the user's own privileges and trusts the local environment).

• Acknowledgement: best-effort within 7 days. This is a solo-maintained project, so response is best-effort, not a contractual SLA.
• Triage and fix: once confirmed, a fix is prioritized over feature work. The timeline depends on severity and complexity; we will keep you updated in the private advisory.
• Disclosure: we prefer coordinated disclosure -- we will agree on a disclosure date with you, publish the fix in a release, and credit you in the advisory and CHANGELOG unless you ask to remain anonymous.
• No bug bounty: there is no monetary reward program. Credit and our thanks are what we can offer.

Every tagged release is produced by this repository's gated release pipeline, which publishes a SLSA v1.0 build-provenance attestation over the release archive. The attestation is signed through GitHub's OIDC identity (Sigstore keyless) -- there is no maintainer-held signing key to leak or compromise -- so anyone can verify a release independently with the GitHub CLI.

1. Download the release archive for the version you want:

gh release download v1.17.0 --repo manderse21/claude-powershell-lsp --pattern "*.tar.gz"

2. Verify its build provenance:

gh attestation verify powershell-lsp-1.17.0.tar.gz --repo manderse21/claude-powershell-lsp

gh fetches the attestation from GitHub, checks the archive's SHA-256 digest against it, and enforces that the signing identity is this repository's release workflow. On success it prints Verification succeeded! and exits 0; on any mismatch -- a tampered byte, the wrong repository, an unexpected workflow -- it exits non-zero and the archive should not be trusted.

The real v1.17.0 verification confirmed the following (abbreviated and illustrative -- not gh's exact console layout):

Verification succeeded!
  predicate type   https://slsa.dev/provenance/v1
  OIDC issuer      https://token.actions.githubusercontent.com
  build / signer   .github/workflows/powershell-lsp-release.yml@refs/heads/main
  subject digest   sha256:bfb2ba3f0c165f6c538682dc605e3ae5433f88a7eeef7950957805b4ee23c339

A successful check proves the archive was built by this repository's release workflow (workflow identity), is byte-identical to what was signed (the digest match), and carries SLSA v1.0 build provenance -- with no maintainer-held key anywhere in the trust path.

This is build provenance and integrity over the downloadable source archive: it proves the published powershell-lsp-<version>.tar.gz came untampered from this repository's pipeline. It is deliberately not Windows Authenticode and does not assert a Windows verified-publisher identity -- there is no SmartScreen reputation and no signed-script guarantee, because the plugin is distributed by git clone, not as a signed Windows binary. The integrity of the normal /plugin install path therefore rests on the git commit and tag themselves, not on the archive attestation.

This boundary is intentional and matches the maintainer-facing release process. See docs/RELEASING.md for what the provenance covers, and TRUST.md for the SBOM, the pinned dependency hashes, and the current (pending -- not signed) code-signing status.