Home Technical Support Troubleshooting DefectDojo Upload Errors (400 Bad Request, 500 Internal Server Error, and TruffleHog Imports)

Troubleshooting DefectDojo Upload Errors (400 Bad Request, 500 Internal Server Error, and TruffleHog Imports)

Last updated on Jan 06, 2026

Troubleshooting DefectDojo Upload Errors (400 Bad Request, 500 Internal Server Error, and TruffleHog Imports)

DefectDojo is a powerful open‑source platform for managing application security findings, but uploading scan results can sometimes trigger error messages that interrupt your workflow. This guide explains the most common upload failures—400 Bad Request, 500 Internal Server Error, and missing content when importing TruffleHog reports—why they happen, and step‑by‑step solutions to get your data into DefectDojo quickly and reliably.

Table of Contents

  1. Understanding the 400 Bad Request error

  2. Resolving the 500 Internal Server Error

  3. Why a TruffleHog upload shows only the file name

  4. General troubleshooting checklist

  5. Tips & Frequently Asked Questions

1. 400 Bad Request – What It Is and How to Fix It

A 400 Bad Request response tells you that DefectDojo rejected the request because the client (you) supplied invalid data. In the context of uploads, the most common causes are:

Cause Description Example
Incorrect scanner name Scanner identifiers are case‑sensitive and must match the exact name stored in DefectDojo. Using --scanner "zap scan" instead of "ZAP Scan"
Missing or wrong argument A required CLI argument is omitted or contains a typo. --scanner "SSLyze 3 Scan (JSON)" – the scanner does not exist in DefectDojo.
Non‑existent engagement ID The --engagement_id you reference does not correspond to any engagement in the system. --engagement_id 3 when there is no engagement with ID 3.

How to Resolve a 400 Error

  1. Verify the scanner name

    • Open DefectDojo → Configuration → Scanners.

    • Copy the scanner name exactly (including spaces and capitalization).

    • Use that string in your upload command.

  2. Check required arguments

    • Run the upload script with the --help flag to see all mandatory parameters.

    • Ensure each argument is present and correctly spelled.

  3. Confirm the engagement ID

    • Navigate to Engagements in the UI.

    • Locate the numeric ID (displayed in the URL, e.g., …/engagement/42/).

    • Use that ID in the --engagement_id flag.

  4. Re‑run the command after correcting the values.

    • If the error persists, capture the full CLI output with --debug and compare it to the API payload shown in the DefectDojo logs (Admin → System Settings → Logging).

2. 500 Internal Server Error – What It Is and How to Fix It

A 500 Internal Server Error indicates that DefectDojo received the request but failed while processing it. The most frequent trigger for upload‑related 500 errors is malformed or empty scan output files.

Typical Scenarios

Situation Why It Causes 500 Remedy
Empty XML/JSON file (e.g., an empty zap-output.xml) The parser expects at least one finding; an empty document raises an exception. Regenerate the scan, ensuring that the tool actually discovers findings, or manually add a dummy entry for testing.
Incorrect file format (e.g., uploading a plain‑text log to a parser that expects JSON) The parser cannot deserialize the content. Use the exact output format documented for the tool (see DefectDojo’s parser list).
Corrupted file (truncated or non‑UTF‑8 encoding) Parsing fails with a Unicode or XML error. Re‑download the report, verify file integrity, and confirm UTF‑8 encoding (file -i report.xml).

Step‑by‑Step Fix

  1. Open the report locally and confirm it contains data.

    cat zap-output.xml | head

  2. Validate the file against its schema (if available).

    • For XML: xmllint --noout --schema zap_schema.xsd zap-output.xml

    • For JSON: python -m json.tool report.json

  3. If the file is empty or malformed, re‑run the original scanner with appropriate options (e.g., -o zap-output.xml).

3. TruffleHog Upload Shows Only the File Name

When importing a TruffleHog scan via CI/CD, you may see the file name appear in DefectDojo but no findings. This usually stems from using the wrong output format or from a parsing mismatch.

Correct TruffleHog Output for DefectDojo

DefectDojo expects JSON formatted results that match the parser documented here:
https://defectdojo.github.io/django-DefectDojo/integrations/parsers/#trufflehog

The CLI flag to produce JSON is:

trufflehog git . --json > trufflehog-report.json

Troubleshooting Steps

  1. Download the generated report from the CI job artifact.

  2. Open the file and verify it contains an array of JSON objects, each with path, commit, rule, reason, etc.

  3. Test the import via the GUI:

    • In DefectDojo, go to Findings → Import Scan.

    • Choose TruffleHog as the scanner, upload the JSON file, and click Import.

    • If findings appear, the file format is correct; the issue lies in the CI upload script.

  4. If the GUI import also shows only the file name, the report is likely not JSON (e.g., plain‑text). Regenerate using the --json flag.

  5. Update your CI/CD step to reference the correct file path and format. Example for GitLab CI:

    trufflehog_scan:
  stage: test
  script:
    - trufflehog git . --json > trufflehog-report.json
    - |
      curl -X POST "$DEFECTDOJO_URL/api/v2/import-scan/" \
        -H "Authorization: Token $DD_API_TOKEN" \
        -F "file=@trufflehog-report.json" \
        -F "scan_type=TruffleHog Scan" \
        -F "engagement=42"

  6. Run the pipeline again and verify that findings appear under the selected engagement.

4. General Troubleshooting Checklist

✅ Checklist Item Why It Matters
Use --debug / -v flags on upload scripts Shows the exact payload sent to the API, making it easier to spot missing fields.
Confirm API endpoint (/api/v2/import-scan/) A wrong endpoint returns 404 or 500.
Validate authentication token Expired or missing tokens cause 401/403, which can masquerade as 400 errors.
Check DefectDojo version compatibility Parsers evolve; an older Dojo instance may not support newer scanner output.
Review server logs (docker logs dojo_web or /var/log/uwsgi/app.log) Provides stack traces that pinpoint the exact parser failure.
Restart the Dojo service after configuration changes Some settings (e.g., new scanners) require a reload to take effect.

5. Tips & Frequently Asked Questions

Tips for Smooth Imports

  • Keep scanner names consistent: Store them in a small reference file (scanners.txt) and copy‑paste to avoid case errors.

  • Automate validation: Add a pre‑flight step in CI that runs python -m json.tool or xmllint on the report before uploading.

  • Leverage the GUI for first‑time imports: It quickly confirms that the report format is acceptable before you script the CI integration.

Frequently Asked Questions

Question Answer
Can I upload a zip file containing multiple reports? Yes, but only if the zip contains files of a single supported format and you specify the correct scan_type.
What if I get a 400 error even after correcting the scanner name? Verify that the engagement ID exists and that you have permission to add findings to that engagement.
Is there a way to see which parser raised a 500 error? Enable detailed logging (LOGGING_LEVEL = "DEBUG" in settings.py). The server log will list the parser name before the traceback.
Why does TruffleHog sometimes output “null” findings? This occurs when the scan runs on a repository with no secrets. The file is still valid JSON but contains an empty array—DefectDojo will import zero findings, which appears as “only the file name”.

Bottom Line

Understanding the root cause of DefectDojo upload errors—whether they stem from incorrect scanner arguments (400), malformed output files (500), or improper TruffleHog formatting—allows you to resolve issues quickly and keep your vulnerability management pipeline flowing. Use the systematic steps above, validate your reports locally, and leverage DefectDojo’s logs and GUI to pinpoint problems before they block your CI/CD processes. Happy scanning!