Photo Courtesy of Douwe De Boer
What is your background ?
I am a web developer and security researcher. In my spare time, I like to contribute to open-source projects, hunt for security vulnerabilities, and triage reports. For a long time, one of my biggest goals has been to learn something new as often as possible and get to know people who share a similar passion for what they do.
How long have you been bug hunting and what are you driven by ?
I have been bug bounty hunting for roughly one and a half years, but I have been interested in security for quite a while. Curiosity and learning something new are what drive me the most. I find myself constantly wanting to try something new and learn as much about the topic as possible.
Can you explain the genesis of security.txt ?
security.txt started as a small idea that I put together while visiting New York City. The original concept was published on GitHub and thanks to all the wonderful feedback, I found myself writing up the first Internet draft.
The basic concept of security.txt is a text file that vendors can use to instruct security researchers on how to contact them if a security vulnerability has been discovered. You could compare it to a site map — the individual directives in the security.txt file help the security researcher find everything they need in order to report a security issue. This includes where the vendor’s security policy, acknowledgements page, and PGP key are located.
My next goal with security.txt is to present the concept at the next IETF meeting in London.
What’s the goal of your new project : Bug Bounty Guide ?
Bug Bounty Guide was a project I wanted to work on for a long time. I keep a to-do list of ideas and projects that I would like to create one day security.txt was on this list, by the way — and in Bug Bounty Guide’s case the project consisted of multiple bullet points on that list.
The actual goal of the project is to help educate bug bounty programs and bug bounty hunters on the various aspects and potential issues one might encounter in their bug bounty journey. I regularly receive emails and messages from companies and individuals asking for help getting started. Therefore, I decided that it was finally time to put the whole project together and hopefully help as many people as possible in the process.
Are you concerned by legal aspects of vulnerability disclosure ?
The legal aspects of vulnerability disclosure have only very recently
become a focus point of mine. I stumbled across Amit Elazari and the EFF’s work on the legal side of coordinated disclosure. It became apparent to me how little I know about the various legal issues a hacker has to keep in mind while conducting research and how extremely important the legal aspects are.
Is Coordinated Vulnerability Disclosure enough to build a better and safer Internet ?
Coordinated vulnerability disclosure is only one form of disclosure and I cannot see how on its own it can build a safer Internet. In my opinion, it is down to the security researcher to decide what they personally believe is the best way of disclosing the issue that they have discovered. security.txt is one way for a vendor to describe how they will handle reports on their side and help the security researcher make an informed decision.
Some particularly good examples to demonstrate where coordinated disclosure has led to confusion and misinformed users, are the recent Meltdown and Spectre flaws. Robert O’Callahan wrote a wonderful piece highlighting the various points of failure in the disclosure process. On a side note, I would highly recommend anybody considering defining a coordinated disclosure process read “The CERT Guide to Coordinated Vulnerability Disclosure” . The authors of that comprehensive document are contributors to the security.txt project and really understand the numerous factors required for successful coordinated disclosure.
In the light of MeltDown and Spectre Flaws, to you what is at stake in terms of Hardware ?
I cannot comment on the actual flaws, but one of the next steps with security.txt is to allow hardware vendors to supply security researchers with instructions on how to report security vulnerabilities. It is not clear yet how I will achieve this exactly, but the idea is there and I have individuals from the hardware security field helping me.
Do you think Artificial Intelligence one day will replace human bug hunters ?
I am almost certain that we will see more and more automation and maybe even artificial intelligence in the bug bounty industry. I know for a fact that many of the top hunters have their own set-ups that automate a significant portion of the process. It is important to note that while the tools do cover a lot of the mundane tasks, a human is always required to verify the actual issue and demonstrate exploitability. Interestingly, automation is an important concept that I am trying to introduce to security.txt. If I make security.txt machine-parsable then the file could be used to automate part of the disclosure and hunting process. Tools such as Burp Suite could use the security.txt file to quickly configure the tool for the target.