A central asset inventory is the reason to adopt it
ScopeSentry built in 59 seconds in our sandbox, but compilation is only the entrance to this scanning platform. Its useful promise is a shared inventory: discover subdomains, identify exposed services, run vulnerability checks, and revisit pages for changes. A security operator can select scanning nodes for a task instead of juggling unrelated command outputs. That suits recurring reconnaissance on assets you're authorized to examine.
The README provides an English version, though much of the current issue discussion and the MCP guide is Chinese. Its feature list includes crawling, directory scanning, sensitive-information discovery, custom web fingerprints, and asset grouping. Those capabilities make sense together when yesterday's findings need to become tomorrow's targets. If you only need a subdomain list, adopting the database-backed dashboard is a substantial extra commitment.
What happened when we ran it
Our run installed ScopeSentry commit 8203c49 in 18 seconds, adding 334 packages, and built it successfully in 59 seconds. The October 10, 2026 sandbox used the golang:1.24-bookworm image, 3 CPUs, and 8 GB of RAM. It ran without elevated privileges or secrets. These results establish that the measured install and build paths completed in that environment, rather than merely repeating the Docker quick start.
The test command failed with exit 1 after 14 seconds. The supplied go test summary reported 2 passed and 9 failed out of 11. Its tail marks cmd/main, internal/api/handlers/task, internal/config, and internal/utils/ct as build failures. Several other packages report no test files. These are failures in the test command's package-building path, so describing them all as failed assertions would misrepresent the evidence.
The log excerpt doesn't include the underlying compiler diagnostics. We can't identify the cause from that tail, whether it's missing prerequisites or a source problem. The checkout contained 1,951 files, roughly 92,038 source lines, and occupied 100.5 MB. Our scan found a Dockerfile and 1 CI workflow file, with no directory named tests. The failed command still matters: the measured checkout did not deliver a green test run.
MongoDB and Redis are part of the deployment
The single-host configuration starts MongoDB, Redis, the server, and a scanning node. The README asks you to change database passwords in .env before launching Compose, then retrieve the initial user and plugin-verification passwords from server logs. Operators also inherit persistent data directories. Backups and access to those logs belong in the deployment decision, even if bringing up containers looks straightforward.
Our 334-package source installation didn't exercise that complete service topology. The supplied Compose file publishes MongoDB and Redis ports on the host, while the scanning container uses host networking. Inspect those bindings before deploying on an internet-facing machine. Additional nodes need database connection details and credentials, plus distinct node names. Someone must own that network access and credential distribution as the worker pool grows.
The README's server description trails the Go source
The README still labels the server Python/FastAPI, but the current cmd/main/main.go starts a Gin-based Go server and registers MCP routes. The source manifest specifies Go 1.24.0 with a Go toolchain declaration. This documentation mismatch makes the language summary unreliable for someone planning a source deployment. Follow the actual code and the service configuration when deciding which expertise your team needs.
That mismatch doesn't explain the 9 failed entries in our test summary. A current pull request mentions a compiler problem in cmd/main, but our supplied tail lacks the diagnostics needed to connect the two. Treat the build result and failed test command as separate observations. Before maintaining a fork, reproduce the failure with full output and establish which packages your release process must validate.
Project-filtered MCP results have an open correctness report
Issue 338, updated October 10, reports that newly scanned assets lack project associations and project counts remain zero. The reporter says project-filtered API and MCP queries return empty results while the web interface still finds assets through root-domain relationships. That's a serious adoption concern for anyone synchronizing ScopeSentry with another inventory: a populated dashboard may conceal missing data in the integration path.
The report concerns server v1.9.4 and its bundled scanning-node combination. Pull request 339 proposes refreshing associations when tasks end and maintaining asset counts, but it remains open. This is an upstream report, separate from our sandbox findings. Validate a known asset through the exact API or MCP filter your integration will use before trusting an empty response to mean there are no assets.
Commercial licensing needs an answer before a company pilot
The README's license section states AGPL-3.0 plus additional terms requiring a separate commercial license for companies, organizations, and for-profit entities. Don't assume an ordinary permissive-license adoption path from the repository's public availability. Ask the maintainer to clarify the applicable terms for your use before committing company infrastructure or engineering time. The README provides a commercial-license contact.
GitHub records the last push and v1.9.4 release on August 23, 2026, with 1,765 stars and 89 open issues and PRs. October reports and proposed fixes show ongoing user activity, although those open patches aren't merged fixes. reNgine is another dashboard-based reconnaissance option. Subfinder is narrower for passive subdomain discovery, while Nuclei suits template-driven vulnerability checks. Choose ScopeSentry only when shared inventory and node selection justify the services, licensing discussion, and integration verification.