Why I Publish G8KEPR's Pentest Results

When G8KEPR hit general availability with v1.0 on April 14, 2026, the release notes included something most software launches leave out: the result of an independent penetration test. Zero critical, zero high, three medium.

The company blog carries the longer version, alongside a post called "Why We Publish Our Pentest Results" and a series of red-team write-ups. This is the founder's-notebook version of that reasoning.

Two terms, quickly

A penetration test is a hired attack. Someone qualified is given permission, and usually a defined scope, to try to break into a system the way a real attacker would. They write up what they found and rate each finding by severity.

A red-team run is similar in spirit but tends to be broader and more goal-driven. Instead of "find every weakness in this app," it's closer to "try to accomplish something an attacker would want, using whatever works." Pentests are thorough. Red teams are sneaky. Both are useful.

Severity ratings run roughly critical, high, medium, low, sometimes with an informational tier below that. Critical and high are the ones that keep people up at night. Mediums are real and worth fixing, but they generally need more conditions to line up before they hurt anyone.

Why publish at all

The default for most companies is to keep test results private. There are decent reasons for that. Reports can be misread. Findings can be taken out of context. Some vendors worry that anything short of "zero findings" will scare buyers off.

I understand all of that, and I still think a security product should publish. Here's my reasoning.

A security product is asking for unusual trust. G8KEPR sits in the path of an application's most sensitive traffic. If you're going to put something there, "trust me, it's solid" shouldn't be enough. It wouldn't be enough for me if I were the one buying.

Independent beats self-reported. I can write tests all day, and I do; the codebase has more lines of test than lines of source. But I wrote those tests, which means they share my blind spots. An outside tester's whole value is that they don't.

Publishing changes the incentive. If results stay private, there's always a quiet temptation to scope a test narrowly, or to treat the report as a box to tick. When you know the outcome is going on the blog, you want the test to be real, because a soft test that later gets embarrassed by a real attacker is worse than an honest medium today.

It sets an expectation I have to keep meeting. Once you've published one result, not publishing the next one says something too. That's a useful pressure to put on myself, especially as a solo founder with nobody else to hold me to it.

What "0 critical, 0 high" does and doesn't mean

It's a good result, and I want to be careful with it.

It means an independent tester, within the scope they were given, at that point in time, didn't find anything they rated critical or high. That's a meaningful signal. It is not a promise that no such issue exists, and nobody who works in security would read it that way. Software changes. New techniques show up. A test is a snapshot, not a warranty.

That's exactly why the red-team runs matter. One test at launch is a data point. A series of runs over time, published as they happen, is closer to a trend you can actually judge.

And the three mediums? I'm not going to walk through them here. This post is about why results get published, not a findings report. What I'll say is that a result with findings in it is still worth publishing. A report with nothing in it at all tends to raise more questions than it answers.

What I'd suggest to anyone evaluating security tools

Ask whether a vendor has had independent testing, and whether they'll show you the results. Not just a badge on a website. The actual outcome, severity counts at minimum.

If they say yes, good. If they say no, that's not automatically disqualifying, but it's worth asking why. For a tool that's going to sit in front of your data, I think "we tested it, here's how it went" is a fair thing to expect.

You can read G8KEPR's published results on the company blog, and the release history is on the changelog.