Case study · DevSecOps + PTaaS
One month, 28 reports, 8 researchers.
In October 2026, during Cybersecurity Awareness Month, our vulnerability disclosure program went from a trickle to a flood. Twenty-eight reports from eight researchers hit every layer of a 100-site estate. Here's what they found and how each one became a permanent fix.
28
real reports
8
independent researchers
22
valid (79%)
~1 day
median time to fix
Valid findings: 1 Critical · 3 High · 4 Medium · 14 Low. 19 public finding cards. Live monthly stats →
What they found
Grouped the way an attacker sees it.
Almost none of it was exotic. It was ordinary enterprise entropy: legacy backends, defaults nobody revisited, half-finished migrations, and controls that worked until someone used them.
No account needed
- — Public database keys that could read or edit data (row-level security broader than intended, on three sites)
- — A sign-in gateway that could hand a token to an outside site
- — A static site publishing its own repository: source, build scripts and internal docs
- — Health checks describing internals, and on failure, database error text
- — HTML injection into automated email from our own domain, to any recipient
Any free account was enough
- — Self-promotion to administrator on a critical-tier app: one request, then tenant-wide access
- — OAuth consent skipped for newly registered clients on AI tool (MCP) servers
- — An AI assistant that would recite its hidden instructions
- — Sign-out that didn't end the central session
Controls that quietly didn't work
- — Two-factor setup that had never worked for anyone, administrators included
- — A development sign-in left in a production app, held shut by one config value
- — A production app whose builds had silently failed for two weeks, so security fixes wouldn't ship
Known debt vs forgotten surface. Some of it was known and unfinished (a planned database migration, an email-escaping audit, "2FA is off on the admins"). The rest was forgotten: seed identities from a build night, a site deploying its repo root, debug health checks, a framework version that aged out of support, a broken build nobody watched.
How it became permanent
One report, one root cause, one test.
A one-operator DevSecOps program turned a month of chaos into a stronger estate. Six habits did the work.
Fix the root cause once
One shared email sender fixed every flow at once; one storage helper fixed 2FA; one field allowlist fixed self-promotion on every table.
Contain before fixing
On the Critical, the elevated test account was reverted and its long-lived token revoked before any code changed.
A test that fails on the old code
Every fix shipped with a regression test written to fail against the vulnerable version. October started test suites in several repositories.
Verify the claim, not the story
Reports were checked against code and live records, read-only. Some were bigger than reported, some were browser autofill or two sessions in one browser.
Rate fairly, say why
Out-of-scope reports closed as informational with a reason, and often fixed anyway. One rating was raised on appeal and became a standing rule.
Fix the program too
Every slow fix was an emailed report sitting in an inbox. Reports now go through one alerted form with a daily digest of anything waiting.
The pipeline
From a report to a retested fix, continuously.
The bug bounty is wired into the same SDLC pipeline as our scanners and DAST: every finding lands in one register, gets fixed with a test, and is verified live.
01
Report
security.txt on every site points to one form: support.cisomarketplace.com/bug-bounty.
02
Triage
Reproduced against code and live behavior; our severity, CWE and system type recorded; the researcher follows status in their portal.
03
Fix + test
Root-cause fix with a regression test, deployed and verified live. Contained first when anything is still exposed.
04
Retest + register
Researchers can retest fixes; every finding is synced into the DevSecOps register alongside scanner and DAST findings.
05
Credit
Points, tiers, badges and a citable finding card on the Hall of Fame. Silver and Gold researchers can join the paid bench.
The researchers
Vetted on a live ecosystem.
Recognition is the currency: public points, tiers with quality gates, badges and citable finding cards. October produced our first Gold researcher, whose reports included the month's only Critical.
Report something to us
Every CISO Marketplace site publishes /.well-known/security.txt. It points to one form, where reports are triaged, fixed with a test and credited. Third-party issues on our subdomains are accepted as referrals.
Takeaways
What any security team can take from it.
- Your attack surface is wider than your inventory. The findings that mattered most were on surfaces nobody had looked at in months.
- "The key is public" is fine; a permissive policy is not. Every anonymous-access finding was a policy problem, not a secret problem.
- Test your controls by using them. 2FA existed for months. Nobody had ever turned it on.
- A broken pipeline is a security finding. If merges don't deploy, your fixes don't exist.
- Researchers find what scanners miss, if intake is fast. One alerted queue, not an inbox.
- One report, one root cause, one test. That's how a hard month becomes a stronger estate.
Can you run this for our company?
Yes. The same intake, triage, fix-verification and researcher bench run as part of our DevSecOps and PTaaS programs, with named, vetted testers under a signed Testing Authorization.
Why publish your own findings?
Because a program you can read is worth more than a certificate. Every credited finding has a public card with its category, severity, CWE and time to fix. Hostnames and exploit detail stay private.
How do researchers report to you?
Every site publishes security.txt, which points to one report form. Rules, scope, test accounts and rewards are on the support site.