monday.com's Playbook: Running a World-Class Private Bug Bounty Program

A public program is a volume dial you can't turn down. Private means you control how many researchers are active at any given moment: open the dial when you have capacity, close it when you don't.

What makes private work:

• Set a broad scope. Researchers want a platform they can spend months exploring. Narrow scope gets you shallow coverage.
• Use your CSM to recruit. Your brand and bounty level do more of the work than you'd expect.
• Resist the urge to go public. Depth of platform knowledge beats volume, especially on complex products.

AI-generated report noise is increasing. Private programs with vetted researchers have a growing signal advantage over public ones.

The researchers who know your platform deeply find your most critical bugs. Keeping them requires treating the relationship as a partnership.

• Pay fast and fairly. Set SLAs for validation and payment. Slow payment is a trust signal (the bad kind).
• Benchmark bounties monthly via your CSM. Aim for the upper tier against comparable programs.
• Give real feedback on every report, including rejections. Tell them what you're looking for. Give them business context they can't get anywhere else: which features are revenue-critical, what high impact actually looks like for your product. Researchers who understand your business find better bugs.
• Upgrade severity when a researcher undersells their finding. If they reported medium but the impact is high, tell them and pay the higher rate. Most programs do the opposite. This is the fastest way to build trust.

The test: Top researchers submitting repeatedly = healthy program. If your best people go quiet, something is wrong with your program, not your security posture.

Every significant feature launch ends with a HackerOne campaign, before it rolls out to all customers. Researchers who know your platform find critical bugs in new features within days of launch. That's when you want to know, not six months later in a pentest.

You'll know it's working when engineering starts requesting campaigns without being asked. That's security embedded in the process, not bolted on after.

Build toward this:

1. Researcher files report via HackerOne.
2. Your team responds immediately, 24/7, and ahead of triage for critical reports.
3. H1 Triage validates, de-dupes, filters false positives, and managers researcher comms.
4. Hai does the second validation pass and assigns to team owner.
5. Internal agent traces root cause to exact location in your codebase.
6. Internal agent suggests a fix and auto-creates PR.
7. Developer receives item with bug, fix, and graded SLA pre-populated. Merges and marks done.
8. Hai automates retest and confirms the fix.
9. Your team reviews, approves, pays bounty, and closes ticket. Target 70-80% reduction in effort per report.

Start here: Map your current process. Every step requiring manual human time is an automation target. Prioritize root cause identification and developer handoff first. 

1. Researcher satisfaction. Measure repeat submission rate. If top researchers go quiet, investigate. Track time-to-payment.
2. Signal quality. Measure % of high and critical of valid reports. Low/medium-heavy = wrong researchers or wrong incentives. On the rest, be willing to upgrade severity, not just downgrade.
3. Coverage depth. Measure (and minimize) time from feature launch to first submission. Researcher-hours per feature can give insight into how secure the feature is.

"No bugs found" is only meaningful when paired with the effort invested.

When you ship AI features, add them to scope immediately. Treat it as education, not just bug-hunting.

Standard CVSS scoring doesn't map to AI risk. A prompt injection that leaks user data might score "medium" but be catastrophic in context. Review AI findings with human judgment.

The researchers who know how to execute prompt injection and jailbreaking are already doing it. Give them access to your AI features and let them show you what's possible. That's faster than waiting for vendor tooling to catch up.

The best way to learn about new AI vulnerabilities is to give researchers the opportunity to break us and to teach us. - Amit Levy, Head of AppSec at monday.com

Three things Amit would tell you:

1. Be fair. Unfair programs, like the ones that downgrade severity to avoid payouts, lose their best researchers. And researchers who don't like you can let the 90-day disclosure clock run out. Fairness is strategic.
2. Give context. Every report is a chance to teach a researcher about your business. The ones who understand your product find better bugs.
3. Use AI to fix fast. Speed fixes the vulnerability and eliminates duplicates. A second researcher who finds the same bug two days later finds nothing if you've already patched it.

• Who owns the operation end-to-end, like the connective tissue between researchers, security engineers, and R&D.
• Controls all key metrics such as signal-to-noise ratio, researcher return rates, time-to-first-finding, and more.
• Builds and enforces unified standards for triage and severity scoring across the program.
• Raises flags immediately when something slips e.g. slow payments, mishandled reports, unjustified severity downgrades.
• Drives continuous improvement, identifies friction points, scopes the next automation target, and integrates AI tooling before gaps appear.