Security Reviews Developers Don't Dread

The failed security review has a familiar shape.

Someone commissions an assessment near the end of a project. A few weeks later a long PDF arrives with 140 findings, most of them rated High. The engineering team is already committed to a launch date, so they fix the top five, mark the rest as accepted risk, and file the document.

Nothing about the system is safer. The company bought a document, not an outcome.

The findings were usually correct. They arrived at the wrong time, in the wrong format, aimed at the wrong person.

Severity should mean "can someone actually do this"

Scanners rate by category. A hardcoded credential is High. But a hardcoded credential for a staging database that was switched off last year is not the same risk as one for the live payment provider. Report them the same way and you teach developers that your ratings mean nothing.

Once a team learns the rating is noise, they stop reading. Rate findings by what an attacker can reach and what they can do with it in this system. A short report where every High is genuinely high gets fixed. A long one where nothing can be trusted does not.

A finding without a location is just a complaint

"The application is vulnerable to SQL injection" is not something anyone can act on.

The file, the line, the parameter, the request that proves it, and a suggested fix. That is something someone can act on.

The difference between those two versions is the difference between a fix that ships this sprint and an argument that runs for three weeks.

Move the feedback to where the code gets written

End of project reviews fail for a simple reason. A design flaw caught during design costs a conversation. The same flaw caught after launch costs a migration, a change window, and possibly a disclosure.

Most of the value comes from moving a small amount of checking earlier:

• Dependency and secret scanning in CI, failing the build only on findings that are reachable and fixable, so the gate keeps its credibility
• Static analysis tuned hard against false positives. A noisy tool is worse than no tool, because it teaches people to click through warnings
• A short threat modelling conversation for genuinely new surfaces: new login flows, new stores of sensitive data, new third party integrations. Thirty minutes at design time, not a formal process

Deep manual testing still matters. Save it for the places that earn it: login and session handling, the boundaries between tenants or roles, anything that moves money, and anything that takes untrusted input.

Write for the person who has to fix it

A finding only a security specialist can read will be handled by a security specialist. That means it waits behind everything else on that person's list.

Write for the developer who owns the code. Explain the attack in terms of the application's own behaviour. Skip the generic CWE description, because they can look it up. Say what breaks, how, and what to change.

The real test of a review

It is not how many findings it produced. Ask a different question three months later. Did the same kind of issue stop appearing in new code?

If it keeps appearing, the review found symptoms but never reached the cause. Usually the cause is a framework default, a template that keeps getting copied, an internal library with an unsafe function, or a gap in what the team was ever taught to look for.

Fixing the pattern is worth more than fixing fifty examples of it. A PDF full of line numbers will never do that part on its own.