Today we're going to be chatting about experience that Jeff and I have had
building bug bounty programs, managing programs.
So we'll dive right on into it then.
So a little bit about us.
Perfect, we do have everything working here. So Jeff?
Hello. Cool, so quick intro.
Sorry I lost my voice, I blamed a DJ yesterday at O'Shea's.
I enjoy driving fast cars,
racing cars professionally, building cars,
security research and building bug bounty programs.
It's where I started my career many years ago and just very passionate about it.
And I'm a senior security engineer at GitHub at the moment.
And I am Logan McLaren. I'm based out of Ottawa, Canada.
So a bit of a trip to get here.
I've been an enthusiast in the security world for longer than I want to admit.
Also a senior security engineer at GitHub.
And following along from a great tip from the last talk,
we are not representing GitHub here today.
Just sharing context on that before we dive on into it.
So to chat a little bit about what we're going to cover here today,
we are going to be as sort of platform and product agnostic
as we can be going through this.
The idea is really to get you set up through different stages
of building a bug bounty program.
So whether you're coming in from a position where you have nothing
that's public facing right now, or you are already set up
with maybe a private program or vulnerability disclosure program
and you want to see how that's going to grow.
We've both lived through this.
We've had a lot of pain and suffering with it.
So we're hoping to share some of that info
so that you don't have to have that same pain and suffering.
So starting off, we are going to make some assumptions
that you've got some fundamentals in place.
We'll sort of talk about what those are.
But this is going to be things like having vulnerability lifecycle tracking,
understanding what your asset inventory is,
so you can actually start building something on top of it.
Next up is going to be the groundwork to actually get a program started,
building a plan to grow from there, sort of getting to an MVP
so you can figure out how you want to scale.
Operations for it as well here.
Sorry, we're on a new platform for this.
So the operations, looking at your communications plans,
your program policies, how you want to handle transparency,
disputes, all that, all the fun that goes with it.
Last up for the main stuff here is also focusing on relationships.
This is something that Jeff and I certainly feel is overlooked in a lot of places.
If you are building a bounty program,
effectively you're building something that's user-facing, customer-facing,
so you want to be sure that you are putting
sort of the best image forward possible for it.
But yeah, just to clarify again,
we are sort of expecting these fundamentals to be in place.
Our goal here is to name drop the talk,
getting you scoped for success.
But yeah, so no fundamentals for this.
So Jeff, over to you.
Cool. All right. Yep, like you said,
we're going to walk through the expectations and necessities
for programs, policies already in place
before starting or launching your program.
However, if you don't have them,
you can still follow along and implement what we're recommending.
So we're taking kind of like a broad approach on this one.
So to start with, without understanding your attack surface,
you can't really scope responsibly.
You should ask yourself, what are you exposing publicly?
What types of threats might you face, right,
based on the industry or assets that you have?
Know what's publicly accessible
and also what you want your researchers to focus on.
What's important for you as a company?
Why are you kind of wanting to host the program?
And yep, build an asset inventory if you don't have one.
A great colleague of ours said,
own your assets before someone else owns them, right?
And so building one, even if you have, you know,
a very immature asset inventory,
ask yourself, how can we work on that
before we actually launch the program?
And so you put in scope what's important to you.
We don't specifically endorse any, like we said earlier,
but some examples, some tools are Detectify, HackerOne Assets,
and many more to kind of get you started
if you need a starting point.
To understand your asset inventory,
you should categorize that you should understand relative risk.
Some examples of this is like using a scoring
or criticality system like Carver to determine risk.
And then various platforms have tools for this,
as well as purpose-built products for enumeration.
We can discuss how we're handling it at GitHub,
but that's another talk for another day.
Finally, like you mentioned earlier,
establishing a vulnerability remediation practice, it's huge.
You should have at least something basic internally
before you start receiving a ton of reports, right?
And the way you can start is kind of understanding
what qualifies as an issue.
What is a security vulnerability for your org and for your company?
Have clear ownership. This is a tough one.
You really want to ensure that when you do receive something on an asset,
you know exactly who owns it, what engineering team will be fixing it.
And that sounds simple, but I've seen organizations
have issues with, at the end of the day,
they've had the vulnerability for a few months now, a few weeks,
and they're having issues with clear ownership on who should fix it.
And so having that in the beginning will save you a lot of time.
And ultimately agreeing upon timelines for remediation.
And if you can, just to add one more thing there,
is having a good exceptions process.
Because if a vulnerability comes in and you don't really know,
it's the first of its class, but in the end it's working as expected,
or you just can't fix it at the moment,
you should have a defined exceptions process.
Because that bug will be sitting there for a while,
so you should know how to deal with it
before you keep getting them from other folks.
So now Logan's going to talk about some groundwork.
Yeah, so now that we sort of are established on what we're hoping is in place,
let's start getting into how we can turn that into
at least the start of a bounty program,
or if you're already there again, how to grow it from that point.
So first thing we'll say is,
understand what the different program options are,
and how these deal with different levels of maturity.
So one of the things that we'll generally recommend
is if you're starting from scratch,
you can look at something like a VDP, a Vulnerability Disclosure Program.
This tends to be a lot lower lift to get started.
You don't necessarily need specific tooling.
This could be a mailing list,
it could be something like Private Vulnerability Reporting on GitHub,
or Confidential Issues on GitLab, anything like that.
I mean, there are some huge projects out there that effectively do this,
like the Git Security Mailing List, which is a Google group at this point.
So there's many ways to go through and build repeatable processes out of this.
As Jeff mentioned, understanding which teams are going to own stuff when they come in,
or understanding how you're handling severities,
how you're doing issue assignment, SOAs, all of this.
This is all things that you can build with a Vulnerability Disclosure Program
before you really have to worry about the money side of it,
or platform, or tooling, or really any of that.
But broadly, the sort of progression we'd suggest, if you're looking at this,
is to start out with a Vulnerability Disclosure Program to get those reps in,
and then from there maybe look at moving into a private program.
You get a bit more control around the number of reports you're going to get,
potentially who's actually working on your program as well,
depending on how you build that out.
And then look at going public once you have those processes in place,
because otherwise you're just going to get buried the second you open things up.
And when you do look at moving into a paid program,
whether that's a private program, public program, whatever,
as Jeff sort of alluded to earlier,
we want you to scope with intention for this,
but also, we both think, importantly,
pair up with a platform that can support you through it.
And again, we're not going to specifically endorse anything,
whether it's HackerOne, Integrity, BugCrowd, whatever,
you get the same idea for it.
But the key things for this is you get a lot of stuff
that you may not think is super important out of the gate,
and then as soon as you don't have it,
it bites you in the ass immediately.
So this is going to be things like having educational resources,
a code of conduct, collaboration on triage and process,
mediation process, if shit really hits the fan,
and you can sort of go from there.
And I guarantee you all of those will happen
as soon as you get money involved for it.
But on a more positive note, a lot of this sets you up
for a situation where it's much easier for folks to submit stuff to you.
Certainly sending stuff in through email to a mailing list,
even if you're using PGP-signed emails or something,
it's not the greatest feeling for a lot of it.
And for a lot of folks that are, again,
at least in the world we work in for this,
a lot of people who are doing bug hunting for this
are already familiar with these platforms,
they're ready to send stuff in through it,
they know what it looks like,
they have a reputation on there already,
they know the ins and outs.
So you're sort of good to go from that.
But again, speaking of scoping with intention,
be very careful about scope creep for this.
Again, with the Vulnerability Disclosure Program,
you get a little more latitude
because you don't necessarily have to fix things.
Take that with a grain of salt.
But when you do start moving into broader stuff,
if you are getting reports and you have money on the line for those
and you don't actually have ownership of those
or a way to remediate stuff,
or an exceptions process if you want to accept risks for it,
you're going to be in for a lot of frustration
on both sides of that relationship,
both for your company, your organization,
and for the hackers that are working on it.
There we go.
And another area that a lot of folks will overlook,
again, until it bites them,
is make sure you are bringing your legal and PR teams into this.
This is all customer-facing stuff.
As soon as you have money on the line as well,
you have a lot of reputational impact that's going to come from that.
You have a lot of legal obligations.
And this is somewhere else that having a platform involved
rather than doing a homegrown thing can be very, very helpful.
As soon as you have to worry about trade sanctions
for where you want to send money to,
currency conversion, all of those moving parts,
if you have a partner that can take care of a lot of that for you,
has a good reputation for it, has all the processes,
you're going to be saving yourself, again,
a lot of frustration, a lot of pain, a lot of suffering.
And also for many of these platforms,
if not all of them at this point,
it gives you standardized tooling for disclosure.
They have their own terms for how you want to handle disclosure.
You don't necessarily need to reinvent the wheel
or have something that's bespoke to you.
Same deal for safe harbor terms, things like that.
So HackerOne has the gold standard safe harbor, I think they call it.
Many other platforms have something similar.
In our experience, the companies we've worked with,
we have some bespoke ones, but it's all sort of the same idea.
If you send stuff in, you're safe.
But again, you're getting a lot of this for free,
out of the box when you're partnering up with somebody.
Forgot about those.
And then as you're going through as well,
as you progress through each of these stages,
you're getting a lot of information around
what that next stage is going to look like.
So when you have a vulnerability disclosure program to start out with,
again, you're getting the reps in for how you want
to build out your processes for it.
When you move into a private program,
you're getting a better idea of what some of the budgeting
is going to look like, your cost per bug.
If you need to fine-tune your severity models,
you can do that in a little bit of a more controlled environment
than if you're already public.
And this also gives you a really good opportunity
to start building out some tooling for this.
And if you're interested specifically in tooling,
we're not going to talk about it here,
but Jeff did a great talk at B-Sides SF earlier this year
called Life of a Bug, which goes through how GitHub
does all their bug remediation, bug tracking, all that.
Very helpful. It saves us a colossal amount of time.
It also makes auditing really easy,
which is another thing that having a good platform
can really help with.
So if we need to go through and say,
hey, are we consistently paying out the same way
for these types of vulnerabilities as they come through?
Are we consistent in our messaging?
All of that is already there. We know exactly what it looks like.
It's the same thing every single time for it.
And yeah, also looking at budgeting and staffing for this.
When you're going through, again, VDP,
you're getting an idea of the amount of time it's going to take
you to remediate something. You move into a private program,
you're getting an idea of the costs for it.
But that's also going to have an uptick in interest,
generally, for the number of reports you're going to get.
So you can start figuring out,
okay, if we're getting 100 reports per year,
100 reports per month, maybe,
what does that look like in terms of time and effort
for our company? And then when you go public,
yeah, all hell's going to break loose.
Especially if you manage to get featured as a new program
on any of these platforms,
you're going to get a big uptick in interest
almost immediately. You need to be prepared for that
because nothing is worse than just having things that will
linger for months while people are expecting it to get fixed.
Oh, and I will give a quick shout-out for...
there's a fantastic resource,
and we do have a slide that has links to all these resources
at the end, as well as these slides in there.
There is a forum called
Bug Bounty Community of Interest,
which has fantastic articles around all of these.
Definitely worth checking out.
I do not remember the URL, but it is linked
in the resources here.
So moving forward, let's chat about
what things look like once you're actually operational.
You've got the baseline stuff
you need in place for this.
And again, our goal here is to talk about
some of the less
easily documentable things
for it when you're going through and building a program.
So the first one is going to be
focusing on transparency for this.
The more you can document
and share with the community of hackers
that's going to be working on your program, the better.
And that's everything from process that you're going through,
your timelines, your payout, your scope.
There's nothing that's worse than
ambiguity in any of this.
Somebody's going to send in a report to you,
you're not going to be sure if it's in your scope.
That's going to suck for everyone.
If they know specifically that it is in scope,
and you wind up having to go through a mediation process,
you've got clarity for that, again,
on both sides for it.
And it gives you a lot of opportunities as well when you start working
with disclosure for it.
The more transparent you can be around that,
whether it's limited disclosure, full disclosure,
whatever, if it's unilateral,
both sides doing a coordinated
disclosure, whatever,
it's giving really good insight into how
your program operates. Whether that's from a timeline
perspective, or it's from a
operation perspective, what your
communications look like, what all of the
individual moving bits and pieces look like,
even payouts. You can start looking at some
of these programs out there and say,
hey, if I get an IDOR for this product,
I have a pretty good idea of what the payout's going to be,
so I can manage my own expectations for it.
So that can be vulnerability classes,
it can be specific assets in there as well.
There's lots to look at for it.
There we go.
And building on that as well is making sure that you've got
good clarity on what you want hackers
to focus on when they are
looking at your program.
So I'll talk about GitHub
very briefly for this, because I think
we've done this all right.
But we have specific lists of stuff that we do care
about, things that we don't care about.
And that's not to say that they're not necessarily security
issues, but they're things we're aware of.
It's accepted risk, so it's pretty
easy for us to filter stuff out when it comes in.
We've seen that with other programs we've worked on
as well. It's a significant time saver on both
sides. If you, as a
researcher in the community, are looking
at a program, and you immediately know,
hey, I don't want to touch this asset,
it's not going to get me any money, it's not going to be
of interest, you can save yourself a lot of time
and focus on something that instead will give you
that level of payout that you're looking
for. And with this as well,
in addition to understanding
what you do want to focus on, what you don't want to focus
on, this is also an area to add a lot of
clarity around your payout structures.
For many programs out there,
it's going to be a set thing, like, hey, if this is
a low severity, it's $100. If it's medium,
it's $500, so on and so forth.
For others, it's a direct tie to
CVSS, or VISS, or
one of five million standards that people are coming
up with now. But having clarity around
it, having examples for it as well, if you're doing
disclosure through your program, is incredibly
helpful for it. And
with that as well, having a communication
plan for a lot of this is really, really helpful.
Whether it is something that you want to handle
specifically internally, whether
you are staffing this program through a
platform to do your triage work, or you're doing
it yourselves, having a list of resources
for that, having things like canned responses
for it, can be very, very helpful.
You're ensuring consistency for it, you're ensuring
that when people work on your program, they know exactly
what they're going to get for it. And it
really does help with a lot of the auditing stuff
as well, as we've alluded to, because you understand
exactly what you're in for every single time
for it.
And I think one of the other things to put on here,
and I say this coming from a customer-facing
background before moving into the security
world, with a lot of this, you have
to remember that you are, quote-unquote,
customer-facing, user-facing, whatever.
So, whatever you say, you're going to be representing
the group you work for. So, if I get
a bounty report, and I am a
giant ass to somebody,
it's not that I was an ass, it's that GitHub was
an ass. You don't want to necessarily be
on the hook for that.
And,
speaking of being an ass, understanding
how to handle disputes and duplicates.
These will happen, they happen very frequently.
More often than not,
a lot of disputes are
of dubious
nature, but duplicates
are going to happen very, very frequently.
And this could be duplicates for stuff you're already
tracking in your company as known issues, but maybe
aren't accepted risks. It could be things
where you have two researchers
who submit the same report within minutes of each other
even. So, having a clear, documented
policy on that is very helpful as well.
And that can be something as simple as, hey,
if we get duplicate reports, if somebody sent it
in first based on timestamp, they're going to get
the award. Understanding whether or not you want
to combine people onto single reports
is also something that sounds a bit
more simple than it actually is. That is
a great way to lead yourself down a path
of pain with mediation requests
and other frustrations and
arguments more frequently than not when that happens.
So be conscious of
that when it goes through. One of the
other things that comes up and causes a lot
of pain and suffering for programs and
researchers is making
sure you have something along the lines of a
one-fix, one-bug, one-payout type
of policy. There was a great example
that popped up the other day. I don't remember
what the asset was, what the company was,
but somebody had found what they
had considered to be 40 or 50 different
crits that were coming in. It was leaking PII,
a bunch of other problems.
This was not for us, I'll say.
But with that,
those all got closed out as a single
low-severity vulnerability because it was
something that was being tracked. So this person had spent
about a month compiling stuff, sent
all of it in, and got completely hosed
on it. So making sure you've got
as much structure there as possible,
you've got the policies in place to avoid that kind
of frustration, is really helpful
because otherwise you're going to wind up on the
bug bounty forum slack, people are going to be flaming your
program, and it's not fun for anyone.
You don't want to be on the other side of that because it's
not going to lead to a positive outcome for anyone.
And last but not least for this bit,
just chatting about doing
your own triage versus working with a
platform for it, both of these are
incredibly feasible
ways to do things. We've both
worked with groups that are using
hosted platform-managed
triage services, whether it's, again,
HackerOne, Integrity, whatever.
These can be incredibly helpful because you don't
need to change your own staffing
for it. The key thing I'll note with that
is on most of these platforms, that's going to come with
an additional cost, but more importantly
you also need to be set up to still
do that triage when it comes through.
A lot of the time, this is going to be lacking
the business context for it, so they may not
necessarily understand severity that's going along with it,
especially as you're starting out as a new program
that will build over time, but
it's not going to be there out of the gate, so you
need to be able to filter through
whatever is coming in after that.
So we've spoken with various other
companies where they'll say, yeah, we're using
a managed triage service,
we don't actually have anybody full-time,
it just goes into our AppSec team, but we're
still spending 50, 60, 70 hours a week
doing triage on this stuff because
yeah, it's valid, but it's stuff that
they don't have visibility into our internal bug
base, so we don't need to do anything with it.
So that's one of the things to consider for it.
One of the other areas that comes with
that as a bit of a selling point is looking at things
like spam filtering, especially as you're going to a public
program. I would
suggest that that's not as important
as it may sound like. You think you have a public
program, you're going to get a lot of garbage, and you
are, but if you have that
context around your program already,
your products, you have that expertise on it,
a lot of that goes away pretty quickly.
So for reference, we're one of the larger
programs, I think, out there at GitHub,
and we get about 20 or 30 spam reports
a week, and those take under a minute to
remediate. So for our entire team, it's a
pretty negligible cost to do that.
And yeah, going for in-house,
the other side of this as well is you're looking at a
situation where you can make the
appropriate decision, whether that's
from a payout standpoint, a triage
process, whatever, you can make that very
quickly because you have the full context around
it, and you've got the expertise
on it. Again, we've heard a lot of challenges,
and that's not to say this solves the
problem by any stretch, but there are many
other cases where something without that context
may show up as being a lower
severity issue, when in fact it's something you might actually
consider to be a crit and need to work on right away.
So being able to make that judgment call
very, very quickly instead of having to route it through another
party can be helpful. So there's a lot of trade-offs
here. It's not to say one way is any better
than the other, but something to be conscious of that otherwise
does not always show up that way.
And with that, we'll talk about
what I think both of us consider the most
important intangible part of this.
So over to you, Jeff. Cool, yeah.
There's not a lot of
documentation around how to build relationships.
It's a rather new thing,
right? And yeah, the
program's up and running, right? You're getting value
out of it. How do you grow from there? How do you create
relationships? How do you celebrate the wins?
How do you keep your researchers coming back?
And so
one thing is
basically create
relationships and celebrate... oh, I already
said that, sorry. An empathetic approach
helps researchers continue to invest time in
your program and represent your
org, right? So
when you get a report and
it's kind of like big bounty and they're like, oh,
I really need like 50 bucks or
I spent 20 hours
on this. You can explore
ways where you don't just turn that into a
negative. You can just close it out as spam and
send them on their way. One
way you can do is like exploring
defense in debt is
one way of handling reports where
you're like, okay, you know what? This might have not met
the low severity, but
it's a good idea. It's a good
maybe security feature request or something.
And so it's kind of, you know, you throw
them $200, $500. We have something
I get where we do that. And we
tell them like, this didn't really meet the low severity,
but this is what we're going to do with
it. And so we're going to award you a
lower than low severity
bounty.
And they like that. It encourages
researchers to continue to try to find bones
on your platform and to
keep coming back.
Yeah, so I
was alluding to be conscious how you close the reports.
Don't close them as spam immediately
all the time. If they're actually
trying or they were close,
you can explore ways of using
informative or
duplicate.
But like, those don't hurt
someone's red points. And so
those are one way that
that's a way that
maybe researchers can...
they'll want to come back, you know, and keep working with you.
And to jump in quickly while Jeff
gets the slide sorted out here, because I think we had
some technical issues with that. The scenario
I mentioned earlier with those 50 reports that
came in for that program, all of those got
closed out as not applicable. That person's
reputation went from being very well respected,
scored on HackerOne, to being
tanked in a single day. So
it led to a lot of other discussions that, again,
are not fun for anybody involved.
Right, right. And so
helping researchers grow, right? This is
the education part that we spend a lot of
time on. We rather
educate rather than, like,
you know, chastise if
there are off-base submissions that aren't spam,
right? What we do is we
provide resources and direct feedback,
right? It takes five minutes to let
them know, hey, maybe you should check out this
podcast that might help you out. Or check out
Portswigger Academy. That might help you get a little
closer to this, you know,
LFI that you thought you found. Or this
SSRF, you know, that's clearly not
an SSRF, but you were looking
for it, you know? So we
have a lot of internal
lists that we
use to try to educate folks to...
And it's cool, because eventually they do
come back. We've seen a few folks where
we helped them out, we educated
them a little bit. Then they came back maybe a year later
and they found like a medium or something.
And they let us know, like, hey, this is
cool, you know? You sent me
on my way and I came back a year later.
Those are special.
Showcasing submissions. That's
something that we love to do.
You should explore opportunities for
joint articles, blog posts,
and the creation of content.
Basically, you know, some
examples are like walkthroughs of disclosed bugs,
their life cycle. If you're
not ready for disclosure,
that's okay. It takes time.
One way that you can do that is if you see a
researcher who's just focusing...
You can tell, they're just focusing on your program.
They're sending in... Every two weeks
you're getting one or two good bugs from them.
Reach out. Form a
relationship with them. Just ask
them, hey, can I give you
a researcher spotlight?
I just want to write a blog
and tell everybody, and maybe inspire
other researchers to
check out our program.
And we've done that a few times where we'll just interview
folks and we'll write a blog
post with the answers and we'll give
them something, you know, a platform
where they can kind of talk about their own
research and really plug
their own stuff, you know, and
why they like to come and hack on us.
And that's pretty cool.
Lastly, researchers
and industry peers enjoy interacting
and reading what programs are up to.
You can do this in a lot of different ways.
You can join, you know, Slack workspaces
like Bug Bounty Forum.
You can, you know, create a Twitter
account and just tweet little things
here and there. Like, we tweet our
monthly stats and people like to engage with them.
That's pretty cool. I like to see, like, how much
did GitHub pay last month, you know?
And some programs are pretty cool
at promoting promotions.
Like, oh, we are paying a 30%
bonus on cross-site scriptings.
And that, you know, if you have researchers
new or, you know, returning
researchers and they check that out
they will most likely want
to hack on you, you know? They'll be like, oh,
30%, 40% bonus sounds nice
this month. And so,
yeah, using these community discussions
it's pretty cool for industry
peers and then also researchers.
So you've got your program scoped, operations
are underway, relationship, you're
building relationships.
You know, what's next?
So,
now that you're operational and have your goals changed
you should create
if you haven't created one
you should create one or
update a roadmap of where you want to be.
Where do you want to be in two
quarters? Where do you want to be in a year?
How do you really get, like, the return
of investment for your bugs?
Let's say you're getting all
your bugs and you're fixing them correctly. What's next?
Like, do you have the bandwidth to explore
varying analysis? Can you enable
something like CodeQL to really try to
find more bugs with the bugs that you're getting already?
You have access to the code base,
right? So, using
tools, tooling,
staffing and all that to try to get more bugs
of the bugs you get are
so impactful.
What needs to change from what you're doing now?
Maybe you need more automation.
How can you do that?
What is working well that you want to double down
on? What do you want to focus on
for the next
two months? What do you really want to focus
on and then move on to the next thing? And what problems
are you having? Is it time
to focus on disclosure? Is it time
to focus on communication? Maybe
you can train your...
If you're using platform triage,
is it time to maybe spend a few
weeks and months just really getting
to know them so that that layer, that
filtering layer gets a little better?
So, what problems are you
having?
That's what you should focus
on. And internally
promote and celebrate findings
from your program. Focus
on blameless handling
of bugs. A blameless culture
really goes a long
way for engineering and security
teams.
I've been at an organization where it
was tougher to get things fixed. It was
always, ah, I don't think
that's an SSRF. I didn't mean to
introduce an SSRF. But like,
truly what it should be is
we did that. We introduced
the SSRF. How do we not
introduce it going forward, right? It's not
so simple. But like, lessons learned from
these bugs, right? Instead of just
paying them out, you
know, having a hard time fixing them and then forgetting
about them, you're just going to keep getting them.
You're going to keep seeing these patterns. So, if
you try, and it's a
cultural thing and it's tough, but if you really
are able to build a blameless culture,
you'll be able to be
way more successful with this bug bounty
program that you're spinning up or
you're revamping.
Another thing is software has bugs, right?
This is another feedback mechanism
in addition to other tooling and
processes. So,
yeah, just understand that you're
in it together.
Cool. So,
most public
programs are very clear about their scopes,
their reward structures, what they do,
right? You can check out activity, everything's
on there, based on the platform
you use.
So, you should compare yourself to industry
peers, but you should understand
you don't need to compete
to be competitive, right? You're in different industries,
you're in different maturity
levels of your program,
and just chat
with industry peers, just see
what they're doing, what can
you implement to your program? Are you ready
to implement some of the things that others are doing?
Can you start simple? I
like how this company has automation in place,
and as a team of three, that's what
I really need, and that's what you're going to focus on.
So, talking and
collaborating with industry peers will
be fundamental, really.
One more thing is, few people
hack on a single program. Like
Logan said earlier, these researchers, they bounce around,
right? Most of them,
they have a lot of experience
working with a lot of companies,
and just for some metric,
GitHub has had a little more
than 850 unique reporters
last year, in 2022,
right? And some of them were
first-timers. I don't have the exact number,
but that's a lot, right? More than 850
people coming to your program for the first time.
That can sound scary,
really, but
like I said, chatting with industry peers kind of
helps build and mature your program so you can
handle that many reporters,
right? Because a lot of these unique
reporters, it's their first time engaging with your program,
so it can be rough if they don't
maybe understand how your program
runs compared to others, right? So
if you have a lot of the communication, automation,
all that, it'll
have a really smooth
process for these new researchers, and they'll
want to come back. And that's the goal, right? You don't want
them to submit one
report and then never again.
And so, yeah, chatting with
industry peers, engage with programs, understand
what they're seeing, what are problems
that they're not seeing and you're seeing,
what are some common issues that are being
submitted, you know,
throughout the industry.
Lastly,
yeah, so you
want to talk to bug hunters and review feedback.
What we do is we go to
conferences, we meet up with all the researchers
that we can, and we just ask them,
like, how's it going? What programs are
you hunting on, right? And if we see a trend
and we're seeing that one program
is what a lot of people are focusing on,
we'll check it out. Like, what are they doing
that's pretty cool? What are we not doing?
Like, at DEF CON
last year, we had a few researchers that we
chatted with for about five hours
in one day, and they said, I really want
swag. And so we said, okay, cool.
We'll work on it. And so we launched a cool
bug bounty swag store that only
people who submit a valid report to us
can get that kind of swag. So we gamified
it a little bit, you know? And so what
that causes is that these people, these
researchers, they're like, I kind of want
that swag that you can only... it's
a challenge, you know? It's kind of like a CTF.
You get some money, and you get cool swag
that only you can get if you submit a bug.
So finding ways to
gamify it, you know? Launching a swag
store is not that expensive.
So yeah, basically
talking to bug hunters and seeing what
is something they would like,
you know? Not all the requests are going to be
things you can do, right? Some things
take time. There's some things that we got asked
for that'll probably take like a year or two.
And that's okay. But at least you're working on them, you know?
You're surveying the community,
and you're interacting with folks on what is
out there right now. Like, what
is trending? What is something that maybe we should
do that others are doing?
I will say swag
is a very common request. There are some
programs out there. I think it's the Dutch government
as well. Their approach is they
can't pay for anything. They have a vulnerability disclosure
program, but you get an awesome shirt that says, hey, I
hacked the Dutch government. All I got was a shitty t-shirt.
That kind of stuff is fantastic. It's very
unique. There's no other place you can
get that. So it's a shameless plug for us,
I guess. If you want one of these wonderful GitHub hoodies,
you can come hack on our program.
Exactly. And I think
that's it.
So I promise this is not a
rickroll. You can go to this, but the link is there
if you don't believe me anyway.
This is going to be a lot of stuff that we've talked about
through this, resources to back it up, a lot of
documentation. There were too many
links to bother putting on here, so if
you want a good weekend, week, month,
year of reading, this is something we're
continually updating with all sorts of bug bounty
stuff, whether it's program building, operations,
building out the fundamentals
for it, sort of a dumping ground for that.
We're trying to structure it in a lot of the
same framework we have for this. We'll also
have a copy of these slides with the speaker notes, once I
edit them down a little bit, to
be up there as well, if you want to loop back to that.
It's going to have contact info for both of us, too.
Feel free to reach out, any questions you have,
whether here or later on, if anything
comes to mind, we're always happy to chat
bounty. So, thank you very much for
sticking with us, hope you had a great DEF CON!