Skip to content

AppSec-ProdSec-DevSecOps Learning Path.md

Latest commit

 

History

History
347 lines (261 loc) · 30.9 KB

AppSec-ProdSec-DevSecOps Learning Path.md

File metadata and controls

347 lines (261 loc) · 30.9 KB

Application Security/Product Security/DevSecOps Learning Path

Why Read This?

So you want to break into AppSec, DevSecOps, or Product Security. This isn't a generic list of certifications to collect or courses to finish. It's a practical roadmap built from real experience.

I was a developer first. I made the transition into security and now run a global AppSec and Product Security team. This is what I hire for, what I mentor people toward, and what I expect from the engineers on my team.

Whether you're coming from software engineering, IT, sysadmin, or starting fresh, this path is designed to get you job-ready with skills that translate directly into the work -- not just the interview.

How to Learn Effectively

Reading or listening is not enough. You need to actively engage with what you're learning. As you go through any material:

Ask critical questions:

  • Why is this important? Why does it matter?
  • What is the small picture (the specific detail or technique)?
  • What is the bigger picture (how does this fit into the overall security landscape)?
  • How would an attacker exploit this? What could go wrong?

Apply actively:

  • Take notes in your own words, not verbatim
  • Immediately test concepts in a lab or personal project
  • Explain what you learned to someone else (or write a blog post)
  • Connect new concepts to real-world breaches or vulnerabilities you've heard about
  • Review your notes within 24 hours, then again after a week

Learning security is about building mental models, not memorizing facts. The goal is to develop intuition for how systems break and how to build them securely.

Here's the list with names and context added:

People to Follow on LinkedIn to Stay Up To Date

Foundational Knowledge

Start Here, Core AppSec Concepts

Essential Video Content

Jim Manico Talks:

Tanya Janca Talks:

Additional Essential Talks:

Learn the Standards, OWASP Frameworks

These aren't just reading material. They're the standards you'll reference daily in this field.

Understand the Cloud

Learn to Code (Yes, Really)

You can't secure what you don't understand. There are lots of free courses on YouTube from different channels such as FreeCodeCamp, and Udemy offers cheap courses if you want more structured learning. Learning how to code, understand code, and recognize what languages are used in different parts of software is absolutely key. Take full stack programming courses and learn Python or Go for automation/API-to-API scripts. You're going to talk to developers and work with developers every single day. You need to speak their language or you won't be effective.

  • You will need to understand how code works -- not just syntax, but control flow, how data moves through a function, how inputs become outputs, and where things can go wrong. You're looking for vulnerabilities in code every day; you can't spot them if you can't read the code.
  • Understand how 3rd party libraries (OSS) are packaged and pulled into code -- how package managers like npm, pip, Maven, and Go modules work, what a dependency tree looks like, and why transitive dependencies matter. Most vulnerabilities in modern apps aren't in custom code, they're in the libraries it uses.
  • How software is built, common design patterns -- understand MVC, microservices, monoliths, and how data flows between layers. Know what an API gateway does, what a service mesh is, and why a frontend talking directly to a database is a problem. Security decisions map directly to architecture decisions.
  • How to read someone else's code -- writing code is one skill, reading unfamiliar codebases is another. In AppSec you will rarely write the code you're reviewing. Practice navigating large repos, tracing data from entry points to sinks, and identifying where user input is handled. This is the core of manual code review.
  • How web frameworks handle requests -- understand the request/response lifecycle in frameworks like Express, Django, Spring, or Rails. Know what middleware does, how routing works, and where user input enters the application. Most injection vulnerabilities live in the gap between input handling and data processing.
  • How authentication and sessions are implemented -- not just how OAuth or JWTs work conceptually, but how developers actually wire them into an app. Where tokens are stored, how session state is managed, and where developers commonly cut corners under deadline pressure.
  • How secrets and environment variables are used -- understand how apps consume API keys, database credentials, and config values at runtime. Know the difference between how secrets should be managed versus how they often are in practice, which is hardcoded in source or committed in .env files.
  • How errors are handled -- stack traces, exception handling, logging. Poorly handled errors leak internal details. Over-verbose logging captures sensitive data. This shows up constantly in code review and is easy to miss if you don't know what you're looking for.
  • How serialization and deserialization works -- data gets converted between formats constantly: JSON, XML, binary, protocol buffers. Understand how an app parses external input and why deserialization of untrusted data is one of the more dangerous things code can do.
  • How version control and branching models work -- understand Git beyond basic commits. Know how feature branches, PRs, and merge strategies work because code review in AppSec happens inside that workflow. If you can't navigate a PR diff or trace a change back through history, you're slower than you need to be.

Read Code Like an Attacker

Most security tools find the obvious stuff. The real vulnerabilities like business logic flaws, broken authorization, subtle trust boundary violations which require a human who can read code and reason about how an attacker would abuse it.

Security code review is not the same as a functional code review. You are not checking if the code works. You are asking: what happens when someone tries to break this? Where does user input go? What happens if this assumption is wrong? Who is allowed to call this function, and is that actually enforced?

This skill takes time to develop but it compounds. Every codebase you review makes you faster at the next one. You start recognizing patterns: where injection flaws live, how authentication gets bolted on incorrectly, what insecure deserialization looks like across different languages. The goal is to build intuition that scanners don't have.

What to focus on during a security code review:

  • How user input enters the application and whether it is validated, sanitized, and encoded correctly before use
  • Authentication and authorization: not just that it exists, but that it cannot be bypassed by manipulating parameters, headers, or request order
  • How secrets, credentials, and sensitive configuration are handled at runtime
  • Error handling and logging: what gets exposed in stack traces, what gets written to logs that should not be there
  • Third party library usage: how OSS dependencies are called and whether they are being used safely
  • Business logic: flows that are technically functional but exploitable by someone who understands how the system is supposed to work

Know Your Codebase Before You Audit It: CLOC

Before you start reviewing code, understand what you are actually looking at. CLOC (Count Lines of Code) is a free, open source command line tool that scans a codebase and tells you every language present, how many files, and how many lines of code, comments, and blanks exist per language.

GitHub: https://github.com/AlDanial/cloc

This matters more than it sounds. To an experienced AppSec engineer, a CLOC output is a threat modeling shortcut:

  • Languages present tell you what package managers to look for (npm, pip, Maven, Go modules, Gemfile), which scanners to run, and what vulnerability classes are most relevant to that stack
  • Legacy languages buried in the output (COBOL, Perl, PHP, old JSP) signal tech debt and code that may not have been touched or reviewed in years, often the most vulnerable parts of the application
  • Disproportionate file counts in unexpected languages can reveal forgotten scripts, internal tooling, or old services still running in production that nobody is accounting for in the security program
  • Comment density gives a rough signal of code quality and documentation practices, sparse comments in complex code makes review harder and riskier

Running CLOC takes seconds. It gives you a map before you start the audit, so you are not discovering mid-review that half the backend is written in a language your SAST tool does not support.

AI & Emerging Technologies

AI security is exploding right now. Get ahead of it:

  • Start with TCM Security's AI Fundamentals course (free on YouTube and TCM Academy)
  • Go to YouTube and search "AI Security" and you'll find tons of videos. Start digesting and learning, taking notes as you go.
  • Dive into Model Context Protocol (MCP), MCP Security, AI Agents, and related topics (Just Google or search on LinkedIn, you'll find a ton of stuff)
  • Reference the OWASP Top 10 for LLMs when working with AI/ML applications

Follow Paolo, as he keeps posting free courses to take and learn on AI, look over his posts

AI SAST

These are not drop-in SAST tools; they are autonomous systems that combine fuzzing, static analysis, and multi-agent LLMs to find and patch vulnerabilities without human input. They competed across 54 million lines of code at DEF CON 33 (August 2025) and collectively found 18 real, non-synthetic vulnerabilities in production open-source projects.

  • Buttercup is the most accessible starting point:
    • Trail of Bits rebuilt it post-competition as a standalone version designed to run on a laptop.
    • Theori's repo is archived and unsupported. Atlantis is actively maintained.
  • These require LLM API keys (OpenAI, Anthropic, or Google) and can burn through budget fast. Buttercup has a tuned-down mode for individual use.
  • Worth studying even if you don't run them: the architecture of how these systems triage, analyze, and patch code is directly relevant to where AI-assisted AppSec tooling is heading.

Key AI Security Terms to Research: Prompt injection, Model poisoning, Jailbreaking, Hallucination, Context window attacks, Model extraction, Data leakage, Shadow AI, AI supply chain, Model Context Protocol (MCP), AI Agents, AI-assisted coding

Build Your Own Secure Pipeline

This is your hands-on laboratory. Set up your own secure pipeline using open source tools. Use GitHub runners or Jenkins locally. Configure it to run against vulnerable code and scan using free open source scanners:

  • SAST: Semgrep (free), OpenGrep (free), Snyk (free tier), Bandit (Python), Brakeman (Rails), Gosec (Go), SpotBugs (Java), ESLint security plugins (JavaScript)
    • use language-specific tools where you can, they produce fewer false positives than generic scanners
  • DAST: OWASP ZAP (free), Nikto (free), Nuclei (free, ProjectDiscovery), Burp Suite Community (free)
    • Nuclei is worth learning early; the template library is massive and it's widely used in real pipelines
  • SCA (Software Composition Analysis): OWASP Dependency-Check, Snyk (free tier), Grype (free, Anchore), OSV-Scanner (free, Google), Dependabot (free, GitHub native)
    • Grype pairs well with Syft; scan the SBOM you generate rather than the source directly
  • Container Scanning: Trivy (free), Grype (free), Docker Scout (free tier), Clair (free, open source)
    • Trivy does double duty here; it also handles IaC and filesystem scanning so it's worth learning well
  • SBOM Generation: Syft (free, Anchore), CycloneDX CLI (free), Microsoft SBOM Tool (free)
    • understand both CycloneDX and SPDX formats; different tools and consumers expect different formats
  • Secrets Detection: Gitleaks (free), TruffleHog (free, Trufflesecurity), detect-secrets (free, Yelp)
    • this category is missing from most beginner lists but secrets in code and git history are one of the most common real-world findings; learn it early
  • IaC Scanning: Checkov (free, Bridgecrew), Trivy (IaC mode), tfsec (free), KICS (free, Checkmarx)
    • if you're working in cloud-native environments you will touch Terraform or CloudFormation constantly; knowing how to scan it is expected
  • API Security Testing: Nuclei (API templates), ZAP (API scan mode), Postman (free tier with basic security testing)
    • most modern apps are APIs; pure web DAST misses a lot without API-specific tooling

Example Pipeline Build Guides

Infrastructure as Code & Container Security

The crucial next step is understanding and triaging those results. Learn how to interpret findings, prioritize based on risk and exploitability, and create actionable remediation plans. Being able to run a scanner is table stakes. Knowing how to triage, prioritize, and communicate findings to developers is what gets you hired.

Alternatively, build a similar home lab environment. Document what you build. This becomes portfolio material.

Learn the Attacker Mindset

Learning the basics of hacking can really contextualize vulnerabilities and is critical for replicating them. Start with the free TCM Security Practical Ethical Hacking course on YouTube: https://youtube.com/playlist?list=PLLKT__MCUeixqHJ1TRqrHsEd6_EdEvo47&si=xxMBSn3Eae4BJH6C

For web application security specifically, work through PortSwigger Web Security Academy (free): https://portswigger.net/web-security -- it covers every major web vulnerability class hands-on in a browser-based lab environment. If you're going into AppSec this is one of the most directly applicable resources available. Most of the vulnerabilities you will find in code reviews and DAST results map directly to topics covered here.

Then consider taking the Certified Penetration Testing Specialist (CPTS) from HackTheBox or the TCM PJPT or PNPT. Understanding how attackers think and operate makes you exponentially better at defense.

Certifications Worth Considering

While certifications aren't everything, some can provide structured learning paths and credibility:

Foundation Certifications:

  • CompTIA Security+ (debatable, but gives you a well-rounded perspective)
  • AWS Certified Cloud Practitioner (foundations of what AWS and clouds do in general)
  • AWS Certified Solutions Architect - Associate (gets your brain thinking on how we build things in the cloud)

Penetration Testing Certifications (these teach you how to break things, which helps you learn to defend them):

In order of recommended progression:

Core Skills That Separate You From the Pack

Threat Modeling: This is fundamental to AppSec. It's not optional. Threat modeling helps you identify security risks during the design phase, before code is even written. Threat Modeling or Secure Design Review, is evaluating architecture before code is written. Most high-impact vulnerabilities are baked in at the design phase. Catching them there is exponentially cheaper than finding them post-deployment. Focus on methodologies like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) and PASTA. This skill separates good AppSec engineers from great ones. Hiring managers look for this.

Risk Communication: A CVSS score means nothing to a VP of Engineering or a CFO. Learn to frame findings in terms of business outcomes: what data is at risk, what does exploitation look like, and what does fixing it cost versus not fixing it. If you can brief a CISO and a developer on the same finding two different ways without losing accuracy in either, you will stand out.

Developer Empathy: Developers are under constant pressure to ship and security is rarely their primary job function. If you show up as the person who slows them down and blocks releases, you will be ignored. If you show up as the person who helps them write secure code faster and integrates into their workflow, you become an asset. The best AppSec engineers have either written production code or spent enough time with engineering teams to deeply understand the tradeoffs developers face daily.

Metrics and Measurement: You cannot defend your program without data. Learn what metrics actually matter: mean time to remediate by severity, SLA compliance rates, scanner coverage, and reduction in repeat vulnerability classes over time. Know what metrics are vanity: total vulnerabilities found means almost nothing without context. When budget cycles come around and leadership asks whether the program is working, you need to answer with data, not anecdotes.

Incident Response Fundamentals: AppSec engineers get pulled into incidents more than people expect. You do not need to be a full incident responder, but you need to understand the basics: how to scope an incident, what forensic preservation looks like, how to write a timeline, and how to communicate status to leadership without downplaying or escalating prematurely. Being calm and structured during an incident is one of the fastest ways to build credibility with senior leadership.

Local Networking

Getting into security isn't just about learning technical skills. It's also about building relationships with other practitioners in your area. Look up local cybersecurity meetups on Meetup.com, search for security events on Eventbrite, and find conferences near you. This will take some Googling, but search for things like "OWASP chapter [your city]", "cybersecurity meetups [your city]", and "security conferences [your state/region]". These events are invaluable for networking, learning what skills are in demand locally, and often hearing about job opportunities before they're posted. Show up, introduce yourself, and don't be afraid to tell people you're looking to break into the field. The security community is generally welcoming to newcomers who show genuine interest.

Podcasts to Tune into

Newsletters & Blogs

Stay current with security news and practical advice:

YouTube Channels & Video Content

Interesting YouTube content creators with security education and training content

Recommended Books

  • "The Code Book" by Simon Singh: Understanding cryptography and its history
  • "The DevOps Handbook": Essential reading for understanding how DevOps and security integrate
  • "The DevSecOps Playbook: Deliver Continuous Security at Speed" by Sean D. Mack: Practical guide to implementing DevSecOps
  • "Agile Application Security: Enabling Security in a Continuous Delivery Pipeline" by Laura Bell: Security in agile and CI/CD environments
  • "Practical Vulnerability Management: A Strategic Approach to Managing Cyber Risk" by Andrew Magnusson: Strategic approach to vulnerability management

Curated Lists & Collections

Final Thought

Breaking into AppSec isn't about collecting certifications. It's about building practical skills, understanding how developers work, and being able to secure software at every stage of the SDLC.

The people who thrive in this field share a few traits: they're curious, they don't stop at "it's vulnerable" -- they understand why, and they can explain it to a developer in a way that ctually gets it fixed. They know how to prioritize when everything feels urgent. They build relationships with engineering teams instead of policing them. And they stay humble, because this field moves fast and yesterday's knowledge goes stale quickly.

You don't need to know everything to get started. You need to know enough to be useful, be honest about your gaps, and show that you're actively closing them. Hiring managers aren't looking for perfect candidates -- they're looking for people who can learn, contribute, and grow without constant hand-holding.

Build things. Break things. Document what you learn. Write about it, even if the audience is small. Contribute to open source projects. Show up to local meetups. Ask questions publicly. That body of work -- your GitHub, your blog, your community presence -- is often more compelling than any certification on your resume.

The security community is more accessible than it looks from the outside. Most practitioners remember what it felt like to be starting out and are willing to help people who show genuine effort. Put in the work, be consistent, and the door will open.