This document explains how to report a vulnerability in TOOLSTORE. It is a reporting policy only. It does not describe the security architecture or the threat model — those will live in docs/SECURITY_DESIGN.md and docs/THREAT_MODEL.md, which are planned for a later Phase 0 step and do not exist yet.

TOOLSTORE is in pre-release development. There is no released version, no published binary, and no distribution channel in operation at this time.

No release has been published, so there is no supported release line. When 1.0 is released this table will be replaced with a concrete support window stating how long earlier versions continue to receive fixes.

Please do not open a public issue containing vulnerability details.

GitHub Private Vulnerability Reporting is the project's primary official channel for confidential security reports, and it is enabled on this repository:

1. Go to https://github.com/emilioperna/TOOLSTORE/security/advisories
2. Select Report a vulnerability
3. Complete the advisory form

The report and its discussion remain visible only to the reporter and authorized advisory participants while the advisory is private. The project intends to coordinate public disclosure with a fix whenever reasonably possible.

You do not need any contact address for the maintainers to use this channel.

If the Report a vulnerability option is not available to you, open a public issue that asks a maintainer to establish a private channel.

That issue must contain only the request for private contact. It must not contain:

• a description of the vulnerability or the affected component;
• reproduction steps;
• proof-of-concept or exploit code;
• logs, stack traces, screenshots, or any other output.

A maintainer will respond and arrange a private channel, and you can send the details there.

Once you are on a private channel, a useful report usually contains:

• the affected component and the version, branch or commit;
• your operating system and architecture;
• what an attacker achieves, and what access or preconditions they need;
• reproduction steps, ideally minimal;
• any proof-of-concept, log excerpt, or crash output.

Please redact personal file paths and private data from logs before attaching them.

TOOLSTORE is maintained by a single maintainer. The following are intentions, not contractual guarantees:

• acknowledgement of your report, normally within a few days;
• an assessment of validity and severity after triage;
• progress updates while a fix is prepared;
• credit in the advisory and release notes, unless you prefer to remain anonymous.

If a report is declined, you will be told why.

Please give the project a reasonable opportunity to release a fix before disclosing publicly. Ninety days from acknowledgement is a sensible default — shorter if a fix ships earlier, longer by mutual agreement for issues that are difficult to remediate.

If a vulnerability is already being exploited, say so in the report. That changes both the priority and the timeline.

In scope: this repository, and any TOOLSTORE component or first-party application published by the ToolStore Project.

The following are normally handled as ordinary issues rather than as security advisories:

• issues in third-party dependencies that do not affect TOOLSTORE as configured — report those upstream, though we appreciate being told;
• vulnerabilities in an application distributed through TOOLSTORE but maintained elsewhere — report those to that application's maintainers;
• issues that require an attacker to already have full control of the same security boundary and that provide no additional confidentiality, integrity, persistence, privilege or trust impact;
• missing hardening with no demonstrable security consequence.

These are classification guidelines, not filters.

If you are unsure whether something qualifies, report it. Elevated privileges being one precondition does not by itself make a finding a non-issue: a crossing of a security boundary is a vulnerability even when the attacker already holds significant access. Misclassifying a real boundary failure is a worse outcome than triaging a report that turns out to be hardening.

If you make a good-faith effort to comply with this policy while researching a vulnerability, the project will not pursue or support action against you. Please act only against your own installations and data, avoid privacy violations, service disruption and data destruction, and stop as soon as you have enough to write a report.