42Crunch Integration with DefectDojo

42Crunch Integration with DefectDojo

42Crunch is an API security platform from the company of the same name. Its API Security Audit runs static analysis against OpenAPI (Swagger) definitions, checking authentication, authorization, transport, and data definitions against several hundred rules and giving each API a score from 0 to 100. Audits run from the 42Crunch platform, IDE extensions, and CI/CD integrations, and the audit report is a JSON document that DefectDojo imports with the Crunch42 Scan parser.

42Crunch Integration with DefectDojo

We picked 42Crunch because our API contracts were drifting faster than anyone could review them, and an audit score on a pull request was the first thing that made developers care. What the score doesn't give you is history. Importing 42Crunch audit reports into DefectDojo turns each issue in an OpenAPI file into a Finding on the Asset that owns the API, so we can see which contract problems are new, which have been open for three releases, and who is responsible for fixing them. The API audit becomes part of the same remediation process as our code and dependency scanning.

Why 42Crunch Matters

Many API vulnerabilities start in the contract. If an OpenAPI file allows an operation with no security requirement, or accepts strings with no length or pattern limit, the implementation usually does the same.

• The audit catches design problems before code is deployed, when changing a definition is cheap.
• Its checks are specific to API definitions: missing or empty security requirements, API keys sent in headers over unencrypted transport, weak schema constraints, and similar contract issues.
• Each issue carries a criticality level and a score impact, which gives teams an ordered list instead of a pass or fail.
• An audit only describes one version of one file. Without a tracking platform, nobody can tell whether a given issue was introduced last week or has been accepted for a year.

Advantages of This Integration

What we gained by routing 42Crunch audit results through DefectDojo:

• Stable identity per issue. The parser stores 42Crunch's own issue fingerprint as the unique ID, and DefectDojo deduplicates Crunch42 Scan findings on that ID. The same issue in the same definition is recognized across audits.
• Lifecycle across contract versions. Reimporting each new audit into the same Test closes issues that were fixed in the definition and adds anything newly introduced.
• Severity that fits our SLAs. 42Crunch criticality levels 1 through 5 map directly to Info, Low, Medium, High, and Critical, so API design issues fall under the same SLA rules as everything else.
• Ownership by API. Each API, or each service that publishes one, maps to an Asset. Findings can be assigned, commented on, risk-accepted, or pushed to Jira from there.
• API design risk in the same reports. Audit findings sit next to SAST, SCA, and DAST results for the same service, so security leads see contract weaknesses alongside implementation bugs.

How This Integration Works

DefectDojo imports 42Crunch audit output with the Crunch42 Scan scan type.

1. Get the audit report as JSON. Run an API Security Audit through whichever 42Crunch tooling you use and keep the raw audit JSON. The parser expects a document with a top-level report object that contains a security section with an issues map, keyed by 42Crunch issue ID. A JSON array of several such documents is also accepted, and each one is processed in turn. SARIF output from 42Crunch's CI integrations is a different format and is not what this parser reads.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Crunch42 Scan, and upload the file. For automation, use the import API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Crunch42 Scan" \
  -F "file=@orders-api-audit.json" \
  -F "product_name=orders-api" \
  -F "engagement_name=API Contract Audit" \
  -F "auto_create_context=true"

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

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Crunch42 Scan" \
  --report-path "./orders-api-audit.json" \
  --product-name "orders-api" \
  --engagement-name "API Contract Audit" \
  --auto-create-context

3. Reimport on every contract change. Send later audits of the same definition to /api/v2/reimport-scan/ against the same Test. Because deduplication relies on the 42Crunch fingerprint, the lifecycle stays accurate as long as each Test holds audits of one API definition.

Data Granularity: What Gets Imported

A few things the parser does not carry over. The pointer value appears in the description as the raw index number from the report, not as a resolved JSON path in the definition. Mitigation, references, CWE, endpoints, and file path are not set. Only the security section of the report is read, so issues listed under the report's data section are not imported. Each occurrence of a rule in the definition becomes its own Finding.

Use Cases

On every pull request that touches a contract: The pipeline audits the changed OpenAPI file and reimports the report into the API's Test. Reviewers see only what the change introduced, and long-standing issues that were risk-accepted don't reappear as new.

When standardizing API security across teams: A platform team with 25 internal APIs imports each audit into the owning Asset. DefectDojo metrics then show which teams carry the most High and Critical contract issues, which is easier to act on than comparing audit scores one API at a time.

Before exposing an API to partners: Security reviews often require that no High or Critical design issues remain open. Querying DefectDojo for active findings on that Asset gives a clear answer, with the history of how each issue was resolved.

Alongside runtime testing: Teams that also scan the running API with a DAST tool can import both into the same Asset, which shows whether a weakness exists only in the contract or was confirmed in the deployed service.

Operational Tips

• Use one Test per API definition and reimport into it. Fingerprint-based deduplication works best when audits of different APIs never share a Test.
• Rule IDs make terse titles. Add a note or tag with a plain-language summary for findings you push to Jira, so developers outside the security team understand them.
• Set minimum_severity=Low if criticality 1 informational items would crowd the Test. They map to Info and rarely need an owner.
• Tag imports with the API name and version (for example tags=orders-api,v3) so findings can be filtered by contract release.
• Remember that data section issues are not imported. If your audits report many of them, review those in 42Crunch directly.
• Risk-accept intentional design choices, such as an operation that is meant to be public, with an expiration date so they are revisited when the API changes.