My Experience Breaking into Product Security

My story is one of many, and there is no “best” way to break into cybersecurity. It’s a vast field, with many specific disciplines within it - so to understand it, it can help to read what others have done and learn a bit from the path they took.

It’s vital to note that there will be differences in these answers based on what roles people obtained. Things that are true for IT Security (“entry-level certifications can help you break in”) may not be true for Software Security (“entry-level certifications are rarely relevant”). Understanding the context behind why authors answer the way they do will help you understand the cybersecurity field more holistically.

r/cybersecurity is working on a directory of these articles - this is the first, and we are working with community members to release more soon. Once written, we hope these will help inform you on your journey towards (or moving around within) cybersecurity!

Index

This is a very long article, as it intends to cover just about everything that people have asked me about my experience getting into security. So if you want to skip around to specific subjects, here’s an index of questions that I answered.

About my first job

• #1 What was your first job in cybersecurity? When was that, and what were your team’s responsibilities?
• #2 Can you discuss some specific tasks you did, or goals you contributed towards?
• #3 What were the most important technical skills that allowed you to succeed in your first role?
• #4 What were the most important attributes and personality traits that allowed you to succeed in your first role?
• #5 What did you like about that job? Is there anything you didn’t like?

About how I broke in

• #6 What degrees, certifications, bootcamps, or field experience did you have at that time?
• #7 Were there other degrees you were considering at the time? Why did you choose the degree(s) you did?
• #8 How did your field experience help you at the start of your career in cybersecurity?
• #9 Out of degrees, certifications, bootcamps, and field experience: what mattered the most for obtaining your role?
• #10 Would you recommend the path you took to get into cybersecurity? Are there cases where you wouldn’t recommend it?

Advice for newcomers

• #11 What are the top three things you think people considering cybersecurity careers should know about the field?
• #12 What coding languages would you recommend people learn to be best-prepared for Product Security?
• #13 What is a project you’d recommend for people trying to figure out if Product Security could be right for them?
• #14 What do you think readers should take away from this series?

And finally, you can learn a bit more about me to understand more about where my perspectives come from. But let’s get into it!

What was your first job in cybersecurity? When was that, and what were your team’s responsibilities? ⏎

My first “true” (full-time, non-intern) cybersecurity job was as a Product Security Engineer in late 2019. In this role, I was embedded with an organization that made products - specifically, we made cloud-managed networking devices such as APs/routers/switches and IoT devices for the small-to-medium business market - and was responsible for the security of those products.

I was the only person embedded with this specific organization, but the Product Security Engineering group as a whole was responsible for answering these questions:

• How is customer data protected within our services? What controls can we build or integrate for better security assurance?
• How can we detect misuse of our devices or services, both from internal and external attackers? How can we scale controls and monitoring in these domains?
• How quickly are we identifying and resolving security problems? How can I measure the success and coverage of the security program we’re implementing?
• What vulnerabilities in our systems or services do we know about currently? How should mitigating or fixing these be prioritized?
• Where are our detection gaps? How complete is our knowledge of the possible vulnerabilities in our platform? What technologies can we employ to increase visibility here?
• Are we on track to meet new compliance goals to provide better security attestation to our customers? Are we meeting our existing compliance goals in an ongoing fashion?

Can you discuss some specific tasks you did, or goals you contributed towards? ⏎

Sure - I was one of several Product Security Engineers, but I was the only one embedded in my specific organization, so I performed many different tasks to improve my organization’s security. Some of these tasks were reactive, addressing specific events or concerns as they occurred:

• Investigating any anomalies in events and monitoring data, across on-premises and cloud environments.
• Researching software or infrastructure security concerns raised by engineers and communicate back recommendations.
• Reviewing and/or penetration testing possibly-risky changes in our code to identify and correct vulnerabilities.
• Triaging responsible disclosures by external researchers and coordinating with internal teams to resolve these.

While others were proactive, smoothing out the road ahead for my organization by making it easier to develop secure software:

• Writing and running internal security training, such as threat modeling basics for developers.
• Auditing our software development lifecycle (SDLC) for security opportunities or gaps.
• Writing internal tools to ensure that previous security issues could not be reintroduced to our codebase.
• Implementing standard technologies for obtaining insights into the security of software applications - among others, this included:
  • Static application security testing (SAST) and security linters to identify possible vulnerabilities in source code.
  • Dynamic application security testing (DAST) to automatically test live systems for security issues.
  • Integrating logs with a security information and event management platform (SIEM) to improve monitoring and enrichment.
  • Web application firewalls (WAF) to monitor for and defend against common or simple attacks.

While there are too many small tasks to list here, this should give you a pretty good idea of what I did. This might seem like “way too much for one person,” which is absolutely correct if I was working on all of this simultaneously, but thankfully I wasn’t. While there were several ongoing efforts that I was working on, on a given week or month I would be pursuing different proactive bodies of work roughly mapped to the Building Security In Maturity Model (BSIMM), which allowed me to improve security procedurally.

What were the most important technical skills that allowed you to succeed in your first role? ⏎

Coding

Reviewing code that developers are authoring for security issues, as well as understanding how that code fits into a larger application, is essential. You will also be expected to write code at times to solve certain problems - maybe resolving a vulnerability (if delegating that isn’t part of your job), writing tools to detect security issues, integrating tools into DevOps processes, etc.

Any area within software security will have much more code-reading and -writing than almost any other discipline within cybersecurity. A lot of people I know in Product Security were software engineers at one point or another in their careers, but while that helps it isn’t a strict prerequisite - it just helps you understand the context beyond code itself, such as an agile SDLC, and gives you ideas for how you might build security into existing development processes.

Broad Foundations

Less related to Product Security specifically, but since I was the only person assigned directly to this organization, knowing a little bit about many things helped me identify gaps as well as address issues when they came up. Some example areas that this role touched on were:

• Linux - Reviewed performance and security changes to our devices which impacted internal packet processing (i.e. how the firewall and IDS on-device are processing packets).
• Applied Cryptography - Assessed a lean, OpenSSL-derived package to ensure it had all TLS 1.2 features we needed for secure communication from our devices to our cloud.

I think people looking at cybersecurity may feel that because it’s such a broad field, they should specialize as early as possible. I would want to dampen that desire - having a strong foundation in many areas can help you, especially on smaller teams where you’ll have the opportunity to own almost everything about your work.

What were the most important attributes and personality traits that allowed you to succeed in your first role? ⏎

Communication

Communicating clearly with all stakeholders, such as non-security engineers, management, customers, and more are imperative in Product Security roles.

• You will often be communicating about security issues to non-security audiences, so you should be able to explain technical problems at various depths.
• You may also need to assist with public-facing communications (in the case of a breach, or vulnerability disclosure, etc.), and therefore need to write eloquently and thoughtfully.
• You will also be designing solutions for the software engineering organizations you support, so you will need to listen, take, and ensure you understand your organization’s needs.

Product Security is not a role where you can put your head down and work solo - you will spend a lot of time working with people. Once in a while, you may spend a half-day (or more) just in meetings - but if you find yourself doing this frequently, that is probably a problem worth solving.

Take Criticism

Eventually, you will be pitching solutions to security problems which may require buy-in from everyone, such as changing some development processes, or enacting certain policies, etc. You should be prepared to explain your ideas, lead meetings, answer questions, and take feedback.

Your ideas are not your baby. They’re not a sensitive subject, or universally correct, or a representation of your total intelligence, or anything like that. Your ideas are a business proposal.

Often, you might not have seen a particular business need or pitfall that other engineers have noticed. Sometimes your idea will be unsalvageable given those issues, and you’ll need to go back to the drawing board. You will need to take all of that in stride - if you are someone who doubles down when receiving constructive criticism, you may struggle to get help and cooperation from your organization, or you may spend weeks/months of effort on changes that don’t increase security.

What did you like about that job? Is there anything you didn’t like? ⏎

The Good

It was really fun to solve problems of all kinds - working with people to improve our processes and technologies. Those changes had clear and meaningful impact for how well we served our customers, and while of course you can’t solve everything instantly, it was great to see our security (and our product!) advance over each week and month in this role.

While I didn’t know exactly what challenges I’d be facing on any given day, I could wake up knowing that I was helping keep our customers safe. Helping people is a big part of why I got into the cybersecurity field, so that always felt great. Being twenty-something and having a position where I could help shape the security posture and maturity of an entire organization undoubtedly helped color my perception of this role too.

The Bad “Depends On the Company”

Something that might not be obvious is that fixing software issues can be complex and (depending on the change) may take a lot of time. This compounds if you need to make process changes as well - enough so that the business may deprioritize or elect not to make specific improvements you recommend, even if the security gains could be significant.

Consider if you find a software signing key on a developer machine. These keys are used to verify that the software your organization releases was actually created by your organization. Here’s the problem - if anyone (an attacker, a malicious insider, etc.) had stolen it from that machine, they could write software that customers would trust because it appears to be legitimate and from your company.

To address this issue: you need to get a new signing key and create a way that protects the signing key from unnecessary access. Just getting a new signing key and giving it to the developers solves nothing! While you’re building the new solution to handle the new key, your organization will still be releasing software that is signed with the old key.

Is this ideal? If you are a security absolutist, no. If you analyze the risks involved, maybe. But in cases like this, you will need to be looking at long-term improvements, not short-term. Some people will struggle with that, but this should be what you expect for Product Security.

And finally, the bad case: if you analyze the risks involved and present a valid business case for fixing the issue, but your organization deems it an “accepted risk,” that’s never fun. You will need to accept that as well - but if this happens so often that you cannot deliver positive security change, you may want to consider working elsewhere. Not all companies prioritize security maturity or understand security risk, which will be bad for morale and professional development in security teams. I thankfully have not worked with companies that accepted too much risk or prevented me from delivering results, but I know people that have experienced that at other companies.

What degrees, certifications, bootcamps, or field experience did you have at that time? ⏎

Degree

I have a BSc from the Rochester Institute of Technology, where I majored in Computing Security and minored in Psychology.

To advance myself outside of classes, I participated in clubs of interest such as RIT’s newly-formed Blockchain Technology Club, where I was a board member and managed internal communications + newsletters. I was also homelabbing during this time, and wrote some software, ranging from DNS scanning and aggregation to a cryptocurrency trading bot (no, it did not outperform the market).

Certifications

The only certification I had was a PADI® Open Water Diver certification. I did not hold any IT or security certifications, and sadly open water diving was not relevant to the role.

Bootcamps

None.

Field Experience

My start was in IT like many others, though I didn’t progress as far in IT. During high school I worked as an IT technician at Staples, and worked with customers mostly on diagnostics and malware removals, though I occasionally scored more work with local small businesses performing services directly for them (such as infrastructure upgrades or disaster recovery). My career in IT effectively ended once I went to college - I continued freelancing in college when opportunities arose but didn’t pursue it very seriously.

Up until my third year of college, I was confident that I’d go into a field like Network Security. In the pursuit of that, I did an internship in Information Security - mostly building out security training and helping out on security administration tasks where I could. My second internship changed that plan: I was an Application Security intern and became fascinated with the complexity of finding and fixing security issues in bespoke software - even while the software was being built and modified around you.

After completing my degree, I took up full-time work as a Software Engineer at the company I had been an Application Security intern for. This was a deal made with the CISO and upper management in the organization, who had the forethought to make sure that I really knew coding and the internal function of the organization before stepping up to implement security practices there as a Product Security engineer - the role I eventually attained, and am writing about here.

Were there other degrees you were considering at the time? Why did you choose the degree(s) you did? ⏎

I’d considered Computer Science, but hesitated because:

• I wasn’t good at Calculus, and struggled enough in Pre-Calc that moving up to Calculus 4 (at some schools) seemed impossible.
• Having read some books on coding and completed some introductory coding courses online, I thought I didn’t like writing code.

So once some acceptances came in, I decided to bet on a cybersecurity degree, which had fewer math and coding requirements but blended in some networking, systems, governance, etc.

I was right on half - my degree required Calculus 1 & 2, which kicked my ass, and I don’t know if I would have made it through college if I had to progress beyond that. I was wrong about writing software though, and found my love for it outside the classroom - in many situations, practical coding and CS-theory-homework (or similar) have little in common, and the projects that I worked on with college friends showed me that I liked coding after all.

This feels a bit ironic, given that I became a Software Engineer after completing my degree, but I stand by my choice. A CS degree may have prepared me more directly on paper, but I would have struggled to succeed and rarely had energy to pursue my passion projects, so it’s dubious if I would have been a better candidate (if I managed to graduate at all).

How did your field experience help you at the start of your career in cybersecurity? ⏎

My prior IT experience was not as deep as many others who break into security after working in IT, but even my limited experience was very impactful in the long term. Working in a customer-first role taught me how to explain technical issues at different levels and depths - this is a skill that I frequently used throughout my role, some key examples being:

• Bringing the right information to managers - ensuring my depth and focus were both appropriate for their business unit instead of dumping useless data on their laps.
• Any time when working with technical but non-security staff on security problems - reframing security problems in the context of what people know, such as software, brings clarity.

This also had some impact to my technical expertise as an engineer, knowing more about small business networking and how the average person saw internet security threats. This would be more impactful if I had gone into IT security spaces, and while I’m happy to have a broader view of the IT field, I will admit that it doesn’t have a huge impact on my work in Product Security (and other software security-adjacent areas).

My software experience prepared me more directly for Product Security, and having intimate knowledge of how an agile software development lifecycle works was pivotal to my work. Understanding how to bring security to developer- and agility-centric processes enabled me to bring more extensive changes to the table without impacting (or sometimes enriching!) developer productivity.

Out of degrees, certifications, bootcamps, and field experience: what mattered the most for obtaining your role? ⏎

At the time that I moved laterally to Product Security within my organization, my Software Engineering experience and degree were the two main factors.

Though get to that initial Software Engineering role, my internships also played a big part, and I wouldn’t be doing them justice if I didn’t mention this. If you’re going to college for a tech role - security, software engineering, IT, whatever - I strongly recommend hunting for summer internships that you can show to potential employers when you’re graduating. My college included internships as part of our graduation requirements (graduates must have two paid summer internships that are degree-relevant), which helped a lot of my graduating class snag jobs when leaving college and helped me find my biggest passions within security. To get more competitive internships, you will likely want to have strong portfolio projects that extend what you’ve done in class, or have relevant personal projects outside of classwork.

Really, no mention of certifications? You don’t wish you had any?

I don’t wish I had any, no. Many beginner and intermediate certifications recommended for IT Security roles are low-value for software-adjacent roles, such as Product Security. This is the kind of advice that is “generally correct but not complete” - many roles in security are in or near IT roles, and will benefit from that knowledge, so I definitely understand why you might see people recommending certifications as the most important factor to have. It’s a recommendation that is true to their experience and the many roles they may interact with, but it omits roles like Product Security that may be farther away from their experiences. Cybersecurity is that broad!

I suppose to summarize though: more knowledge is never a bad thing to have, and if you are considering other roles it’s certainly not a detriment to get these, but having projects (preferably open source!) which are related to Product Security will make a bigger impact to employers in many cases. If I had to recommend any beginner to intermediate certifications for Product Security roles, maybe consider some public cloud certifications from AWS/GCP/Azure - but I’d still more recommend taking the time to build things in the cloud and learning hands-on.

Would you recommend the path you took to get into cybersecurity? Are there cases where you wouldn’t recommend it? ⏎

I think that depends on a few factors:

• Your desired area of focus, if you have a specific one already.
• Your risk tolerance.
• Your ability to take on debt (especially in the USA).

My respective answers to that were “didn’t know, high, moderate” - I was happily “young and dumb” at 18, I guess. I took on much more risk by going to college, beyond the obvious massive costs if you’re in the USA (and therefore debt), there’s no guarantee that you get desirable job when leaving college. Anecdotally, I know lots of grads of the COVID era struggled to find work, vs. people who I knew were let go from professional roles in tech found new opportunities pretty quickly. That all said, if it does work out it can help you enter different roles - in my case, college resources and CS requirements helped me get to a Software Engineering role, most likely in less time than it would have taken me moving to that role vertically and laterally from IT. Conversely, if I had gone into IT Security after college, I’d be lacking knowledge compared to someone who had just been doing IT for those 4 years.

It’s definitely not the only way, and it’s not perfect for all people. For example, you may want to consider non-college options if you:

• Historically struggle in academic settings.
• Have lower tolerance for debt or risk.
• Need to provide for yourself or your family.
• Would prefer to get experience on-the-job.

The other option that I see recommended frequently is to break into IT and work up. It’s lower barrier to entry, low risk, and probably equips you better for the cybersecurity field that a degree does if you know you want to look for IT-adjacent roles in security (such as IT Security, System Security, Network Security …). Starting in helpdesk with some IT certs and self-study will take a few months or up to a year depending on what your prior experience looks like, but it is a reliable foot in the door and many successful security engineers I know went that route. It’s not glamorous when you’re starting out, but you’re learning on the job, being paid to do so, and getting the most valuable currency of all: professional experience. This minimizes your debt and may help insulate you from risks like long-term unemployment, recessions, etc.

What are the top three things you think people considering cybersecurity careers should know about the field? ⏎

I’ve stated this in the prior answers, but I want to reiterate: my number one thing that you should know about the field is that the one true path doesn’t exist. There genuinely isn’t a “best” way to break into cybersecurity. Cybersecurity is an extraordinarily broad field and you should find the path that’s right for you - even if that can be winding at times. We all benefit from people breaking into security with various sources of expertise, broad experiences, and passion for whatever it is you are doing or have done. You shouldn’t go to college because I did, in the same vein that you shoudn’t take a helpdesk role because someone said that’s the fastest way in - you should find the way in that’s right for you and your situation.

The next thing that I would want to impress on you is that cybersecurity can be a fun, empowering, and impactful field for many people - I felt my Product Security role was that and more - but cybersecurity is not like what you might see in the media. Ethical hacking is an excellent example of this: what you see is the cool hack at the end, not the weeks or months of research, trying something, failing, hitting a wall, trying again, keeping notes, asking other people for ideas, or even giving up and trying something else. Basking in media attention and waving around your cool new exploit is maybe 1% of your time - if you’re lucky. Please think carefully about the tasks and responsibilities I’ve discussed, and especially please try some hands-on activities before taking any significant risks on Product Security.

Finally, cybersecurity is tough to get into. The media, certain bootcamps and colleges, etc. will take news about the “cybersecurity talent gap” and twist that into implying that cybersecurity jobs are easy to attain, or even worse, that there is “negative unemployment in cybersecurity.” What they conveniently omit is that current hiring priorities in the cybersecurity field are heavily biased to candidates with prior experience - fundamentally, “we need experienced people to trust with securing our corporate data.” Unemployment and underemployment are still a definite possibility in the cybersecurity field, and you should be prepared for some risk and difficulty when breaking in (though this is admittedly still less of a struggle than many non-tech fields, it’s not a field that guarantees employment).

What coding languages would you recommend people learn to be best-prepared for Product Security roles? ⏎

In my opinion, there are two “you-must-know-these” languages:

• Start with Python. Python is easy to learn, quick to read and write, and hugely popular within the security field. Python is still my daily driver for personal projects and certain work things.
• Then, get familiar with C. A lot of software is written in C, and you should be familiar with memory vulnerabilities, as these are still a colossal issue.

I’d have been entirely lost at many points in my studies and career if I hadn’t started with Python + C. From there, you’ll probably want to build out your repertoire, but it depends on what kind of products you’d be interested in securing. Some examples:

• For IoT, you’ll be pretty close to the hardware here, so keep working on your C, and pick up Assembly (ARM or MIPS).
• For Web, you should be familiar with JavaScript and a serverside language (PHP is a perennial favorite and has a substantial market share), CSS/HTML basics to understand what happens in the frontend, and SQL basics for interacting with common databases.
• For Cloud, this is a bit of a wildcard - I’d get familiar with Go and TypeScript instinctively.

Reading this, you might be concerned that it’ll take a year or more to learn each of the many languages mentioned - this is thankfully not true for most people. Your first language is hard to pick up and could take a year or more of work. It certainly took me a while to code without constantly copy/pasting from StackOverflow. While moving from a memory-safe language to C or from C to Assembly is still tough, changing between contemporary languages such as PHP, JavaScript, Go, etc. won’t take as much effort. This is because you’re translating existing problem-solving skills into a new medium, and just need to learn the quirks of each language to be pretty proficient.

Is this section going to be a struggle for many people? Probably. It was a struggle for me too, but it’s certainly not impossible.

What is a project you’d recommend for people trying to figure out if Product Security could be right for them? ⏎

This is currently in progress, but will be posted separately.

Not to leave you in a lurch while I flesh out some more context and background for why I recommend these, and building criteria so you can self-evaluate your progress: I was asked this before and gave the following answer.

If given Damn Vulnerable Web App (DVWA), could you:

• Identify flaws in it manually through code review and when using security tools on it when live.
• Document the security issues and how to fix them in a developer-friendly way.
• Automate identification of possible security issues via SAST and DAST, and analyze what gaps SAST/DAST left.
• Write, test, and deploy changes to fix those security issues yourself.
• Harden the system where DVWA is deployed to minimize blast radius of attacks, or detect anomalous behavior.
• Deploy DVWA to a cloud provider and mitigate threats through that provider’s security offerings (e.g. implementing a WAF).

What do you think readers should take away from this series? ⏎

Above all, I want you to be able to use this to answer some of your own questions about the cybersecurity field - like:

• Based on the tasks and skills listed, does this sound like a role that I could be successful with?
• What’s the right path towards this role for me based on this information?
• What skills, talents, or experience do I bring to the table now that could help me succeed in this rule?

I think that you should use your own judgment to answer these questions. The context of your interests and life’s experiences matters, and you know that context better than anyone else can. You might not find the perfect answer immediately, but that’s ok - keep trying, and keep working to find the truth.

I know this was a lot of reading, and maybe after all of this, things seem more daunting and foreign than they did before. While I think you will do a lot of research and work while building your foundations in cybersecurity (especially if you keep reading other articles!), don’t be afraid to go out and try things. I hope you will try my projects or projects that others recommended - the journey of a lifetime always starts with a single step, and it’s never too early to try new things.

I’ve been honored to work with so many people who seek to lift others up, and I look forward to working with many more people throughout my career. There are so many problems to solve, and we need creative, thoughtful, and intelligent minds to drive these changes. Maybe after all this, you’d consider joining us too!

About the Author ⏎

My work has remained focused on software security since my Product Security role, and I had a brief stint in Vulnerability Management before my current role in Cloud Security. In my spare time, I pet the heck out of my cat, help moderate r/cybersecurity and r/cybersecurity_help, and get involved in cybersecurity shenanigans. I’m so excited about new and convenient ways to authenticate that I once paid a pre-medical student a bottle of wine to put an NFC card in my hand. I touch grass rarely and only under duress.

If you’d like to keep in touch, I’m around on LinkedIn for professional stuff and Twitter for shitposting, among others.

Thank you for reading - I hope that my experience and the directory of these interviews can help you work through the peculiarities of the cybersecurity field. <3