Weekend Project: Build a Security Tool for Your Own Job
Here's a dirty secret about security operations: half the job is wrestling with data formats, copying things between tools, and building one-off scripts that probably should have been proper tools years ago.
That phishing email analyzer you wish existed? The IOC extractor that actually works with your threat reports? The dashboard that shows exactly what you need without 47 clicks?
You can build those now. In a weekend. Without being a developer.
I've been experimenting with vibe coding for security tooling, and the results have been... honestly kind of life-changing for the small stuff that used to eat hours of my week.
The Tools I've Actually Built
Let me be specific about what's worked:
1. Phishing Email Analyzer
Paste in a suspicious email (headers and all), get an instant breakdown: sender reputation indicators, URL analysis, attachment flags, SPF/DKIM/DMARC alignment issues, and a plain-English summary of why it's suspicious or not.
Time to build: About 3 hours. Most of that was refining the output format.
2. IOC Extractor
Drop in a threat report PDF or paste raw text, extract all indicators: IPs, domains, hashes, file paths, registry keys, MITRE ATT&CK techniques. Output in STIX, CSV, or just a clean list ready to paste into your SIEM.
Time to build: 2 hours for the basic version. Another hour to add the STIX export.
3. Vulnerability Prioritization Calculator
Input CVSS score, asset criticality, exposure level, exploit availability. Get a risk score that actually reflects your environment, not just the raw CVSS number. Includes reasoning for the score so you can explain it to leadership.
Time to build: 90 minutes. The hardest part was deciding on the weighting formula, not the code.
4. Log Query Generator
Describe what you're looking for in plain English ("show me all failed login attempts from external IPs in the last 24 hours"), get the Splunk SPL or KQL query. Saves me from constantly Googling syntax I can never remember.
Time to build: 1 hour. This one felt like cheating.
Why Security Tools Are Perfect for Vibe Coding
There's a pattern here that makes security tooling particularly well-suited to AI-assisted development:
The logic is well-documented. How to parse email headers, what makes an IOC valid, how CVSS scoring works... this stuff is public knowledge. The AI has seen thousands of examples of how to do it correctly.
The stakes are appropriate. These are internal tools for your own use. If the phishing analyzer misses something, you're still going to review the email yourself. If the IOC extractor formats something wrong, you'll catch it when you paste it into your SIEM. The human is still in the loop.
The alternative is worse. The choice isn't "vibe-coded tool vs. professionally engineered tool." It's "vibe-coded tool vs. doing this manually forever" or "vibe-coded tool vs. never having this capability at all."
You know the domain. This is critical. You understand what correct output looks like. You can immediately tell if the tool is producing garbage or gold. That domain expertise is what makes vibe coding work.
The Security Angle on Vibe-Coded Security Tools (Yes, Really)
I'd be a hypocrite if I didn't address this: vibe-coded applications have real security issues.
Palo Alto's Unit 42 just released a whole framework (SHIELD) for securing vibe-coded apps. The research shows about 25% of AI-generated code has security flaws. Hardcoded credentials, missing input validation, broken authentication... the usual suspects.
Here's how I think about it for internal security tools:
Don't put secrets in the code. Use environment variables or a secrets manager. Every time. No exceptions. This is the most common failure mode.
Assume the input is hostile. Even if it's "just" an internal tool, treat user input like it's coming from an attacker. The AI will often skip input validation unless you specifically ask for it.
Run it isolated. My phishing analyzer runs in a container with no network access to production systems. If something goes wrong, the blast radius is contained.
Review the authentication logic yourself. If your tool has any kind of access control, read that code manually. Don't trust the AI got it right. This is the one area where I break the "don't look at the code" rule.
Use it for low-stakes first. Run it alongside your existing process for a week before trusting it. Compare outputs. Build confidence gradually.
The irony isn't lost on me: using potentially insecure AI-generated code to build security tools. But the alternative, for most of us, is continuing to do everything manually or waiting for vendors to build exactly what we need (which they won't).
A Practical Example: The Phishing Analyzer
Let me walk through how I actually built this, because the process is replicable.
Step 1: Define the scope clearly.
"I want a tool where I can paste a raw email (including headers) and get a structured analysis of whether it's likely phishing, with specific indicators called out."
Step 2: List what you want it to check.
- Sender domain vs. reply-to domain mismatch
- SPF/DKIM/DMARC results from headers
- URL reputation (using VirusTotal API)
- Attachment analysis (file type vs. extension mismatch)
- Urgency language patterns
- Impersonation indicators (CEO name in From field, etc.)
Step 3: Specify the output format.
I wanted a JSON object with a risk score, a plain-English summary, and an array of specific findings. This makes it easy to integrate with other tools later.
Step 4: Tell the AI what you want.
I used Claude Code and literally described the above. "Build me a Python script that takes a raw email as input, performs these checks, and outputs this format."
Step 5: Test with known samples.
I ran it against 20 emails I'd already analyzed manually. Compared the outputs. Found a few edge cases where the header parsing was wrong. Asked Claude to fix those specific issues.
Step 6: Add the security guardrails.
I explicitly asked: "Review this code for security vulnerabilities, especially around input handling and any external API calls. Suggest fixes."
Total time: 3 hours. Total lines of code I wrote myself: zero.
What NOT to Build This Way
Some things are not appropriate for weekend vibe coding:
- Anything that touches production data directly
- Tools that make automated decisions without human review
- Anything handling credentials or authentication tokens
- Customer-facing security tools
- Anything you're going to deploy widely across the org
For those, you need proper engineering, code review, security testing, the whole nine yards. Vibe coding is for your personal toolkit, not enterprise deployment.
The Compound Effect
Here's what I didn't expect: these tools compound.
The IOC extractor feeds into a threat intel enrichment script I built. That feeds into a report generator. The phishing analyzer integrates with my email triage workflow.
Each tool is simple. Together, they've probably saved me 5-6 hours a week on tasks that used to be pure manual drudgery.
And because I built them, they work exactly the way I think about these problems. No vendor assumptions about my workflow. No features I don't need. No missing features I desperately want.
Try It This Weekend
Pick one pain point in your daily workflow. Something you do manually that feels automatable. Something annoying but not critical.
Open Claude or ChatGPT or Cursor. Describe what you want. See what comes out.
The barrier to building your own tools just dropped to nearly zero. The question is whether you're going to take advantage of that or keep doing things the hard way.
What security tools have you built with AI assistance? I'm collecting ideas for what to tackle next. The weirder and more niche, the better.