DevSecOps · 3 min read · 659 words

GitLab SAST to Jira: Automate Security Tickets

By Chris Clark · AppSec practitioner & AWS Solutions Architect

Disclosure: Some links in this article are affiliate links. We may earn a commission at no extra cost to you if you purchase through them.

GitLab SAST → Jira: One Click Is Not "Auto Dump Every Finding"

Your scanner found something. Your team lives in Jira. The gap between those two tools is where security work dies: someone copy-pastes a finding into a ticket, loses the file path, or never opens a ticket at all.

GitLab's official bridge is real. It's also narrower than "auto-generate tickets from SAST" sounds. Read the settings before you promise your manager unattended ticket spam.

What actually happens

SAST—static application security testing—means the pipeline looks at your source without running the app. You enable it with the SAST CI template (or the UI on Ultimate), and jobs land under the test stage. Findings show up on the pipeline Security tab. On Ultimate, confirmed issues on the default branch appear in Secure → Vulnerability report. Findings on feature branches become vulnerabilities when they merge to default.

Jira comes second. Under Settings → Integrations → Jira issues, you turn the integration on, point it at Cloud or Data Center/Server, and check Create Jira issues for vulnerabilities. Set one Jira project key, pick an issue type. That create-for-vulnerabilities path is Ultimate only. The base integration is Free/Premium/Ultimate, but the button you care about is not.

Then the workflow: open the vulnerability → Create Jira issue. If you enabled Customize Jira issues, GitLab sends you to Jira's create form pre-filled so you can edit before save. Otherwise it creates the issue with info from the report.

That's the product. One vulnerability, one deliberate create. Not "every SAST job opens fifty Jira tickets while you sleep."

What this is not

It's not a Free-tier feature. If you only have Free SAST JSON artifacts, you can download reports, but you don't get Vulnerability Management or that Create Jira issue button.

It's not a license to skip triage. SAST is noisy. Opening a Jira ticket for every raw finding trains your team to ignore both tools. Triage first. Then create the ticket for what you'll actually fix.

It's not immune to your Jira field scheme. GitLab's troubleshooting guide says create can fail with "field is required" when Jira demands a field GitLab doesn't send. Their workaround: a dedicated Vulnerability issue type with a field scheme that doesn't require the missing field.

You can also link existing Jira issues by putting /-/security/vulnerabilities/ in the Jira description. Useful when the ticket already exists and you only need the join.

What to actually do

  • Confirm you're on Ultimate if you need Vulnerability Management and Create Jira issue.
  • Turn on SAST (include: template: Jobs/SAST.gitlab-ci.yml or the Security configuration UI).
  • Configure Jira issues integration with a user/token that can create issues in the target project. Test settings.
  • Enable Create Jira issues for vulnerabilities, one project key, issue type. Turn on Customize if humans should edit the ticket before it lands.
  • After a default-branch scan, open Secure → Vulnerability report, pick a real finding, create the Jira issue, confirm the link back.
  • Fix your Jira required-field scheme before you roll this to every squad.

    • If someone asks for "fully automatic tickets on every finding," say what the docs say: GitLab gives you a sourced create from the report. Anything beyond that is custom automation you own, not a checkbox you invent.

    Chris's take

    I think custom automation you own is ideal, but if the COTS tool works for you and your team, that's great. I built a Jira ticket job that runs after SAST: it creates tickets from the findings if one doesn't exist, and closes them when the vulnerability no longer exists. We're also a large enterprise app with a pile of custom fields and very specific rules for how security items get created and tracked. I use labels and issue types to drive dashboards for those tickets. It works great for us. It may not be for everyone, though.

    Sources:

    Tags: gitlab · sast · jira · security · automation