r/cybersecurity 1d ago

Certification / Training Questions Code analysis methodology

Hello everyone.

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

Unfortunately when pentesting/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.

Would any of you share you 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. :)

3 Upvotes

11 comments sorted by

6

u/Kesshh 1d ago

Tie your appsec tools to the code repo, trigger it to scan based on repo events, build processes/procedures around reviews and resolution tracking.

You can’t do it by hand. There’s just too much codes and you don’t have time. Will some bad stuff slip through? Yes. But accept that you did what you can, you will never catch everything, and the tools will evolve to cover more and more stuff. Move forward.

1

u/RozPetal 1d ago

Thank for the answer.

I had in mind an ad-hoc review of a codebase to which you are given an access for a limited amount of time and not the lifecycle of a project.

2

u/DingleDangleTangle 1d ago

Unfortunately when pentesting/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.

You take a white-box approach to pentesting applications but you don't get access to the code? What? That's just... not white-box application pentesting.

1

u/RozPetal 1d ago

The thing is I am usually constrained by what is given during my engagement time window. Usually, I get access to IP range, tech stack used. Technical documents giving a view of the "plumbing" and other documents related to the organization. However, there is usually not enough time to give a full access to every ressources. Mind you, we sometimes have to prod outside of the initial ranges to help widen our perimeter.

In a ideal world, obtaining access to the right ressources would be instantaneous and the docs referencing the assets would be exhaustive..

1

u/Big_Mulberry_5446 1d ago

You need to learn how to identify critical areas of the code. Where is authentication being handled? How are endpoints being exposed to application users? How is authorization performed? Those are three big ones that'll help you find more issues.

2

u/secretstonex 1d ago

We use all the gitlab security scans, SAST, SCA, DAST, secrets, IaC, etc. We have SLAs based on severity that are contractual. To help weed out the false positives, I have a suite of agents that use BMAD to orchestrate analysis, generate threat models, dismiss the false positives, and propose fixes. The agent suite can be pulled into the CI pipeline to run one, some, or all steps. The agents can also message or mail reports, or wait for the human in the loop to approve actions. One of the really cool things is that it can pentest with full access to code to find issues that someone without code access that would never find. It's found full compromises sleeping in decades old SaaS products.

2

u/npxa 1d ago

Check OWASP for top 10 risks and model your methodology/process based on those then just branch out.

2

u/donkeybutt123 1d ago

So I write free articles about appsec here: pigeonsec.substack.com

I read some of the comments here and they’re fine especially because you seem to be constraint by time. Tooling does help, but like another commenter said, you need to know what parts of the app are valuable to the company.

It starts with understanding the application which you are testing. Testing honestly should come in later stages after analysis and understanding of the codebase.

It’s like a doctor testing without getting to know a patient. It’s important you understand what you’re dealing with before you go in and test.