Table of Contents generated with DocToc
<Project Name> — Security Model referenceThis file is the project-specific reference to the project's Security Model, which the canned responses and validity assessments cite as the authoritative answer to “is this a vulnerability in <Project>?”.
Project-agnostic drafting rules (tone, brevity, threading) live in the repo-level ../../AGENTS.md. The content the responses link to is what lives here.
TODO: the URL to the project's public Security Model. Canned responses must link directly to the relevant chapter instead of paraphrasing it; paraphrases drift over time and create a second source of truth that has to be maintained.
Example shape:
The [
<Project>Security Model](TODO: URL) is the authoritative source for what is and is not considered a security vulnerability in<Project>.
TODO: list anchor fragments that canned responses commonly link to. One anchor per bullet, slug-form.
Example shape:
#capabilities-of-X#Y-executing-arbitrary-codeWhen adding a new canned response, identify the matching chapter in the Security Model first. If no chapter covers the case, that is a signal the Security Model should be updated upstream (in the project's source repository) rather than duplicated in canned-responses.md.
TODO: the project's public-facing SECURITY.md or equivalent URL (what reporters are expected to follow).
TODO: for ASF projects, the ASF Severity Rating blog post is the rubric. For other projects, point at whatever rubric the team uses when scoring severity. Reporter-supplied CVSS scores are informational only — the ASF-level rule that governs this is in the repo-level ../../AGENTS.md (it is not project-specific).