The security ecosystem is packed with tools—frameworks, scanners, helpers, and one-off scripts for almost every imaginable task. And yet, many of the most effective solutions still start the same way:

“I guess I’ll just build it myself.”

In this workshop, Senior Security Analyst Tom Hudson explores the practical realities of building your own security tooling focusing on decision-making first, code second.

This isn’t about building tools for the sake of it. It’s about knowing when it’s worth the effort, when existing tools are the better choice, and how to build something useful without overengineering or burning time.

Session Summary:

Tom Hudson walks through a practical framework for deciding why and when to build security tools, emphasizing that tools are capability amplifiers and that “reinventing the wheel” is often appropriate when you need a specialized fit, tighter control, or faster iteration. He advocates for a pragmatic, iterative approach: start with a real problem, build the simplest viable solution, and refine as you learn—favoring “Iron Man” tools that augment human operators over “Ultron” tools that try to replace them. Using the Unix philosophy (small composable programs connected via stdin/stdout) and pragmatic interfaces like plain text or JSON Lines, he live-codes two small Go utilities that chain together to find reflected parameters and expand URL parameter coverage across hosts, demonstrating how quick, modular tools can unlock real workflow leverage.

Key Takeaways:

1. Start with a problem, not a tool idea: the best tools are born from a concrete pain point (speed, control, visibility, repeatability).
2. “Don’t reinvent the wheel” is overapplied: specialized “wheels” are common in real industries—building a custom tool is often the right move.
3. Build the simplest thing that works (and iterate later): avoid “world’s best tool” traps; YAGNI applies hard in tooling.
4. Prefer augmentation over replacement: design tools that keep the human in the driver’s seat for accountability, observability, and creativity.
5. Compose small tools via stdin/stdout: the Unix style enables chaining tools written by different people (or past-you) into workflows greater than the sum of parts.
6. Use pragmatic interfaces: plain text is great; when structure matters, JSON Lines is a solid middle ground.
7. Language choice is secondary to fluency: use what you know best; Go can be great for CLI tooling due to distribution and standard library, but bash/Python/etc. absolutely “count.”