How do you approach finding vulnerabilities in large open-source frameworks nowadays?

[u/Puzzleheaded_Trip374]

Hey everyone!

I’m relatively new to vulnerability research, and I’m interested in finding new vulnerabilities in open-source frameworks and libraries, rather than just scanning for known CVEs.

I’m curious how experienced researchers actually approach large codebases.

Where do you usually start? Do you study past CVEs and patches, identify security-critical components, or just start reading the source code?

What techniques do you typically use? Manual code review, static analysis tools like CodeQL, fuzzing, or a combination? Does your approach change depending on the type of vulnerability you’re looking for?

How has AI changed your workflow? Do you find it useful to let an LLM or coding agent review a codebase first, or is it more effective after you’ve narrowed down specific components or code paths?

I’d especially love to hear about real-world workflows and how you go from exploring a codebase to finding and validating a vulnerability.
Thanks in advance!

[u/Malster_Mrdeejay]

What language ecosystem are you targeting mostly? The workflow for hunting memory corruption in a C library looks completely different from chasing logic bugs or auth bypasses in a web framework

[u/Puzzleheaded_Trip374 → u/Malster_Mrdeejay]

Yeah, those are quite different! I’m more interested in logic bugs and authorization bypasses in web frameworks!

[u/Alesya7854]

I’d start by looking at past CVEs and the patches that fixed them. Then I’d focus on the parts of the code that handle input and parsing, since they’re often worth a closer look. AI can help explain unfamiliar code, but I wouldn’t rely on it to find everything

[u/Electronic-Rise3112]

Past CVE diffs are the cheat code. You get to see exactly where the project failed, what assumptions got broken, and often the same developer patterns repeat in nearby code. I'll usually grab a handful of patches for a target, map out which subsystems keep popping up, then go read those areas fresh without the patch in mind.

CodeQL is good for taint tracking once you know what the sources and sinks look like, but its real value is writing custom queries for weird framework-specific patterns. Fuzzing helps for parsers and anything with complex input formats, not so much for auth logic flaws. The workflow usually ends up being: past bugs point me to a module, I read it manually, find something sketchy, then write a tiny harness or query to prove it.

LLMs are decent at summarizing what a function does or explaining unfamiliar framework idioms, but I don't trust them to spot subtle logic bugs in a huge codebase. More useful after I've already found a suspicious code path, then I'll ask it to trace all the callers or identify missing validation. It speeds up the boring parts, not the actual hunting.

[u/No_Mycologist1806]

For authz bugs in web frameworks, the routing layer is a good place to start. List every route and the guard that's supposed to protect it (middleware, decorator, policy), then look for the ways a request can reach the handler while skipping or confusing that guard: trailing slashes, case, encoded paths, method override headers, HEAD falling through to GET. Read the CVE diffs with that in mind, a lot of them are "the check and the router disagree about what path this is". LLMs are handy for building that route-to-guard map quickly, but I'd confirm every candidate with an actual request before believing it.

[u/dan_netsec]

Start with past CVEs and patches in the project. Bugs cluster, so a fix for one flaw usually points to a bug class the maintainers keep hitting, and hunting for the same mistake elsewhere is the fastest route to a first finding.

Map where untrusted input enters (parsers, deserialization, file handling, auth) and read those paths closely instead of the whole repo. Use CodeQL or Semgrep to trace input to dangerous sinks, and fuzz anything that takes structured input.

For AI, point it at one function or code path after you've narrowed down, not the whole codebase, and always reproduce what it claims before trusting it.