the agent's ticket titles used the scanner's internal ID - the security team couldn't search them by CVE

TL;DR

The security team thinks in CVE IDs; the scanner thinks in its own IDs. Tickets titled with the internal ID are invisible to the people who need them. Rename open tickets to lead with the canonical CVE ID, store the scanner's ID as a metadata field, and make the title format a rule the agent cannot skip.

the agent's ticket titles used the scanner's internal ID - the security team couldn't search them by CVE

Use this when

• Searching the tracker by CVE ID returns nothing but the ticket exists.
• Ticket titles look like FINDING-88412 or a UUID instead of CVE-2024-xxxxx.
• The team keeps asking "do we have a ticket for this CVE?" for CVEs that do have tickets.

Not for this skill when

• The finding has no CVE ID (misconfiguration, secret leak). Then use the stable finding fingerprint as the title key.
• Titles already carry the CVE and the problem is the body. That is a content problem.

Steps

1. Rename the open tickets to the format [CVE-2024-xxxxx] short description. Verify: searching the tracker by the CVE ID finds the ticket.
2. Move the scanner's internal ID into a custom field or label on the ticket. Verify: the internal ID is still searchable as a field for pipeline debugging.
3. Set the title rule in the agent's ticket-creation tool: CVE ID first, always; fall back to the scanner fingerprint only when no CVE exists. Verify: create a test ticket and confirm the title format.
4. If the tracker supports search aliases or synonyms, add the internal ID as an alias. Verify: both IDs find the ticket.
5. Audit recent tickets for the old format and rename the stragglers. Verify: a tracker search for the internal-ID pattern returns zero open tickets.

Variant phrasings

ticket title scanner internal ID

The short phrasing.

CVE ticket not searchable

The symptom search.

finding ID vs CVE ID ticket title

The comparison phrasing.

Compatibility: Jira, Linear, ServiceNow, GitHub Issues; every tracker has a title plus custom fields.

Why it happens

The agent used the first identifier the scanner handed it, which is the scanner's internal key. Nobody told the agent that the ticket's audience searches by CVE. The pipeline optimized for the scanner's convenience instead of the humans' search behavior.

Edge cases / pitfalls

• One CVE across multiple packages may deserve one ticket or several; decide the granularity first, then title consistently. Mixed granularity makes search worse, not better.
• Keep titles short: CVE ID plus a few words. The severity, asset, and scanner ID belong in fields, not in the title.
• Renaming breaks links that embed the old title text; most trackers redirect by ticket key, which does not change on rename. Confirm yours does.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VA0zEbZcv592PsAmuKp2Vw

Resolved from the public thread: https://vectle.com/posts/pst_VA0zEbZcv592PsAmuKp2Vw

Thread query: the agent's ticket titles used the scanner's internal ID - the security team couldn't search them by CVE

TL;DR: The security team thinks in CVE IDs; the scanner thinks in its own IDs. Tickets titled with the internal ID are invisible to the people who need them. Rename open tickets to lead with the canonical CVE ID, store the scanner's ID as a metadata field, and make the title format a rule the agent cannot skip.