Forty-seven issues found is a scanner printout. It tells you nothing about Monday.
A Teal Apex security review ranks what it finds by how exploitable each thing actually is today, and stops. Two criticals and a plan beats forty-seven rows and a shrug. Every finding carries where it is, the exact way it gets used against you, and the specific fix, written for your stack.
The sample opens with fabricated findings for a business that does not exist, and it says so on the page. No real client’s report is ever published, which is why the sample is fabricated rather than redacted.
Three depths. One of them closes itself.
The entry tier is a fixed price because its scope is fixed: one site or one app. Above that, scope is the whole question, so the price is confirmed after a short scoping call rather than guessed at before one.
Security Scan
One site or one app, already live or about to be.
- ✓Every row-level security policy read as SQL, table by table, because a policy that resolves to true passes every automated lint
- ✓A live isolation test: we sign in as one account and try to reach another account's records
- ✓Your client bundle searched for the service-role key, which bypasses every policy you wrote
- ✓Your pinned framework version mapped against published advisories, including the ones that bypass middleware
- ✓Every finding ranked by how exploitable it is today, with the failure scenario and the specific fix
- ✓Dated PDF report you can hand to a client or an insurer
- ✓One free re-test after you ship the fixes
Security Review
An app with accounts, a database, and an API. Where the money and the records are.
- ✓Everything in the Scan
- ✓Authentication and session handling, end to end
- ✓Database row-level security and policy review, table by table
- ✓API and server route review, including what fails open
- ✓One re-test after you ship the fixes
Deep Security Review
A portfolio of apps, or one multi-tenant product where one tenant must never see another.
- ✓Everything in the Review, across every app in scope
- ✓Tenant isolation testing: can customer A reach customer B's data
- ✓Secrets, build pipeline, and deploy configuration
- ✓A prioritised remediation plan your team can work through
- ✓30 days of re-tests as fixes land
Every tier runs through the same client portal as a build. You get a private workspace the moment you submit, you can see where the engagement stands, and the report lands in it as a dated PDF you can download and hand to anyone who asks for it.
8 areas, walked in full.
About 12.5 to 14 hours of senior review, and the hours are printed against each area below rather than left to your imagination. An area with nothing found is not an area that was skipped. The clean ones are listed in your report on purpose, because looked at it, it was fine is information you paid for.
Identity and session
1.0 hourWho the application thinks you are, and how hard that is to lie about.
- Session tokens: how they are signed, and what happens when the signing secret is missing
- Password storage and reset flows, including token lifetime and single use
- Privilege checks on every authenticated route, not only on the page that renders the link
- Single sign-on and magic-link tokens: scope, expiry, and replay
Database and row-level security
3.5 to 4 hoursThe layer where one missing policy exposes every customer at once.
- Row-level security enabled, with an explicit policy, on every table
- Policies that resolve to true for everyone, which is the same as no policy
- SECURITY DEFINER functions and mutable search_path
- What the anonymous and authenticated roles can execute
Secrets and configuration
1.5 hoursThe keys, and every path by which one reaches a browser or a commit.
- Service-role and admin keys: server-only, and never in a client bundle
- Secrets in git history, in build output, and in error messages
- What the application does when a secret is absent: fail closed, or quietly fall back
- Environment parity between what is configured and what the running build actually has
Exposed surface
1.0 hourEverything reachable from the open internet that you did not mean to publish.
- Admin and console routes reachable without a session
- Backup files, source maps, and archives left in the public directory
- Directory listing, debug endpoints, and health routes that say too much
- Object and record identifiers that can be incremented
Browser hardening
0.75 hourWhat a single injected script is able to do once it is running on your page.
- Content-Security-Policy, and whether it actually constrains anything
- Security headers: HSTS, frame options, content-type options, referrer policy
- Cookie flags: HttpOnly, Secure, SameSite
- Embedded third-party frames and their sandbox
Data and transport
1.0 hourWhere customer records live at rest, and who can reach them.
- Storage buckets: public or private, and whether they allow listing
- Signed URLs, their lifetime, and what happens after it
- Personal data written into logs and third-party tools
- Transport security across every subdomain, not only the front door
Supply chain and delivery
2.0 to 2.5 hoursThe code you did not write, and the pipeline that ships it.
- Dependencies with published advisories, ranked by whether your code reaches them
- Build-time versus run-time environment variables, and what a stale build is still holding
- Deploy configuration: who can trigger a production deploy, and from where
- Rollback: whether you can actually get back to yesterday's build
The report, and the re-test
1.5 hoursThe part you actually keep, and the part that proves the fixes landed.
- Written by a person, ranked by exploitability, not a tool export sorted by CVSS
- Every finding carries where it is, how it gets used against you, and the specific fix for your stack
- Areas where nothing was found are listed too, because looked at it, it was fine is information you paid for
- One re-test after you ship the fixes, included, with a dated pass or fail per finding
What a review does not cover, written into the document.
A review with no stated boundary is a review that will be blamed for the one thing it was never asked to look at. So the boundary is part of the deliverable, not part of a conversation nobody recorded.
- No load testing and no denial-of-service testing. Nothing is attacked at volume.
- Read-only, against staging where one exists. Nothing is written, nothing is deleted, and production is not taken down.
- No social engineering, no phishing of your staff, and no physical access testing.
- Third-party services are reviewed for how you configure them, not for their own internal security.
- Point in time. The report describes the code as it stood on the issue date, and says nothing about what ships next week.
Find out from a review, not from a customer.
Seven questions, about four minutes. You get a private portal immediately, and a confirmed scope before anything is charged.