The beginning of this month marked my first year working at GitLab. Before joining the GitLab team, I'd been doing security consulting and penetration testing for my entire career. I didn’t change jobs much until last year ... actually I haven't at all. I'd been happily hacking all the things over at Recurity Labs since 2007.
I would like to use my first anniversary here at GitLab to compare both sides, namely penetration testing and security consulting versus the product security side of security. Nowadays, I’m working on the Security Research team here at GitLab. A lot of my work is closely interwoven with the Application Security team: reviewing features and merge requests, and responding to pings asking for security advice. It appears a bit like in-house security consulting, but in reality, the work is much broader in general and I’ll outline the main differences here in this post.
Distractions
I was a bit baffled when I was asked, ‘How do you keep state? How do you take notes about your projects?’ in the very first run of the Source Code Audit Training I delivered as a security consultant to some in-house security team. About a decade into the job at that point, I'd never thought about the massive distractions one might have being part of a product security team. It was a simple question: the team was wondering about my note keeping techniques. At this point I didn't have any good answer. I didn't have an external process to keep track of my projects. Why? Because I had the luxury of executing one project at a time; only one thing to hack, only one thing to focus on deeply for a week or two. I could just rely on my memory because I barely needed to context-switch. When the project was over, I dumped my findings into a report and was ready to move on to the next project.
In my current role, I’ve since adapted to the huge amount of context switching one needs to do in the day-to-day work. Though, I still need to find the perfect note taking solution for myself (if you have any cool pointers, just leave a comment with this post). And generally, having a greater variety of tasks and obligations during a week of work is something refreshing, at least for me. It allows me to switch topics in the event I’m stuck on something. Later on, I can switch back with a fresh mindset ready to tackle the problem, possibly with a new perspective.
Thinking broad vs. deep
I was used to thinking very deeply when performing code reviews. And, during a pentest, you can dig really, really deep into the application you're assessing (please stay in scope though ;D).
However, in product security you are delivered the output of that deep thought process. Often the job of the in-house application security engineers is to communicate security impact and consequences to engineering and product management teams; effectively switching from thinking deep to thinking broad.
When I was writing assessment reports on the consulting side, I expected a certain, rather high level of security expertise on the receiving end. Now, on the product security side, the information shared has to be communicated to development and product management counterparts in a readily understandable manner. Suddenly, things need to be taken into consideration, which an external security consultant (luckily :sweat_smile: ) doesn't have to think about. This might be, for instance, product decisions or other non-technical aspects. This intersection of product security engineers and external pentesters is where friction can emerge. One side might disrespect or poke fun at the other side, due simply to the lack of some context or information the counterpart has. That being said: the "other" side typically isn't "ignorant" or less skilled, they just have another level of focus (deeper or broader, perhaps) and, most importantly, different priorities.
Being able to take-on the perspective of someone else is a great skill to have in almost any situation in life. That’s just a general take away. This being said, though, I’m not accusing any pentester of not possessing this skill -- it’s merely that they’re not expected to have this in the context of a pentest. Rather, it’s the deep level of technical abilities they’re hired for. For me, the change was quite beneficial. The variety of tech stacks is lower here at GitLab; for instance, I don’t think I’ll see too much PHP or Java code to audit, but the broadened view beyond the horizon of technical questions was a trade worth making for me.
We're in the same boat
Be it a security consultant doing a code review or an in-house application security engineer triaging and validating bug bounty submissions: they're on the same side. Ultimately, everyone wants to improve the security posture of whatever they're in charge of. For a pentester this "thing they’re in charge of" changes with every project they take. For in-house application security teams it's roughly the same product the whole time. While the goal is common, it is the work and the environment that can differ a lot. I personally am happy to have made the step to "the other side", working in product security now. It has given me the opportunity to approach security issues from new and, at least for me, unusual angles.
Photo by Jason Polychronopulos from Unsplash.