Home / Solutions / Product teams
For product teams
Keep the annual pentest.
This covers the other eleven months. Every role, every door, every deploy, with the proof attached. Built for teams running five to thirty applications with one engagement a year and nothing in between.
The gap
The problem is the calendar, not the tester
Your pentest is good. It is also annual, because that is what the budget and the calendar allow. Meanwhile your team merges every day, and everything shipped between engagements sits unexamined until the next one.
By the time a finding surfaces it is eleven months old, buried under two hundred other changes, and expensive to unpick. The author has moved teams. Nobody remembers why the check was written that way.
We are not asking you to cancel anything. Keep the pentest. A good human tester still finds things nothing automated will. Keep your scanner too; this is for the bugs it cannot see. What we are proposing is that you stop leaving the rest of the year uncovered.
Between engagements
What runs while nobody is looking
Scan on merge
Wire it into the pipeline and the finding arrives attached to the change that caused it, while the author still has the context loaded.
Nightly on staging
A full run with exploitation enabled, against an environment where breaking things is the point. Schedule it on cron or fire a one-off.
Who can see what
Every role against every door. Green means locked. Pink means someone got in who should not have. This is the class of bug a scanner with one login cannot reach.
What changed since last time
New, fixed and regressed, side by side in the console, so a run is a diff rather than another wall of output. Scheduled delta-only reports come later.
One portfolio view
Every application in one list, sorted by what is actually exploitable rather than by finding count. Duplicates merged, assigned to people, tagged, exportable.
Prove the fix
“Fixed” is a hypothesis until the same exploit fails. The retest replays the exploit that worked; the finding closes only when the replay fails.
In the pipeline
Block the merge that breaks access
A finding nobody reads is not coverage. The gate is where continuous testing stops being a dashboard and starts being a decision.
The gate, today
One call from your pipeline starts the scan, and the build fails when the run comes back with something serious. A GitHub Action template ships with it, so the first wiring is a copy-paste rather than a project. Findings stream in as they are confirmed rather than arriving in a batch at the end.
What you set
You choose the severity that fails the build, across six tiers from critical down to best practice, so the gate matches how your team actually ships. Confirmed-only mode lands 19 October: one list, only what we exploited, no maybes and no homework.
Cost, before and after
Per-scan time and spend caps land 13 November, with the cost shown before a run starts and again when it finishes. You bring your own AI key at every tier. No per-scan billing, and no surprise at the end of a quarter.
Hardening, dated
CI gate hardening for GitHub and GitLab lands 25 November. Native two-way Jira and GitHub Issues sync is not built. Today you paste a reference by hand, and we would rather say that here than let you find out in week three. What connects today →
What lands on the desk
A finding your engineers do not argue with
A finding is the request, the response, the screenshot and the line of code. Anything less is a suspicion, and a suspicion costs an engineer an afternoon to disprove. If we did not break it, we do not report it.
Questions
What product teams ask first
Do we cancel the annual pentest?
No. Keep it. A human tester brings judgement to your specific business, and the engagement is worth more when it starts from a clean baseline instead of a year of accumulated drift. This is the eleven months in between, not the two weeks you already pay for.
We already have a scanner. Why this too?
Keep it. A scanner has one login, so it cannot tell you whether a support agent can read a customer’s invoice or whether a trial account can call the admin endpoint. That is the class of bug we go after, and it is the one that shows up in breach reports.
Will this drown us in findings?
That is the failure mode we built against. We report what we exploited, with the proof attached. Confirmed-only mode lands 19 October and makes that the default view rather than a filter.
What does it test?
Web applications and their APIs. We do not scan networks or infrastructure. That is a different tool, and we are not going to pretend to be it.
What does it cost for thirty applications?
$699 per application per year at the founding rate, locked for two years, available until 28 February 2027. From 1 March 2027 the list price is $1,199. Running the agent inside your own network is $944. All prices exclude 18% GST, which applies to customers invoiced in India. Full pricing →
What have you not proved yet?
We have not published a detection rate, and we are not going to invent one. The benchmark runs against Juice Shop, WebGoat, DVWA and real open-source applications with known CVEs, and publishes 3 November with the misses included. Read the honest page →
Point it at one application.
Pick the application that changes most between your annual engagements. We will show you what runs on a merge, what the gate stops, and what the diff looks like on the second run.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.