Mayhem Integration with DefectDojo

Mayhem Integration with DefectDojo

Mayhem is a dynamic application security testing platform from Mayhem Security, the company formerly known as ForAllSecure. It finds defects by running the target: its code security product combines fuzz testing with symbolic execution against compiled applications, and its API security product sends generated requests to a running API to find authentication, validation, and error-handling problems. Both produce results in SARIF, through the Mayhem CLI, the mapi CLI, or Mayhem's CI integrations, and DefectDojo imports those SARIF files.

Mayhem Integration with DefectDojo

We run Mayhem in CI because it finds issues by triggering them, which means fewer arguments about whether a finding is real. Importing the Mayhem SARIF into DefectDojo puts those defects on the same Asset as our static analysis and dependency findings, with CWEs, severity, and a link back to the reproducer in Mayhem. DefectDojo uses a Mayhem-specific SARIF parser rather than the generic one, so titles come through without Mayhem's defect ID prefixes and markdown links, and every Finding is marked dynamic.

Why Mayhem Matters

Some defects only show up when the software runs with input nobody wrote a test for. Mayhem is built to generate that input.

• Fuzzing and symbolic execution explore code paths that unit tests and static rules miss, particularly in parsers and native code.
• API testing exercises a running service, so it catches problems such as endpoints that accept default credentials or return internal errors.
• Each defect comes with evidence from Mayhem's run, such as a stack trace or a sample request and response, which speeds up reproduction.
• SARIF output is a single run's result. Tracking which defects persist across builds, who owns them, and when they were fixed needs a platform behind it.

Advantages of This Integration

What running Mayhem results through DefectDojo adds:

• Readable titles. The Mayhem parser strips markdown links, Mayhem defect ID prefixes (TDID), quotes, and encoded characters from titles, so similar defects group cleanly and titles stay stable across runs.
• Dynamic classification. All Mayhem findings are marked dynamic, which keeps them separate from static analysis results in filters and metrics.
• CWE mapping. CWEs are pulled from SARIF taxa and from rule tags, so API and code defects can be reported by weakness class.
• Lifecycle on reimport. Reimporting the next run into the same Test mitigates defects Mayhem no longer reports, adds new ones, and reactivates regressions.
• Suppressions respected. Results that are suppressed in the SARIF import as inactive false positives, so a suppression made upstream does not reappear as open work.
• Triage and ticketing. Findings can be assigned, given SLA due dates by severity, risk-accepted, or pushed to Jira like any other Finding.

How This Integration Works

DefectDojo reads Mayhem output with the Mayhem SARIF Report scan type. It accepts SARIF from both code and API runs.

1. Produce a SARIF file. For API testing, add --sarif with an output file name to your mapi run command. For code testing, run mayhem run and then mayhem wait with its --sarif option to write the report once the run finishes. In GitHub Actions, the Mayhem actions expose an input for the SARIF output file (sarif-output for code, sarif-report for API).

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Mayhem SARIF Report, and upload the file. For automation, the API works in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=Mayhem SARIF Report" 
  -F "file=@mapi.sarif" 
  -F "product_name=orders-api" 
  -F "engagement_name=CI Fuzzing" 
  -F "auto_create_context=true"

DefectDojo Pro users can do the same with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Mayhem SARIF Report" 
  --report-path "./mapi.sarif" 
  --product-name "orders-api" 
  --engagement-name "CI Fuzzing" 
  --auto-create-context

3. Reimport on each run. Send later reports to /api/v2/reimport-scan/ against the same Test, so fixed defects are mitigated and history stays in one place.

Like the generic SARIF parser it extends, the Mayhem parser aggregates every run in the file into one import. Results whose SARIF kind is anything other than a failure are skipped.

Data Granularity: What Gets Imported

Use Cases

In a CI/CD pipeline: Each pull request runs a short Mayhem API test, and nightly builds run longer code fuzzing. Both reimport into their own Tests on the service's Asset, so engineers see which defects are new to their change and which were already known.

For native code and parsers: A team maintaining a C library fuzzes it with Mayhem on every release branch. Crashes import with their CWE and stack trace, and the release manager checks DefectDojo for open High findings before tagging.

For API programs: A platform team runs Mayhem against every internal API from a shared pipeline. Findings grouped by CWE across Assets show which weakness classes recur, which points to shared libraries or frameworks that need fixing once.

Alongside static analysis: Because Mayhem findings are dynamic and carry CWEs, security leads can compare what fuzzing confirms with what SAST reports for the same Asset, and prioritize static findings in the same weakness classes.

Operational Tips

• Use separate Tests for API and code runs on the same Asset. They target different things, and keeping them apart makes reimport results easier to read.
• Mayhem API descriptions can include the sample request and response from Mayhem's run. Review who can see those Findings, since request headers and response bodies can contain environment details.
• Severity follows the SARIF level unless a rule carries a security-severity score. If Mayhem's levels do not match your risk model, adjust severity during triage rather than editing reports.
• The description links back to Mayhem for the full reproducer, since unprintable characters in fuzzed input are replaced on import. Use that link when reproducing a crash.
• Set minimum_severity if short CI runs produce many low-value warnings, and keep the full set for nightly runs.
• If you want deduplication on fields other than the Legacy algorithm's defaults, configure a hash code setting for this scan type in your deployment.