Use WASM module of zen-internals instead of FFI

[hansott]

Similar to go agent, packages the wasm module inside the agent jar and gets rid of the required native flag to disable warning

In terms of perf, it's 3-4x faster than the current FFI approach. However, we're loading the FFI library on every invocation so it was slow by design. Caching the FFI library is much faster than the WASM approach but in a real application you don't notice the difference between cached FFI and WASM (because there's other overhead).

[aikido-pr-checks]

🟠 High - Release job can publish an unvalidated WASM module

The PR makes test workflows overwrite agent_api/src/main/resources/zen_internals.wasm with make wasm, but the release workflow now skips that step and packages whatever binary blob is committed in the repository. Because runtime integrity only compares the WASM file to the adjacent checksum file shipped from the same source tree, a modified zen_internals.wasm plus matching .sha256sum would still be accepted at runtime while CI never exercised that binary. This creates a supply-chain gap where released artifacts can silently ship a different SQL-injection detector than the one CI validated, weakening the product's protection guarantees for all users of that release.

Suggested change

	- name: Build with Gradle
	run: chmod +x gradlew && make build
	- name: Build with Gradle
	run: chmod +x gradlew && make wasm && make build

_{More info - Reply on this comment to give feedback or ignore the issue.}

[codecov]

Codecov Report

❌ Patch coverage is 66.91176% with 45 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...ulnerabilities/sql_injection/WasmSQLInterface.java	67.41%	21 Missing and 8 partials ⚠️
...pi/vulnerabilities/sql_injection/WasmInstance.java	65.21%	9 Missing and 7 partials ⚠️

📢 Thoughts on this report? Let us know!

[aikido-pr-checks]

🟠 High - Checksum download failures are masked, producing builds with SQL detection disabled

The new make wasm target pipes the checksum download through sed without pipefail, so a network or HTTP failure on libzen_internals.wasm.sha256sum can still leave the recipe successful while truncating or rewriting zen_internals.wasm.sha256sum. The resulting artifact builds normally, but runtime initialization then caches the checksum mismatch and Agent continues startup anyway, causing every later SQL-injection detection attempt to return false. A transient build-time fetch failure can therefore silently ship a release where SQL injection protection is completely disabled.

Suggested change

	curl -fL $(WASM_BASE_URL)/libzen_internals.wasm.sha256sum \
	| sed 's/libzen_internals\.wasm/zen_internals.wasm/' \
	> $(WASM_RESOURCE_DIR)/zen_internals.wasm.sha256sum
	curl -fL -o $(WASM_RESOURCE_DIR)/zen_internals.wasm.sha256sum.tmp $(WASM_BASE_URL)/libzen_internals.wasm.sha256sum
	sed 's/libzen_internals\.wasm/zen_internals.wasm/' $(WASM_RESOURCE_DIR)/zen_internals.wasm.sha256sum.tmp > $(WASM_RESOURCE_DIR)/zen_internals.wasm.sha256sum
	rm $(WASM_RESOURCE_DIR)/zen_internals.wasm.sha256sum.tmp

_{More info - Reply on this comment to give feedback or ignore the issue.}