[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f1y7iymu3wficr":3},{"code":4,"message":5,"data":6,"timestamp":42},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":38,"homepage":39,"updated_at":40,"history":41},"Autumn-27\u002FScopeSentry",13,"ScopeSentry-Cyberspace mapping, subdomain enumeration, port scanning, sensitive information discovery, vulnerability scanning, distributed nodes","Go",2126,477,189,971,[],"A self-hosted asset-mapping and vulnerability-scanning platform for security teams who need to run many recon tools against many domains and keep the results in one place.","If you already chain subdomain enumerators, port scanners and directory brute-forcers by hand, ScopeSentry is worth a look: it turns that loose pipeline into scheduled tasks against a persistent asset database. It is a self-hosted scanning platform, not a drop-in replacement for a single CLI tool.\n\n## The problem\n\nThe usual recon workflow is a stack of separate commands: enumerate subdomains, resolve them, scan ports, fingerprint services, fetch URLs, brute-force directories, and then grep the output files for leaks. Each step writes somewhere different, and repeating the scan for a new CVE means re-assembling the whole chain. ScopeSentry changes that step by storing assets in MongoDB and letting a task walk the pipeline, so a fresh scan builds on what you already know about a root domain's subdomains, URLs, ports and services rather than starting from raw files. The result is an asset tree you can search and re-scan instead of a folder of outputs.\n\n## What's different\n\nThe mechanism is a plugin system wrapped around a Python\u002FFastAPI server, a Go scanner and a Vue front end. Modules ship for subdomain enumeration, takeover detection, port scanning, asset identification, directory scanning, vulnerability scanning, sensitive-information detection, URL extraction, crawling and page monitoring, plus custom web fingerprints and POC import. You can add tools through the plugin template and a plugin market rather than committing to only the built-in set. A distributed design lets you register extra scan nodes, so heavier scanning work can run on separate hosts while the server and database stay in one place.\n\nThe practical benefit is that a task can run continuously and feed a shared asset database, which suits recurring checks after a new vulnerability is disclosed. The trade-off is that this is a multi-component system: four containers by default, plus an optional node stack, with MongoDB and Redis beneath it. Getting the data model and scanning results to line up requires reading the official site and plugin docs; it is not a single binary you run and forget.\n\n## Who should try it\n\nThis fits security teams, bug-bounty hunters and internal red teams who repeatedly scope many root domains and want the results to persist and aggregate per project. If you already know which tools you like and just want one more scanner, the platform overhead will not pay off. A smaller alternative that may suit individual users is running the scanner directly from its separate repository rather than deploying the full server, database and UI stack. The choice matters because the default deployment already assumes you can host and maintain MongoDB and Redis.\n\n## Requirements and limitations\n\nThe documented setup is Docker Compose with four containers (MongoDB, Redis, server and one scan node), and you are instructed to change the MongoDB and Redis passwords in the .env file before starting. The initial user and plugin secondary-verification passwords come from the server container logs. Adding nodes means cloning the scanner repo and running its own compose file with matching database connection details and a unique node name; the [project's instructions](https:\u002F\u002Fgithub.com\u002FAutumn-27\u002FScopeSentry\u002Fblob\u002Fmain\u002FREADME.md) and [scanner deployment notes](https:\u002F\u002Fgithub.com\u002FAutumn-27\u002FScopeSentry-Scan) are the places to check before planning a fleet. Weak-password cracking is listed as a to-do, so do not expect it yet, and the README does not describe resource sizing or scan throughput for a given host count.\n\nThe licensing is the biggest practical boundary. The README says all branches follow AGPL-3.0 but add that commercial use requires a separate license, and companies and for-profit entities must obtain one before using, distributing or modifying the software; individuals and non-profits are free under AGPL-3.0. That makes this unsuitable for an unlicensed commercial rollout. The repository also does not declare a license file, so treat the README terms as the governing statement and verify them with the maintainer before internal deployment.\n\n## HotRepo's take\n\nHotRepo's stored coverage contains one dated observation: ScopeSentry ranked #13 on the weekly Go board with +189 stars on 2026-10-25. That is a single weekly snapshot, not a day-by-day series, and there is no comparable daily-board history, so persistence of interest cannot be judged. The project was about 971 days old at that time. Before committing, verify the commercial-license requirements and the current [deployment guide](https:\u002F\u002Fwww.scope-sentry.top\u002F) against your intended infrastructure.",{"slug":19,"name":20},"security","Security & Privacy",[22,23,24,25,26,27,28,29,30,31,19,32,33,34,35,36,37],"bug-bounty","bugbounty","bugbounty-tool","crawler","dirscanner","infosec","osint","pagemonitor","scanner","scope-sentry","security-tools","src","subdomain-enumeration","subdomain-takeovers","urlscan","vulnerability-scanners",null,"https:\u002F\u002Fwww.scope-sentry.top\u002F","2026-10-25T12:17:44Z",[],1792968039]