I built this after running into the same issue with Nmap: once scans get larger, the bottleneck isn’t collecting data, it’s figuring out what actually matters.
This is a small, dependency-free approach: a single XSLT that turns Nmap XML into an interactive HTML report using xsltproc.
The focus is on triage rather than listing everything:
* highlighting unusual hosts based on service rarity
* grouping services by version to spot drift
* simple views to make patterns easier to see
Curious how others handle post-scan triage, especially in constrained environments
Are you focusing more on static analysis or runtime checks?
In my experience a lot of Django issues only show up once config + environment are combined (middleware, reverse proxy headers, etc.), so curious how far you can get without execution context.
Interesting—what’s the failure mode compared to tmux/screen?
With tmux I mostly rely on the server-side persistence, so even if my client drops completely I can just reattach. Are you maintaining state client-side, or is there still something running server-side to keep sessions alive?
This is a small, dependency-free approach: a single XSLT that turns Nmap XML into an interactive HTML report using xsltproc.
The focus is on triage rather than listing everything: * highlighting unusual hosts based on service rarity * grouping services by version to spot drift * simple views to make patterns easier to see
Curious how others handle post-scan triage, especially in constrained environments