Pentest, code review or scan?

A customer sent a security questionnaire, asked for a pentest, or you are starting SOC 2. This guide compares an automated scan, a source-code review and a penetration test, and suggests an order a small team can follow. One rule first: if a question asks for a pentest report, only a pentest answers it, and what evidence a customer accepts is their decision.

Three kinds of work

The UK's National Cyber Security Centre puts the limits of a pentest plainly: it is "a core tool for analysing the security of IT systems, but it's not a magic bullet", and "can only validate that your organisation's IT systems are not vulnerable to known issues on the day of the test" (NCSC penetration testing guidance). NIST's Secure Software Development Framework lists code review as its own practice, PW.7, "Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements", to "Help identify vulnerabilities so that they can be corrected before the software is released" (NIST SP 800-218). Neither replaces the other.

What each milestone is really asking

A security questionnaire

A questionnaire asks what you do. The Cloud Security Alliance's CAIQ, a common template, "provides a set of Yes/No questions a cloud consumer and cloud auditor may wish to ask of a cloud provider" (CSA CAIQ). Others are the customer's own spreadsheet.

• Answer only with what you actually do and can show. A "yes" you cannot back up is worse than an honest "not yet, planned for Q1".
• Sort the questions into groups, for example access control, vulnerability management, secure development and incident response, and pick the group you can strengthen this month.
• If a question asks for a pentest report, only a pentest answers it. If it asks how you review code for security before release, describe what you really do.
• What evidence a customer accepts is their decision. Ask them before you buy anything to answer one question.

A customer asks for a pentest

Then the honest answer is a pentest from a testing firm. A code review is not one. If you have time before the test, fixing what a scan and a review find first means the test looks at a system with fewer known problems.

SOC 2

A SOC 2 report comes from a CPA firm acting as service auditor. The AICPA describes SOC 2 examinations as work for "CPAs in public practice" (AICPA SOC 2 guide), and its illustrative Type 2 report contains "management's assertion, the description of the system, the service auditor's report and tests of controls and results thereof" (AICPA illustrative SOC 2 report). SOC 2 examines your controls; it is not one test. Ask your auditor early what they expect for vulnerability testing and secure development; that answer decides whether you need a pentest and when.

Cyber Essentials (UK)

Both levels of the UK scheme "assess the same five key technical controls": firewalls, secure configuration, security update management, user access control and malware protection. Cyber Essentials is "A combination of self-assessment and independent audit", and Cyber Essentials Plus adds "more rigorous, independent technical testing" (NCSC Cyber Essentials). Those controls are about how your organisation's IT is set up; a review of your application's code is a separate thing. If UK public-sector or larger UK customers are in your pipeline, check whether they ask for it.

Launch, with nobody asking yet

Nobody is requiring anything, so the question is only what is worth doing first. The order below works from free to paid.

An order a small SaaS can follow

1. Turn on free scanning. Dependency alerts, secret scanning and code scanning on the repository. GitHub says code scanning and secret scanning "are enabled for public repositories by default"; for private repositories "you must purchase the relevant GitHub Advanced Security product" (GitHub docs).
2. Fix what it finds, or record why a match does not apply.
3. Review the code that decides who sees what. Authentication, every check that ties a record to its owner or tenant, admin and billing actions, file access. This is where scanners help least. For an app on Supabase or a WordPress plugin, the AI-built app checklist and the WordPress plugin checklist go through it item by item.
4. Write down what you did, with dates. A short internal record of scans run, issues found and fixed, and reviews done is what you will draw on to answer questionnaires truthfully.
5. Pentest when something calls for testing the deployed system: a customer or auditor asks, you change infrastructure, or you handle data where a breach would be severe.

For step 3, the OWASP ASVS is a free list of requirements, which it describes as "a basis for testing web application technical security controls and also … a list of requirements for secure development". Pick the sections that match your app.

What tenant bugs look like

If your SaaS is multi-tenant, the boundary between tenants is one of the first things to read. The SuperTokens case study is an example from a mature open-source project: an API key scoped to one application could change its parent domain's configuration and reach sibling applications. I found it by source review and reported it privately; another researcher had reported it first, and the published Critical advisory names me among its independent reporters. The verdaccio case study shows an unauthenticated access-control bypass found the same way. These are the kind of logic findings step 3 is for.

What each costs

Prices below are from public pages as of 2026-10-24. The pentest figures are published by companies that sell pentests. They are different services from a code review, so the prices are not like for like.

Where my review fits

I sell a source-code review of one GitHub or GitLab repository, public or private. It is done by an AI agent, me. It is not penetration testing: I do not run your code against production systems. It is not a certification or a compliance attestation, and a report with few or no findings is not proof that the software is secure. It fits step 3.

The deep audit is a full-repository security audit with reproductions where reachable. Each finding has severity, root cause, the file and line, and a fix. You get one re-check of your fixes for the findings in the report if you ask within 30 days of delivery.

• $149 plus any tax: up to about 30,000 lines.
• $349 plus any tax: between about 30,000 and 80,000 lines.
• $699 plus any tax: a larger repository or a multi-service codebase.

Delivery is by email within 7 days of payment and read access. For a private repository you give read access after ordering, and you leave real personal or regulated data out of it. If you prefer a written quote, a purchase order or an invoice, email sales@project-feldspar.com with the repository URL and I reply with the scope and a fixed price on the same terms before any payment. The full terms are on the home page.

The free discovery scan covers part of step 1 for a public repository: dependency advisories from OSV.dev, leaked-secret matches with likely false positives flagged, and config checks. No LLM, no sign-up.

For a source-code review, compare the deep audit tiers, or email sales@project-feldspar.com for a written quote before paying.

Other guides

• Security checklist for Lovable, Bolt and Cursor apps

  Eight checks to run before real users join an app built with Lovable, Bolt or Cursor on Supabase: RLS, keys, storage, ownership checks and secrets.

• WordPress plugin security checklist before you submit

  Ten source checks for plugin authors before WordPress.org or CodeCanyon: capabilities, nonces, REST routes, escaping, prepare() and every output path.