Gradle

AI Security Review

Evidence context: threat category none; evidence quality moderate.

What this extension is

Gradle is JetBrains' official build-tool integration for IntelliJ-based IDEs. It runs on the JetBrains Marketplace under the verified JetBrains publisher account, with 692,748 users on version 262.10968.148. Its job is to drive Gradle from inside the editor: syncing build scripts, executing tasks, resolving dependencies.

Filesystem and process access

This build records no manifest permissions, no host permissions and no network endpoints. The 149 findings in the low-severity code-smell bucket match ProcessBuilder, System.getenv and Runtime.exec patterns plus assorted code-quality rules, which is what a scan of any large Java or Kotlin bundle returns. A Gradle plugin spawns a daemon, reads build.gradle and settings.gradle, and writes into the project's build directory. That is the stated purpose. Nothing in the findings pairs a file read with a destination for the data.

Credential access

No secret findings were recorded. Nothing matched .env, .ssh, private keys or cloud credential paths, and no rule flagged access to IDE credential storage. The environment-variable code smells sit only in the low bucket and name no target file.

The one high-severity match

YARA--CAP_HookExKeylogger fired at gradle-plugin/lib/gradle-api-9.6.0.jar. The path matters. That is Gradle's own published API jar, bundled into the plugin's lib directory, and the signature is a capability rule from a public rule set: it describes Windows API imports a keylogging family has used. Gradle's console and input handling code exercises similar APIs, which is enough for this rule to fire.

Supply chain signals

Nothing points at impersonation. The publisher account is JetBrains, the listing is the official JetBrains Marketplace entry, and the user count fits a first-party plugin. No tool-poisoning, obfuscation or dependency findings were recorded. The bundled gradle-api-9.6.0.jar follows Gradle's own release numbering, which is what a genuine integration looks like.

Counterargument

The case for treating this as more than noise is that a keylogger signature is specific. Someone wrote it for a reason, and it is the only high-severity hit here. What weakens that case: the match site is a bundled artifact published by the Gradle project, the extension's own code is not where the signature landed, and a keystroke capture tool needs a sink. Nothing here transmits. No network endpoint is recorded, no persistence or startup-modification finding exists, and no write outside the project directory is described. A jar sitting in a build tool's library folder with no outbound route is not a working keylogger.

Key Reasons

• Single high-severity hit (YARA--CAP_HookExKeylogger) is located in gradle-api-9.6.0.jar, a bundled artifact published by the Gradle project rather than extension-authored code
• No network endpoints, IoC hits, obfuscation, tool-poisoning or secret-access findings were recorded for the extension
• 149 low-severity code-smell findings are process-spawning and environment-variable patterns expected from a build-tool integration
• Verified first-party JetBrains publisher on the JetBrains Marketplace with 692,748 users on version 262.10968.148, with no typosquat or impersonation signals
• No persistence, startup modification or outbound data path exists to support an actual keylogging payload

False Positive Considerations

• CAP_ capability rule firing on Gradle's own bundled API jar instead of extension code
• Broad code-smell rules matching standard Java subprocess and environment-variable usage
• Zero corroborating network, exfiltration or persistence findings alongside the signature
• Signature attributed to a third-party published dependency rather than the plugin's own binaries

Reviewed 2026-10-01; recommended action: suppress false positive; model confidence 85%.