Case Study
Caught before launch day.
A fast-growing fintech put a vetted researcher cohort on its new product weeks before launch. They found a critical authentication bypass no scanner was programmed to see — and the fix was verified before a single customer signed up.
Representative engagement — details anonymized
01
Challenge
The client was weeks from launching a new consumer product: mobile-first onboarding, two-step verification, money moving from day one. The security team had already done the responsible things — a scoped pentest earlier in the quarter, scanners in the pipeline — but they knew the gap those leave. Point-in-time testing had signed off on the product as it existed then; the launch build was still changing weekly.
What kept the CISO up at night wasn't the known checklist. It was business-logic flaws — the chained, creative attacks that only show up when a skilled human works the product the way a real attacker would. And with a public launch date already announced, a full public bounty program was off the table: the scope was too sensitive, the product too unreleased, and the team too small to absorb a flood of unvetted reports.
They needed continuous, adversarial testing — private, controlled, and pre-validated — in the window between code freeze and launch.
02
Solution
SecurityBoat launched a private, invite-only Bug Bounty program on TriNetra, run SecurityBoat-managed so every report reached the client pre-validated.
Vetted researcher cohort. An invite list of 24 researchers filtered by skill match — mobile, API, and auth specialists — each carrying identity-verification and signed-agreement trust badges. Submissions stayed gated to invited researchers only.
Scope bound to real assets. Program scope was tied to the client's actual asset inventory in TriNetra — the launch build's mobile apps and APIs, nothing else — with rules of engagement and a safe-harbor policy attached to the program itself.
Per-severity reward structure. Reward tiers set per severity in INR, alongside reputation-point tiers, so cost tracked discovered risk rather than hours billed. (Illustrative structure — every program sets its own tiers at scoping.)
One console for the whole program. Lifecycle states (inactive → active → paused → closed), a full activity log, an announcements feed for scope updates, and role-scoped program chat between the client team, SecurityBoat's TPM, and researchers.
AECM Corp — Bug Bounty Program
Private● ActiveSeverity-tiered rewards · accepted reports only · CVSS v4.0 scored by the same triage engine as PTaaS
03
Methodology
Every submission ran through the same findings engine that powers TriNetra PTaaS — one record of risk, one state machine, no side channels.
1. Program setup. Bug Bounty (rewarded) selected over a points-only VDP; visibility set to private; SecurityBoat-managed operating model.
2. Scope and rules. Launch-build apps and APIs bound from the asset inventory; rules of engagement and safe-harbor policy attached; reward and reputation tiers defined; hall of fame enabled for post-launch.
3. Cohort invited. Skill-filtered researchers invited; program state moved inactive → active.
4. Triage and validation. Every submission got a human-readable program ID and CVSS v4.0 score, then moved through the state machine: triage → accepted → fix-in-progress → ready-for-retest → resolved. SecurityBoat's managed triage validated and deduplicated before anything reached the client queue.
5. Remediation routing. Accepted findings routed one-click into the client's Jira, mapped per program — fixing a bounty report looked like fixing any other bug.
6. Retest gate. The client marked fixes fix-in-progress → ready-for-retest; the reporting researcher confirmed each fix before the finding could reach resolved.
7. Disclosure control. Nothing went public without two approvals in sequence: TPM review first, then explicit client approval — only then did a report reach the hacktivity feed.
Throughout the program, the client's security lead used Ish to stay current without digging through queues — asking, in one prompt, questions like “What came in from the bounty program this week, and what should we fix first?” and getting answers grounded in the live submission data.
04
Attack Lifecycle
The bug: a critical authentication bypass in the onboarding flow.
- 01
1. Discovery. In week two, an invited researcher specializing in mobile auth noticed that the onboarding API issued a session token after the first verification step — and that the second-factor check lived on a separate endpoint the mobile client was trusted to call. Server-side, nothing bound the token's privileges to completing step two.
- 02
2. The chain. Intercepting onboarding traffic, the researcher replayed the interim token against account endpoints directly — skipping the second factor entirely. Result: full account takeover on any account mid-onboarding, with no OTP ever entered. A textbook business-logic flaw: every individual endpoint behaved “correctly,” and no scanner pattern-matches its way to that sequence.
- 03
3. Submission → triage. The report landed with steps-to-reproduce and raw request/response evidence, got its program ID, and entered triage. SecurityBoat's managed triage reproduced the chain the same day, scored it CVSS v4.0 Critical, and moved it to accepted — the client's first sight of it was a validated, severity-scored finding, not a raw report.
- 04
4. Fix. The finding routed one-click into Jira. Engineering bound token privileges server-side to verification state, so no session issued before step two carries account access. The card moved to fix-in-progress on the shared board.
- 05
5. Retest → resolved. The client flagged ready-for-retest; the original researcher re-ran the full chain against the patched build and confirmed the bypass was dead. Only then did the finding reach resolved — with an append-only state history recording every transition, timestamp, and actor.
- 06
6. Reward. The payout resolved automatically from the program's Critical tier, cleared the approval workflow, and paid out via verified bank transfer with an auto-generated invoice. The researcher took the top of the program leaderboard.
- 07
7. Disclosure — on the client's terms. Pre-launch, nothing was published. After launch and a hardening window, the client chose to disclose the (fixed) finding through the two-stage workflow — TPM review, then client approval — putting it on the program's hacktivity feed as public proof that reports get handled seriously and fixed fast.
Client Testimonial
Client quote pending approval.
A named client quote is published only after client sign-off.
On the record
Disclosure — on the client's terms.
Nothing reached the public hacktivity feed without two approvals in sequence: TPM review, then explicit client approval.
Disclosure Requests
AllPending TPMPending ClientPublishedRejectedServer-Side Request Forgery via webhook URL
Priya N. · CVSS 6.5 · awaiting TPM review
IDOR on /api/v2/statements/{id}
@k4rthik · CVSS 8.2 · TPM approved ✓ — your call next
Race condition in wallet balance update
R. Iyer · CVSS 6.5 · View public page →
Two approvals — TPM, then you — before anything reaches Hacktivity.
06
Key Outcomes
One critical authentication bypass found, fixed, and retest-verified before public launch.
38 submissions distilled to 15 valid findings — managed triage absorbed the noise; the client queue saw only validated signal.
4 High, 7 Medium, and 3 Low findings all resolved through the same state machine before or shortly after launch.
Same-day triage on the Critical — reproduced, scored, and accepted within one working day.
Program still live post-launch. Hacktivity feed and leaderboard now serve as ongoing assurance — for the client's customers, partners, and the researchers deciding where to hunt next.
The larger point: the program didn't end at launch. It moved from pre-launch gate to standing assurance — vetted researchers still hunting the live product, approved disclosures still feeding the public hacktivity record. A pentest ends. A bounty program keeps watching.
Ready when you are
Launch knowing, not hoping.
Shipping something sensitive? Put a vetted, private researcher cohort on it before your customers arrive — and keep them hunting after.