Why I'm building my own security tool

Lately it feels like every week brings another headline about a breach, a leaked credential, or a supply-chain attack. Since AI-assisted development took off, the amount of software being shipped has exploded — and with it, the amount of software being shipped with holes in it. Code gets written faster than it gets reviewed, dependencies get pulled in by the dozen, and secrets end up in git history because nobody was watching that one convenience commit at 17:55 on a Friday.

Reading those articles did something to me. I've always been drawn to the security side of this field — it's the part of software development where the stakes feel real. But every time I tried to bring security tooling into day-to-day development work, I ran into the same feeling: the existing tools never felt quite complete. Each one does its own trick well, but none of them tell you the thing you actually want to know: is this release safe to ship?

That itch grew into a project. I'm building my own tool — one that helps development teams feel genuinely secure about releasing their software, instead of just having "a scanner somewhere in the pipeline" and hoping for the best.

The building blocks: what's already out there

To be clear: there is excellent open-source scanning tooling available today, and I use it daily. The problem isn't the scanners — it's everything around them. Here's the landscape as I see it, and what each piece actually does:

gitleaks — secrets detection

Gitleaks scans your repository — including its full git history — for secrets: API keys, tokens, passwords, private keys. This is the one I'd run first on any codebase, because a leaked credential is the shortest possible path from "repository" to "incident". It's fast, it has sensible built-in rules, and it will absolutely find that AWS key someone committed three years ago and "removed" in the next commit. (Removed from the working tree. Not from history. It's still there.)

Trivy — dependencies, containers, and misconfigurations

Trivy looks at what your software is built from: it scans your dependency lockfiles and container images for known vulnerabilities (CVEs), and it can also flag infrastructure-as-code misconfigurations. Modern applications are mostly other people's code — your composer.lock or package-lock.json is a bigger attack surface than anything you wrote yourself this sprint. Trivy tells you which of those inherited parts have known problems and whether a fixed version exists.

Semgrep — static analysis of your own code

Semgrep covers the third angle: the code you actually wrote. It's a static analysis tool (SAST) that pattern-matches your source against rules for injection flaws, unsafe deserialization, path traversal, weak crypto usage, and so on. Unlike older enterprise SAST tools that take an hour and produce a 400-page PDF, Semgrep is quick enough to run on every push and its rules are readable enough that you can understand why something was flagged.

So what's missing?

Run all three and you've covered secrets, dependencies, and your own code. Sounds complete, right? In practice, this is where teams get stuck:

• Three tools, three output formats, three exit codes. Nobody on the team reads three reports per pipeline run. Realistically, nobody reads one.
• Noise kills adoption. The first run on a real codebase produces hundreds of findings. The team turns the pipeline red for a week, then someone sets it to || true and the tool is dead — still running, telling no one anything.
• No verdict. Findings are not decisions. A team about to release doesn't need a list of 340 issues; it needs to know which five actually matter for this release, and whether any of them should block it.
• Security stays someone else's job. When results live in a tool only one person understands, developers never build the habit of owning them.

The scanners are fine. The experience around them is incomplete. That's the gap I'm building for.

The project

PenShield sits on top of proven scanners instead of reinventing them. The idea, in one sentence: one pipeline step in, one honest answer out — "here's what stands between you and a safe release."

The principles I'm building it around, all learned the hard way:

• One report, not three. All findings normalized, deduplicated, and merged into a single view a developer actually reads — grouped by what to do about them, not by which scanner happened to find them.
• Warn first, block later. New teams start in warn-only mode. You see everything but nothing fails the build, so adoption doesn't start with a week of red pipelines and resentment. Blocking is something you grow into, per rule, at your own pace.
• A baseline, so old debt doesn't drown new problems. Existing findings get acknowledged and tracked; the pipeline gets loud about new ones. The question on every merge request becomes "did this change make things worse?" — which is a question a team can actually act on.
• A release verdict. Not a wall of severities, but a clear answer: these findings are release-blocking, these should be planned, these are noise we've suppressed with a reason attached.

PenShield is a personal project, born from personal interest — not something I’m building for an employer. I’ve been proving the approach on real pipelines and real, messy codebases: running gitleaks, Trivy, and Semgrep side by side, warn-only first, exactly as described above. That hands-on experience is shaping what PenShield automates: everything I currently glue together by hand.

What's next

The plan is to launch an open test phase later this year. I want it in the hands of real teams with real, messy codebases — not demo repos — because the whole point of the project is surviving contact with actual development practice.

If you run a team that ships software and has ever quietly disabled a security scanner because it was more annoying than helpful: you're exactly who I'm building this for, and I'd love to have you in the test phase. Keep an eye on this blog — the announcement will land here first.