Detectify

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build the external monitoring I actually need instead of Detectify — with the limit understood.

**You cannot replicate the check library.** It comes from researchers finding new bugs continuously, and that is the product. What you can build is the surface monitoring, which is where most of the real findings come from anyway.

STACK
- Node 20+ with Fastify, server-rendered HTML
- SQLite through better-sqlite3, WAL mode
- Established open scanners as the engines — do not write your own detection logic
- Caddy in front

THE DATA MODEL
- assets: id, kind, value, first_seen, last_seen, source — domains, subdomains, IPs, ports, certificates
- scans: id, asset_id, tool, started_at, finished_at, raw_path
- findings: id, asset_id, scan_id, code, severity, detail_json, first_seen, last_seen, status, triaged_by
- changes: id, asset_id, field, before, after, at — **append-only, and this is the actual product**

SURFACE DISCOVERY, WHICH FINDS MORE THAN SCANNING DOES
- Certificate transparency logs: every certificate issued for your domain is public, and it is the best subdomain source there is
- DNS enumeration against your own zones, plus passive sources
- Port and service identification on what you find
- **The finding that matters is almost always 'something new appeared'**: a staging environment exposed, an old subdomain still pointing at a decommissioned service, an admin panel on a port somebody opened. Not a subtle injection

THE CHECKS WORTH RUNNING
- Dangling DNS records pointing at services you no longer own — subdomain takeover, the highest-value finding in this whole category and cheap to detect
- Certificates expiring, and certificates issued that you did not expect
- Exposed administrative interfaces, default credentials, directory listings, exposed .git or .env
- Security headers and TLS configuration
- Known vulnerable versions from banners, via an existing template library rather than your own

STAYING LEGAL AND SAFE
- **Scan only what you own or have written permission to scan.** Keep an explicit scope list and refuse anything outside it in the code, not in a policy document
- Rate limit hard. A scanner is a load test nobody asked for
- Never run an exploit check that changes state

TRIAGE, OR YOU WILL STOP READING IT
- Findings deduplicated and carried across scans by a stable key, so a known issue does not reappear as new every night
- **Alert only on a new finding or on a change**, never on the full list. A nightly email of two hundred known issues is an email that gets filtered
- An accepted-risk status with an expiry date, so accepting something is not the same as forgetting it

WHAT MATTERS MOST
Certificate transparency monitoring and dangling DNS detection. Those two find the real incidents, and neither needs a research team.