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.
Maru Security · Independent application security · United States
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.
{ "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
The problem
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.
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.
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.
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
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.
The full assessment
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.
Best before a launch, a funding round, or an enterprise customer's security review.
Focused, pre-launch
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.
Best for solo founders and lean teams about to put real users on a new build.
Re-audit on release
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.
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
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.
Signed scope, rules of engagement, data handling. No test runs without it.
Subdomains, exposed files, leaked secrets, the full attack surface mapped.
TLS, security headers, cookies, CORS, source maps, preview exposure.
Brute force, MFA bypass, password reset, OAuth, JWT forgery.
Token entropy, fixation, logout invalidation, CSRF.
IDOR, privilege escalation, multi-tenant isolation, row-level access rules.
SQL, XSS, SSRF, command, template, path traversal, prototype pollution.
Rate limiting, BOLA, excessive data exposure, webhook verification.
Price tampering, race conditions, workflow bypass, refund abuse.
DOM XSS, clickjacking, secrets in the bundle, postMessage origins.
Webshells, SVG XSS, traversal, signed-URL scope, metadata leakage.
Password hashing, secrets in git, weak algorithms, data at rest.
Webhook signatures, price authority, entitlement, idempotency, PCI scope.
Env var exposure, cron auth, edge bypass, WAF, monitoring.
Known CVEs, outdated frameworks, lockfile integrity, third-party scripts.
Reproducible findings, CVSS, business impact, remediation, retest.
The deliverable
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.
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
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.
One page. Overall posture, the top risks in plain business language, and what to fix first. The page your buyer, board, or insurer reads.
Every issue, ranked worst-first, each with reproduction steps, evidence, affected endpoints, and a CVSS score.
Exactly how your engineers close each finding, with the specific fix and code or config example. Written to be actioned, not admired.
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.
Full compromise: RCE, auth bypass, cross-tenant access, payment forgery.
Account takeover, stored XSS, IDOR, secret exposure. Fix before release.
CSRF, weak config, info leak, missing rate limits. Should fix.
Minor hardening: missing headers, verbose errors, metadata leak.
Observation or process note. No direct exploit.
Sample report
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.


Independence
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.
We are paid to find problems, not to minimize the work of fixing them. The incentive points one way: at the truth.
We never commit, deploy, or alter a line. You keep full control and a clean separation of duties.
An independent report is what an enterprise customer, a partner, or a cyber-insurer will actually accept.
Method
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.
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.
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.
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.
A structured report with an executive summary, prioritized findings, CVSS scores, and exact remediation guidance. Your team fixes on your timeline, in your codebase.
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
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.
From the outside in
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.
Most engagements
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.
Maximum assurance
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
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.
Multi-tenant apps, dashboards, internal tools. Access control, tenant isolation, and business-logic abuse.
REST, GraphQL, gRPC, webhooks. BOLA, mass assignment, excessive data exposure, rate-limit gaps.
iOS and Android. Insecure storage, weak transport, hardcoded secrets, and the APIs behind them.
AWS, GCP, Azure, Cloudflare, Vercel. Misconfigurations, exposed secrets, IAM gaps, public storage.
Prompt injection, data leakage, insecure tool use, and over-trusted model output. The new attack surface.
Stripe, Adyen, PayPal, custom ledgers. Price tampering, webhook forgery, and checkout abuse.
Who it is for
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
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.
Established businesses & enterprises
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.
Questions
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.
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.
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.
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.
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.
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.
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
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.
Direct
security@marusystems.devCoverage
Serving companies across the United States
▸ No testing of any kind begins until a written authorization and scope are signed by the system owner.