Building Security Tools

The release build

The headline feature is the build itself. One command produces a small, static, portable binary:

# Static (no libc), stripped (-s -w), reproducible (-trimpath), for Linux/amd64.
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
  go build -ldflags='-s -w' -trimpath -o scanner ./cmd/scanner

# Same source, a Windows build from the same machine:
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 \
  go build -ldflags='-s -w' -trimpath -o scanner.exe ./cmd/scanner

• CGO_ENABLED=0 — no C, so the binary is static and cross-compiles cleanly.
• -ldflags='-s -w' — drop the symbol table and DWARF debug info; a noticeably smaller binary.
• -trimpath — strip your local filesystem paths out of the binary (privacy and reproducibility).

The anatomy of a tool

Most scanners and recon tools share the same shape. Build it once and reuse it:

graph TD
CLI["flags / config<br/>(targets, rate, scope)"] --> SCOPE["scope guard<br/>(authorized only)"]
SCOPE --> JOBS["jobs channel"]
JOBS --> POOL["worker pool<br/>(bounded N)"]
POOL --> RL["rate limiter<br/>(req/sec)"]
RL --> PROBE["the probe<br/>(scan / fetch / fuzz)"]
PROBE --> RESULTS["results channel"]
RESULTS --> LOG["structured log<br/>+ report (JSON)"]

The only part that changes between a port scanner, a subdomain enumerator, and a web fuzzer is the probe. Everything else — bounded concurrency, rate limiting, scope checks, logging — is shared infrastructure.

See it: the reusable scanner skeleton

A fixed worker pool drains a jobs channel, a rate limiter (a ticker here) caps the pace, and results come back deterministically sorted. Swap the body of probe and you have a different tool. This runs here — the “probe” is simulated so it works without a network:

package main

import (
"fmt"
"sort"
"sync"
"time"
)

type result struct {
target string
open   bool
}

// probe is the ONLY part that changes per tool. Here it's simulated:
// pretend even-numbered targets are "open".
func probe(target int) result {
return result{target: fmt.Sprintf("10.0.0.%d", target), open: target%2 == 0}
}

func main() {
const workers = 8
jobs := make(chan int)
out := make(chan result)

// Rate limit: at most one probe per tick (kept short for the demo).
tick := time.NewTicker(time.Millisecond)
defer tick.Stop()

var wg sync.WaitGroup
for i := 0; i < workers; i++ {
	wg.Add(1)
	go func() {
		defer wg.Done()
		for t := range jobs {
			<-tick.C // pace ourselves — never hammer a target
			out <- probe(t)
		}
	}()
}

// Feed jobs, then close so workers finish.
go func() {
	for t := 1; t <= 12; t++ {
		jobs <- t
	}
	close(jobs)
}()
// Close results once all workers are done.
go func() { wg.Wait(); close(out) }()

var open []string
for r := range out {
	if r.open {
		open = append(open, r.target)
	}
}
sort.Strings(open) // deterministic report
fmt.Printf("found %d open:\n", len(open))
for _, t := range open {
	fmt.Println("  ", t)
}
}

That worker-pool-plus-rate-limiter is the backbone of every scanner in this track. The port scanning page fills in a real probe; worker pool and rate limiting cover the pattern in depth.

Embedding assets and logging actions

Two finishing touches make a tool field-ready:

import _ "embed"

//go:embed wordlists/subdomains.txt
var subdomains string // baked into the binary at compile time

go:embed keeps the drop-and-run promise: wordlists, payload templates, or a pinned CA certificate travel inside the binary. And for authorized work, log every action with slog in JSON so you have a timestamped, queryable record for the engagement report:

slog.Info("probe", "target", t, "port", p, "result", "open", "ts", time.Now())

See also

• Port scanning — the skeleton above with a real probe.
• Worker pool & rate limiting — the concurrency backbone.
• Structured logging — slog for auditable action logs.
• Secrets management — keeping API keys out of the binary and the repo.

Next: the canonical first tool — port scanning.

Related topics