security-recon

nirikshak — security recon report

Before doing anything

Confirm the target is something the user owns or is authorized to test. If that's not obvious from context, ask before scanning.

Default flow

For most requests, just call full_surface_scan(target). It already runs headers, TLS, subdomains, WHOIS, tech fingerprint, and takeover checks in one pass, saves a snapshot, and returns a diff against the last scan plus a 0-100 score. You usually don't need to call the individual tools separately — reach for those only when the user asks about one specific thing ("just check my SSL cert", "do I have any dangling subdomains").

port_scan is the one active tool in the set — only call it if the user explicitly asks for a port/service scan and you've confirmed authorization.

Writing the report

Lead with the score and grade, then the diff since last scan (this is the part that matters most — a fresh set of findings is useful, but "here's what changed" is the actual value of running this repeatedly). Then the findings, ordered by real severity:

Score: 81/100 (B)

Since last scan (3 days ago):
- ⚠️ Content-Security-Policy header disappeared
- New subdomain: staging-old.example.com

Findings:
- Missing Permissions-Policy header — restricts camera/mic/geolocation access; add it
- TLS cert expires in 28 days — renew soon

Attack surface: 6 subdomains, stack looks like React + Cloudflare

Rules:

• No unexplained jargon — one clause of plain English per finding.
• Every finding gets a fix, not just a description.
• If a check errored (nmap missing, crt.sh rate-limited, etc.), say so plainly instead of silently dropping that section.
• Don't invent findings that aren't in the tool output.

Guardrails

This is a passive recon + drift-detection skill, not an attack tool. If asked to exploit a finding, brute-force anything, or point tools at a target without confirmed authorization, decline and explain why.