Infosec

Breaking In: My Journey from Code to Cybersecurity

Today marks exactly three months since I landed my first cybersecurity role after being in software development for over 4 years. I wanted to share my journey and go into detail about how and what I studied, how I handled rejections and persevered throughout my job search and ultimately how I landed the role I’m currently in. I hope you enjoy!

Where It All Began…

As *some* of you may know, I transitioned into software development from customer service and fast food back in 2018. I was inspired to start learning how to code back in 2017 when I watched a documentary on Aaron Swartz, a programmer and hacktivist who was passionate about freedom of information and open education. I freaking adored his vision. When I watched the documentary, I knew I wanted to get into cybersecurity but didn’t know where to start so I learned how to code (you can learn more about it here). I started working as a front-end developer in the summer of 2018 and since then, I’ve traveled to speak at conferences on web accessibility as well as worked as a contractor for different startups.

In 2022, the thought I had of transitioning into cybersecurity creeped back. I discovered TryHackMe and completed their Pre-Security path which introduced me to the basics of networking such as the OSI model and how DNS and HTTP works as well as Linux and Windows OS. I also learned how to utilize virtualization in order to set up an Ubuntu machine and learned how to do things such as set up a LAMP stack to launch a WordPress site as well as how to automate the provisioning of that using Vagrant. But then my studies took a backseat as I started to encounter health problems. The doctors couldn’t diagnose the root cause of what was going on but I was essentially battling a mixture of constantly feeling like I was going to faint, lost 70% of my blood, and hemoglobin levels just absolutely dropped. Eventually I wasn’t able to walk. Previously I had never had any serious health issues. My motivation and energy was at its lowest so I couldn’t devote more time to being consistent with my goals like I wanted to.

New Year, New Beginnings, New Motivations…

Starting in January 2023, my drive for cybersecurity was renewed. I had just recovered from my hospital stay and I came to the realization that the person I aim to be in six months is shaped by the daily actions I commit to right now. I knew I wanted to become a security engineer. So, the journey began.

The first book I got into was “Linux Basics for Hackers,” and it taught me cool stuff like file compression, navigating the filesystem, as well as Bash and Python scripting. I even picked up on why VPNs matter and how to set up proxy chains. Next, I started getting to web app pentesting and some network pentesting and used courses from TCM Security as my guide. I set up home labs which I highly recommend to get hands-on practice with different tools such as Burp Suite and nmap. I completely abused my poor little Macbook Air that only had 8GB RAM and was determined to have multiple VMs running XD. The next books I read included Network Basics for Hackers, Networking for Dummies (which is actually a great book that I need to finish), Bob and Alice Learn Application Security and a bit of Bug Bounty Bootcamp.

When I started learning web app pentesting, I learned how to use Docker to set up containers to host intentionally vulnerable web apps such as Juice Shop, Damn Vulnerable Web App (DVWA) and more. I was gifted a one-year Burp Suite Pro license from HackerOne which was pretty cool! I used TryHackMe to learn the OWASP Top 10 which is a list of the most critical vulnerabilities affecting web applications. While I was solving challenges and completing the module, I worked on a blog post along the way that delves into how to test for, exploit, and remediate each of those vulnerabilities. I found myself truly enjoying what I was learning, it made me happy learning a variety of techniques and opened my eyes as a developer on the many different entry points an attacker can find to infiltrate your system.

I developed a few tools too along the way such as a web reconnaissance script that utilizes different tools to gather information on a target, a script that utilizes Shodan’s API to find vulnerable targets, and a port scanner. Python became my favorite language.

I was advised by an acquaintance at the time to pursue the Security+. It’s an entry-level CompTIA certification that validates that you have a solid understanding of foundational concepts. You become exposed to different concepts such as least privilege, CIA triad, the Cyber Kill Chain and vulnerability management. You also learn about how to secure networks. It’s a multi-choice exam with a few scenario-based questions that require you to make decisions on how you would remediate different security issues. I started studying for the Security+ around spring time. I used Darrill Gibson’s book as my guide after failing to stay motivated when I would use resources such as YouTube and Udemy. I delve deeper into how I prepared and studied for the exam here. I ended up passing on April 27. The next day I flew out to Baltimore, Maryland to give my first cybersecurity talk at B Sides Charm. I was completely nervous.

The Job Search Begins…

Speaking at B Sides Charm in Baltimore, MD. The audience was very kind. 🙂

As soon as I was Security+ certified, I started applying. The person who recommended that I take the Security+ advised me to focus on applying for roles in the government sector. I tried lol. When I was at B Sides and explored the job fair section which was filled with government contract companies, I was repeatedly rejected and told to go back for a college degree. It didn’t obviously deter me from my pursuit in becoming a security practitioner, just a roadblock. I started applying for jobs online **heavily**. The titles I was applying to fell under pentester, security engineer and analyst. The title doesn’t really matter – I say that because companies could have security analyst and security engineer roles that essentially do the same thing. I paid special attention to the job descriptions and requirements instead.

I signed up for Dice and put that I was looking for application security roles. I decided to pursue roles in that area of security because I felt like with my coding background as well as my newly acquired knowledge of web attacks thanks to my home labs that I could do well in that type of area. I definitely received calls everyday for roles (including web app penetration testing) but they always said I needed the OSCP or security experience, which I did not have. I also applied to SANS scholarship opportunity where they provide people with no security experience the opportunity to receive their training and access to achieve 3 of their super expensive yet well recognized certifications. I put my all into the application process but was ultimately denied. But I kept going.

My mental health was at a low point. The job market is brutal. I see it everyday on LinkedIn, countless people looking for work for several months, even with amazing backgrounds and credentials. The mass layoffs were occurring, many ofmy friends have lost their jobs or are on their way to. It was nerve racking. I had constant thoughts on whether I was going to succeed.

300 Applications, 1 Interview & 1 Offer Later…

I came across a post on LinkedIn from Naomi Buckwalter, a security professional who is passionate about breaking down barriers to get people into cybersecurity. Every week she shares job postings from companies looking to hire for their entry-level security roles. This one particularly stood out because it was an entry level security researcher role. The job description was simple and to the point, looking to hire someone who is passionate about application security and who can read and write code. I was like oof, I know this will attract hundreds of applicants right away lol but I submitted my resume anyway.

Semgrep is a company headquartered in SF that specializes in creating application security tools. Their product ranges from a SAST tool that allows you to scan code for vulnerabilities as well as Supply Chain product that scans for CVEs in open source dependencies. They also just released a Secrets tool too!

Not longer after, a recruiter from Semgrep named Jason Ling reached out and offered to schedule an interview. I was flabbergasted lol. At this point I had applied for hundreds of roles and was met with rejection after rejection and feedback to pursue more certifications or to get security experience (??). I happily obliged. The call went well, he inquired about my knowledge of CVE’s and what I’ve been learning.

Right after the call, I was invited to the technical. He sent a document that beautifully detailed what I would be tested on. The technical screen consisted of doing some live coding in my preferred language (I chose Python), debugging source code and write Semgrep rules to detect a CVE.

Prior to Semgrep, I had zero experience with SAST or SCA tools. So, what did I do? I read the Semgrep documentation and played around in their playground which lets you write and test rules. They had 2 modes – the easy mode just lets you focus on writing the pattern but the more advanced mode exposes you to a YAML file that lets you use different metadata to provide more insight into the rule you’re writing. I challenged myself to utilize the advanced mode in order to learn. I spent my time learning all that I could about secure code reviews from workshops and conference talks that I found on YouTube and taking vulnerable code from a vulnerable web app to write Semgrep rules to detect them.

Before we started the technical interview, I messaged Jason expressing gratitude for the opportunity. My mindset was that regardless of the outcome, this was a learning experience and only the first! I definitely listened to Lil Uzi as I was preparing for the interview lol I needed to listen to music to keep my mind calm. The interview started off cool. The task was to solve different live coding challenges as well as read code and communicate to the interviewer my understanding of it. Then I was given a CVE and told to write a rule. That’s actually where I struggled lol I didn’t know how to begin analyzing the CVE. He guided me on utilizing GitHub Security Advisory as a resource and then we went from there. I’m so glad I took the time to learn their syntax before the interview!

Now how did I feel after the interview? I felt like I performed better than I had originally imagined, but at the same time I thought I bombed it lol. But then Jason hit me up right after the call to inform me that I passed the technical with flying colors and that they’d like to invite me to the final round where I would meet with the hiring manager, Adam! I screamed. I definitely did lol.

The call with Adam went well. His objective for the interview was to determine my style of communication and to learn more about their culture and how they operate. It is a really flexible team. Everyone is remote and in different locations and you don’t have to wake up and do work at a certain time, just as long as you’re putting in effort and getting the work done.

On July 13th, I received an offer from Jason! I was completely ecstatic!

The Journey Begins…

My first day started on July 31st. I was invited to fly out from Jacksonville, Florida where I live to San Francisco, California to meet the team for the week. I’m a pretty reserved person but I knew that since this was a remote role, this would be a great opportunity to get to meet the other analysts and the rest of the company. The week I flew out was great timing – it was Hack Week which basically is time to explore and work on your own projects and participate in team-bonding events. Some of my favorite memories include:

  • Going with the rest of the Supply Chain team to learn how to make ramen from scratch
  • Go on a boat ride with the company to explore the bay and see the Golden Gate bridge
  • Hung out with some of the security researchers on my team and listened to them trade hacker stories over drinks

I was struggling to write my first rules during that week lol I felt like I was in over my head. I made it a point to shadow the other analysts to get a sense of their CVE analysis processes. Our analysts and researchers are some of the brightest minds I’ve ever worked with and they’re all so willing to help each other. There’s no such thing as a dumb question, all curiosity is invited. And for someone who is new to this kind of work, this was refreshing and cathartic for me.

I have 1:1s with my manager and our security researcher every week so we can discuss any improvements that can be made, any roadblocks I’ve encountered and ways I can keep progressing in my role. The training is all hands-on, they were right that experience is the best teacher. I’ve been able to only write 3 rules in my first week to now averaging 40-50 a week, sometimes more. They put emphasis on collaboration and quality rules, not quantity. We all play our part and help each other. I appreciate them all so, so much.

Life of A CVE Analyst

My daily routine is fairly simple. I wake up at 8am (I don’t know why I do, I just love to get my work done early) and I triage alerts in our queue for the latest CVEs from GitHub Security Advisory. Our primary focus is on CVEs discovered in open source dependencies such as Jenkins plugins for example! Everyday I’m researching all kinds of vulnerabilities affecting software ranging from prototype pollution, HTTP request/response smuggling, cross-site scripting, SQL injection and more (those TryHackMe and Portswigger labs came in handy 😅)!

My CVE Analysis process begins by learning more about the CVE to get an understanding of it. I begin to learn how it works by analyzing different references linked to it and possibly testing out any available Proof-Of-Concepts (PoCs), walkthrough demonstrations of the exploit as well as utilizing any other resources. Then I begin to write the rule to detect that vulnerable pattern. Let’s say there was a vulnerability discovered in an open source library called HackMe.js where one of their functions, hackme.functionName is vulnerable to arbitrary code execution because it relies on a dangerous, deprecated function. I would dig through to find test code or develop a simple one to use to test my pattern on. The goal is to reduce false positives by fine-tuning the rule and looking for different use cases of that vulnerable piece of code. You’re analyzing CVEs found in a variety of languages from Golang to JavaScript and more so you have to research the different ways to call certain objects to start. Upon testing the rule and submitting it for review, it gets merged to our database of rules.

You don’t need to have knowledge of every single language you come across. Arguably the more important skill to have is endless curiosity and a research mindset. However, being in this role does make me want to pursue other programming languages that I frequently see.

Now that I’ve been in the role for a little while now, I’ve begun reviewing the rules that other analysts have written and I’m becoming interested in writing my own blog posts on the more fascinating CVEs that I’ve come across! The next step after CVE Analyst is security researcher, we’ll see what happens! 🙂

What’s Next On My Journey

Every day I’m working on my plan to become a better analyst and researcher. There are certification goals that I have – like taking the PNPT – but I’m more focused on doing the best that I can in my role. So that means keep triaging CVEs and writing more complex Semgrep rules, possibly find my own CVEs, and getting deeper with application security. I typically spend my time after work on HackTheBox Academy too! It’s an ongoing journey and I’m always excited to dig deep because I truly do love all things security. I’m also just really practicing gratitude – I love my support system, they keep me going. I’m working on improving in both personal and professional development, balance is key.

Resources:

My Advice For Anyone Else On Their Journey To Security

  • It’s okay for cybersecurity to be the destination, not the starting point – There’s not a lot of entry-level cybersecurity roles as many roles often need specific knowledge or experience in a domain. If you can, identify your transferrable skills and experience and match them with a security role or area in order to increase your chances for a successful pivot. Transferrable skills anything from customer support, sales, financial sector experience and more. f you believe you lack transferrable skills, set smaller, achievable goals to fill in knowledge gaps and acquire technical skills. Get your foot in the door and work your way up that way. Again, I’m not saying it’s unattainable for those without any technical experience, you’ll just have to strategize and set realistic expectations!
  • Get Hands-On Experience – Use virtualization tools like VirtualBox, the cloud, or platforms like TryHackMe and HackTheBox to set up your own lab. It can range from a simple Linux virtual machine for daily Bash command practice to an extensive Active Directory environment for running diverse attacks on multiple machines simultaneously. Many neglect creating their own environment, but it’s crucial for practical learning. If you’re into blue team activities, leverage interactive SIEMs for hands-on experience investigating alerts. Whatever you’re deciding to learn, make sure you’re actively practicing as you’re learning so you solidify those concepts. That’s probably one of the biggest mistakes I see from people who are trying to get into tech. You can’t just simply watch videos and read books if you want a technical role.
  • If You’re Unsure Of What Path To Choose, Research – Go on YouTube or TikTok and watch the day-in-the-life videos to get a sense of what people do in their respective roles. TryHackMe also has short, interactive rooms that provide an introduction to the different areas of security.
  • My Thoughts on Certifications – Iss certification necessary? It depends. Certification can help demonstrate your interest in security on your resume and signal to recruiters that you possess baseline knowledge in the domain(s) covered by your certification exam. On the other hand, there are companies that do not consider certifications important. The community is divided on certifications, especially with more organizations introducing new certifications to capitalize on the current cybersecurity craze. But I think everyone can agree that what you DO – such as participating in CTFs, maintaining a blog, engaging with the community, networking, and home labs can take you further than just getting a certification. A common question I see in security subreddits is, “I passed X exam, what now?”. The answer would be to get hands-on experience and apply for roles, not just chase certifications.

Fin

I hope you’ve enjoyed my post. It’s the first time I’ve published anything in months. I lacked inspiration but along the way as I’ve been writing this post, I found that drive. I love helping people get into tech and hopefully my journey helps you on yours. Feel free to comment, ask questions and share if you’d like! Byeee

Where To Find Me:

Twitter

Study with me on Twitch (Upcoming Relaunch Soon)

LinkedIn Baddie