Last updated: 13 June 2026
Forge is a trust registry — its security posture is the product. This page explains how to report a vulnerability, what we commit to in return, and what Forge's trust signals do and do not mean.
Reporting a vulnerability
Email security@forgeregistry.com. Please include reproduction steps, the affected component (registry API, CLI, MCP server, or website), and an impact assessment if you have one. Please don't open a public issue for a security report.
| Our commitment | Target |
|---|---|
| Acknowledgement | within 48 hours |
| Triage & severity assessment | within 5 business days |
| Fix or mitigation (critical / high) | within 30 days |
| Fix (medium / low) | within 90 days |
| Coordinated disclosure | after a fix ships, or 90 days — whichever comes first |
Safe harbour for researchers
Good-faith security research is welcome. We will not pursue or support legal action against you for research that respects the following: don't degrade or disrupt the production service, don't access or modify data that isn't yours, don't exfiltrate personal data, and give us a reasonable chance to fix an issue before disclosing it publicly. Test against your own installations wherever possible.
In scope
- Registry API — authentication bypass, claim/publish forgery, revocation bypass, data tampering.
- CLI (
@forge-registry/cli) — signature-verification bypass, command injection, key handling. - MCP server (
forge mcp) — tool-level injection, unauthorised file writes, privilege escalation. - Trust pipeline — anything that lets an unverified party obtain a verified badge, forge a trust score, or poison scan results.
- Website — XSS, CSRF on the claim/publish flows.
Out of scope: vulnerabilities in the third-party packages Forge indexes. Report those to the package's author — and to us at security@forgeregistry.com so we can flag or revoke the listing (see When a package goes bad below).
What "verified" means — and doesn't
This matters as much as any single control, so we state it plainly:
- "Verified" is an identity claim, not a safety claim. It means the publisher demonstrated control of the linked source repository — not that their code is safe, correct, or free of malicious behaviour.
- A clean scan means "no known issues found", not "no issues exist". Our checks cover known CVEs (including the dependency tree), suspicious install scripts, code-obfuscation markers, prompt-injection patterns, the declared tool surface, and cryptographically verified build provenance. Pattern-based analysis catches known and low-effort attacks; it cannot prove the absence of novel or carefully hidden malicious code.
- A verified publisher can ship a malicious update later. Scans are point-in-time and re-run on a schedule, not on every release.
You remain responsible for deciding whether to trust and run any package. Forge narrows risk and creates accountability; it does not certify safety.
How we protect the registry
- Package signing. Publishing signs a canonical record with Sigstore keyless signing where available, binding the signature to a GitHub identity and recording it in the Rekor public transparency log. Signatures are cryptographically verified — including that the signing identity matches the declared repository — before a listing is trusted.
- Signed API responses. Trust-bearing registry responses are signed; the CLI verifies them and refuses tampered data, so a spoofed or modified response is detectable.
- Revocation. Verification can be withdrawn at any time; the CLI and AI tools then report the package as revoked and cap its trust score.
When a package goes bad
If a listed package is found to be malicious or compromised, we:
- Revoke its verification — clients immediately report it as revoked;
- Log the action and reason in our append-only audit trail;
- Surface the reason publicly on the listing and in the API, so downstream tooling can alert users;
- Publish a postmortem for any incident caused by a failure in Forge's own process.
What Forge does not protect against
In the interest of honesty: Forge does not execute or continuously monitor the runtime behaviour of indexed packages, cannot detect novel malware that evades pattern analysis, and cannot guarantee a package is safe. These limits are inherent to supply-chain tooling, not unique to Forge. We are transparent about them on purpose — a tool that claimed otherwise would be the one not to trust.
Contact
Security reports: security@forgeregistry.com.