APKLeaks Integration with DefectDojo

APKLeaks Integration with DefectDojo

APKLeaks is an open source command-line tool, created by Dwi Siswanto, that scans Android APK files for URIs, endpoints, and secrets. It decompiles the package with jadx, then applies a set of named regular expressions (for example Google_API_Key, Firebase, IP_Address, and LinkFinder) to the recovered code, resources, and manifest. Results can be written as JSON for import into DefectDojo.

APKLeaks Integration with DefectDojo

We ship Android apps, and the fastest way for a key or an internal hostname to leak is for it to be compiled into a release build. APKLeaks gives us a cheap check on the actual APK, not the source tree, which catches values injected at build time. Importing its JSON into DefectDojo turns each pattern that matched into a Finding on the app's Asset, with the matched strings as evidence, so someone owns the cleanup and we can see whether the next build is clean.

Why APKLeaks Matters

Anything inside an APK can be extracted by anyone who downloads the app, so hardcoded values are effectively public.

• It scans the built artifact, which includes resources and the manifest as well as code, so it finds values that never appear in source control.
• It reports API keys, cloud service identifiers, IP addresses, and URLs, which tell an attacker where your backend lives and sometimes how to call it.
• Its pattern set is extensible with custom patterns, so teams can add checks for their own key formats.
• APKLeaks output has no history. Without tracking, nobody knows whether a leaked key was rotated or is still shipping in every release.

Advantages of This Integration

• Actionable grouping. DefectDojo creates one finding per pattern, not per match. "This package leaks a Google API key" is the unit of work, and the matches are its evidence, counted in the occurrence field.
• No secrets in titles. Because findings are grouped by pattern, titles name the pattern and the package, never the matched value.
• Release-over-release tracking. Reimporting each build's report into the same Test shows which leaks were removed and which persist.
• Mobile findings in context. APK results sit beside the app's SAST, SCA, and backend findings, so the team that owns the app sees them all.
• Workflow features. Assign findings, set SLAs, push them to Jira, or mark expected patterns as false positives with a note.

How This Integration Works

1. Install APKLeaks and jadx. APKLeaks needs jadx to decompile the APK. If jadx is not on PATH, APKLeaks prompts interactively to download it, which makes an unattended CI run fail. Install jadx and put it on PATH before the scan step.

2. Scan the APK and write JSON.

pip install apkleaks
apkleaks -f app.apk --json -o apkleaks.json

When APKLeaks matches nothing at all, it prints a message and writes no output file, even with -o. In practice this rarely happens, because the LinkFinder pattern matches the Android XML namespace URL that every manifest declares. Handle a missing file in your pipeline anyway.

3. Import the report. In the UI, open the Engagement, choose Import Scan Results, select APKLeaks Scan, and upload the file. For automation, use the API (Community Edition or DefectDojo Pro):

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

DefectDojo Pro users can use Universal Importer in the build pipeline:

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

4. Reimport per build. Send each new report to /api/v2/reimport-scan/ against the same Test to keep one history per app.

Data Granularity: What Gets Imported

Use Cases

Release gating: Every release build runs APKLeaks and reimports the report. A pipeline step queries DefectDojo for active key or secret pattern findings on the app's Asset and blocks the release if any appear.

Secret rotation follow-up: After a key is found in a shipped APK, the finding is assigned to the owning team with an SLA. It stays open until a later build no longer contains the key, and the team records the rotation in a note.

Third-party or acquired apps: A security team assessing an APK it didn't build imports the scan into a dedicated Asset to inventory every backend URL and identifier the app reveals.

Portfolio view: Organizations with several apps import each into its own Asset and use DefectDojo reporting to see which apps still ship hardcoded keys.

Operational Tips

• A lone LinkFinder finding usually means a clean scan. It matches the Android manifest namespace that every APK declares, so treat it as expected or mark it false positive once.
• Every finding imports at Medium. Raise key and secret patterns to High or Critical by hand, and lower link and IP patterns, based on what each one means for your app.
• Matched values are copied into the description as evidence. They may include live keys, so restrict access to the Asset and rotate anything real rather than relying on the finding being hidden.
• The description, which holds the matches, is part of the dedupe hash. A new or rotated value under the same pattern changes the hash, so expect the finding to be replaced on reimport rather than updated.
• Pin APKLeaks and jadx versions in CI so pattern behavior doesn't change between builds without notice.
• If you add custom patterns, document them in the Asset's description so reviewers know what each pattern name means.