Maru Security · Independent application security · United States

Built at AI speed.Audited like an adversary.

Whether your application was built by a seasoned engineering team or generated by an AI assistant, the vulnerabilities ship with it. We assess your software the way a real adversary would, then deliver an independent report rigorous enough for your engineers to close every finding, and credible enough for your customers and insurers. We assess. You stay in control of the code.

136
controls per audit
16
testing phases
0
lines of your code we touch
findings/MARU-0007.jsonFINDING · CRITICAL
{
  "id": "MARU-0007",
  "title": "Cross-tenant data access via object ID",
  "severity": "critical",
  "cvss": 9.1,
  "class": "A01 Broken Access Control",
  "endpoint": "GET /api/orders/:id",
  "evidence": "tenant_a token read tenant_b orders",
  // exactly how your engineers close it:
  "remediation": "scope query by auth tenant + RLS"
}

▸ Representative finding · the #1 cause of real-world breaches.

Methodology aligned to

  • OWASP Top 10 · 2021
  • OWASP API Top 10 · 2023
  • OWASP Web Testing Guide
  • CVSS 3.1 scoring

The problem

The software is shipping.
The security is not keeping up.

We are living through the fastest change in how software gets built in a generation. That is a good thing. It is also a security problem that almost nobody is positioned to catch, because the tooling that writes the code does not stop to ask whether it is safe.

01minutes

Code ships faster than it is secured.

An AI assistant generates a working feature in minutes. The auth check it skipped, the query it left open, the secret it hardcoded · those ship at the same speed. Velocity is the new attack surface.

02#1

Access control is where it breaks.

Broken access control is the number one category in the OWASP Top 10. One object ID swapped in a URL, one missing tenant check, and one customer is reading another's data. It rarely shows up in a demo. It always shows up in a breach.

03$0

Nobody is checking.

Solo founders and lean teams ship to real users with no second set of eyes. Established teams move too fast to slow down for security. The gap between live and reviewed is exactly where incidents are born.

Engagements

Three ways in.
One independent verdict.

Every engagement ends the same way: a written report your own engineers can act on. We test and document. We never touch your codebase. That independence is the point.

01

The full assessment

Application Audit

The complete 136-control methodology run against your live application. Every phase, fundamentals to advanced: access control, injection, authentication, business logic, payments, infrastructure. The deep one.

  • All 16 testing phases
  • Manual testing, not just a scanner
  • Full written report + executive summary
  • Every finding scored and prioritized
  • One remediation retest included

Best before a launch, a funding round, or an enterprise customer's security review.

02Most requested

Focused, pre-launch

Ship Review

A targeted assessment of the highest-risk surface: authentication, access control, secrets, and the money path. The 80/20 of what actually gets exploited, turned around fast.

  • Access control + auth + secrets
  • Payment and business-logic abuse
  • Prioritized findings report
  • Fast turnaround
  • Upgrade path to a full Audit

Best for solo founders and lean teams about to put real users on a new build.

03

Re-audit on release

Continuous

Security is not a one-time event when you ship every week. A standing retainer: we re-test the changed surface on each release and keep a living record of your posture over time.

  • Re-test on each release
  • Living findings register
  • Quarterly posture report
  • Priority response window
  • Insurer / customer-ready summaries

Best for funded teams and established businesses shipping continuously.

▸ Scope sets the price. Every engagement starts with a short scoping call and a signed authorization · no testing happens without it.

Coverage

136 controls.
Nothing waved through.

This is the actual methodology, not a marketing list. Sixteen phases run in order, every control tested and recorded with a pass, a fail, or a documented reason it does not apply. The two phases marked live are where most real breaches begin.

00
8

Engagement & Authorization

Signed scope, rules of engagement, data handling. No test runs without it.

01
10

Recon & Info Gathering

Subdomains, exposed files, leaked secrets, the full attack surface mapped.

02
11

Configuration & Deployment

TLS, security headers, cookies, CORS, source maps, preview exposure.

03
11

Authentication

Brute force, MFA bypass, password reset, OAuth, JWT forgery.

04
6

Session Management

Token entropy, fixation, logout invalidation, CSRF.

05
13

Authorization & Access Control

IDOR, privilege escalation, multi-tenant isolation, row-level access rules.

06
16

Input Validation & Injection

SQL, XSS, SSRF, command, template, path traversal, prototype pollution.

07
9

API & Backend

Rate limiting, BOLA, excessive data exposure, webhook verification.

08
8

Business Logic

Price tampering, race conditions, workflow bypass, refund abuse.

09
6

Client-Side

DOM XSS, clickjacking, secrets in the bundle, postMessage origins.

10
7

File Upload & Storage

Webshells, SVG XSS, traversal, signed-URL scope, metadata leakage.

11
7

Crypto & Data Protection

Password hashing, secrets in git, weak algorithms, data at rest.

12
7

Payments

Webhook signatures, price authority, entitlement, idempotency, PCI scope.

13
7

Infrastructure & Cloud

Env var exposure, cron auth, edge bypass, WAF, monitoring.

14
4

Dependencies & Supply Chain

Known CVEs, outdated frameworks, lockfile integrity, third-party scripts.

15
6

Reporting & Remediation

Reproducible findings, CVSS, business impact, remediation, retest.

highest-risk phase16 phases · 136 controls · manual + tooledaligned to OWASP WSTG · Top 10 · API Top 10

The deliverable

What one
finding
looks like.

No vague scanner output. Every finding in the report is written so an engineer who has never met us can reproduce it, understand the business risk, and close it. This is one of them.

▸ Reproduction steps and raw request / response are included in the full report and redacted here.

MARU-0007

Cross-tenant data access via object ID

Critical
Severity
Critical · CVSS 9.1
Class
A01 Broken Access Control · IDOR / BOLA
Endpoint
GET /api/orders/:id
Environment
Production

Impact

Any authenticated customer can read another customer's orders, including names, addresses, line items, and totals, by changing the numeric ID in the request. This is a confidentiality breach affecting every tenant on the platform and is directly reportable under most privacy regimes.

Evidence

A token issued to tenant_a returned order records owned by tenant_b. The endpoint authenticates the user but never checks that the requested order belongs to them.

Remediation

Scope the query by the authenticated tenant rather than the URL parameter, and enforce it at the database with a row-level security policy: USING (tenant_id = auth.tenant()). Apply the same object-ownership check to every /api/:id route, not just this one.

The report

A document your
team can act on.

The audit is only as good as what you can do with it. Every engagement ends with a structured report built to be handed straight to your engineers, and a summary built to be handed straight to whoever needs assurance.

01

Executive summary

One page. Overall posture, the top risks in plain business language, and what to fix first. The page your buyer, board, or insurer reads.

02

Findings register

Every issue, ranked worst-first, each with reproduction steps, evidence, affected endpoints, and a CVSS score.

03

Remediation guidance

Exactly how your engineers close each finding, with the specific fix and code or config example. Written to be actioned, not admired.

04

Retest & verification

After your team fixes, we re-run the affected controls and mark each finding verified-fixed, so you have proof it is actually closed.

Severity model

Every finding is rated by real impact and scored with CVSS 3.1, so you triage by risk, not by guesswork.

  • Critical

    Full compromise: RCE, auth bypass, cross-tenant access, payment forgery.

  • High

    Account takeover, stored XSS, IDOR, secret exposure. Fix before release.

  • Medium

    CSRF, weak config, info leak, missing rate limits. Should fix.

  • Low

    Minor hardening: missing headers, verbose errors, metadata leak.

  • Info

    Observation or process note. No direct exploit.

Sample report

See exactly
what you get.

The audit is only as good as the report it produces. So here is a full one. This is a complete, redacted sample assessment against a fictional health platform, the exact deliverable your engineers would receive, down to the severity scoring and remediation.

  • Executive summary written for the CTO, not the console
  • Every finding scored with CVSS 3.1 and ranked worst-first
  • Business impact in plain language, plus exact remediation
  • Methodology, severity model, and a retest commitment
Download the Sample ReportPDF · 21 pages · no email required
Sample report findings pageMaru Security sample assessment report cover

Independence

We assess.
Your team fixes.

We do not touch your codebase, and that is deliberate. The auditor who also writes the patch has a reason to look the other way. Staying strictly third-party means our only job is to tell you the truth about your security, and our report carries the weight of a genuinely independent assessment.

No conflict of interest

We are paid to find problems, not to minimize the work of fixing them. The incentive points one way: at the truth.

Your code stays yours

We never commit, deploy, or alter a line. You keep full control and a clean separation of duties.

A verdict others trust

An independent report is what an enterprise customer, a partner, or a cyber-insurer will actually accept.

Method

How an engagement actually runs.

I.Scope & authorize

Nothing happens without a signature.

We agree the targets, the rules of engagement, and the test window in writing. A signed authorization is the first artifact of every engagement. No permission, no testing, ever.

II.Map

We learn the application before we attack it.

Recon the full surface: subdomains, endpoints, inputs, integrations, exposed files. You cannot test what you have not mapped, so we map all of it first.

III.Test like an adversary

Manual testing, not a scanner left running.

We work the 136-control methodology by hand, the way a real attacker would: chaining small flaws into real impact, probing the logic a scanner can never understand.

IV.Validate

Every finding is proven before it is written.

We reproduce each issue and discard anything we cannot demonstrate. A confident false positive wastes your engineers' time and costs us your trust. Only confirmed findings make the report.

V.Report

We hand it to you. You stay in control.

A structured report with an executive summary, prioritized findings, CVSS scores, and exact remediation guidance. Your team fixes on your timeline, in your codebase.

VI.Retest

We confirm it is actually closed.

After remediation we re-run the affected controls and mark each finding verified-fixed, so you finish with proof, not a hope that the patch worked.

Engagement models

You decide
how deep we go.

The depth of an assessment scales with the access you're comfortable giving. We recommend the right fit for your goals and budget. You make the call, and you can start with less.

01

From the outside in

Black-box

We test with nothing but your target and scope, exactly as an external attacker would, with no credentials and no code.

You provide: the target and scope.

Simulates a real-world outside threat.

02Recommended

Most engagements

Grey-box

We test as an authenticated user with one or two accounts. The best balance of realism and coverage, and where most real issues live.

You provide: one or two test accounts + your stack.

The default for most web and SaaS applications.

03

Maximum assurance

White-box

We combine live testing with read-only review of your source for the deepest coverage, finding what the outside can never see.

You provide: read-only source access, in addition.

For high-stakes systems and compliance.

▸ Whatever you share, source, test accounts, or just a URL, is covered by NDA, handled on an isolated environment, and destroyed when the engagement closes. We never need write access, and grey-box never requires your source code.

What we assess

Any stack.
Any application.

We assess software across the full range of modern applications, from multi-tenant SaaS and APIs to mobile, cloud, and AI-powered products, and across industries from fintech and health to e-commerce and developer tooling. The vulnerability classes are universal; the OWASP methodology is stack-agnostic, and so are we.

We also ship production software ourselves, so we read code the way the people who wrote it do. That instinct, knowing where a subtle bug actually hides, carries across every system we touch.

Web & SaaS platforms

Multi-tenant apps, dashboards, internal tools. Access control, tenant isolation, and business-logic abuse.

APIs & backends

REST, GraphQL, gRPC, webhooks. BOLA, mass assignment, excessive data exposure, rate-limit gaps.

Mobile applications

iOS and Android. Insecure storage, weak transport, hardcoded secrets, and the APIs behind them.

Cloud & infrastructure

AWS, GCP, Azure, Cloudflare, Vercel. Misconfigurations, exposed secrets, IAM gaps, public storage.

AI & LLM applications

Prompt injection, data leakage, insecure tool use, and over-trusted model output. The new attack surface.

E-commerce & payments

Stripe, Adyen, PayPal, custom ledgers. Price tampering, webhook forgery, and checkout abuse.

Who it is for

From first launch to enterprise scale.

The same rigorous methodology runs against a weekend build and a platform doing millions in revenue. The depth scales to the scope. The standard does not move.

Founders & fast-moving teams

Built something real.

You shipped a product that has users now, whether a senior team wrote it or an AI assistant did. You should not have to be a security expert to know it is safe. We are the independent assessment between your launch and your first incident, in language you can act on.

  • A clear report, prioritized worst-first
  • The critical issues separated from the noise
  • Findings any competent engineer can close
  • Proof of diligence for users, partners, and app stores

Established businesses & enterprises

Have something to lose.

You carry customers, revenue, and regulatory exposure, and your teams ship faster than any internal review can keep up with. We are the independent, third-party assessment that satisfies the customer security questionnaire, the cyber-insurer, the board, and your own standard.

  • Independent assessment for vendor security reviews
  • Cyber-insurance and compliance-ready summaries
  • Continuous re-testing as you keep shipping
  • A documented record of your posture over time

Questions

The things people ask first.

Is this legal?+

Completely, when it is authorized. Every engagement begins with a signed authorization and a written scope that you sign as the owner of the systems being tested. We do not touch anything that is not explicitly in scope. That document is the line between professional security testing and a crime, and we never cross it.

Do you fix the vulnerabilities?+

No, and that is on purpose. We are a third-party assessor. We find, prove, and document the issues with exact remediation guidance, and your own engineers fix them on your timeline. Staying independent is what makes the report trustworthy to your customers and insurers. If you need hands to fix, we can point you to people.

Will testing break our production app?+

We test carefully and agree the rules of engagement up front, including intensity, timing, and anything off-limits. Before any state-changing tests we confirm you have a current backup. The goal is to find what an attacker would find without behaving like one.

What do you need from us to start?+

A short scoping call, the list of targets, a signed authorization, and whatever access the engagement type calls for. For a deeper grey-box audit that might be a low-privilege test account; for a black-box review, sometimes just the URL.

How long does an audit take?+

A focused Ship Review is days. A full Application Audit is typically one to two weeks depending on the size of the surface. We agree the timeline in the scope before anything begins, and the retest happens after your team has remediated.

Is our data and the report confidential?+

Yes. Findings are confidential by default and covered by an NDA. We minimize what we access, store any evidence encrypted, and destroy it per the engagement agreement. Your security report is yours to share, or not.

Why should we trust you to assess us?+

Because we build production software on the exact stack we audit, our methodology is mapped to the OWASP standards the whole industry uses, and every finding we report is one we can prove and reproduce in front of you. We would rather under-claim and demonstrate than over-claim and hope.

Accepting engagements

Request
an audit.

Tell us what you have built and where it lives. We reply within one business day with a scope, a timeline, and a price. The first step is always a short conversation, never a scan.

Coverage

Serving companies across the United States

▸ No testing of any kind begins until a written authorization and scope are signed by the system owner.

Confidential · we reply within one business day.