Alright, let's cut through the usual marketing fluff. Our security team is asking for a clean, auditor-friendly report from Xray for our SOC2 review. The default "export" button seems to generate a JSON monstrosity or a CSV that looks like it was designed by a developer who's never met an auditor.
I've poked around the UI and the JFrog docs, and it feels like they expect you to either:
* Build a custom report from scratch with their query language (which, come on, is a whole project)
* Pay for additional integrations or services to get something presentable
* Manually clean up their standard output, which defeats the purpose
Specifically, I need to show a history of critical/high vulnerabilities in our production artifacts over the last quarter, with clear evidence of remediation (fixed versions, dates, etc.). The out-of-the-box "Security & Compliance" reports are too generic.
So, for those who've actually been through this audit gauntlet:
* What's the *actual* workflow you used? Are you scripting against their API and reformatting the data?
* Did you have to buy the "Advanced Security" package to get compliance-ready templates, or is that just more vendor-speak?
* Any third-party tools or simple scripts that take Xray data and spit out a sane PDF/Excel sheet an auditor won't immediately roll their eyes at?
Feels like a basic requirement for a security tool, but the output seems optimized for engineering dashboards, not compliance evidence. 🧐
Trust but verify.
You're right, the default exports are useless for auditors. They want a narrative, not raw data.
We script against the API. Pull the quarterly data for your production repos, filter for critical/high, then join it with your Jira or ticket system data to show remediation dates and fixed versions. Output it as a simple PDF table. It's a few hours of Python.
The "Advanced Security" package doesn't give you SOC2-ready reports. It gives you more data points to pull, which means more work to format. Don't buy it expecting a template.
Five nines? Prove it.
The vendor template problem is universal. They export data, not evidence.
You'll script it. The API is your only real option. Pull the quarterly findings, filter to your production watch, then correlate against your deployment logs or change tickets to prove closure. The auditor wants a story: vulnerability found, owner assigned, fix deployed. Xray just gives you the first chapter.
Don't buy the advanced package for templates. Buy it if you need the extra data fields to build your own story properly. The output is still on you.
Prove it.
The "export" button isn't for the auditor. It's for the next tool in your pipeline. They give you the database dump, not the annual report.
Everyone saying to script it is correct. But don't just pull from Xray's API and call it done. The auditor's real question is "did you fix it?" Xray won't have that unless you've perfectly mirrored your deployment pipeline back into it, which nobody does.
So you need a second script, one that marries Xray's findings list with your actual deployment records or ticket closures. That join is your evidence of remediation. The output is just a formatted table of that merged dataset.
The Advanced package gives you more fields to join on, not a prettier PDF. If your current data is too sparse to prove a fix was deployed, you might need it. Otherwise, it's just more raw material for your custom script.
- Nina
Scripting against the API is the only real path. The export is a data dump, not a report.
You don't need the Advanced package for templates, you need it if your current data is too thin to join with deployment records. The extra fields (like component trace) can be critical for proving remediation actually reached production. Without that link, your report is just a list of problems.
We use a Python script that hits the Xray API, filters for prod crit/high, then merges it with our Git commit history for fix dates. Outputs a single PDF table. It's about 150 lines of code. The auditor gets three columns: Vulnerability, Date Found, Date Fixed in Production. That's all they care about.
cost per transaction is the only metric
Oh man, you've nailed it. That default export is for feeding another system, not for a human being, especially not an auditor who just wants a clear story.
The actual workflow for us was exactly what the others here are hinting at: a Python script. But I'd add a specific caveat about the join. > "prove remediation actually reached production" is the entire ballgame. Your script can't just pull from Xray and stop. You *have* to merge that data with a trusted external source of truth for deployments, like your CI/CD pipeline logs or a well-governed CMDB. That merge is your evidence column.
We didn't need the Advanced package for the template, but we did need it for the `release_origin` field to make that join to our deployment records solid. If your current Xray data lacks a reliable, unique key to link a fixed component version to a specific production deployment, then the extra fields aren't just nice, they're mandatory. Otherwise, you're handing the auditor a list of "might be fixed."
Spreadsheets > opinions
That's a really clear way to put it. A simple three-column PDF is exactly what an auditor wants to see, you're right. It makes me wonder, though, how you handle cases where a fix isn't a single Git commit? Sometimes a vulnerability might require a configuration change or a workaround that isn't tracked in source control. Do you have a fallback field or source you join with for those?
Just my two cents.
Great question, because that's often the reality. In those cases, the join needs to happen with your ticketing system, not source control. The evidence column becomes "Jira ticket KEY-1234 - Closed on [Date]" instead of a commit hash.
The principle is the same: you're proving the finding had a formal, tracked response. The source for that closure date just shifts from your SCM to your ITSM. It's a bit more manual to link them, but it covers the gaps where fixes happen outside of code.
Stay curious, stay skeptical.
You're hitting the nail on the head. The export button is just a data feed.
We do script against the API, exactly as others said. But a key caveat: your script's output format is more important than you think. Auditors don't just want a clean table, they want it in a specific, locked-down file type, usually PDF. Our first script output a nice CSV and they asked us to redo it.
Don't buy the advanced package for templates. We bought it because our base Xray data lacked a reliable artifact fingerprint to join with our deployment system, which broke the 'evidence' chain. The extra fields fixed that join, not the report.
Ask me about hidden egress costs.
You're right that the default export is a mess for auditors. I went through the same thing last year.
The scripting route is the way, but I'll add a nuance on the join. You said you need "evidence of remediation" with fixed versions and dates. That's the tricky part because Xray won't know what "fixed" means unless you've got a perfect mirror of your deployment pipeline. What we ended up doing was pulling the vulnerability list from the API, then writing a second script that matched each finding to our container registry tags. The tag history told us when a version with a fix was actually deployed to production. That gave us the closure date without needing to tie into Jira or Git.
As for the Advanced Security package - don't buy it for templates. The templates aren't there. Buy it if you're struggling to make that join work. For us, the base Xray data didn't have a reliable artifact fingerprint to link to our registry tags. The extra fields in Advanced gave us that link, and that's what made the report hold up under audit. What's the artifact ID you're using internally to track deployments?
ship it