Xanitizer Integration with DefectDojo

Xanitizer Integration with DefectDojo

Xanitizer is a commercial static application security testing (SAST) tool from RIGS IT GmbH. It analyzes Java and Scala web applications, including presentation frameworks such as JSP and JSF, and scans source code, configuration files, and rendering templates for vulnerability types such as SQL injection, cross-site scripting, and XML external entity issues. Xanitizer can write its results as an XML findings list report, which is the format DefectDojo imports.

Xanitizer Integration with DefectDojo

We use Xanitizer on our Java services because its findings show where tainted data enters the application and where it ends up, which is what a developer needs to fix an injection bug. DefectDojo is where those findings get owners and deadlines. Each Xanitizer finding becomes a Finding on the service's Asset with its CWE, file, line, and the code excerpt from the report, so the engineer assigned to it can start fixing without opening Xanitizer. The next scan's reimport closes what was fixed.

Why Xanitizer Matters

Injection flaws in Java web applications usually come from data crossing several classes before it reaches a dangerous call. Finding them requires following that path.

• For data flow problems, the report gives the starting point and ending point of the flow, with class names, line numbers, and code lines.
• Findings carry CWE numbers, which lets them line up with findings from other SAST tools and with secure coding standards.
• Each finding has a numeric rating that DefectDojo turns into a severity, so prioritization starts from the tool's own judgment.
• Results in a standalone tool are hard to compare release over release, and harder still to report alongside dependency and runtime findings.

Advantages of This Integration

What running Xanitizer through DefectDojo gives us:

• A remediation lifecycle. Reimporting a new findings list into the same Test mitigates findings that disappeared, adds new ones, and reactivates regressions.
• CWE-based reporting. The parser extracts the CWE number, so Xanitizer results can be grouped with other SAST findings by weakness class.
• Code context on the Finding. Start and end locations and code excerpts from the report are written into the description, which is usually enough to locate the bug.
• Consistent severity and SLAs. Ratings map onto DefectDojo's Critical to Info scale, and SLA timers apply as they do for every other tool.
• Assignment and ticketing. Findings can be assigned to the owning team, risk-accepted with an expiry, or pushed to Jira.

How This Integration Works

DefectDojo imports Xanitizer results with the Xanitizer Scan scan type.

1. Produce a findings list report. Generate Xanitizer's XML findings list report for the project. DefectDojo recommends generating it with the parameter generateDetailsInFindingsListReport=true, which adds the node and code details the parser uses for descriptions. The parser checks that the XML root element is a XanitizerFindingsList and rejects other files.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Xanitizer Scan, and upload the XML. For automation, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Xanitizer Scan" \
  -F "file=@xanitizer-findings.xml" \
  -F "product_name=customer-portal" \
  -F "engagement_name=SAST" \
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Xanitizer Scan" \
  --report-path "./xanitizer-findings.xml" \
  --product-name "customer-portal" \
  --engagement-name "SAST" \
  --auto-create-context

3. Reimport after each scan. Send subsequent reports to /api/v2/reimport-scan/ for the same Test to keep one history per application.

Data Granularity: What Gets Imported

Each finding element in the XML becomes one Finding. The parser does not merge repeated entries within a report, and it does not set Mitigation or References, so remediation guidance has to come from the description, from Xanitizer itself, or from notes your team adds during triage.

Use Cases

In a nightly build: A Java monorepo runs Xanitizer nightly and reimports the findings list into a Test per service. Developers start the day with a short list of new findings in DefectDojo instead of a full report.

For release sign-off: Before a major release, the AppSec team filters the Asset for open High and Critical Xanitizer Findings, confirms each is fixed or risk-accepted, and exports a report showing the state at release time.

Alongside other SAST tools: Teams running Xanitizer next to another static analyzer import both into the same Asset and compare them by CWE and file. Where both tools flag the same weakness in the same file, the overlap is easy to spot.

For secure coding training: Grouping Findings by CWE across the organization's Java Assets shows which weakness classes keep recurring, which tells the training program where to focus.

Operational Tips

• Always generate the findings list with details enabled. Without it, descriptions contain only the problem description and the Finding loses the code context.
• The line number is part of the title and of the hash, so a code change that shifts a finding a few lines down can create a new Finding on reimport and mitigate the old one. Review mitigated-and-new pairs after large refactors.
• Severity is derived from Xanitizer's numeric rating. If your Xanitizer configuration adjusts ratings, DefectDojo severities move with it.
• Set minimum_severity=Low on import if Info findings (rating 0 or missing) are not worth tracking.
• Mark confirmed false positives in DefectDojo. Because the title and hash are stable while the code doesn't move, the false positive status holds on reimport.
• If a finding's description mentions a CVE, the parser picks up the first CVE ID it sees as the Finding's vulnerability ID. Check it during triage when a description cites more than one.
• Tag imports with the branch or release (for example tags=release-5.2) so you can report on findings by version.