# How to Integrate MobileAudit Findings with DefectDojo Using API v2

> Learn how to integrate MobileAudit findings with DefectDojo using API v2. Streamline vulnerability management by sending findings directly to DefectDojo for efficient tracking and resolution.

- Repository: [Mónica Pastor/mobileaudit](https://github.com/mpast/mobileaudit)
- Tags: how-to-guide
- Published: 2026-03-07

---

**MobileAudit integrates findings with DefectDojo using API v2 by constructing a JSON payload in [`app/integration.py`](https://github.com/mpast/mobileaudit/blob/main/app/integration.py) and POSTing to the `/api/v2/findings/` endpoint, then storing the returned DefectDojo ID in the local database.**

The mpast/mobileaudit repository provides a built-in integration that forwards mobile application vulnerability findings to DefectDojo using the v2 REST API. This enables security teams to consolidate scan results within their centralized vulnerability management workflow. When you integrate MobileAudit findings with DefectDojo using API v2, the system maps local finding fields to DefectDojo's schema and maintains bidirectional linkage via the `defectdojo_id` database column.

## Prerequisites for DefectDojo API v2 Integration

Before you can integrate MobileAudit findings with DefectDojo using API v2, ensure you have the following components configured:

- **DefectDojo Instance**: A running DefectDojo server (v2 API) accessible from the MobileAudit container network.
- **API Token**: A DefectDojo user API key with permission to add findings. Store this in the `DEFECTDOJO_API_KEY` environment variable.
- **Environment Variables**: Add the following to your `.env` file or Docker Compose environment:

```dotenv
DEFECTDOJO_ENABLED=True
DEFECTDOJO_URL=http://defectdojo:8080/finding/
DEFECTDOJO_API_URL=http://defectdojo:8080/api/v2/
DEFECTDOJO_API_KEY=your-defectdojo-api-key

```

These values are read via `env()` in [`app/config/settings.py`](https://github.com/mpast/mobileaudit/blob/main/app/config/settings.py)【/cache/repos/github.com/mpast/mobileaudit/main/app/config/settings.py#L167-L170】.

## How the Integration Works

When you integrate MobileAudit findings with DefectDojo using API v2, the export process follows a specific pipeline from the UI through the backend to the external API.

### Triggering the Export from the UI

The integration activates when a user selects the **Push to DefectDojo** option in the Findings view. This sends a POST parameter `push_dojo` to the backend. The view in [`app/views.py`](https://github.com/mpast/mobileaudit/blob/main/app/views.py) checks both this flag and the `DEFECTDOJO_ENABLED` setting before invoking the integration routine:

```python

# app/views.py (excerpt)

if (push_dojo and settings.DEFECTDOJO_ENABLED):
    analysis.create_finding_on_dojo(f)

```

This logic appears at line 86 in the view【/cache/repos/github.com/mpast/mobileaudit/main/app/views.py#L85-L87】.

### Payload Construction in app/integration.py

The `create_finding_on_dojo` function in [`app/integration.py`](https://github.com/mpast/mobileaudit/blob/main/app/integration.py) constructs a JSON payload that maps MobileAudit fields to the DefectDojo v2 API schema. The function populates critical fields such as title, description, severity, CWE, and file path information:

```python

# app/integration.py (excerpt)

data = {
    'title': finding.name,
    'description': '####Description\n' + finding.description + '\n####Snippet \n' + finding.snippet,
    'severity': finding.get_severity_display(),
    'cwe': finding.cwe.cwe,
    'found_by': [1],
    'reporter': 1,
    'date': finding.created_on.strftime("%Y-%m-%d"),
    'test': finding.scan.defectdojo_id if finding.scan.defectdojo_id else 1,
    'impact': "N/A",
    'active': True,
    'mitigation': finding.mitigation or 'N/A',
    'references': finding.risk.reference,
    'line': finding.line_number,
    'file_path': finding.path,
    'static_finding': True,
    'duplicate': False,
}

```

This payload construction appears at lines 63-88【/cache/repos/github.com/mpast/mobileaudit/main/app/integration.py#L63-L88】.

### API Authentication and Request

The integration sends the payload via POST to the DefectDojo v2 findings endpoint with Token-based authentication:

```python
headers = {
    'content-type': 'application/json',
    'Authorization': 'Token ' + settings.DEFECTDOJO_API_KEY
}
response = requests.post(
    settings.DEFECTDOJO_API_URL + 'findings/',
    data=json_data,
    headers=headers,
    verify=False
)

```

This request logic is implemented at lines 22-24【/cache/repos/github.com/mpast/mobileaudit/main/app/integration.py#L22-L24】.

### Storing the DefectDojo ID

Upon successful creation, the integration extracts the returned `id` from the JSON response and persists it to the local database. This establishes a permanent link between the MobileAudit finding and the DefectDojo record:

```python
if ('id' in json_response and json_response['id']):
    finding.defectdojo_id = json_response['id']
    finding.save()

```

This storage operation occurs at lines 26-28【/cache/repos/github.com/mpast/mobileaudit/main/app/integration.py#L26-L28】.

## Linking MobileAudit Scans to DefectDojo Tests

DefectDojo organizes findings under **Products → Engagements → Tests**. To integrate MobileAudit findings with DefectDojo using API v2 and link them to a specific Test:

1. Create or identify the Test ID in DefectDojo.
2. Set the `defectdojo_id` field on the MobileAudit **Scan** model to this Test ID.
3. When findings are pushed, the payload uses this value in the `test` field instead of the default `1`.

Both the `Scan` and `Finding` models include the `defectdojo_id` field as an integer defaulting to `0`, defined in [`app/models.py`](https://github.com/mpast/mobileaudit/blob/main/app/models.py):

```python

# app/models.py (excerpt)

defectdojo_id = models.IntegerField(blank=True, default=0)

```

This field appears at lines 65-66 for the `Scan` model and line 40 for the `Finding` model【/cache/repos/github.com/mpast/mobileaudit/main/app/models.py#L65-L66】【/cache/repos/github.com/mpast/mobileaudit/main/app/models.py#L40-L41】.

## Programmatic Export Example

If you need to integrate MobileAudit findings with DefectDojo using API v2 outside the web UI—such as in a CI/CD pipeline—you can invoke the same logic manually:

```python
import json, requests
from django.conf import settings
from app.models import Finding

def push_finding(finding_id):
    f = Finding.objects.get(pk=finding_id)

    data = {
        "title": f.name,
        "description": f"####Description\n{f.description}\n####Snippet \n{f.snippet}",
        "severity": f.get_severity_display(),
        "cwe": f.cwe.cwe,
        "found_by": [1],
        "reporter": 1,
        "date": f.created_on.strftime("%Y-%m-%d"),
        "test": f.scan.defectdojo_id or 1,
        "impact": "N/A",
        "active": True,
        "mitigation": f.mitigation or "N/A",
        "references": f.risk.reference,
        "line": f.line_number,
        "file_path": f.path,
        "static_finding": True,
        "duplicate": False,
    }

    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Token {settings.DEFECTDOJO_API_KEY}",
    }

    resp = requests.post(
        settings.DEFECTDOJO_API_URL + "findings/",
        data=json.dumps(data),
        headers=headers,
        verify=False,
    )
    resp.raise_for_status()
    payload = resp.json()
    f.defectdojo_id = payload["id"]
    f.save()
    print(f"Finding {f.id} exported – DefectDojo ID {payload['id']}")

```

## Summary

To successfully integrate MobileAudit findings with DefectDojo using API v2, remember these key points:

- **Enable via environment variables** by setting `DEFECTDOJO_ENABLED=True` and providing your API key and URLs in [`app/config/settings.py`](https://github.com/mpast/mobileaudit/blob/main/app/config/settings.py).
- **Trigger exports** from the Findings UI, which invokes `create_finding_on_dojo()` in [`app/integration.py`](https://github.com/mpast/mobileaudit/blob/main/app/integration.py) to build and POST the JSON payload.
- **Link to specific Tests** by setting the `defectdojo_id` field on the `Scan` model, which maps to DefectDojo's Test ID in the API payload.
- **Store remote IDs** by saving the returned DefectDojo finding ID back to the `Finding.defectdojo_id` field for bidirectional tracking.

## Frequently Asked Questions

### What DefectDojo permissions are required for the API key?

Your DefectDojo API key must belong to a user with permission to add findings. Specifically, the user needs the "Add Finding" permission within the DefectDojo authorization framework. The integration uses Token-based authentication via the `Authorization: Token <key>` header when posting to the `/api/v2/findings/` endpoint.

### Can I link findings to existing DefectDojo engagements?

Yes. To link findings to a specific DefectDojo Test (which belongs to an Engagement), set the `defectdojo_id` field on the MobileAudit **Scan** model to the numeric Test ID from DefectDojo. When `create_finding_on_dojo()` constructs the API payload, it uses this value in the `test` field. If no ID is set, the integration defaults to `1`.

### How does MobileAudit handle duplicate findings in DefectDojo?

The integration explicitly marks new findings as non-duplicates by setting `"duplicate": False` in the JSON payload sent to DefectDojo. Additionally, MobileAudit stores the returned DefectDojo finding ID in the local `Finding.defectdojo_id` field, allowing you to track which items have already been exported and prevent redundant manual pushes via the UI or API.

### Is SSL certificate verification enabled for the API requests?

No, SSL certificate verification is disabled by default in the current implementation. The `requests.post()` call in [`app/integration.py`](https://github.com/mpast/mobileaudit/blob/main/app/integration.py) uses `verify=False` when sending findings to the DefectDojo API endpoint. If your DefectDojo instance uses a self-signed certificate or operates on an internal network, this allows the integration to function without certificate errors, though you should consider the security implications for production deployments.