Unpatched vulnerabilities in issue trackers: exclude or keep?

The short rule: open security issues stay out#

Open security issues stay out of every licensed dataset, with no exceptions for severity or age. A ticket describing an unpatched weakness is a map to an attack on your product and your customers, and once a dataset is delivered you cannot recall copies made by people you have never met.

The same rule covers issues that are fixed in the current release but not in older versions you still support. Customers on those versions remain exposed, and the ticket explains exactly how. Treat an issue as open until the fix ships in every supported version and customers have had a reasonable chance to upgrade.

Everything else in the security category, from patched vulnerabilities to pen test findings, needs review before it can stay. The table in the next section sets a default for each type.

Which tickets count as security issues?#

Security issues include more than tickets labeled as vulnerabilities. Pen test findings, bug bounty reports, incident tickets and dependency upgrades all describe weaknesses, and each needs its own default.

Security reports also arrive outside the tracker. A customer may describe a data exposure in a support ticket, an engineer may discuss a bypass in a Slack thread before filing anything, and a sales engineer may record a prospect's pen test result in the CRM. If those systems are in scope, run the same text patterns on them and trace each hit to its Jira ticket so both records get the same treatment.

Labels and fields to filter on#

Labels and fields give the first cut, but no single filter catches everything, because teams label inconsistently over the years. Combine structured filters with text patterns, and run them in Jira before any export so excluded tickets never leave the system.

Large Jira histories need batching. Atlassian supports the asynchronous CSV export from the issue navigator for up to 10,000 work items and recommends splitting larger exports into JQL batches, for example by date range. Put the security exclusions into every batch's JQL so no batch slips through without them. GitLab's project export carries issues with comments and labels, so confidential issues need the same filtering before an export is shared.

• 1Security level or restricted visibility fields set on the ticket.
• 2Issue types such as vulnerability, security bug or incident.
• 3Labels such as security, vuln, cve, pentest, audit and bounty.
• 4Components covering authentication, authorization, cryptography and session handling.
• 5Linked CVE or CWE fields and references to security advisories.
• 6Reporters or assignees from the security team or a bounty platform integration.
• 7Text patterns such as CVE-, CVSS, XSS, SQL injection, RCE, SSRF, privilege escalation and bypass.

What review does a patched issue need before it stays?#

A patched issue needs a review that keeps the reasoning and removes anything that helps an attacker or names a customer. The diagnosis, the discussion of root cause and the design of the fix are the valuable parts; the reproduction steps and payloads are the dangerous ones.

Pasted logs and configuration snippets are where secrets hide. Open-source scanners such as TruffleHog look for credentials across Git history, chat, wikis and logs, and can be pointed at exported ticket text before release. Its option to test whether a found secret is live sends real authentication requests, so use that feature with care and only against your own systems.

• 1Confirm the fix shipped in every supported version and any advisory has been published.
• 2Remove exploit steps, proof-of-concept code, payloads and attack scripts.
• 3Remove names of affected customers and links to their tenants or environments.
• 4Remove internal hostnames, IP addresses, file paths and infrastructure details.
• 5Scan for keys, tokens and passwords, and rotate anything found even if it looks expired.
• 6Remove names of external researchers unless they were publicly credited.

Illustrative: a vertical SaaS company filters its Jira history#

Illustrative: a fictional vertical SaaS company with many years of Jira and GitHub history plans to license its bug-fix records. The CTO asks the security lead to define the exclusions before engineering builds the export.

The structured filters catch tickets in the security project and those with a security level set. The text patterns then find older tickets from before the security project existed, including a pen test finding filed as an ordinary bug and a support escalation describing a permission bypass. Older supported versions still lack one fix, so every ticket tied to that issue stays out.

Patched tickets that pass review keep their root cause discussion and the linked pull request description, with reproduction steps, customer names and pasted logs removed. A secret scan of the cleaned text finds an old API token in a comment; it is removed and rotated. The security lead signs the exclusion list before export.

Does excluding security work reduce the value of the dataset?#

Excluding open security work reduces value very little, because developers use the reasoning in ordinary fixed bugs far more than the rare vulnerability ticket. In the SourceX Enterprise Data Value Framework, AI utility and human-generated signal raise value, while preparation cost lowers net value; security tickets are expensive to prepare and add little that the much larger body of ordinary fixes does not.

Patched security work that passes review can still add something specific: how a team diagnosed an authorization flaw or redesigned a session model. Keep it when the review is clean, and leave it out when there is any doubt.

How SourceX handles security-sensitive tickets#

SourceX treats security-sensitive tickets as a supplier-defined exclusion in the Preparation step of the SourceX five-step transaction. The supplier's security lead sets the rules and approves the exclusion list in the Approval step, and the release authorization in the SourceX Evidence Packet records who signed it and which filters were used.