SARIF and JUnit XML: Running Vexta Findings Inside CI/CD

SARIF security scanning in a CI/CD pipeline means a scanner's findings show up as annotations inside the tools a development team already uses, instead of a separate report nobody opens. Vexta, VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, exports results as SARIF 2.1.0 for GitHub Code Scanning and GitLab security dashboards, and as JUnit XML for Jenkins, CircleCI and TeamCity, so a finding from a Vexta scan lands in the same place a failed unit test would.

What is SARIF, and what does Vexta put in it?

SARIF, the Static Analysis Results Interchange Format, is a JSON schema that lets any scanning tool describe its findings in a structure that code hosting platforms already know how to render as inline annotations. Vexta produces SARIF 2.1.0 output with one Run per scan and one Result per finding, so a CI pipeline that ingests the file gets the whole scan as a single, structured unit rather than a pile of loose text.

Each result carries a severity mapping: critical and high severity findings come through as SARIF errors, medium severity as warnings, and low or informational findings as notes. Alongside that, each result carries CWE references, CVSS scores, and Vexta's proof status, so a reviewer looking at an annotation in GitHub or GitLab can see not just that something was flagged, but how confident the scanner is that it is real.

This is the same finding data that drives Vexta's Confidence Score elsewhere in the platform, so a critical SARIF result is not just a raw severity label. It reflects the same combination of severity, detector confidence, proof status, reachability, and known-exploited signals that the scanner uses everywhere else, carried through into the format your pipeline reads.

Where SARIF output actually shows up

GitHub Code Scanning and GitLab's security dashboards both consume SARIF natively. Upload the file as part of a pipeline step and findings appear as annotations directly on the relevant code or as entries in the security dashboard, the same place static analysis and dependency scanning results already live for a team using either platform.

That placement is the actual value. A finding a developer has to seek out in a separate report is a finding that competes for attention with everything else on their plate. A finding that shows up next to the pull request they are already reviewing does not need to compete for anything; it is already where they are looking.

It also changes who sees a finding first. Without CI integration, a scan result typically reaches a security-minded reviewer who then has to route it to the developer who owns the code. With SARIF annotations on the pull request itself, the developer sees the finding at the same moment they see the rest of the review feedback, before the code merges rather than after.

JUnit XML for pipelines that speak test results

Not every CI system consumes SARIF as its native format. Jenkins, CircleCI and TeamCity are built around test reporting, so Vexta also exports results as standard JUnit XML, with one test case per finding, tagged with severity and confidence metadata. To the pipeline, a critical finding looks like a failed test case, which means it can drive the same pass/fail gate a pipeline already uses for unit and integration tests, without a team having to bolt on a separate security-specific step to notice it.

Why format choice is a deployment decision, not a scanning one

Neither format changes what Vexta actually finds. Both are exports from the same underlying scan data; the choice between SARIF and JUnit XML is about which system is downstream, not about running the scan differently. A team can generate both from the same scan if part of their pipeline runs on GitHub Actions with Code Scanning and another part reports through a Jenkins job.

That also means a security team does not have to choose a scanner based on which CI system a particular project happens to use. If the pipeline changes from Jenkins to GitLab CI six months from now, the scan configuration does not need to change, only which export format the pipeline step consumes.

There is a practical upside to that independence for a team standardizing tooling across several projects. One project on GitHub Actions and another on a self-hosted Jenkins instance can both run the exact same Vexta scan configuration and still get results in the native format each pipeline expects, without maintaining two different scanning setups to get there.

A practical gate: failing a build on a real finding

Authorized testing is still the baseline for any of this. Wiring Vexta into a CI/CD pipeline against a staging or pre-production environment you own or are contracted to test is a normal engineering workflow; pointing the same pipeline at a target outside your scope or a client's signed engagement is not, regardless of how convenient the automation makes it.

Once results land in a format the pipeline understands, using them as a gate is a normal CI configuration problem, not a Vexta-specific one. A build step can fail if the JUnit XML contains any test case above a chosen severity, or a repository can require the GitHub Code Scanning check to pass before a merge is allowed. The scanner's job stops at producing a structured, accurate result; enforcing a policy on top of it is standard pipeline configuration a team already knows how to do.

Which plans include CI/CD export alongside the rest of Vexta's reporting is worth checking on the pricing page before you wire it into a pipeline that your whole team depends on.

Key takeaways