What this template is for
Modern services declare hundreds of transitive dependencies and SCA scanners produce a steady drip of CVE alerts. Most are noise; a few are not; the cost of treating every alert as critical is the same as the cost of treating none of them as critical - either way the real issues drown.
This template imposes the same triage contract on every CVE ticket: confirm the version, assess reachability, set an SLA, decide a disposition. It also captures the disposition - patch, mitigate, or accept-risk - so audit can see what was decided and why.
When to use it
Use this template for every CVE that lands in your scanner queue at Medium severity or higher, or any severity if the package is on a critical path (auth, payments, crypto). For Low-severity findings on non-critical packages, batch them into a weekly grooming ticket rather than opening one per CVE.
Sub-task breakdown
The sub-tasks above are the contract. Reachability assessment in particular is the step that distinguishes mature programmes from immature ones - it converts a flood of alerts into a prioritised queue. STM Issue Templates auto-creates the sub-tasks on every new vulnerability ticket, so the triage process is consistent whether the scanner files 3 tickets this week or 300.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | CVE-2026-12345 in log4j 2.17.0 - reachable in payments-svc | Yes |
CVE ID (custom) | CVE-2026-12345 | Yes |
CVSS Score (custom) | 9.8 / Critical | Yes |
Affected Package (custom) | org.apache.logging.log4j:log4j-core | Yes |
Affected Version (custom) | 2.17.0 | Yes |
Fixed Version (custom) | 2.17.2 | Yes |
Source Scanner (custom) | Dependabot / Snyk / Trivy / Grype | Yes |
Affected Services (custom) | payments-svc, audit-worker | Yes |
Reachability (custom) | Reachable via /api/payments handler | Yes |
SLA (custom) | 7 days (Critical / reachable) | Yes |
Disposition (custom) | Patch / Mitigate / Accept Risk | No |
Linked Patch PR | https://github.com/org/repo/pull/1450 | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Confirm the CVE applies to the version actually deployed (not just declared)
- Assess reachability - is the vulnerable code path used in our service?
- Determine SLA from CVSS + reachability matrix
- Open patch PR or document mitigation if a patch is not yet available
- Verify fix in a non-prod environment with the SCA scanner
- Deploy and confirm scanner shows clean
- Close ticket with disposition and any exceptions logged
Common questions
How do you triage a CVE alert in Jira?
Three questions in order: does the CVE apply to the version we actually deploy, is the vulnerable code path reachable from our service, and what is our SLA given CVSS and reachability. A critical CVSS in an unreachable transitive dependency is a lower priority than a medium CVSS in a hot code path. Capture all three answers on the ticket.
What is reachability in dependency vulnerability triage?
Reachability means: does our code actually call the vulnerable function. A library can be a declared dependency but never invoked, or invoked only in dead code paths. Modern SCA tools (Snyk Reachability, Endor, Socket) estimate reachability automatically; for tools that don't, the assessment is a manual code review captured on the triage ticket.
Should you accept the risk of an unpatched CVE?
Sometimes - when the CVE is unreachable, the CVSS is low, or no fixed version exists yet. Accept-risk is a legitimate disposition but it must be explicit, time-bound (revisit in 30/60/90 days), and signed off by the right approver. Use the Disposition field and link to a compliance-exception ticket for anything beyond a quick revisit.
Can you auto-create dependency vulnerability triage tickets from a scanner?
Most SCA tools have a Jira webhook that opens a ticket per finding. [STM Issue Templates](/stm/) complements that by auto-creating the standard triage sub-task checklist (confirm version, assess reachability, set SLA, patch, verify, close) on every new vulnerability ticket via an On Create Issue Executor.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →