We asked GitLab sr. security engineer Andrew Kelly about the projects he’s working on, what he’s learned from mistakes he’s made in InfoSec and why writing unit tests for unexpected events is so important.
Name: Andrew Kelly
Title: Senior Security Engineer, Application Security
How long have you been at GitLab?: I joined July 2019
GitLab handle: @ankelly
Tell us what you do here at GitLab:
I work with GitLab teams and HackerOne reporters to ensure that GitLab products are secure. This includes conducting application security reviews, verifying and determining the impact severity of vulnerabilities, collaborating with development and product teams on solutions, and a variety of other application security related tasks.
What’s the most challenging or rewarding aspect of your role?
I find that one of the most rewarding aspects of my role is working with our HackerOne reporters. The GitLab bug bounty program receives reports from all sorts of hackers all over the world and I really enjoy the process of investigating and triaging their findings. These reports describe potential vulnerabilities impacting a number of different GitLab applications and systems. Oftentimes, while recreating a vulnerability or investigating a report I end up learning something new about application security or GitLab itself.
And, what are the top 2-3 initiatives you’re currently focused on?
I’m the application security stable counterpart for the Growth and Enablement teams. Application Security stable counterparts collaborate with teams throughout the software development lifecycle to assess risk, review code, and otherwise help drive security-conscious outcomes. This has given me an opportunity to work with an amazing and talented group of people on a number of different projects and in much more depth than I might otherwise be able to.
In addition, I’ve recently been working to help get GitLab’s Secure tooling enabled in several of our major product repositories. This effort has involved coordination across teams, code review, and working with CI/CD configurations. This impacts a significant number of GitLab repositories and I’m excited for the amount of coverage this will provide. I’ve also been involved with configuring and enabling the GitLab container scanning tools to analyze certain docker images.
What is the most significant piece of security advice you could provide to a colleague or friend?
Write unit tests that cover unexpected cases. Oftentimes when writing software we get focused on expected use cases and our specs tend to reflect that bias. In order to improve application security, I recommend taking the time to think about creative and malicious ways that user controlled input can be abused. This is worth the effort because you will inevitably find situations in which the code did not behave the way you expected and this will help you prevent some security problems before they get released.
How did you get into security?
I spent a lot of time on the internet growing up. My experiences online and the depiction of hackers in pop culture sparked my interest in security at a young age. It wasn’t until several years into my software development career that I realized it was something I was capable of doing and could do professionally. I started by learning about common web vulnerabilities and looking for them in the codebase that I contributed to as a developer. Over time I continued to learn and build my information security knowledge either on the job or in my freetime.
From the perspective of your role, what’s GitLab doing better than anyone else in terms of security?
I’m hesitant to say that we’re doing this better than anyone else, but I’m very proud of GitLab’s commitment to transparency. Our teams are very committed to clear, open communication internally and with our customers and community members. This is especially true with regards to security -- transparency is baked into our procedures and processes and is always at the forefront of our minds. From a security perspective, this can be a tricky balancing act but I’m happy that it’s something we take very seriously. I think Dominic Couture covered this well in a recent blog post (“Security strengthened by iteration, and transparency ”) that I recommend reading.
What was your personal worst moment in the Infosec world and how did you recover?
Years ago I wanted to build an application using a particular platform’s API, so I searched for and visited what I thought was the correct website and tried to log in. For some reason, my password didn’t work so I tried it a few more times and eventually gave up. Hours later I was alerted to an attempted sign-in to the real website from a location thousands of miles away. At this point, I realized the mistake I had made. In my haste I didn’t notice that the website I was putting my credentials into was actually using a homograph to trick people whose attention is divided like mine was into giving up their passwords. Luckily I had two-factor authentication enabled and so my account was still protected, but I learned and reinforced some very important lessons that day:
- Slow down and take the time to verify the address of the website you are visiting before entering any credentials
- Better yet, bookmark important sites rather than searching for the website you’re looking to log into
- Use a password manager and ensure you use unique passwords for each website
- Enable multi-factor authentication everywhere that it is supported
These last two pieces of advice are something you’ll hear from many security professionals, including some of my coworkers -- like in this post, "The sky is not falling: tips to avoid the FUD and protect yourself online".
What would you like to see more of in the industry?
I’d like to see vulnerability management integrated into the software development lifecycle across the tech industry. Organizations large and small are typically building applications bundled with dozens, if not hundreds, of dependencies and third-party libraries, all of which have the potential to become security concerns. Tooling and alerting has come a long way to help out, but it still requires organizational discipline and a not insignificant time investment. This can be a time-consuming task and often involves a lot of collaboration on behalf of the engineering and product teams, but is worth every bit of effort.
Now, for the questions you really want to have answered:
VIM or EMACS?
I believe that you have to choose the right tool for the job. It just so happens to usually be VIM, at least for me.
What was the first computer you owned?
The first computer my family owned was a Commodore 64. My experiences playing video games on that and other early consumer computers paved the way for a lifetime of interest in technology.
Show us your frequently used slack emoji list. What do you think this says about you?
My current 'Frequently Used' emojis indicate to me that I probably spend a little too much time in the #dog channel 😆. It also appears that emojis are my favorite way to say thank you.
Photo by Christina Morillo from Pexels.