Bug bounties can be a valuable marketing tool to:
š strengthen ties between a company and specialists
š reach hidden ātalent pocketsā
š ensure customers know you care about your product/service security, but, ā¦
Bug bounties are no panacea or substitute for strong security thinking across different product stages and departments. We had Spectre and Meltdown due to the industry shortcoming in this regard, not because we didnāt conduct enough bug bounties.
When estimating the cost of bounties donāt forget to plan and allocate the time needed by your organization to manage results/findings (can be larger than the reward price by magnitudes).
Good security is taken for granted because itās invisible to the user! So creating awareness for your security is an uphill struggle for anyone. I understand the urge to allocate limited budget on a bug bounty instead of investing in internal training or awareness.
It is easy to measure / justify the budget due to quick (but short lived) returns from a bug bounty. Accurately measuring real security improvements over a long time frame is much harder.
If budget is limited then priority should be to raise the bar internally regarding infosec and train everyone within engineering/development. You canāt outsource strong security-thinking of your teams.
Your developers might be rockstars but they often still live in a bubble isolated from having to care about security (more often they donāt have time to care because no security questions were asked when defining the features use-cases).
IETF RFCās drafts always lacked sections on āsecurity considerationsā and eventually in 2003 (after many years of complaining) there was an RFC 3552 addressing the problem. We can learn something from this RFC when creating user-stories, use-cases and implementing features.
Some simple changes to your agile workflows should be higher priority than planning your first bug bounty:
š describe security challenges and solutions with every new feature
š storing and maintaining the threat-model together with your code and testcases
š ā¦
Consistently maintaining a dynamic threat model gives insight into parts of your stack which should be refactored. Dynamic threat-modeling requires everyone onboard and allows you to identify which part of your product most effectively benefits from a bug bounty and when is the right time for it.
Itās your team that makes your product so this is where you have the most to gain in the long run (and the most to lose if you donāt). What a bug bounty can always give you though, is a realization that long term investments in your security culture should no longer be postponed.
Successful bug bounties (and security audits) are those that seem to yield little results. Keep in mind that there are plenty unsuccessful bounties which just yield noise or where the company was maybe ill prepared.
In general number of flaws found should be a quality indicator of how well your internal security thinking is evolving and whether *real* product/service security progressing.
