Since September 2017, BlaBlaCar has been managing with a select number of security experts a private Bug Bounty program to enhance the operational security of its platform.
Previously accessible only by invitation via YesWeHack, this program has enabled BlaBlaCar to remain proactive on the cyber security of its services.
Thursday April 19, BlaBlaCar’s program is public
What is your role at BlaBlaCar?
I am a backend developer profile, today overseeing application security. When I joined BlaBlaCar, I was in charge of the platform’s performance and security. In mid-2015 and early 2016, our operational security needed to level up significantly, especially following our major fund-raising campaigns, which put BlaBlaCar under the light and pressure. So at that period of time, i took the lead of a small team to mitigate these attacks, and audit/consolidate the platform.
What is your approach to security, including coordinated vulnerability disclosure?
We have kept application security in-house for a long time. Previously, we used classical audits conducted by various companies, by several basic pentest applications, by using static analysis tools, etc. I think it helped to rough out a lot of little things that would have been detected by bug hunters.
In addition, we received a few troll messages on Twitter reporting vulnerabilities without notice and without any details… We also have some emails via customer support about potential security holes, but nothing was disclosed by these contacts, they first wanted to be paid and this, without proof of the existence of a security flaw, so it was impossible for us to enter the game.
Over the last months, these emails were more and more numerous so we decided to take the step of Bug Bounty.
What criteria guided you in choosing YesWeHack?
We made a comparison of the different Bug Bounty platforms in Europe and we preferred to take a French company mainly for regulatory reasons. The second criterion was the number of active hunters on the platform, it doesn’t make much sense to put money and energy into a program if there isn’t a critical mass of hunters to effectively search for vulnerabilities.
What have you learned from the private phase of your program?
As soon as a program was launched on YesWeHack, it generated a large number of reports in the first few days, not because the site has holes everywhere, but because it took us time to describe our program as well as possible.
There are certain IT security standards that are not compatible with our product, or there are others that are technically too costly to implement given their added value.
In short, the first thing we learned was the importance of properly defining the scope, i.e. the play perimeter of the bug hunters.
In the batch, there were some real flaws, really critical that were reported, and they convinced us of the relevance and efficiency of YesWeHack’s service.
After the first week, the number of reports decreases greatly, but the ones that have come up are more interesting, because hunters get into our product and make reports that are really specific to our business.
After the first month, it was quieter. It gave us time to manage the flow. And as soon as everything was fixed, we added bug hunters.
Adding hunters is about the same as when you arrive on the platform, there is a jump of reports linked to standards, good practices, automatic scans, etc. then you realize that the reports are more specific to the product, more relevant and it is again the lull.
You will soon switch to public mode, have you prepared this phase and what are your expectations?
We have not prepared anything specifically and the private phase went well. We expect to have many more reports and we hope to have a low positive ratio over the first few weeks.
In terms of communication, we were really satisfied with the quality of the exchanges with the bug hunters during the private phase and obviously we expect the same quality of service by going public.
Once again, we count on the expertise and responsiveness of the YesWeHack team to approach this stage with the utmost serenity.
Like OVH, is your program supposed to remain public in order to respond in an operational and continuous way to the evolution of your tools?
Yes, we wish to open our program to the public on an ongoing basis, whenever possible. For example, if we have too many reports to process, we may put it back in private to manage the flow and avoid duplicate reports. Hunters work very hard to find loopholes, so it is top priority to avoid being overwhelmed.
On the side of your team, Devs, Devsecops, have you noticed any healthy stimulation in the framework of this program?
We are a small technical team in a company with big ambitions. So there’s a lot of work to do. Since our days only include 24 hours, it has sometimes been complicated to make our managers understand the need to integrate bug fixes that appeared not very serious, some may consider this as a chore. On the other hand, from the point of view of the attacker who uses a tailored and clever chaining, a vulnerability seeming harmless can prove out to be critical therefore some devs as bug researchers can find an interest and thus can improve their skills !
The stimulation is healthy when the devs clearly see a potential harm. My job is to make them aware that the devil is in the detail: everyone must be aware of what is at stake and must play the game. We look forward to the next critical flaws, because they are the ones that stimulate us the most.
In terms of external communication, will you communicate on your program?
No, even if internally we communicated widely about the bug bounty to answer questions from the support which received quite a few tickets containing “bug bounty” or “hunter”, the marketing and communication departments do not plan for the moment to use it as a sales force.
Our community already trusts us, and we must preserve their trust by delivering a secure platform. All our communication focuses on sharing and living together better.