Written by Allar Lauk, Cybersecurity Engineer at Bolt

As Bolt continues to grow, so does the complexity of securing our platform. With services spanning ride-hailing, food delivery, micromobility, and car-sharing, our systems are built to constantly evolve. That evolution raises a critical question: how do you discover edge-case vulnerabilities fast and before bad actors do?

Over the years, we’ve invested heavily in internal security and regular penetration testing. But that wasn’t enough, so we launched a private bug bounty programme and are now going public with it.

Why Bolt needed a bug bounty program

Traditional security efforts like internal testing and even well-scoped pen tests can only go so far when you’re operating with hundreds of interconnected services. At Bolt, our attack surface includes:

Several mobile apps (Bolt, Bolt Driver, Bolt Food)
Web applications
Public APIs
Backend systems and databases

All of these are maintained by teams across different product domains and ship at high velocity. With a lean Information Security team supporting a company of 4,000+ employees, we needed a new approach — one that would scale with our platform and augment our internal capabilities.

We’d already expanded our InfoSec structure into multiple sub-teams focused on different security domains. But we wanted broader, continuous coverage, and most importantly, external perspectives. That’s where the bug bounty programme came in.

How we designed the private programme

We began with a private bug bounty programme hosted on Bugcrowd. Researchers who submitted vulnerabilities to our security email were directed to the Bugcrowd platform, where each submission went through a two-step triage:

Initial validation by Bugcrowd
In-depth review by Bolt’s Security team

We scoped the programme to include our main public-facing services, applying Bugcrowd’s default severity ratings, from P1 (Critical) to P5 (Informational). Our triage SLAs were structured to support this two-stage process, ensuring we could validate high-severity issues quickly.

We chose Bugcrowd because of its flexibility, collaborative roadmap, and willingness to build custom features. Their support team has been a true partner in helping us scale.

Lessons from the private phase

Running the private programme taught us a lot:

Low signal-to-noise ratio: Many submissions were out of scope or duplicates, yet still required full triage.
Inconsistent reporting: Researchers came from various backgrounds, and submissions often lacked a clear Proof of Concept (PoC) or reproducible steps.
Common issues reported:
- Security misconfigurations (often identified via automated tools, but lacking exploit details);
- Leaked credentials (hard to verify, often unverifiable, and easily exploitable by submitting the same leak in multiple batches, so typically excluded from rewards).

Despite these challenges, the programme provided real value. It uncovered genuine vulnerabilities, improved our internal tooling, and gave us broader external coverage.

Why we went public

We chose to open the programme to the public after identifying that some high-impact reports were lost in our reporting process. Similar issues had been flagged before, but through informal channels that didn’t reliably reach our InfoSec team.

This highlighted the need for a single, well-structured funnel where anyone could submit findings, and where we could automate as much of the triage as possible. This would help us separate the signal from the noise and would allow us to only focus on the highest priority and most impactful findings.

How the public programme works

The public bug bounty programme keeps the core structure of our private one but expands in key areas:

Wider scope: more assets, better documentation, and clearer submission guidelines;
Optimised triage: leveraging Bugcrowd’s validation process to reduce the volume of low-quality submissions.

Here’s how the lifecycle of a reported vulnerability looks now:

1. Submission → A researcher submits a report via Bugcrowd.

2. Bugcrowd validation → The platform checks it against known issues and guidelines.

3. Bolt InfoSec review → We assess impact and validity, asking:

- Is there an impact?
- Is the submission in the scope and within our Terms of Service
- Is there a working PoC?
- Are the steps to reproduce clear?

4. Severity + payout → If valid, we assign a severity and issue a payout.

5. Issue tracking → The report is pushed to JIRA and assigned for remediation.

6. Resolution → Once fixed and verified, the issue is marked resolved.

What we've learned so far

Going public brought scale and new challenges. But it also helped us mature in how we handle vulnerability management.

Real-world findings

Some of the impactful categories of bugs we’ve received include:

Broken Access Control (BAC)
Server Security Misconfiguration
Cross-Site Scripting (XSS)
Server-Side Injection

Early mistakes (and fixes)

Too much time on duplicates: we initially spent too long analysing submissions before checking for existing issues.
Low-quality reports: we learned to tightly define our testing scope and to push back, requesting more detail from researchers when key criteria (like PoC or reproducibility) weren’t met.
Lack of clear standards: setting minimum requirements for submissions helped streamline triage and reward genuinely valuable reports.

Process improvements

We've defined more consistent triage workflows to deal with the wide variability in report quality.
We're experimenting with AI-assisted validation, especially for identifying duplicates and extracting PoC steps.
We’re working to better connect Bugcrowd with our internal systems, improving issue tracking, SLAs, and visibility for engineering teams.

What’s next

As we continue scaling our security testing, our top priorities are:

Improving signal-to-noise ratio: encouraging better reports, and discouraging spammy or low-effort submissions.
Tightening SLA metrics: shortening the time between submission and validation.
Engaging the community more deeply: giving feedback to researchers and refining our programme based on their input.

Ultimately, security is too big a job for one team. Even with automation and coverage improvements, external researchers bring the creativity and perspective we can’t always replicate in-house. Their contributions have helped us catch bugs early, fix them faster, and rethink our own assumptions.

We also see the bug bounty programme as a potential hiring pipeline. Some of our favourite reports have come from people we’d gladly welcome onto our team.

Join us!

If you’re a security researcher passionate about mobility, infrastructure, or complex systems, we’d love to collaborate! Check out our public programme and start helping us build an even safer service for everyone.

Scaling security testing: lessons from launching a public bug bounty at Bolt

We’re hiring!

Recent posts

How to get hired as a software engineer at Bolt (+ sample interview questions)