Need a security check by tomorrow? Start here.
You need to know what is exposed, what needs fixing and what you can tell a customer. Here’s how to scope a useful first check without spending the day comparing scanners.
Ask what evidence will get the job done.
A launch check, a customer security review and an independent penetration test have different deliverables. Ask whoever requested the check: which product and environment, which testing method, who must perform it, how recent it must be and whether they need a retest report. Confirm the answer in writing.
If this is your own launch decision, prioritize the paths that handle customer data, account access, payments, uploads and administrative actions. If you suspect an active breach, start incident response and preserve evidence rather than treating a routine scan as the response.
Use a tool for the part it can actually see.
| What you need to check | A practical starting point | What to verify |
|---|---|---|
| Public website and application responses | ZAP’s baseline scan, run by someone who can configure its scope. | Which URLs it visited and whether important routes were missed. |
| Known vulnerable dependencies | Your repository’s dependency alerts, such as GitHub Dependabot. | The affected version, deployed use and an upgrade or mitigation owner. |
| Leaked credentials | Repository secret scanning and your existing cloud security alerts. | History and supported secret types covered; revoke or rotate exposed credentials. |
| Product paths behind login | An authenticated application scanner, configured with test users and representative flows. | Successful login, role coverage, API coverage and any untested paths. |
| Customer isolation and sensitive business actions | Targeted checks by an experienced application-security reviewer. | Whether the server enforces the intended user, tenant and action boundaries. |
ZAP’s baseline explores the site and applies passive checks; it does not run the active attack scan. Exploration still sends requests, so agree the target and exclusions. Dependabot flags known vulnerable dependencies. Neither check establishes that your application’s permissions are correct.
For a hosted scanner, check authenticated coverage, API support, report format, total price and whether remediation advice or a retest is included. For example, Intruder’s setup guide describes authenticated scanning and its application-license requirement. Verify the current plan against your scope before purchasing. A low subscription price is only useful if it covers the product you need checked.
Spend the deadline on coverage and fixes.
- Write the boundary. List domains, APIs, environments, roles and the customer journey. Agree permission to test, allowed techniques, request limits, exclusions and a stop contact. Use test data; avoid live payment, email and deletion actions unless explicitly included.
- Run the existing checks. Review dependency, secret and cloud alerts alongside a scoped application scan. An empty dashboard is useful only when you know what was checked. GitHub recommends rotating exposed credentials; removing the visible string alone leaves the credential usable.
- Check behind login. Give the reviewer separate test accounts for the important roles and two test customers. Confirm the scanner stayed authenticated. Include exports, uploads, admin actions and integrations.
- Triage with an engineer. Confirm the finding, affected deployment, reachable path and customer consequence. Prioritize exposed credentials, unauthorized access and sensitive actions. Keep severity scores, but investigate the actual product context.
- Fix and retest. Record the change and repeat the original check. Leave unresolved findings visible with an owner, interim control and next decision.
Can one customer access another customer’s export?
Suppose your SaaS lets customers download reports. A scan of the marketing site says little about whether a signed-in user can fetch another customer’s report. In an authorized test environment, the reviewer uses two test customers and checks that cross-customer requests are denied by the server. The same boundary should hold for downloads, APIs and background jobs.
OWASP’s authorization guidance calls for permission checks on every request and tests of access-control logic. Ask for the expected rule, actual result and evidence. That gives an engineer a specific defect to fix and a check to repeat.
If the product includes AI, test the same boundary through retrieval, connectors and agent actions. Add the agent launch checks for tool access, approvals and recovery.
Make it easy for a tester to give you a useful answer.
We need a security review of [product] for [launch/customer requirement] by [date]. In scope: [domains, APIs, environment and key workflows]. We can provide [test accounts, roles, test data and technical contact] through an agreed secure channel.
Please confirm the testing method, authenticated and tenant-isolation coverage, exclusions, testing window and stop procedure. We need reproducible findings, affected components, severity with product context, remediation guidance and a retest. Please state the total fee, delivery date and any independence or accreditation requirements you meet.
Keep account credentials out of the initial brief. Agree how access will be shared and removed after testing.
A decision and a fix list.
Keep a dated record of the tested version, scope, methods, coverage gaps, verified findings, fixes, retest results and unresolved risks. The founder and technical owner can then choose to launch, narrow access, delay a feature or commission deeper testing. Describe the work performed precisely when sharing evidence with a customer.
For AI-enabled products, use our business security guide to connect product controls with ownership and recovery. If a customer is reviewing your AI supplier evidence, use the vendor review guide.