Adversarially verified penetration testing
An enterprise customer sent a security questionnaire and your deal stopped moving. We run the test, then argue with ourselves about it — and you get the argument, not just the verdict.
Everyone in this category shows you what survived their testing. We print what did not, and why — because a report you cannot check is just a list with a logo on it.
The situation
Someone in procurement sent over a spreadsheet. Question 4.7 asks for the date of your most recent third-party penetration test and the remediation status of any Critical findings. There is no good way to answer it with nothing.
So the deal sits. Not dead — worse than dead, because everyone is still spending time on it. Your champion is waiting on you, legal has already redlined the MSA, and the quarter is closing.
This is not a security problem. Your app is probably fine. It is an evidence problem: a reviewer needs a specific artifact in a specific shape, and until it exists, no amount of being genuinely secure moves the contract forward.
That is the whole job. Produce the artifact, make it good enough that the reviewer stops asking, and get out of the way.
How it works
A scanner has one opinion and no way to check it. Most of what ours finds does not survive its own review — and that is the point.
Pass 1 · broad sweep
Deliberately over-eager. A finding never raised cannot be verified later.
Pass 2 · fresh context
A second model gets the findings and nothing else — no code, no notes — and is told to refute them.
Pass 3 · arbiter
Disputes adjudicated. Unproven findings are held for a human, not padded in.
Illustrative shape of a real engagement. Thirty-five findings did not survive, and you never see them.
What that rules out
A scanner sees innerHTML in a bundle and files XSS. Pass 2 asks which line, reachable from which input, with what payload. When the answer is “it is React’s own internals,” the finding dies.
Caught and removed by this pipeline on a real scan.
v1.0 · versioned · public
The method is published, not asserted.
Scoring table, the SSRF blocklist our own scanner runs under, the noise we suppress and the carve-outs we refuse to. Read it and grade us against it.
Read the methodology →The deliverable
Each finding carries what Pass 2 challenged and how Pass 3 ruled. A shipped report contains a MEDIUM our own arbiter demoted to LOW — printed, with the reasoning, against our interest.
Do it yourself with the exact config, use this named tool, or hire someone at this hourly range for this many hours. Enforced on every finding down to Informational — the renderer fails loudly if a level is missing.
Plus rate limit, the user-agent we scanned from, and our egress path. The fields an auditor checks first.
A named section for scope gaps and methodology limits, inside your report rather than omitted from it.
Scored against a pinned reference table so the same issue does not drift between engagements.
Request, response and exact path for anything we could reproduce. Configuration findings carry the observed response instead — we do not dress one up as the other.
We do not ship scanner output as a penetration test report. Findings we cannot stand up are withheld rather than padded in — which is why ours are sometimes shorter than you expect, and why the long ones are worth reading.
Pricing
Scope moves the number, so it is a range rather than a single figure. Nothing here is gated behind a call you do not have time for.
$3,500–$5,000
by scope · one-time
For when someone has asked you for a report and the deal is waiting on it.
Quoted
continuous
Your questionnaire comes back every year and your app changes every week.
Rate card
wholesale
You have a client who needs a pentest and nobody to staff it.
Founding cohort: $2,500 until 31 December 2026. We are new and we would rather have your case study than your full fee. That is the entire reason for the discount, and it ends on the date above rather than renewing quietly forever.
Who does the work
Pilum is small on purpose, and we would rather say so than let you find out. There is no account manager between you and the person who ran the engagement, and no junior tester learning on your codebase. You will be talking to the person who did the work, for the whole engagement.
We are also based in Indonesia and selling mostly to buyers in the US and EU, which is a reasonable thing for you to have a question about. The honest answer is that where we sit changes your cost, not your controls — so here is exactly what protects your code and your findings, and all of it is enforced in the tooling rather than promised in a sales call.
A passive engagement runs entirely against what your app already serves the public. Source access is optional and scoped, and nothing runs against production data.
Active testing is gated on a signed scope document. This is enforced in the tooling, not by discipline — the pipeline refuses to deliver a paid report with no agreement on file.
Scan artifacts live in an isolated per-engagement directory and are removed once the report is confirmed. Credentials found during a scan are redacted from the report and stripped from storage.
Reports are encrypted and the password goes over a different channel you choose. An intercepted mailbox does not hand anyone your findings.
Our own site is scanned with the same pipeline we sell, and the findings go into the same report format. The most recent self-audit downgraded one of its own findings on review and printed the reasoning — the same treatment your report gets.
Before you ask
What gets checked is scope, named methodology, dates, reproduction evidence and whether a retest closed the findings out. Scope, methodology and dates are on our cover page, and evidence is attached wherever a finding could be reproduced. Two honest caveats: we do not currently run a formal retest cycle, and we only issue a certificate when an audit closes with zero Critical and zero High — so if you need a signed attestation regardless of outcome, say so before you engage and we will tell you whether we can help.
No, and it is the fair question to ask of anything automated. A scanner has one opinion and no way to check it. Ours runs three passes where the second is given the findings and nothing else and is told to refute them, the third arbitrates, and a person reads the whole report before it goes out. Findings that cannot be reproduced are withheld rather than padded in.
If you need a named human tester on an accredited firm letterhead for a specific contractual clause, or your framework explicitly requires a CREST-accredited provider, we are not that and will tell you so on the call rather than after the invoice. Most vendor security questionnaires do not require it. Some contracts do.
No. A passive engagement runs entirely against what your app already serves the public. Repository access is optional and improves depth; production credentials are never required and we will decline them if offered.
Scanning is fast — a passive engagement completes in well under an hour of machine time. The honest constraint is the human review afterwards, and we are a small team, so give us a working week and tell us your actual deadline on the call. We would rather decline than miss it.
You get a report saying so, with the evidence of what was tested and how, which is exactly what a reviewer needs. A clean result is a legitimate outcome and it is not a reason to manufacture findings — inflating severity to justify an invoice is the most common failure in this category.
That is genuinely enough to scope it. You will get a fixed price and a delivery date back, and if we are the wrong fit for your deadline or your framework we will say so on the call rather than after the invoice.
Or email security@pilum.io — it reaches the person who would run the engagement.