TODO:

Every tracker gets exactly one scope label at Step 5 of the handling process (valid/invalid consensus landed). The scope:

• pins the tracker to one product the CVE will be allocated against;
• drives the release train the fix backports to (see release-trains.md);
• determines the milestone format (see milestones.md);
• maps to the product / packageName of the CVE record (see the table below).

TODO: list the project's scope labels, one row per label. If a report affects more than one scope, the security-issue-sync skill surfaces this as a blocker and the triager splits the report into per-scope trackers.

Scope to CVE product / package-name table

Tracker scope label	CVE product	CVE container packageName	Collection URL
TODO: e.g. foo	TODO: e.g. Apache Foo	TODO: e.g. apache-foo	TODO: e.g. https://pypi.python.org

Default packageName and vendor

• vendor: TODO — usually from the project.md → Identity block.
• Default packageName for untagged / uncertain reports: TODO.

These defaults are declared in project.md under Identity and CVE tooling; the CVE-JSON generator reads them from there.

Closing dispositions (not scope labels)

invalid, not CVE worthy, duplicate, and wontfix are closing dispositions, not scope labels. They are set at Step 5 or Step 6 of the process when the tracker leaves the flow without a CVE. They do not imply a product and never end up in the CVE-tool product field. These are part of the generic lifecycle — see ../../tools/github/labels.md.