For code-hardening products such as zShield, identify the protected code types and post-build output. Tests on the final package provide stronger acceptance evidence than integration visible in the source project.
Evaluation approach
Code protection aims to increase resistance to analysis and modification. Verify current language, architecture and package support with the vendor.
Application example
When distributing a protected SDK, test both its binary and a sample consuming application.
Limits and considerations
Code hardening does not fix server-side business logic. A module name does not establish every RASP capability.
Two targets in SDK distribution
Assessing a protected library involves more than its binary. Test the consuming sample application's build, execution and updates. Preserving the public API contract matters for integration.
State which proprietary logic the resistance assessment targets. Obfuscated file size alone is not a security gain. Consumers' ability to decode crashes and report compatibility problems also belongs in delivery requirements.
Checks and decisions
- Verify SDK coverage
- Inspect the final binary
- Measure integration effects
Request code-resilience evidence for zShield and separate operational evidence for runtime-event components.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.