What this template is for
Security findings sit at the intersection of compliance, engineering speed, and customer trust. Get them wrong and you either ship vulnerable software or grind product work to a halt every time a scanner flags a low-severity issue.
This template encodes a defensible security workflow into Jira:
- Restricted-by-default fields on the create screen - CVSS, exploitability, deadline, customer-notification flag. The restricted-issue setting at create time keeps the ticket visible only to the security team and the named engineering owners.
- STM-created close-out sub-tasks - triage, compensating controls, fix, verification, regression test, customer notification, disclosure. Each step has an owner the moment the finding is filed.
When to use it
Use this template for any vulnerability reported through any channel: internal pentests, SAST/DAST tooling, bug bounty submissions, customer reports, or coordinated disclosure. Even findings that turn out to be false positives should be filed - the triage sub-task documents the not-a-vulnerability decision.
Don’t use this template for general security hardening work that didn’t come from a discovered finding. Use a regular story or task instead.
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 | SQL injection in /api/v1/search endpoint | Yes |
Vulnerability Type (custom) | OWASP A03:2021 - Injection | Yes |
CVSS Score (custom) | 8.6 (High) | Yes |
CVSS Vector (custom) | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | No |
Exploitability (custom) | Proof of concept / In the wild / Theoretical | Yes |
Affected Component | search-service, all versions before 4.13 | Yes |
Discovered By (custom) | Internal pentest / SAST / DAST / Bug bounty / Customer report | Yes |
Remediation Deadline (custom) | 2026-06-12 - per security SLA | Yes |
Compensating Controls (custom) | WAF rule deployed as interim mitigation | No |
Customer Notification Required (custom) | Yes / No / Pending legal review | Yes |
CVE (if assigned) | CVE-2026-12345 | No |
Restricted Issue | Yes - access limited to security group | Yes |
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.
- Triage - validate CVSS, deduplicate, assign engineering owner
- Determine if compensating controls are needed in the meantime
- Engineering fix - implemented and code-reviewed
- Security verification - confirm the fix actually closes the vulnerability
- Regression test - add a test case that fails on the unfixed code
- Customer notification - if required, draft and send per legal review
- Public disclosure - if applicable, post advisory after a fix is widely deployed
Common questions
Should Jira security findings be public or restricted?
Restricted by default. Issue-level security applied at create time so only the security team, the engineering owners, and named executives can see the ticket. Public visibility lets attackers triage which vulnerabilities to exploit before you've patched them.
What SLA should security findings have in Jira?
Tied to CVSS score. Common SLA: Critical (9.0+) - 7 days. High (7.0-8.9) - 30 days. Medium (4.0-6.9) - 90 days. Low (under 4.0) - 180 days or next planned release. The remediation-deadline field on the ticket makes this queryable so the SLA is enforced, not aspirational.
Who triages incoming security findings in Jira?
A named security engineer or AppSec lead, not 'security' as a group. Triage is fast (minutes per finding) but requires judgement: deduplicate against known findings, validate severity, assign an engineering owner, and decide if customer notification is needed. Without a named triager, findings sit in the backlog past their SLA.
How do you automate security-finding sub-tasks in Jira?
Build an STM sub-task template containing the triage / fix / verify / disclose sub-tasks. Wire it to an Executor that fires On Create Issue scoped to the security-finding issue type. Every new finding gets the same checklist - reducing the chance someone forgets the post-fix verification or customer notification step.
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 →