# Mobile Testing Quality Gates and DefectDojo Integration

> **Intro:** Mobile scanning becomes useful when it moves from “someone looked at a report” to a repeatable release control. This page shows how to place mobile testing in CI/CD and how to route results into DefectDojo for normalized triage.
>
> **What this page includes**
>
> * a basic mobile quality gate model
> * a MobSF example in GitLab CI
> * DefectDojo import pattern
> * sample findings and gating logic

## Recommended gate model

### Do not block on everything

Block only on a small set of meaningful conditions, such as:

* new **critical** mobile findings
* new findings in categories you treat as release blockers
* evidence of cleartext traffic in a production build
* debug flags or exported sensitive components in a release artifact
* hardcoded production secrets in the client bundle

### Everything else can be advisory

Examples:

* tracker inventory
* low-risk informational findings
* medium findings that require product-specific triage first

## GitLab CI example

```yaml
stages:
  - build
  - mobile_scan
  - aggregate

mobile:mobsf:
  stage: mobile_scan
  image: curlimages/curl:8.7.1
  script:
    - apk add --no-cache jq
    - curl -F "file=@app-release.apk" -H "Authorization: $MOBSF_API_KEY" "$MOBSF_URL/api/v1/upload" > upload.json
    - export APP_HASH=$(jq -r '.hash' upload.json)
    - export FILE_NAME=$(jq -r '.file_name' upload.json)
    - curl -X POST -H "Authorization: $MOBSF_API_KEY" -F "scan_type=apk" -F "file_name=$FILE_NAME" -F "hash=$APP_HASH" "$MOBSF_URL/api/v1/scan" > scan.json
    - curl -X POST -H "Authorization: $MOBSF_API_KEY" -F "hash=$APP_HASH" "$MOBSF_URL/api/v1/report_json" -o mobsf-report.json
    - python3 scripts/mobile_gate.py mobsf-report.json
  artifacts:
    when: always
    paths:
      - mobsf-report.json
```

## Sample gate logic

A small gate script can:

* fail on any new critical finding
* fail on release builds with `android:debuggable="true"`
* fail on cleartext traffic allowed for production flavor
* fail if a finding title matches a high-risk allowlist

## DefectDojo import pattern

### API example

```bash
curl -X POST "$DEFECTDOJO_URL/api/v2/reimport-scan/" \
  -H "Authorization: Token $DEFECTDOJO_TOKEN" \
  -F "scan_type=MobSF Scan" \
  -F "test=$DEFECTDOJO_TEST_ID" \
  -F "active=true" \
  -F "verified=false" \
  -F "minimum_severity=Low" \
  -F "file=@mobsf-report.json"
```

Use **reimport** instead of one-off imports so that:

* the same test record tracks trend over time
* duplicates are reduced
* teams can watch regressions between builds

## Sample findings with commentary

> **Pattern note:** The short statement stays visible. The fuller explanation is hidden in a collapsible block so a reviewer can scan the page quickly.

### 1. `android:allowBackup="true"`

This means app data may be backed up and restored on another device or extracted during some workflows. It matters more when the app stores tokens, cached PII, or business-sensitive offline data.

<details>

<summary><strong>Reveal the finding rationale and short fix</strong></summary>

**Short fix:** turn backups off or exclude sensitive data.

</details>

\### 2. Release build marked debuggable This lowers the cost of runtime inspection and tampering.

<details>

<summary><strong>Reveal the finding rationale and short fix</strong></summary>

**Short fix:** verify release build config and signing pipeline.

</details>

\### 3. Cleartext traffic permitted This increases the chance of insecure transport and downgrade-like mistakes.

<details>

<summary><strong>Reveal the finding rationale and short fix</strong></summary>

**Short fix:** disable cleartext traffic in production unless there is a narrow, approved exception.

</details>

\### 4. Sensitive logs Logs can leak tokens, identifiers, or internal states.

<details>

<summary><strong>Reveal the finding rationale and short fix</strong></summary>

**Short fix:** remove them in release builds.

</details>

\### 5. Exported activity with no meaningful protection Other apps can trigger behavior unexpectedly.

<details>

<summary><strong>Reveal the finding rationale and short fix</strong></summary>

**Short fix:** restrict exported components and add permissions where required.

</details>

## Where the metric goes

Useful mobile program metrics:

* percent of release artifacts scanned before promotion
* percent of scans imported into DefectDojo
* critical mobile findings by app tier
* median age of mobile findings
* number of release-blocking mobile issues by quarter

## Cross-links

* [📱 Mobile Application Security Testing](/application-security-and-secure-sdlc/index-1/mobile-application-security-testing.md)
* [Security Quality Gates and Release Blocking](/devsecops-cicd-and-supply-chain/index-1/security-quality-gates-and-release-blocking.md)
* [🥋 DefectDojo and ASPM Platforms](/application-security-and-secure-sdlc/index-1/defectdojo-and-aspm-platforms.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/devsecops-cicd-and-supply-chain/index-1/mobile-testing-quality-gates-and-defectdojo.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.