A Penetration Tester’s Journey to the Code Analysis Camp

Most of you know me as an offensive security gal. The fact that I decided to join a SAST team frankly surprised me as well.

Now that I have officially started my job at ShiftLeft, I am taking this moment to reflect on how I got here and how I see the future of application security.

Confessions of a newbie web developer

I started my career as a web developer. And I absolutely loved it! I loved building tools that solve someone else’s problems. And there is no feeling like seeing your vision materialize right in front of your eyes.

I developed many applications used by medical professionals. And my apps were often handling sensitive information of children and patients. So security was always at the back of my mind. I wanted to protect my users’ data but had no idea how to secure an application. Learning about application security felt overwhelming. And honestly, I had a lot more to worry about other than security: fixing UI meltdowns, deciphering old codebases, and dealing with surprise data losses ate up my day.

Penetration testing and bug bounties

Then, I discovered bug bounties (my first bug was a CSRF!) and eventually got into penetration testing. I worked to find vulnerabilities in client applications and helped fix security holes.

Through my experience, both building and securing web applications, I learned two things:

  • Serious security vulnerabilities often stem from small programming mistakes, and
  • It is easier and cheaper to find security vulnerabilities early in the software development life cycle (SDLC).

Offensive security practices like penetration testing or bug bounties are a great way to secure your applications. But they should only be used as a fail-safe to catch vulnerabilities that slip past security protocols implemented during your development cycle. Catching issues and errors early can save you a lot of time and headaches.

I became quite discouraged with what I could do to secure applications as an individual penetration tester. I can focus on securing my client’s products but can’t do much about the security environment at large. There is still a lot of insecure code out there, and I want to help change that.

Securing software is a complicated business. I want to make security approachable and help developers integrate security into their processes.

Looking ahead in infosec

Here are some challenges I see ahead and what I hope to help solve by teaming up with the folks at ShiftLeft.

  • How can we help developers learn about security concepts?
  • How do we make it easier for developers to integrate security into their workflow?
  • And above all, how do we make developing secure software easier for our fellow developers?

What is the most challenging part of developing secure software for you? I’d love to know. Feel free to connect on Twitter @vickieli7.

You may also enjoy