Inspiration
The idea for ScanTrace came from a common IT problem: another "I can't connect to the VPN" ticket <3. While troubleshooting, I noticed something more interesting than vague log entries—the firewall was being hammered by credential-spraying attacks from constantly changing IP addresses.
The firewall only generates alerts when multiple attempts come from the same source. The vendor's recommendation was essentially, "Here's our blacklist." But blacklists are always reactive and always stale.
That led to a simple question:
What if we could identify reconnaissance and attack patterns before they became incidents?
ScanTrace began as an effort to transform noisy internet scan traffic into actionable intelligence that security teams could actually use.
What it does
Every internet-facing system is continuously scanned by automated tooling—botnets, vulnerability scanners, nation-state reconnaissance platforms, and internet mapping services such as Shodan and Censys.
Security teams typically face two poor choices:
Ignore the noise and risk missing meaningful reconnaissance activity. Drown in raw telemetry by exporting logs into SIEMs, writing detection rules, and maintaining dashboards outside their normal workflow.
Neither approach creates evidence-quality investigations that can be escalated, shared, or reported.
ScanTrace bridges the gap between raw scan telemetry and actionable threat intelligence by transforming scanning activity into evidence-backed investigations directly inside Slack. Instead of reviewing thousands of disconnected log entries, analysts receive aggregated events, enriched context, and case-ready evidence within the platform where they already collaborate.
How I built it.
The short version: persistence, Google, and a lot of learning.
I started this project with no Go experience. After researching suitable languages for high-performance log processing and backend services, I decided to learn Go by building something real rather than following tutorials.
Development took place primarily in VS Code, with a locally hosted LLM helping review code, challenge assumptions, and catch mistakes before they became technical debt. As the project evolved, it grew from a simple log-processing concept into a complete ingestion, enrichment, aggregation, and reporting pipeline.
The result is a lightweight architecture capable of processing scan events, correlating activity, generating evidence records, and delivering findings directly into Slack.
Challenges we ran into
The biggest challenge was learning a new programming language while simultaneously building a security product.
Writing PowerShell scripts and automating administration tasks every day gave me confidence in the framework of what I want to do, how to get there, and things to watch out for. It did not automatically translate into being productive in Go. Learning Go's patterns, concurrency model, package structure, and testing workflows required a lot of trial and error.
Another challenge was determining how to integrate local AI capabilities without turning the project into a resource-hungry science experiment. Finding the right balance between performance, hardware requirements, and useful intelligence generation proved more difficult than expected.
I also had to learn how to use GitHub for more than storing code and dead ideas.
Accomplishments that we're proud of
Successfully built a functioning end-to-end solution in a language I had never used before. Created an effective log aggregation and filtering pipeline that dramatically reduces noise. Generated evidence-oriented investigation records instead of simply displaying alerts. Delivered findings directly into Slack, eliminating the need for analysts to constantly switch tools. Demonstrated that lightweight local AI can enhance security workflows without requiring large cloud infrastructure.
What we learned
One of the biggest lessons was that hardware constraints matter more than model aspirations.
I originally tested with desktop-class LLMs because they were available and convenient. Looking back, it would have been better to start with the lowest-powered hardware I expected customers to deploy and work upward from there.
This project also reinforced that good security tooling is rarely about generating more alerts. It is about producing better context, stronger evidence, and faster decisions.
What's next for ScanTrace
The roadmap focuses on making ScanTrace easier to deploy and applicable to more environments:
Support additional log formats and security data sources. Expand enrichment and correlation capabilities. Optimize for low-resource hardware and edge deployments. Continue evaluating lightweight local LLMs that provide meaningful intelligence without excessive CPU or memory requirements. Improve the user experience and visual design. Open-source more of the project and prepare it for broader public adoption.
The long-term goal is simple:
Help security teams turn internet reconnaissance data into actionable intelligence before an attack becomes an incident.
Log in or sign up for Devpost to join the conversation.