Prism X puts asset discovery, weak password checks and PoC verification in one Go binary

One binary for discovery, fingerprinting and vulnerability confirmation

The project's own summary is unusually direct about what the tool claims: Prism X integrates asset discovery, fingerprint recognition, weak password detection and vulnerability verification, using a modular YAML plugin strategy configuration to reach a PoC verification mechanism similar to real attack chains. That last phrase describes the design goal that separates it from a pure port scanner. Instead of reporting that a service looks vulnerable, the scan tries to confirm the flaw.

The audience is the enterprise security team: the README describes it as an automated enterprise network security risk detection and vulnerability scanning tool, and the topic list for the repository names scanner families that security teams already know by reputation. The intended user has a network range and needs to know what is exposed on it, what those hosts are, and whether the known issues are real.

The project ships as a Go program. The module in go.mod is named prismx_cli, the primary language is Go, and the repository even contains a compiled prismx_cli.exe next to the source, which tells you the audience includes Windows operators who want a binary they can run without a toolchain. A Chinese README sits alongside the English one, so the project is maintained with both audiences in mind.

YAML plugin strategies are where the checks are defined

The plugin approach is the part of the design that scales. The core package contains a plugins directory described as a plugin registration center and plugin files, and the strategy configuration is YAML. A check is therefore data, and the plugin registry is where that data is wired into the scanner.

This has a practical consequence for the operator. Adding or adjusting a check does not require recompiling, which is exactly what you want in a tool whose plugins encode the vendor specific knowledge that changes weekly. The same design also means the quality of a scan is the quality of the plugin set, which is not visible from the binary alone.

The build note confirms the plugin ecosystem sits on top of the core rather than being compiled in: the plugin registration center is one package among several in core/, alongside the detection modules and the models package that holds dependencies for public modules. The README also links a separate port fingerprint recognition framework, yqcs/fingerscan, which is the part of the system responsible for identifying what is running on an open port.

The command line is a set of switches with explicit defaults

Everything Prism X does is driven from one binary with a flat set of flags. The usage block below is the complete option list as printed by the program:

Usage of prismx_cli.exe:

  -t  string
        Target hosts to scan, supporting formats like 192.168.1.1/24, 16, 8, 192.168.3.1-80, prismx.io, separated by commas.
  -p  string
        Ports to scan, supporting formats like 80,22,8000-8080.
  -bip  string
        Filter hosts, supporting IP ranges.
  -bp  string
        Filter ports, supporting port ranges.
  -m  string
        Scan speed, options: s (slow), d (medium), f (fast). Default is "d".
  -ping  boolean
        ICMP packets may not be sent under low privileges. Default is -ping=false.

Read that carefully and it tells you how the tool thinks. Targets are ranges, individual addresses or domain names, and commas separate several of them. Ports accept ranges as well as lists. Separate filter flags for hosts and ports let you narrow an already discovered set without losing the rest of the scan, which matters when a first pass finds more than you expected. Speed is a single choice between slow, medium and fast with medium as the default, so the rate of scanning is an explicit operational decision rather than a fixed constant.

Two flags deserve a note. ICMP may not be sent under low privileges, which is why -ping defaults to false. And -pn skips host survival detection entirely, which is the flag to reach for when you already know the hosts are up and want the scan to spend its time on services.

Inside core: aliveCheck, hydra, jsFind and an owaspTop10 that is not finished

The source tree documents the architecture better than any prose would. core/ holds aliveCheck for host and port survival detection, hydra for weak password detection, jsFind for detecting sensitive content in JavaScript files, owaspTop10 for tools that detect XSS and SQL injection, plugins for registration, subdomain for subdomain scanning, vulnerability for vulnerability detection, and models for dependencies of public modules.

The scan/ directory is the task scheduling center, and utils/ handles the task list and creating a new task. main.go is the entry point. That layout describes a scanner that fans a set of specialized modules out over a queue of targets, which is why a speed flag makes sense.

Now the honest part. The README annotates owaspTop10 with the note that it is not completed yet and needs further optimization. Those two words carry the most weight in the whole tree, because OWASP Top 10 checks are the part most teams would sign up for. Anyone evaluating Prism X should treat the web application layer as the least finished area of the project, and the jsFind module, which hunts for sensitive content in JavaScript files, is the more mature half of that story.

The dependency list in go.mod also hints at the breadth of protocols involved: MySQL, PostgreSQL and SQL Server drivers, Redis, FTP, SMB, WinRM and DNS libraries are all present, alongside HTTP crawling, raw packet handling and certificate parsing.

Building from source, and the Go version advice that comes with it

The build section gives one tip and one command. The tip is to use Golang version 1.20 for compilation, and the reason given is that newer versions of Go no longer support Windows 7 and earlier versions. The command is a stripped, position independent build with the symbol table and build id removed:

  go build -ldflags "-s -w   -buildid=" -buildmode="pie"  -trimpath

Those flags do three things at once. Stripping symbols and the build id shrinks the binary, which is what you want for a scanner that gets copied around internal networks. Building as pie produces a position independent executable, and trimming the path removes local filesystem paths from the output. For a tool that is distributed to operators, these are sensible choices rather than cosmetic ones.

The version advice is where the friction lies. go.mod declares go 1.26.2 for the module itself, so the project is written against a recent Go release, while the README asks you to compile with 1.20 for Windows 7 targets. That gap is a real constraint for anyone building on an older Windows fleet, and it is worth resolving on your own build machines rather than discovering it during a rollout.

JNDI support and the two scanners it covers differently

Two design decisions set Prism X apart from a generic port scanner, and both are visible in the README rather than inferred.

The first is the built in JNDI external link service. The README explains that it supports scanning of vulnerabilities that require external connections, such as JNDI and RMI. Some deserialization and lookup style flaws can only be confirmed when the target is able to reach out and the scanner can observe or receive that callback. A scanner without an external endpoint can detect such a flaw but cannot demonstrate it, so this feature turns a heuristic finding into a confirmed one.

The second is that port fingerprinting is delegated. Rather than keeping the service identification inside core, the project points at yqcs/fingerscan as its port fingerprint recognition framework. That is a deliberate split: the identification database changes on a different cycle from the scanning logic, and keeping it in another repository means the scanner core does not need to be rebuilt when fingerprints are updated.

Both choices point the same way. Prism X is built around producing evidence about a specific target rather than producing a broad list of possible matches.

What Prism X costs you, and where it falls short

The obvious alternative to a bundled scanner is a small pipeline of separate specialized tools, each with its own strengths, orchestrated by a script or a CI job. The difference in approach is real and it cuts both ways. A pipeline can use the best tool for each job and upgrade each one independently, and it gives you per tool reports that mature projects have already refined. Prism X instead gives you a single consistent view of a network, one configuration format, one place where a new check has to be added, and a shared notion of what a target and a port are.

The cost is that you inherit the weakest module in the tree. The unfinished owaspTop10 module is the clearest example: in a pipeline you would substitute a different scanner for that job, while here you either wait or you write the plugin yourself.

There are other limits. The README does not document a configuration file format for the YAML strategies in any detail, does not describe how results are stored or reported, and says nothing about scheduling, authentication or integrating with a ticketing system. The repository carries a compiled prismx_cli.exe and an .idea/ directory, so a binary is committed rather than distributed through a package channel, and the README links a customized commercial edition at prismx.io while the repository itself has no homepage of its own. For a security tool, the gap between what the docs cover and what an enterprise deployment needs is the thing to measure before you commit.

Release history: an open source v1.5 followed by a quiet stretch

The license is Apache-2.0, with the copy in the LICENSE file at the repository root. The project is not archived, and the last push was on 2026-06-17, which is inside the six month window that keeps the code moving but also leaves a visible gap since the last recorded release.

The release list is short. v1.5.0, tagged as the OpenSource v1.5.0 release, is dated 2026-05-05, and before it there is a release named latest from 2024-07-29. The version label in the README header also reads Open Source v1.5, so v1.5.0 is the current published state of the open source code.

Read together, those dates describe a project whose open source line moves in larger steps than its commit history suggests. The code tree receives pushes after the release, but a release tag is what gives you a version to pin, to test against and to cite in a scan report. For a security tool that is the artifact that matters, so plan your upgrades around the v1.5.0 tag rather than around the commit log.

Editorial conclusion

Prism X fits security teams that want one Go binary that enumerates assets, fingerprints ports and verifies vulnerabilities through YAML plugin strategies, and it does not fit an environment that needs a hardened, fully finished vulnerability engine, since the owaspTop10 module is marked unfinished and the build notes recommend Go 1.20; before deploying it, confirm that the plugins/ directory holds the checks you rely on and that your target ranges stay inside authorized scopes.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. yqcs/prismx on GitHub