Wasted half a day because Veracode's built-in Jira integration can't filter on severity alone. The workflow rules are too basic. Wrote a Python script that hits their API and creates tickets only for critical flaws.
Requirements:
* Veracode API credentials (ID & Key)
* Jira API token
* Python with `requests`
Script logic:
* Pulls recent scan results for a given app.
* Filters for flaws with severity 5.
* Creates a Jira ticket per flaw with key details (CWE, module, source file).
```python
import requests
import base64
import json
# Config
VERACODE_API_ID = 'your_id'
VERACODE_API_KEY = 'your_key'
JIRA_URL = 'https://your-domain.atlassian.net'
JIRA_API_TOKEN = 'your_token'
JIRA_PROJECT_KEY = 'PROJ'
# ... (authentication and API call logic omitted for brevity)
```
Key points:
* Script runs on a schedule (cron, CI/CD pipeline).
* Adds the Veracode flaw deep link to the Jira description.
* Sets the Jira issue type to 'Bug' and assigns based on your team's mapping.
The built-in integration is fine for a blanket dump, but if you're operating on SLAs for criticals, you need this level of control. Posting in case it saves someone else the time.
-dk
Trust but verify, then don't trust.
Nice. I've been meaning to poke at the Veracode API. How do you handle duplicate tickets if the script runs daily and the same critical flaw is still open? Do you check for an existing Jira issue by a custom field or something?
Glad you shared this approach! While it's great to get that level of control, a word of caution: running a script that creates a ticket per flaw could lead to a noisy backlog if you have many recurring criticals. You might consider grouping flaws by CWE or module into a single parent ticket, or setting up a pre-check to see if a similar issue was created recently.
How are you planning to handle the ticket assignment logic? I've seen teams struggle with that mapping when they rotate on-call or project leads.
— isabel
That's a really good shout about the noisy backlog. I've been burned by that before, where a similar script for our old error monitoring tool basically spammed the dev team into ignoring the whole board. Grouping by CWE is smart. Maybe you could even hash the source file path and line number as a dedupe key?
On assignment, we've had a nightmare with that too! Our current stopgap is mapping the Jira project's default assignee to a shared team email alias, and then relying on a separate Jira automation rule to pick someone from a rotation based on the component field. It's... clunky, and it breaks when the component isn't set. Would love to hear if anyone's cracked that nut without buying another expensive orchestration tool. 😅
Good approach for taking control of the workflow. I've found the same limitation with the native integration's filtering. A few things I added to my similar script:
* It stores the Veracode flaw ID in a Jira custom field to allow for easier deduplication checks on subsequent runs.
* Added a configurable severity threshold instead of hardcoding to 5, so you can adjust the sensitivity per project.
The SLA point is critical. Without this, you're either missing criticals in the noise or manually sifting through reports.
Measure twice, buy once.
Grouping by CWE is the only sane way. I've seen tickets-per-flaw scripts grind a Jira instance to a halt and get the API token revoked for abuse.
The assignment problem is a red herring. You shouldn't assign tickets to individuals from an automated script. Just assign to a team queue or a placeholder. Let your team's own process handle the handoff. Otherwise you're just building a second, worse on-call roster that'll be wrong in three weeks anyway.
-- old school
You're absolutely right about the API abuse risk. I've had to throttle my own scripts after getting rate-limited warnings from our Jira admins.
The team queue assignment is solid advice. We tried mapping to individuals based on a component field and it created more confusion than it solved, because that mapping was always outdated. A placeholder keeps the workflow simple.
That said, grouping by CWE can sometimes hide the urgency of multiple instances of the same vulnerability type across different services. How do you handle prioritizing a CWE that appears in twenty places versus one that appears in two?
Reviews build trust.
Oh wow, this is super helpful to see. I've been frustrated with the same limitation in another tool's integration, so it's cool to see the actual script structure. Saving this for later.
Quick question - how do you manage the API keys safely? I'm always nervous about putting tokens in a script file, even a private one. Do you use environment variables or a secrets manager?
Good luck with your ticket storm.
The built-in integration exists to prevent exactly that kind of self-inflicted noise. You've just replaced one basic filter with another basic filter and called it control. Creating a ticket per flaw at severity 5 is how you get criticals ignored because they're buried in 50 identical tickets.
And assigning based on a "team's mapping" from a script? That mapping is stale the moment you write it.
Trust but verify.