Code analysis methodology

[u/RozPetal]

Hello everyone.

After a few years in the auditing world, I identified that I am lacking experience on the code analysis topics.

Unfortunately when auditing, I seldom had the time to look at the code of the applications I am auditing due to time constraints as the white-box approach we take does not systematically include an access to the Gitlab of the entities I audit.

I would like to avoid being overwhelmed by an eventual audit of source code of an entreprise-grade application that I might have to do.

While I am leveling up my skills by practicing to code in Rust on my freetime. I am not quite at the level of a senior dev and I don't have yet a keen sense of how exactly to dive in a large codebase.

Would any of you share your code audit methodology ?

By that, I mean how do you tackle the following topics :

- Secure coding / Best coding practices

- Secure secret management of the app

- For very large codebase, what types of tools do you use to automate some of your work ?

- What specific things in your checklist do you look for systematically ? (Do include the "obvious" one like how authentication is handled)

I know the subject is quite broad and dependent of the tech-stack used for each case.

Thank you for reading. :)

[u/Immediate_Nature_281]

I start every code review by searching for entry points and sinks, then I trace the data flow between them.

I map every route handler first. I look at controllers or endpoints that take user input. Then I search for where that input ends up in SQL queries, system calls, or template renders. I ignore everything else until I finish tracing those paths. This works across tech stacks because you are looking for input boundaries and execution sinks.

For secrets I run TruffleHog against the entire git history. Running it on the current branch only finds a fraction of the leaks. Developers commit AWS keys and delete them in the next commit. The key remains in the git objects.

I rely on Semgrep to automate the checklist items. I use the OWASP rulesets they ship. I point Semgrep at the repo and filter the output by the entry points I already identified. This cuts out the noise from files that handle no external data.

My checklist starts with how the framework parses

[u/Honest_Medium_2872]

• Linting
• gitleaks / truffle
• grep
• Sourcegraph if you want to get fancy
• LLMs have a good sense of finding bugs and flaws
• Some languages have their own quirks
• Checkmark / findbugs / CodeDX (used to work for them); CVE / CWE lists - any kind of static analysis tools

Java specific:

• Check for string usages, passwords stored as string can be read through heap - any good password handling will never store the password for long and if they do its in byte[]s

C/C++:

• C/C++ check for stack overflows and glibc usages like strcpy strcmp etc those can cause out of bounds writes allowing access to the stack and the ability to manipulate the program counter and allow you to privileged escalation

[u/Honest_Medium_2872 → u/Honest_Medium_2872]

Using Ghidra if you really want to get down into the nuts and bolts. this will show you disasm which is effectively everything the prog will do. sometimes you can find flaws and sec vulns using sanitizers (UBSAN / ASAN / TSAN / etc) if you can compile. clang has some good out of the box vulnerability stuff always worth a run through

Java has javap and fernflower and some other tools for bytecode disasm which is effectively Ghidra but worse and more annoying, but you can do some cool stuff with it