Please do not open a public issue for a suspected vulnerability. Use GitHub's private security advisory flow for this repository and include:

• the affected packageproof version and Node.js version;
• a minimal manifest or command that reproduces the issue;
• expected and observed behavior;
• potential impact; and
• whether registry access is required to reproduce it.

Remove credentials and proprietary dependency names unless they are essential to the report. When a public repository is created, maintainers must enable private vulnerability reporting before release. If private reporting is unavailable, ask the maintainer for a private contact without posting vulnerability details publicly. There is no guaranteed response or remediation deadline.

Security fixes are made for the latest released version. Older releases may not receive patches. Until a first stable release, minor versions can include security-relevant behavior changes.

packageproof reads manifests and, unless --offline is set or a dependency is allowlisted, sends package names in read-only HTTPS GET requests to fixed public registry hosts. It does not accept arbitrary registry endpoints, install packages, import project code, or execute lifecycle scripts.

Manifest contents, paths, package names, configuration, registry responses, and environment-provided terminal metadata are treated as untrusted. Output is escaped for its destination, including GitHub workflow commands.

The tool is a preinstall heuristic, not a malware detector. Findings about existence, age, or lifecycle-script metadata are prompts for review. A missing public-registry entry is not proof that a name is a typo or malicious, and says nothing about private registries. Network and registry failures are reported as unknown warnings.

See docs/THREAT-MODEL.md for assumptions, mitigations, and out-of-scope risks.

• Pin a reviewed packageproof version in CI.
• Grant CI only read access to repository contents.
• Do not place secrets in manifests or .packageproof.json.
• Use --offline when package-name disclosure is unacceptable.
• Allowlist private packages so their names are not queried publicly.
• Review allowlist changes as security-sensitive changes.
• Combine results with source review, lockfile review, provenance, integrity verification, advisory scanning, and policy controls.

Do not use packageproof as the sole gate for approving or installing a dependency.