Software contractor is suggesting static code analysis instead of a penetration test, does this replace a pentest?

Static analysis only looks at raw text in the code you wrote. A misconfigured port on your server, an unpatched web server package, or an open public permission on a cloud database isn't contained inside your code. Those vulnerabilities are only caught via a pentest while the application is running in an active environment.

We made the exact same mistake with our e-commerce stack in Kazan. The contractor handed us a static analysis report, and we passed it along to the client. The client's audit team found unauthenticated access to the admin panel within the first two hours. The project was delayed by two months, and on top of that we had to scramble to hire an outside pentest team for 400,000 rubles.

What does the exact technical specification in your contract with the client state? If it explicitly mentions a penetration test or independent security audit, their legal or compliance department will reject a static analysis report on the spot. Have you reviewed the precise definition in the agreement?

Here are the key distinctions between the two: 1) Static analysis scans text without executing the code, whereas a pentest is dynamically applied to a live system. 2) Static tools cannot grasp business logic flaws, whereas a pentester attacks the system using human reasoning. 3) Enterprise client audits only recognize an independent pentest report as valid proof.

The contractor's offer doesn't seem genuine to me. For static code analysis, they just dump the code into an open-source or off-the-shelf scanner and pull an automated report within a few hours. Asking 120,000 rubles for an out-of-the-box report generated with the click of a button is way overpriced.

Edit: asked below, I wrote the answer in the second message.

Email your client's technical lead directly. Ask in writing whether a static source code analysis report is acceptable. A 90% chance they'll say a pentest is required. That way you avoid throwing 120,000 rubles away on the contractor for nothing.

Developers usually avoid independent penetration testing because another tech team comes in and documents their sloppy work and careless server setups right to the boss. Imo it's not about the budget they just don't want their own flaws exposed.

we had a static scan done on our project too and it spit out pages of false positives but missed the actual authorization vulnerability. an enterprise client will never accept it, don't waste your money.

Let me speak from the other side; I'm on the supplier side. Everything goes well for the first three months; problems arise in the fourth.

My question might sound amateurish, sorry about that. An automated scan report is not the same as a penetration test.

Everything goes well for the first three months; problems arise in the fourth. Good luck with that.

The discussion got scattered, let me summarize. Don't hesitate to ask; those who don't ask always pay more.

My perspective changed after experiencing that. Everything goes well for the first three months; problems arise in the fourth.

An automated scan report is not the same as a penetration test. This is my opinion, I'm not claiming it's absolute truth.

Let me share my experience. Processes without records never improve, because you don't know what to fix.

That's all, sorry if I went on too long.

My questions are cleared up, thanks. The real issue isn't the number, but what it's based on.

Good luck with that.

I'd say don't rush. The real issue isn't the number, but what it's based on.

Trying to do this alone is the most expensive way. Just leaving this note, it might be useful.

I agree with this. If permission and scope aren't in writing, don't start that test.

Mistakes made on the static code analysis side are usually reversible but expensive. Of course, it varies if your situation is different.

I partly agree, partly disagree. When making a decision, first look at what data you have on hand.

Just because everyone does it doesn't mean it's right. If I were you, I'd go this route.

I agree with this. When making a decision, first look at what data you have on hand.

That's all sorry if I went on too long.