SEO Engineers
AppSec Assessments

Your scanner passed. Would a real attacker?

For a vibe-coded SaaS, an automated vulnerability scanner isn't a security review. You need engineers who read the actual code — architecture, authentication, authorisation — then get hands-on and attack the running application the way a real attacker would.

Multiple monitors and a laptop on a wooden desk, each screen showing live terminal windows, logs, and document output during active system testing

Photo: Yutaka Tsutano / Flickr, CC BY 2.0

Assessed against OWASP ASVS 5.0.0 — the Application Security Verification Standard OWASP itself describes as the basis for testing web application security controls, not just the ten categories in the OWASP Top 10.

Automated scanning is a start. It was never the whole assessment.

A scanner is good at what it does — known patterns, missing headers, outdated dependencies. What it can't do is understand what your application is supposed to do. It won't notice that a logged-in user can edit someone else's invoice by changing a number in the URL. That's not a pattern a scanner recognises; it's a business-logic decision your code made, correct by its own rules and wrong by yours.

That's the layer this assessment is built for: someone who reads the actual source code — authentication, sessions, permissions, API endpoints, database access, secrets, file uploads, payments, webhooks — and then gets hands-on with the running application and tries to break it, the way an attacker actually would.

It matters more, not less, when the codebase was largely AI-generated. Vibe-coded software tends to work first time and get reviewed never. The mistakes that slip through usually aren't syntax errors; they're the subtle authorisation and business-logic calls a coding assistant made confidently, that nobody ever questioned.

Three phases. Not just a scan.

Every AppSec assessment runs the same disciplined sequence, because business-logic vulnerabilities need a human trying to break your application, not a tool checking it against a known-bad list.

01

Secure code review

We work from your actual source, not a black box. Authentication and session handling, permissions and role checks, every API endpoint, database access, secret management, file uploads, payment flows, and webhooks — reviewed for the mistakes that don't show up in a diff. Especially important on AI-assisted codebases, where subtle authorisation and business-logic errors are easy to introduce and easy to miss.

02

Web & API penetration test

Against a staging or production-like installation, we attack the running application the way an attacker actually would: SQL injection, cross-site scripting, CSRF, IDOR and broken object-level authorisation (BOLA), privilege escalation, authentication bypass, session attacks, API abuse, SSRF, file-upload vulnerabilities, and more. Business-logic vulnerabilities need a person doing this — automated scanners aren't built to notice two individually-fine features combining into an exploit.

03

Remediation & retest

You, or we, fix what was found. Then we test again — the same findings, re-verified against the fixed application — and issue a final report confirming exactly what's been resolved. Not a re-scan. A retest.

We also offer to help fix the security issues we've documented — either directly, or working alongside your own developer or AI coding tool of choice.

Assessed against OWASP ASVS, not just the OWASP Top 10

The OWASP Top 10 is a good primer on the most common vulnerability categories. It was never meant to be a testing methodology. The OWASP Application Security Verification Standard (ASVS) — currently version 5.0.0 — is what OWASP itself describes as the basis for testing web application security controls, with specific, checkable requirements across authentication, session management, access control, and more.

We assess against ASVS because a list of ten categories doesn't tell you whether your session tokens are actually handled correctly. A verification standard does.

For a SaaS that's past the first version

If you're a solo founder shipping a first version with an AI coding assistant, our faster Vibe Code Security Audit — a code-only review, scoped in days — is probably the right starting point.

This assessment is for a vibe-coded SaaS that's moved past that stage: real users, a staging environment worth attacking properly, and a reason to want the fuller three-phase treatment — a funding round, an enterprise sales conversation, a compliance requirement, or simply wanting the rigorous version done properly, once.

Not sure which one you need? Start with a short call and we'll scope it honestly. The other side of a proper assessment isn't just a report — it's not lying awake wondering what's still broken.

Founder leaning back from their desk, hands behind head, relaxed after clearing a security review

Photo: nodstrum / Flickr, CC BY 2.0

Frequently asked questions

What's the difference between this and your Vibe Code Security Audit?

The Vibe Code Security Audit is a faster, code-only review built for early-stage, solo-founder apps. This AppSec assessment is the fuller three-phase engagement — secure code review, a hands-on penetration test against a running installation, then remediation and retest — assessed against OWASP ASVS. If you're not sure which fits, start with a short call and we'll scope it honestly.

Do you test against the OWASP Top 10 or the full ASVS?

ASVS. It's a more rigorous, checkable standard that the OWASP Top 10 was never designed to be — and it's the current basis OWASP itself recommends for verifying web application security controls.

What do you need from us to run the penetration test?

A staging or production-like installation you're comfortable with us attacking, plus read access to the source code for the code review phase. We scope exact access requirements on a short call before anything starts.

Will you help us fix what you find?

Yes — that's built into the third phase. We can implement fixes directly, or work alongside your developer or AI coding tool of choice, then retest and confirm what's actually closed.

How long does the whole engagement take?

It depends on the size of the codebase and the application, which we scope on a short call before quoting a timeline. Three phases makes this a longer engagement than a single audit — expect weeks, not days.

Not sure this is the right starting point? See our faster Vibe Code Security Audit, browse our case studies, or read about the team running both.

Find out what's actually exploitable.

Code review, penetration test, retest — one assessment, ASVS-grounded, no guessing.