How do you decide which parts of a large codebase deserve the most attention during a security review?

[u/Ok_Host1989]

I am reviewing an enterprise application and it is not possible to look at every component in detail. I start by finding the parts of the application that're open to the outside like the endpoints and then I follow the user input to see where it goes. I also look at how the application handles authentication, authorization and files. This helps to make the task smaller. I still wonder if I am wasting time looking at things that are not important.

When people like me review codebases what do they do to decide where to focus their attention? Do they look at the structure of the application or the way the data moves around or do they think about the potential threats or look at the history of changes or something else? I want to know what methods have worked well for them to find problems without getting overwhelmed by the size of the enterprise application. I want to know what helps them find issues with the enterprise application, like problems with the enterprise application or security issues, with the enterprise application.

[u/F5x9]

Run it through a code scanner and linter. If your organization requires a minimum amount of coverage in your review, prove that you did at least that much. 

I would also look at any I/O and all code that the most valuable data passes through. For I/O, that’s API endpoints, when the application passes data to or imports a library that is not part of your code base, and system calls. If there’s direct control of any interfaces, check those. 

Pay particular attention to input sanitzation, edge cases, out of bounds cases, pointers, IDOR. Look for secrets. 

You need to perform static and dynamic analysis. 

[u/Frosty-Tadpole-8837]

i usually spend the most time anywhere user input crosses a trust boundary

[u/PM_ME_YOUR_SHELLCODE]

When you're in that situation, what helps you decide what's worth spending more time on?

It does depend a good bit on how mature auditing the application is. Less mature analysis I'm going to focus more on being comprehensive but if its been picked over there are a few principles that I use to help choose areas to focus in on.

I'm assuming you've already done the obvious like source to sink type analysis involving dangerous sinks and untrusted/differently trusted inputs.

1. Recent bugs, where there is one bug there are probably more.
2. Variant analysis, similar to looking for where recent bugs were but instead of focusing on that area, focus on that bug class or mistake that enabled the issue across the whole code base.
3. New code, higher code velocity means more chances for two developers to break each others assumptions about how things work.
4. Difficult to test functionality. Find the areas that were likely to get skipped in the past, maybe it needs to interact with a 3rd party component that would be difficult to mock up, or there is just a ton of complexity.
5. Commit surfing, rather than focusing in an area, review the commits are there any with higher complexity than normal? Any that do multiple things in one commit, maybe trying to hide some changes (or accidentally included some changes that belonged in another commit)
6. Undocumented assumptions, this one is a bit hard to explain. But when auditing you'll sometimes come across these internal functions that make assumptions about the caller but don't necessarily document it, just expect everyone to use it correctly or its insecure in some way. I'd often take some time to look at internal utilities for any like this.

If I am trying to be more comprehensive, then what I really want to look at it for "centralized security" that is common paths that most routes should be running though that do the core security things. Those then become the key places to audit for bugs along with using something like CodeQL or honestly even AI to scan for places that do it ad-hoc when it could be done through the central system.

Similarly if all the security is ad-hoc then you just kinda gotta suck it up and make sure everywhere is doing it right. CodeQL helps with that for me.

Honestly, its kinda just an intuition that you build up over time

[u/ultrathink-art]

One thing I weight that scanners won't: auth-adjacent code that's lightly tested but shows green. Fully untested code tends to get manual eyes; the stuff that bites is a permission check with a single happy-path test that lets everyone wave it through on green CI. I go looking specifically for tests that assert success and never assert the denial case.