And a written list of everything we could not check. RedForge tests your running web, Android and iOS applications the way an attacker would, proves each finding with a reproducible request, and hands you the part most reports leave out.
untested never renders as clean. A module that ran and examined nothing says so, with the reason — so you can tell “checked, nothing there” from “never reached”.
Fixed scope, written authorization, and a report your engineers can act on the same afternoon. Every engagement ends with a free retest once you have patched.
Broken access control, injection, business logic and race conditions across your full request surface — plus the external footprint and the servers nobody remembers running.
IDOR and BOLA · REST, GraphQL and gRPC · business logic · attack surface · subdomain takeover · cross-tenant isolation
Web & API testingWhat anybody who downloads your app can pull straight out of it — Android APK or AAB and iOS IPA, then the backend API those apps actually talk to.
Hardcoded secrets · manifest, IPC and deeplinks · entitlements and ATS · backend hosts extracted, then tested
Mobile testingThe secrets and flaws already sitting in your repository, the libraries carrying known CVEs, the buckets left open, and the assistant you added last quarter that nobody is logging.
Source review · dependency and CVE review · cloud configuration · cloud storage · AI and LLM testing
Code & cloud reviewIndia’s Digital Personal Data Protection Act applies to any business handling the personal data of people in India, with no small-business exemption. Penalties for the security obligation reach ₹250 crore.
Consent, notice and tracker audit · personal data exposure testing · §8(4) safeguards evidence · obligations mapped to sections
DPDP readinessEvery engagement is priced by scope, and the passive attack-surface report costs nothing. Start there if you want to see what you already expose before spending anything.
Every scanner claims detection. Almost none will tell a client what they did not look at, because it reads as weakness — right up until the client’s next assessment finds something in the gap and asks why the first report implied it was clean.
The module ran, examined a real surface, and reported what it found.
Some of the surface was reached. Never counted as a clean pass.
It ran and examined nothing. Our gap, disclosed with the reason.
The engagement chose not to test it. Your decision, kept separate.
An advisor once suggested we relabel untested as “out of scope”. We refused. It blames our gap on the client’s decision and destroys the difference between something you chose not to test and something we could not see. Both appear in your report, under their own names.
What we will not say: “zero false positives.” The verification oracle reduces them; it does not eliminate them. What is true is narrower and checkable: every finding is verified with reproducible evidence, and anything we could not prove is reported as unproven — a lead, never a silent omission.
Most scanners never get there, so they report the marketing site and call it an assessment. We get in without breaking anything, because breaking a control is not in any engagement letter.
You export that session and hand it to us. No credential stuffing, no CAPTCHA solving, no OTP interception — a person authenticates normally, exactly as your policy already allows.
Actual query strings, body field names, real object IDs. A crawler infers none of those and a JavaScript bundle states none of them — which is precisely why the login POST body is where scanners miss things.
Two captures from two tenants is what turns “can user A read user B’s data” from an opinion into a test with an answer and an artifact behind it.
No CAPTCHA, OTP, MFA or SSO defeat, ever. Those are controls doing their job. Where one blocks us, the coverage table records it as blocked rather than quietly reporting the area as clean.
Run against a container pinned by image digest — never a tag, because ground truth that drifts leaves a suite green while it stops describing the target. Same scorecard that gates our releases.
This page used to say 5 of 6. The denominator went up, not the score. We went back to the same pinned container and found two more real exposures we had never written down — a directory listing over cryptographic keys, and one over application logs. Both are genuinely there. Our scanner does not request either path, so it does not find them.
We added them to the ground truth anyway, and our own number got worse. The alternative was to leave two known vulnerabilities out of the scoring, or to paste those two paths into our wordlist until the page went green. The first is dishonest and the second measures nothing except how well we tuned for one container.
The rest depends on what you give us, and we would rather say
which. One of the misses is a POST-body SQL injection at
/rest/user/login
that no crawler can reach, because a request body is not stated anywhere
a crawler can read. Given a browser session capture the same scan proves
it. Crawling alone scores 4 of 8; with a capture, 5 of 8. If you
cannot supply one, that is the honest expectation, and the coverage table
will say the request bodies were never reached rather than let silence
imply they were clean.
Two different denominators, and both are right. This benchmark scores detection against eight vulnerabilities we planted in a pinned container and know the answer to. Our sample report separately says 6 of 10 findings confirmed, which counts how much of what we reported carries proof. Different sets, different questions — we name which is which wherever either appears.
Scope note: this is a small, pinned, self-hosted lab — the score above is six planted vulnerabilities and ten paths verified absent, on one target, scanned with a browser capture supplied. It is not an industry benchmark and it does not predict a detection rate for your application. We publish the size and the conditions along with the score, because a detection rate quoted without its denominator is not a measurement.
A vulnerability list is useless without the parts that let someone act on it. Every RedForge finding carries three things, in this order.
What we assert is wrong, named and rated, anchored to the exact endpoint, screen or API route it affects.
The reproducible request and response that proves the claim. Every claim class has a minimum standard of evidence; anything that cannot meet its own standard is demoted to a lead rather than dropped.
The fix written in your framework and captioned as an illustrative pattern. We tested your running application from the outside, so it is never presented as a diff of your code — and an unrecognised framework gets no code rather than the wrong framework’s.
The technical report is for your engineers. These four are for everyone else on the deal — and they are usually what the engagement was really about.
One page, signed, forwardable. Scope, method, testing window, findings by severity, retest status — and the coverage disclosure in the same size type. This is what unblocks a deal.
The questions buyers actually ask, from the SIG, CAIQ and SOC 2 Common Criteria families, answered from your evidence. The ones this kind of testing cannot answer are marked as such, rather than left blank for someone to fill in optimistically.
Findings mapped to ISO/IEC 27001:2022, SOC 2 and DPDP 2023 as evidence against named controls. We are not a certification body and this is not an audit opinion — it is the evidence your auditor will ask for.
Findings land in GitHub code scanning, stay until they are fixed, and close themselves when they stop reproducing — so the report does not become a spreadsheet nobody reopens.
Every finding is tagged against the frameworks below, so the report you get is usable as evidence rather than needing to be translated into it first.
Findings mapped to named Annex A controls, so a gap in your ISMS evidence pack points at the control it belongs under rather than at a severity label.
Mapped to the Common Criteria families your auditor works through, covering the security principle most Type II reports lean on.
Each finding tied to the section it bears on — and the penalty attached — so exposure reads in rupees rather than in severity labels. See the DPDP page.
Web and API findings classified against the OWASP Top 10 and the Application Security Verification Standard, plus the OWASP Top 10 for LLM Applications where an assistant is in scope.
Android and iOS findings mapped to MASVS and the OWASP Mobile Top 10, and bound to the exact build by SHA-256. See the mobile page.
Every finding carries its CWE identifier, and the questionnaire pack answers the SIG and CAIQ families from your evidence — marking the ones this kind of testing cannot answer rather than leaving them blank.
This is not an accredited audit. We are not a certification body, and a RedForge assessment is not an audit opinion or a compliance statement. If you need an ISO 27001 certificate or a SOC 2 report for a customer or an investor, you need an accredited auditor — what we provide is the evidence that auditor will ask you for.
The compliance page covers what each artefact contains, what an auditor will accept it as, and the frameworks we deliberately do not cover.
Automated reconnaissance, payload generation and triage compress weeks of manual work into hours. The model proposes; a deterministic oracle decides. Nothing the AI says becomes a finding on its own.
We agree targets, timelines and testing windows, and sign a written authorization from the legal owner of the asset. No scanning begins before this exists.
Subdomain and endpoint discovery, technology fingerprinting, and the real request shapes recovered from your own browser session.
Our team validates, chains and proves real impact. Anything that cannot meet its own standard of evidence is demoted to a lead rather than dropped.
Full remediation report with the coverage table attached, plus a free retest once you have patched, so the attestation reflects the fixed state.
We never scan a system without written authorization from the legal owner of the asset, an agreed scope, and a defined testing window.
An assessment is not a certification, an audit opinion, or a compliance statement. Where you need an empanelled auditor, we will tell you plainly instead of taking the work. Being wrong about this once is the whole business, so it is on the homepage rather than in a footnote.
Including the ones with an uncomfortable answer. Another twenty-plus are on the questions page, covering scoping, method, compliance and what happens to your data.
A full technical report with every finding, the evidence that proves it and the fix; a one-page signed letter of attestation you can forward; a security-questionnaire answer pack; findings mapped to ISO/IEC 27001:2022, SOC 2 and DPDP 2023; and SARIF for your GitHub Security tab.
Attached to all of it is the coverage table, stating what each module actually reached. A free retest is included once you have patched.
Two to seven days from signed scope to delivered report for a typical engagement. Larger or multi-application scopes take longer, and we tell you that before you commit rather than after.
No, and you should be wary of anyone who says otherwise. What we commit to is narrower and checkable: every finding is verified with reproducible evidence, anything we could not prove is reported as an unproven lead rather than quietly dropped, and the coverage table tells you what each module reached.
Our published benchmark includes the vulnerability we missed, for the same reason.
No. An assessment from us is not a certification, an audit opinion or a compliance statement. If your requirement specifically names a CERT-In empanelled auditor, we will tell you that rather than take the work.
It depends on scope: how many applications, whether mobile builds and source review are included, and how much of the surface sits behind authentication. Engagements start at ₹30,000, and the passive attack-surface report is free. See pricing.
Twenty-five more, grouped by topic. Scoping and authorization, how we test, coverage and its limits, compliance, pricing and data handling — and if yours is still not there, ask it directly.
All questionsSend us your scope and we will come back with an approach, a timeline and a price. No obligation, and no scanning of any kind until an authorization is signed.
