Quark-Engine Integration with DefectDojo

Quark-Engine Integration with DefectDojo

Quark-Engine is an open source tool, maintained by the Quark-Engine Team and released under GPL-3.0, for automating the analysis of suspicious Android applications. It loads an app's Dalvik bytecode and uses a scoring system to detect behaviors, which Quark calls "crimes", such as sending the device location over SMS, then estimates an overall threat level for the APK. Detection rules describe the permissions, API calls, and call relationships behind each behavior. Quark writes its results as JSON.

Quark-Engine Integration with DefectDojo

We run Quark-Engine on Android builds, ours and third-party SDK-heavy ones, because it answers a question vulnerability scanners do not: what does this app actually do with the permissions it requests? Importing Quark's JSON report into DefectDojo turns each detected behavior into a Finding on the app's Asset, graded by how confident Quark is that the behavior is real, with the permissions and native API calls listed in the description. When a new build adds a behavior nobody approved, it shows up as a new Finding instead of a line in a report nobody compared.

Why Quark-Engine Matters

Mobile app risk is not only about known vulnerabilities. An app, or a library bundled in it, can collect location, contacts, or device identifiers and send them somewhere, and that is a security and privacy problem in its own right.

• Quark detects behaviors from combinations of permissions and API calls, not from signatures of known malware.
• Its confidence value says how many detection stages matched, up to a confirmed data flow between the APIs involved.
• Rules are labeled with categories such as location or collection, which helps route results to the right reviewer.
• It analyzes the APK statically, without running it on a device.
• The report is per APK and per run. Comparing behaviors between releases is left to whoever reads it.

Advantages of This Integration

What running Quark-Engine through DefectDojo gives us:

• Severity from confidence. Quark assigns no severity. DefectDojo maps 100% confidence to High, 80% to Medium, 40 to 60% to Low, and 0 to 20% to Info, so confirmed data flows get the most attention.
• Behavior detail in one place. The rule, confidence, score and weight, labels, required permissions, and native API calls are listed in the description, along with the APK name and MD5.
• Per-APK tracking. The APK filename becomes the component, so behaviors are tracked per app file.
• Deduplication on behavior, APK, and rule. DefectDojo hashes title, component name, and rule, so the same behavior found again matches the existing Finding.
• Lifecycle on reimport. Reimporting a new build's report into the same Test mitigates behaviors that were removed and adds new ones.
• A decision record. Expected behaviors, like a navigation app reading location, can be risk-accepted with a note so the reasoning is kept.

How This Integration Works

DefectDojo imports Quark-Engine results with the Quark-Engine Scan scan type, which reads the crimes array from the JSON report.

1. Produce a JSON report. Run Quark against the APK with summary output written to a file:

quark -a sample.apk -s -o quark-report.json

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Quark-Engine Scan, and upload the report. 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=Quark-Engine Scan" 
  -F "file=@quark-report.json" 
  -F "product_name=field-app-android" 
  -F "engagement_name=Release Builds" 
  -F "auto_create_context=true"

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

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Quark-Engine Scan" 
  --report-path "./quark-report.json" 
  --product-name "field-app-android" 
  --engagement-name "Release Builds" 
  --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

The report-level threat_level and total_score describe the APK as a whole and are not mapped onto individual Findings. Quark reports no CWE, file path, or line.

Use Cases

Reviewing third-party SDKs: A team adding an advertising or analytics SDK scans the build before and after the change. New behaviors that appear only after the SDK was added are reviewed and either accepted or removed.

Release comparison: Each release APK is reimported into the same Test, so the security team sees which behaviors were added or removed between versions.

Vetting apps for a managed fleet: IT security teams evaluating Android apps for corporate devices import each APK's report into its own Asset and use High Findings as a quick triage list.

Privacy review: Behaviors labeled for location or collection give a privacy reviewer a concrete list of data the app is capable of handling, with the permissions that enable it.

Operational Tips

• Use minimum_severity=Medium if low-confidence behaviors are too noisy. They reflect partial matches without a confirmed data flow.
• The APK filename is part of the dedupe hash. Use a stable filename for each app in CI, or every build will look like a new set of Findings.
• Risk-accept expected behaviors with an expiration date, so they are reviewed again when the app's purpose or SDKs change.
• Read the native API list before escalating. It shows which classes and methods triggered the rule.
• Quark's per-APK threat level is not imported. If you track it, add it as a tag at import time.
• Tag imports with the app version so behaviors can be filtered by release.