My name is Eric Rosenberg and I am a support engineer at GitLab. I’ve always had an interest in security and have spent my support career with a goal in mind to one day work in a security position. After speaking with some of our security team members, and directors, I was chosen to participate in a 4 week security internship to implement security scanners on some selected open source projects that we have hosted on GitLab.
I wanted to explain the details of my internship and share my experience to hopefully help others that may be chosen for similar internships, and also spread knowledge about the scanners that GitLab offers.
The internship that I took part in was to integrate GitLab Secure features into open-source projects that are hosted on GitLab.com to improve those projects, increase awareness of GitLab’s security offerings, and get us valuable feedback to help us improve the product. Some of the goals to achieve personally were to help others understand how simple it is to add security into their pipelines, build my knowledge of using our scanners and working through any issues along the way, and to help provide feedback not only to the project owners but also back to GitLab.
What I did
My first week was mainly prep work in order to find a few projects that I could reach out to, and hopefully work with, the project’s maintainers/owners. I wanted to explain the internship, what my goals were, and how the security scans could be beneficial. I also wanted to have a stable testing environment that I could copy the project over to, so that I would not interfere with their project, just in case they did not want to participate and also so I would not make any changes that could potentially cause issues on their end. I wanted to also run through all of the security scan types on my own projects so that I could become more familiar with what the scans were, how to use them, and how to read their output. I decided to focus mainly on project ASE as the project owner was happy to have some extra added security, as well as a point of contact for questions on scanning their code.
The second week I had a project owner, ASE, reply to my email and was very interested in working with me. He explained he was busy and may not have a lot of time to communicate with me, however he was happy to have me take lead and add the scans so that I could provide the results back to him. I was able to copy the project to my test instance, run the scans, provide the results, and in the end submit an MR so that they could implement the scans on their end and use them moving forward.
The third week was mainly focussed on the results from the scans and helping provide the answers to many questions the project owner had. This was expected and greatly appreciated from my point of view as this not only showed me that the project owner had a lot of interest in keeping the project secure, but it challenged me to work with the members of our security team and build my knowledge of what needed to be done so that I was able to then relay this information back to the project owner. I felt that I gained a lot of information and towards the end of the week, I was very comfortable discussing steps to not only use the scanners but to make changes to the code to keep things secure. Using the SAST scanner (Static Application Security Testing) I was able to scan the Ruby code and print out known vulnerabilities within the Security & Compliance dashboard within the admin area. One of the things I found interesting was finding “false negatives” when it came to the vulnerability report. For example: “Password in URL detected; please remove and revoke it if this is a leak.” This would cause alarm to anyone that views this in their security & compliance dashboard, however after taking a further look, the password that was being displayed was only an example, which caused no issues.
My fourth week I wanted to dedicate to wrapping up my internship and providing as much feedback as possible. I was able to keep notes along the way, as well as one on one meetings with my internship mentor every week. I felt that the communication was amazing when it was needed. I was able to reach out over slack anytime and either receive the answers I needed, or I was pointed in the correct location so that I could discuss with the team.
Closing Thoughts
Some feedback I would like to add is that the timing, while being sufficient enough to handle what I needed, was not long enough for what I would have hoped for. I would have wished for more time to work on different projects, with different project owners, in order to provide a better outcome of variety within the time of my internship. That being said, since security is still a focus of mine, I am glad that GitLab allows me the flexibility to still keep in contact with the project owners I worked with, and I am happy to continue to help them with the knowledge I have learned from doing this internship, and I cant wait to learn even more.
I believe that in the near future, we will be able to provide internships that can open more opportunities for GitLab team members to be involved with security type positions and raise interests in working in security. I know that it is tough to extend a “shadowing” type internship into the security field as there is more sensitive data being dealt with, but hopefully this internship will continue to be offered and grow to even higher possibilities.
Overall, I am extremely happy that I was chosen to take part in this internship, and I would hope to work more with the team in the future. I have learned a lot and I look forward to using this knowledge to help others including team members and project owners.