Why We Run a Bug Bounty Program (And Why It’s Worth the Noise)

We hold a SOC 2 Type 2 attestation and have done so for four years. We’re working through ISO 27001 and Cyber Essentials Plus right now. We do a full penetration test every year with an independent firm. And on top of all of that, we run a bug bounty program.

If you’re a customer, a prospect filling out a vendor security questionnaire, or another SaaS founder wondering whether a bug bounty is worth the hassle, this post is for you. I’ll cover why we run one, how we run it, what it’s actually found, and the very real noise it generates. Spoiler: the noise is annoying, and it’s still worth it.

PS: But for those customers and IT companies, IT reviewers who buy software. This should be a mandatory question on every single incoming software review. Does the company have a bug bounty policy? Because that tells you whether the company actually puts their money where their mouth is, and how badly they care about security.

Certifications, pen tests, and bug bounties are three different things

People sometimes lump these together. They shouldn’t. They occupy different spaces.

Certifications like SOC 2 and ISO 27001 are about your processes and controls. They prove you have a working security program, access reviews, change management, incident response, vendor management, and that an independent auditor has verified it over a period of time. They’re essential, but they test the system around the software more than the software itself.

An annual penetration test is a point-in-time exercise. A skilled team spends a defined window attacking a defined scope, using a defined methodology, and hands you a report. It’s rigorous and structured, and every serious SaaS company should do one. But it’s a snapshot. The day after your pen test ends, you ship new code, and that new code was never tested.

A bug bounty program is continuous and open-ended. Instead of one firm testing for two weeks a year, you have researchers around the world probing your platform 365 days a year, each bringing their own tools, techniques, and obsessions. They don’t follow your methodology. They follow their curiosity. And they only get paid when they find something real, which is a very different incentive model from a fixed-fee engagement.

None of these replaces the others. The certifications prove the program, the pen test provides depth, and the bounty provides breadth and continuity. We do all three because they catch different things.

How SyncEzy runs its program

We’ve run our bug bounty in two ways, and both are live today.

Independently, on our own site. We published our own bug bounty and responsible disclosure policy on our blog some years ago, and it’s still active. It sets out the scope (our integration platform and APIs), the exclusions (more on those in a minute), how to report, and how rewards work. Anyone who finds our platform and wants to report a vulnerability responsibly has a clear, public path to do it. We think every SaaS company should have at least this , a responsible disclosure page is the security equivalent of having a fire exit.

Through a third-party marketplace. More recently we also listed our program on Bugbop, a newer third-party bug bounty marketplace. The reason is simple: reach. Running a program on your own blog means only the researchers who stumble across your site know it exists. Listing on a marketplace puts your program in front of active bounty hunters who are browsing for targets every day, and gives us a standard workflow for validating and paying out reports. The self-hosted policy gives us a permanent public commitment; the marketplace gives us distribution.

A word on Bugbop specifically, because we think it deserves a shout-out. Until recently, running a program on a marketplace meant HackerOne, Bugcrowd, or one of the other enterprise platforms — and that meant tens of thousands of dollars a year in platform fees before you’d paid a single bounty. That’s fine if you’re a bank. It’s a non-starter if you’re a bootstrapped SaaS company with fewer than fifteen staff. Bugbop flips that model: no monthly charges, no lock-in contracts, no “contact us” pricing — you pay a fee only on valid bugs, and their platform fee undercuts the industry-standard cut. Setup took minutes using their scope templates, and their AI-driven triage does the pre-filtering that used to require a dedicated security team — checking reports against scope before submission, assigning severity, and flagging duplicates before anything hits our queue. What’s refreshing is that it’s built by someone who ran a bug bounty program at a small company himself, and it shows. Bug bounties used to be a big-company luxury; platforms like Bugbop have made them accessible to the little guys — and if a company our size can run one, so can you.

What the program has actually found

This is the part that justifies everything else. Over the life of the program, researchers have surfaced genuine issues that our internal testing and annual pen tests hadn’t caught: things like misconfigured security headers, lack of limits on OTP generation, some simple IDOR errors, session handling edge cases, information disclosure in error responses, and authorisation gaps on less-travelled API endpoints. Individually, most were low-to-medium severity. None was a catastrophic hole. But every one of them was a real weakness that is now fixed, and a few of them were the kind of subtle logic issue that automated scanners simply don’t find; only a curious human poking at your product in ways you never anticipated does.

That’s the honest value proposition of a bug bounty: it’s not that you’ll find one giant vulnerability. It’s that you’ll steadily sand down dozens of small rough edges, each of which made your platform slightly more attackable. Compounded over years, that’s a materially more secure product.

Now, the noise. Let’s talk about the noise.

Here’s what nobody tells you before you launch a bug bounty program: for every genuine, in-scope report, you will receive a pile of noise.

The noise comes in flavours:

Beg bounties. Automated scanner output (“your SPF record could be stricter”) copy-pasted into an email with a demand for payment. These aren’t vulnerabilities. They’re spam wearing a security costume.

Duplicate and out-of-date reports. The same missing header reported fifteen times, or a “vulnerability” in a library version we don’t even run.

And the big one for us: out-of-scope reports on explicitly excluded assets. Our policy is explicit, in writing, in bold, that our WordPress marketing site, our CRM Contact forms, and our Zoho SalesIQ chat widget are excluded from scope. These are standard, well-maintained third-party components; a contact form that lets you type an emoji into the name field is not a vulnerability. Despite this, our support and sales queues are regularly inundated by bounty hunters going after this low-hanging fruit, submitting “reports” through the very contact form the policy excludes, and expecting payment. Our support team, whose job is helping actual customers, ends up triaging security spam. It’s genuinely frustrating, and it’s a real, ongoing cost of running the program.

I won’t pretend otherwise: if you launch a bug bounty, budget real time for triage, and expect that a large majority of what comes in will be noise. 

Additionally, there will be some amount of back and forth with every security researcher that thinks self-scripted XSS is a  BUG or being able to enter code characters in a contact form is a legit security issue.

So why is it still worth it?

Because the maths works; the noise costs us hours. The signal makes the product safer. If the entire program, the payouts, the triage, the queue spam, all of it, makes our platform even a few points more secure than it would otherwise be, then the whole effort has paid for itself. We handle payroll and HR data flowing between systems like HiBob and Employment Hero Payroll for businesses across Australia, New Zealand, the UK and the US. In that business, “a few points more secure” is not a marginal improvement. It’s the job.

There’s a second-order benefit too: it changes how your own team builds. When your engineers know that thousands of strangers are financially motivated to find their mistakes, they write more defensive code. The bounty program is a standing red team you never have to schedule.

Considering a bug bounty or responsible disclosure policy? Our recommendations

If you’re a SaaS company thinking about this, here’s what we’d tell you after years of running one:

1. Start with a responsible disclosure policy, not a paid bounty. A public page saying “here’s how to report a vulnerability to us, and here’s our commitment to you” costs nothing and closes the worst gap: a researcher finding a hole and having nowhere sane to report it.
   
2. Write your scope and exclusions in blunt, unmissable language. Then accept that people will ignore them anyway. Define your in-scope assets precisely, and explicitly exclude your marketing site, forms, chat widgets, and anything third-party hosted.
   
3. Prepare your support team before launch. They will be the front line for out-of-scope noise. Give them a canned response, a routing rule, and permission to close beg bounties without escalation.
   
4. Use a marketplace for reach, keep your own policy for permanence. The marketplace brings researchers and triage structure; your own published policy is the durable public commitment that survives any platform.
   
5. Pay fairly and pay fast for real findings. Your reputation with researchers is an asset. The good ones talk to each other, and you want them coming back to your program instead of a competitor’s.
   
6. Don’t treat it as a substitute for anything. Keep the annual pen test. Keep the certifications. The bounty is a layer, not a replacement.
   
7. Measure it honestly. Track valid findings versus noise, time to triage, and time to fix. If after a year the program has surfaced nothing real, revisit your scope or your rewards, but in our experience, it will surface things.

PS: A note for the buyers, IT reviewers, and questionnaire writers

We fill out a lot of vendor security questionnaires — it comes with the territory when you sell integration software to enterprises. They ask about our SOC 2 report, our encryption at rest, our RTO and RPO, our subprocessors. All fair questions. But here’s one that almost never appears, and in our view should be mandatory on every single incoming software review: “Does the company have a bug bounty or responsible disclosure policy?”

Why? Because certifications tell you a vendor has documented processes, and a pen test report tells you they tested their app once this year. But a live bug bounty program tells you something no questionnaire checkbox can: this company has voluntarily invited the world’s security researchers to attack its product, all year round, and has committed to paying real money when someone finds a real hole. It tells you whether the company actually puts its money where its mouth is — and how badly they care about security when nobody’s making them. A vendor with no disclosure policy at all is telling you something too: that a researcher who finds a vulnerability in their product has nowhere to report it. If you buy software for a living, add the question. It costs you one line on a form, and it separates the vendors who perform security from the vendors who practise it.

Security isn’t a certificate on a wall. It’s a set of overlapping, imperfect layers, each catching what the others miss. Our bug bounty program is one of the noisier layers — but it’s caught real issues, it keeps us honest every single day of the year, and we’d recommend one to any SaaS company that’s serious about protecting customer data.

Want to report a vulnerability to SyncEzy? Our responsible disclosure policy is published on our blog, and our program is live on Bugbop.