Assertive

AI Security Review

Evidence context: threat category none; evidence quality moderate.

Assertive is a JetBrains marketplace plugin published by the account assertive, version 2025.05.1-SNAPSHOT, with roughly 220 installs. The build scan returned 2,249 items, and nearly all of them land in two buckets that carry no weight: 1,842 IoC entries and 262 code-smell matches. One high-severity item sits apart from those, and it is the only thing worth examining.

Filesystem and process access. The build is a Jar collection. The one file path tied to a real finding is lib/jna-platform-5.5.0.jar, the JNA Platform library, which exists to bind Java methods to native operating system calls. That is the standard mechanism JetBrains plugins use for hotkeys, window focus and desktop integration. There are no manifest-analysis findings, no dependency findings, and the package metadata declares no host permissions. Native binding inside an IDE plugin is the tool doing its job.

Credential access. The secret category is empty. Nothing in this build reads .env files, .ssh material, or a credential store, and no finding targets JetBrains or VS Code secret storage. The strings in the endpoint list that look like they might be hosts are not hosts at all, as covered below.

Network. The endpoint list is extractor output rather than a server inventory. Entries such as 0c.by, 0m.dj, 0ۯ.gg and 2ԉ.me are two-character strings, several with non-Latin characters mixed in, which is how hex or base64 fragments inside compiled bytecode get read as hostnames. The network category recorded zero findings of its own, meaning no finding tied a live call to any of these strings.

The counterargument. YARA--CAP_HookExKeylogger, high severity, matched inside lib/jna-platform-5.5.0.jar. If that rule had fired on plugin code, it would describe a Windows keyboard hook, which is precisely how a keylogger collects keystrokes, and that would justify escalation to a confirmed credential-theft finding. It fired on JNA Platform instead. JNA Platform ships with the IntelliJ Platform and with any plugin that talks to Win32, and its class files contain the declarations the rule looks for (SetWindowsHookEx, WH_KEYBOARD_LL, KBDLLHOOKSTRUCT) as named method bindings. A signature written for hook-installing code matches a library that only names the API. Nothing else in the build corroborates it: no obfuscation findings, no exfiltration endpoint, no credential reads, and no process-spawn anomalies.

Residual unknowns. The published version is a SNAPSHOT, the publisher has a single plugin, and the install count is small, so there is little history to compare against. That gap does not turn an API declaration into a keylogger, but it is the reason this is not a clean bill of health on provenance alone.

Key Reasons

• The single high-severity match, YARA--CAP_HookExKeylogger, fired on lib/jna-platform-5.5.0.jar, the JNA Platform native-binding library bundled with the IntelliJ Platform, not on plugin code
• The 1,842 IoC entries are two-character fragments and mixed-script strings such as 0c.by, 0m.dj and 2ԉ.me, and the network category recorded zero findings
• No secret-category findings: nothing reads .env files, SSH keys or credential stores
• No manifest-analysis, dependency or obfuscation findings anywhere in the build
• The 262 code-smell matches are low-severity rule noise on compiled Java, which does not drive a verdict

False Positive Considerations

• Generic YARA rule (CAP_HookExKeylogger) matching Win32 API declarations inside the bundled jna-platform jar
• IoC extractor reading hex and base64 fragments in compiled bytecode as hostnames, producing 1,842 bogus endpoints
• Low-severity code-smell rules firing across bundled third-party libraries
• JetBrains plugins bundle the platform's own library set, so native-binding artifacts appear in every such package

Reviewed 2026-09-30; recommended action: suppress false positive; model confidence 85%.