What I Actually Look for During a Product Security Review

Let me be upfront about something: most security reviews I've seen are theater.

Someone runs a scanner, skims the OWASP Top 10, writes up a report with color-coded severity boxes, and calls it done. The engineering team fixes the critical findings, closes the ticket, and everyone moves on feeling good about themselves.

Then six months later, something gets breached — and it wasn't any of the things the scanner flagged.

Over the years doing product and application security across different companies and teams, I've had to unlearn a lot of what I thought "doing security" meant. What follows is how I actually approach a product security review today — not the checklist version, but the real one.

Start with the architecture. Always.

I know this sounds obvious, but you'd be surprised how many reviews skip straight to scanning.

Before I look for a single vulnerability, I want to understand what I'm looking at. What are the components? Frontend, backend, APIs, microservices — where does data enter, where does it go, what touches what? More importantly: where are the trust boundaries?

I use a lightweight threat modeling approach here, usually STRIDE. Nothing fancy. Just enough to ask the right questions: Where could someone impersonate a legitimate user? Where could data be tampered with? What gets exposed that shouldn't?

Without this step, everything that follows is just guesswork. You're poking at things hoping to get lucky.

Authentication and authorization — this is where most things actually break

If I had to pick one area that catches the most real-world issues, it's this one.

Not because authentication is technically hard (it usually isn't), but because authorization is consistently implemented inconsistently. I've lost count of how many times I've seen APIs that were properly locked down at the UI layer but had no actual server-side enforcement. The frontend checked roles. The backend assumed you'd already been checked. Nobody noticed for months.

I look specifically for IDOR (Insecure Direct Object Reference), where you can swap out an ID in a request and access someone else's data. I look for role validation that's applied in some endpoints but not others — usually because different developers built different parts of the API and made different assumptions.

If the authentication and authorization layer is broken, nothing else really matters. An attacker doesn't need to find a clever exploit when they can just ask for data they shouldn't have access to.

APIs deserve a lot of attention

Modern applications are API-first, and that shifts where the real attack surface lives.

The things I'm checking: Is input validation happening server-side, or are teams relying on the frontend to catch bad data? Are there injection risks — SQL, command injection, template injection? Is there any rate limiting, or can someone just hammer endpoints until they find something interesting?

One thing that gets overlooked constantly: APIs that return way more data than they need to. You ask for a user's display name and the response comes back with their email, internal ID, account flags, and half a dozen other fields that the frontend ignores but an attacker absolutely won't.

Cloud misconfiguration is where breaches actually happen

This point never lands as dramatically as it should, so let me say it plainly: most breaches today aren't sophisticated attacks. They're someone finding an S3 bucket with public read access, or a leaked service account key with admin permissions, or a database that was "temporarily" opened up and never locked back down.

My checklist here is pretty consistent. IAM roles — are they following least privilege, or did someone just click "admin" to make something work? Storage — anything publicly accessible that shouldn't be? Secrets — are credentials hardcoded anywhere in the codebase or sitting in environment variables committed to a repo? Encryption — is data encrypted at rest and in transit, or is TLS optional?

The misconfiguration stuff is genuinely some of the highest-impact work in a review. It's also the stuff that feels boring until you find something, and then it suddenly feels very important.

The pipeline is part of the attack surface

CI/CD security is still treated as an afterthought at most companies, which is a problem, because a compromised pipeline can undermine everything else you've built.

I want to know: are dependencies being scanned? Is there an SBOM? Are secrets showing up in build logs? Are build artifacts verified? And — importantly — who actually has deployment access, and are there any approval gates, or can anyone with the right GitHub permissions push directly to production?

Supply chain attacks have become genuinely common. Treating your pipeline as out of scope for a security review is no longer reasonable.

Secrets management: the thing that's always worse than expected

Every time. Every single time, there are hardcoded credentials somewhere.

It might be an old API key in a config file that "we stopped using." It might be a token in a comment left over from debugging. It might be credentials that were committed to a private repo three years ago — private repos that aren't actually private anymore because of an org setting change nobody noticed.

I look for: hardcoded keys and tokens, whether secrets rotation is actually happening, and whether the team is using a proper vault (AWS Secrets Manager, HashiCorp Vault, whatever) or just leaning on environment variables and hoping for the best.

One leaked secret can unravel everything. I've seen it happen.

You can't defend what you can't see

Security isn't just about prevention. It's about detection.

If something goes wrong — and eventually something will — you need to know about it. That means logging meaningful security events (failed logins, privilege escalations, unusual API patterns), having alerting that actually fires, and protecting logs so they can't be tampered with or quietly deleted.

I'm still surprised how often security logging is just… not there. No one thought about it, or it was deprioritized, or the assumption was "we'll add it later." Detection is what turns a breach into a recoverable incident instead of a months-long intrusion no one notices until the data shows up on a forum somewhere.

The thing that matters most: thinking like an attacker

All of the above is just structure. The part that actually makes a review valuable is the mindset underneath it.

After I've gone through everything methodically, I step back and ask: if I were trying to cause damage here, where would I start? What's the path of least resistance? What gives maximum impact for minimum effort?

That question surfaces things that no checklist catches — the weird interaction between two systems that each look fine in isolation, the edge case in a business logic flow that only makes sense once you understand what an attacker would actually want to do.

Checklists are starting points. Curiosity is the actual tool.

Mistakes I keep seeing

After enough reviews, certain patterns show up again and again. Teams relying entirely on automated scanners and treating the output as a complete picture. Assuming internal systems are implicitly trusted and don't need the same rigor. Authorization checks exist in some places and not others. Cloud roles that are over-permissioned because restricting them would require figuring out exactly what each service needs. Secrets sitting in codebases, sometimes for years.

None of these are exotic. They're all fixable. They just require someone to actually look.

Final thought

A good product security review isn't about ticking boxes or generating a report with findings sorted by CVSS score. It's about understanding a system well enough to know how it could fail, and caring enough to find the things that matter before an attacker does.

That requires technical depth, yes. But it also requires genuine curiosity, the willingness to collaborate closely with engineering teams, and the habit of always asking: what am I missing?

Security embedded early, continuously, and with real intent is a fundamentally different thing from security bolted on at the end. The difference shows up eventually — one way or another.

References:

Goyal, S., Kaur, N., & Majithia, S. (2021). Software Security: Role in SDLC. CGC International Journal of Contemporary Technology and Research, 3(2), 205–210. https://doi.org/10.46860/cgcijctr.2021.06.31.205

‌Mateosian, R. (2009). Software Architects [review of 97 Things Every Software Architect Should Know: Collective Wisdom from the Experts (Monson-Haefel, R., Ed.; 2009)]. IEEE Micro, 29(3), 62–64. https://doi.org/10.1109/mm.2009.47

‌Amgothu, S. (2024). An End-to-End CI/CD Pipeline Solution Using Jenkins and Kubernetes. International Journal of Science and Research (IJSR), 13(8), 1576–1578. https://doi.org/10.21275/sr24826231120

Written from real-world experience in product and application security. Opinions are my own.