Inventory
The Client ships payment, analytics, and auth SDKs. KeysDefender holds their secrets.
App Security · AppDefender.dev
SDKGuard
Protect payment, analytics, and auth SDKs inside the Client app.
Watches embedded third-party SDKs for tamper, data exfiltration, and hooking. Same 44/23 rule catalog applies to the host app and the libraries it ships.
Payment SDK integrity
Analytics / auth library watch
No extra JS keys
Reports into Client Admin
Same 44 / 23 catalogs
Sandbox proof before Production
What it does
SDKGuard on the launch path
SDKGuard watches the third-party libraries a Client app already ships — payments, analytics, Maps, push, and auth. Those SDKs run inside the same process AppDefender scores. A hooked Juspay or analytics binary is the same class of FAIL as a hooked host app.
The 44 Android and 23 iOS catalogs apply to the host and the libraries. Keys for those SDKs still unwrap only through KeysDefender after ALLOW. SDKGuard does not put extra secrets on the React Native bridge.
Reports land in Client Admin ThreatDesk for that environment. Super Admin enables Sandbox first so Makers can prove a tampered payment SDK without touching Production traffic.
What it scores
Signals this module is built for
- Payment SDK integrity (host plus library)
- Analytics, Maps, and push library watch
- Hooking and tamper on embedded SDKs
- No extra JS keys for watched libraries
- Same catalog actions: LOG, WARN, CLOSE, BLOCK
- Isolated reports per Client environment
How it runs
Detect, decide, enforce
Watch at runtime
SDKGuard scores those libraries on the same launch and session path as the host app.
Report
FAIL actions go to that Client’s ThreatDesk. Production policy still needs two checkers.
Operators
Who owns the control
Super Admin
Enables the catalog that covers host and libraries. Vault stays in KeysDefender.
Client Admin
Sees SDK FAILs for their app only. Cannot mix Sandbox library evidence into Production.
Other App Security modules
Read the product page, not a copy here
All modules