How do bug bounty hunters use GitLab to help their hack?

Higher agent accuracy, lower token cost
Learn how to harden your software factory and let AI agents earn autonomy, without trading away security.
Stay updated with our latest features and improvements.
Published on: June 11, 2021
We know GitLab is a complete open source DevOps platform, but can it improve your hack? We chat with three bug bounty hunters to find out.
GitLab is best known as a complete open source DevOps platform, delivered as a single application, but it also offers powerful project management and collaboration capabilities. In fact, every GitLab team uses GitLab to develop, track and collaborate on projects, processes, and programs.
But, what about... other uses? Say ... hacking, for instance. 🤷‍♀️
Can GitLab help a hacker fine-tune their craft? Through our Ask a Hacker AMA series we discovered that there are some bug bounty hunters who use GitLab to streamline their research process. And, like so many cool and awesome things, we learned on Twitter about another contributor using GitLab for bug bounty hunting. So, we followed up to learn more.
Alex has been hacking for 14 years professionally, but his interest was piqued well before that!
🦊 @ajxchapman on GitLab 🪲 @ajxchapman on HackerOne 🐦 @ajxchapman on Twitter
Dominic is a senior security engineer on GitLab's Application Security team and has been hacking for fun for roughly 20 years, though he admits there were some "long periods in the middle where he didn't do too much". 😆
🦊 @dcouture on GitLab 🪲 @dcouture on HackerOne when working and dee-see on HackerOne when playing! 🐦 dee__see on Twitter
Nishant has been hacking for 1.5 years and is currently working on LinkShare, a platform which enables users to share and categorize bug bounty resources. 🦊 @archerl on GitLab 🪲 @archerl on HackerOne 🐦 @realArcherL on Twitter
Alex: I use GitLab for all of my bug bounty issue tracking from idea, through discovery, POC development and report writing. One of the biggest revelations for me in bug hunting involved note-taking. I used to be terrible at recording my thoughts, progress and ideas when hunting for bugs. This meant whenever I got sidetracked, or took a break, I would inevitably forget what I was up to and what leads I was working on.
Now I record everything I can in GitLab issues. Have a random thought about something to check? Create an issue for it. Spot a potentially interesting bit of functionality while pursuing another bug? Create an issue. Get inspiration in the shower? That's right, get out the shower and create an issue. Even if I don't think it's particularly useful at the time, it can sometimes spark something several days later and I can go back and find those notes. I tag each issue with a label specifying what kind of issue it is (bug, task, lead, etc.), how worthwhile I feel it will be to complete, and how much effort I think it will require. This way when I complete my current bug exploration path, I have a whole load of leads I can go back to and pick from and investigate.
At the end of each bug hunting session, I always make sure I take five to ten minutes to write down any outstanding thoughts so nothing is lost between bug hunting sessions. This way of working means I always have a pipeline of things to investigate and, when I wake up in the middle of the night with a new idea on how to exploit something, I can just add to the existing issue and push it off until morning. Whereas before, I might have got up and started working on it right away. That's not really viable for me these days, I'm certainly getting older and I need my sleep 🤣
As an issue progresses from a lead to a reported bug, I label the issue with the bug bounty program report state, and finally as bugs are paid out I label the issue with the payout amount. This helps track lucrative programs and functionality for future research.
Editor's note: To dive even deeper into how Alex approaches bug hunting, check out his "Ask a Hacker" profile blog and this Ask Me Anything session we held with him where he talks about everything from what inspired him to start hacking to the types of bugs he likes to hunt.
Dominic: I use GitLab private projects to collaborate with friends on hacking projects. Our approach is simple: Each idea about a potentially interesting thing to explore gets its own issue and then we discuss, via comment thread, the different attack vectors and the things we try and whether our attempts work or not. Everything is documented with screenshots or code snippets using the markdown formatting. When we find something it's reported and a ~reported label will be applied. The issue is closed either when a reported issue is accepted by the bug bounty program or when we've finished exploring an idea and found nothing. This helps us collect all ideas, validate them and exhaust all possibilities we can think of before moving on.
The other useful part is obviously the git repository. Any script that we come up with, any important file that was found, or any general note that isn't related to one specific issue is pushed to make sure it isn't forgotten over time. I have a handful of interesting targets that I like to focus on for a month or two in rotation so I can give them my full attention and go deep. This means that a given target will usually be focused on once or twice a year with long downtimes in between. The repository contains all the things I'll definitely forget and will help bring me back up to speed when the time comes.
Nishant: Like all great things, we stumbled upon our next contributor's story via the internet. Twitter to be exact. 😉
I've been using GitLab for my blog, where I post details about bug bounties, and the CI/CD feature is really easy to use. I chose GitLab to host my CTFs and hacking POCs because GitLab has shown that it is friendly to hackers (Kali Linux is even hosted on GitLab) and with the Web IDE, I can edit them from the repository itself.
Recently, I've been using GitLab to work with other hackers on