QARK Integration with DefectDojo

QARK Integration with DefectDojo

QARK (Quick Android Review Kit) is an open source static analysis tool from LinkedIn for Android applications, published on GitHub as linkedin/qark. It analyzes either Java source or a packaged APK, which it decompiles before inspecting the manifest and the recovered code for common Android weaknesses such as exported components without permissions, TapJacking exposure, logging left in release builds, and hardcoded keys. QARK can also generate proof-of-concept material for some findings, and it writes a JSON report with --report-type json.

QARK Integration with DefectDojo

We added QARK to our mobile release checks because it looks at the built APK, which is what actually ships, and DefectDojo is where its results turn into tracked work. Importing QARK's report.json into DefectDojo turns each issue into a Finding on the mobile app's Asset, with a stable relative file path, the line, and the Android-specific details QARK found, like the package and exported component. Successive builds deduplicate against what is already open, so the team works on what changed instead of rereading the whole report.

Why QARK Matters

Many Android security problems come from configuration in the manifest and from habits in code, not from vulnerable libraries. QARK checks both.

• It flags exported components, such as activities, that are not protected by a permission and could be invoked by other apps.
• It reports TapJacking exposure, which depends on app-wide settings such as minSdkVersion.
• It finds logging calls and hardcoded keys in the decompiled code of the release APK.
• It runs locally against the APK file with no device or emulator needed.
• Its own report has no history. Without a platform behind it, nobody knows whether an exported component was flagged last release too.

Advantages of This Integration

What importing QARK into DefectDojo adds:

• Stable file paths. QARK writes absolute paths through its build directory. The parser strips everything up to QARK's /qark/ output marker, leaving paths like cfr/com/example/App.java that stay the same between runs.
• Clear severity mapping. QARK's VULNERABILITY, WARNING, and INFO levels map to High, Medium, and Info, and Findings fall under DefectDojo SLAs by severity.
• Android context in the description. Category, line and column, and the exploit details QARK records (package name, tag name, exported component type) are kept.
• Deduplication across builds. DefectDojo hashes title, CWE, line, file path, and description, so the same issue in the next build matches the existing Finding.
• Lifecycle on reimport. Reimporting into the same Test mitigates issues fixed in the new build and adds new ones.
• Triage of known false positives. Results such as the signing block API-key match can be marked false positive once, and reimports respect it.

How This Integration Works

DefectDojo imports QARK results with the QARK Scan scan type, which reads the JSON array of issues QARK writes.

1. Produce a JSON report. Install QARK and scan the APK:

pip install qark
qark --apk app.apk --report-type json

Two practical details from the DefectDojo documentation: QARK needs a full JDK (it calls jar while unpacking), and it writes the report inside its own package directory, at <site-packages>/qark/report/report.json, rather than in the build path. Collect the file from there.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select QARK Scan, and upload report.json. Through the API, in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=QARK Scan" 
  -F "file=@report.json" 
  -F "product_name=android-app" 
  -F "engagement_name=Release 4.2" 
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "QARK Scan" 
  --report-path "./report.json" 
  --product-name "android-app" 
  --engagement-name "Release 4.2" 
  --auto-create-context

3. Reimport for each build. Send later reports to /api/v2/reimport-scan/ against the same Test.

Data Granularity: What Gets Imported

Manifest-level issues such as TapJacking have no file or line. QARK reports no CWE, so Findings are distinguished by name, location, and description.

Use Cases

Release gating for a mobile app: Every release candidate APK is scanned and reimported into one Test. New High Findings, such as a newly exported component, are reviewed before the build goes to the store.

Reviewing a third-party build: When a vendor delivers an APK, the security team runs QARK against it and imports the results into an Asset for that vendor app, which gives the procurement conversation concrete evidence.

Cleaning up logging: QARK's Logging found results land with file and line, so a mobile team can assign them by package and track the cleanup to zero.

Combining with other mobile tools: Teams that also run APK secret scanners or dynamic mobile testing import those into the same Asset, so manifest issues, secrets, and runtime findings are reported together.

Operational Tips

• Expect code issues twice. QARK decompiles with both fernflower and cfr, so one log call can appear under two paths that differ only by decompiler name. Filter on the path prefix if you want one view.
• The APK signing block can trip QARK's API-key check. If a Finding points at META-INF signature files, review and mark it false positive.
• QARK's JSON writer sometimes logs a conversion error and omits issues that the HTML report shows. Compare reports if a build's Finding count drops unexpectedly.
• Set minSdkVersion deliberately. Without 9 or higher, QARK always reports TapJacking.
• The description is part of the dedupe hash, so a QARK version change that rewords descriptions can create new Findings. Pin the QARK version in CI.
• Tag imports with the app version so findings can be compared release by release.