Frontier Verify is self-serve: you choose the assets, choose the depth, pay by card, and a report arrives inside a week. The part that is not self-serve is the testing and the verification. Both are done by people. This note explains exactly what that means, because “human-verified” is a phrase that gets attached to a lot of reports that are, on inspection, exported scanner output with a signature on the cover.
The problem with scanner exports
A vulnerability scanner is a useful instrument. It is fast, consistent and good at breadth. It is also wrong a lot, in both directions.
It reports issues it has inferred rather than demonstrated: a version banner that matches a CVE, a header that is missing, a configuration that is sometimes dangerous. Many of these are not exploitable in your environment and some are not even present, because banners lie and backports exist. It also misses the issues that matter most: logic flaws, authorization gaps between users and roles, weaknesses that only appear when several small things are chained together. No scanner will notice that a quote request from one customer can be read by another by changing a number in the URL. A person will, in about a minute, if they think to look.
When a scanner export is dressed up as a penetration test, the organization that paid for it receives two things: a long list of items its engineers will spend days triaging and dismissing, and false confidence about the things that were never tested. We built Frontier Verify to deliver the opposite.
The reproduction standard
Every finding in a Frontier Verify report has been reproduced by a second analyst who did not do the original testing, working from the tester’s notes alone. The rule is simple: if the second analyst cannot make the issue happen by following the steps as written, the finding does not ship. Either the steps are rewritten until it can be reproduced, or it is removed.
This does three things. It eliminates false positives, because an inference that cannot be demonstrated fails the test. It forces the reproduction steps to be exact, which is what your engineers need in order to fix the issue without a call. And it catches the cases where the original tester misread what they were seeing, which happens to everyone and is why the second person exists.
The reproduction is recorded. Each finding carries the request and response, the screenshot or output, and the time it was confirmed. If a finding depends on a specific account, role or sequence of actions, that is written down too.
How severity is scored
Severity starts from the Common Vulnerability Scoring System base score, because it is a published standard and your auditors and customers know how to read it. It does not end there. A base score describes the vulnerability in the abstract; your report describes it in your environment.
The verifying analyst adjusts for context and writes the reasoning next to the score. An authentication bypass on an internal administration panel that is only reachable from a corporate network is still serious, but it is not the same finding as the same bypass on a public login page. An information disclosure that reveals a stack trace is low on its own and considerably higher when the trace includes a connection string. The adjustment is explicit, so that when your team disagrees with it they are disagreeing with a stated reason and not a number.
Where several findings combine into an attack path, the chain is written up as its own finding, with the combined impact scored and the individual steps referenced. This is the single most common thing a scanner cannot do and a reviewer can: see that three mediums are, together, a critical.
What gets removed
A scanner would have shipped all of the following. We do not.
- Version-based findings where the version could not be confirmed and the vulnerable behaviour could not be demonstrated.
- Missing security headers reported as individual issues. They are consolidated into one finding with the actual exposure explained, or dropped where the header would make no difference.
- Informational items that are not findings: open ports running the services they are supposed to run, the existence of a login page, the presence of a technology.
- Anything reproduced only against a test or staging system when the scope was production, unless you asked for it.
- Duplicates. The same issue in twelve parameters is one finding with twelve locations.
The result is a shorter report. That is deliberate. A report with eleven real findings is more useful than a report with ninety items, eleven of which are real, and it is a great deal faster to act on.
What gets added
Manual testing finds the things that make reports worth paying for. Within the depth you selected, the tester looks for the classes of issue tooling does not reach: access control between users, roles and tenants; business logic that can be abused in the order it was never meant to run; session and token handling; the behaviour of the application when inputs are unexpected rather than malicious; and the chains described above.
At the deeper levels, authenticated testing with the roles you provide covers the parts of the application that scanners never see at all, because they sit behind a login.
How the week works
A standard scope runs on a predictable rhythm. Scoping and payment happen on the site. Testing runs across the following days in the window you chose, with tooling for breadth and manual work for depth. Verification follows: a second analyst reproduces each finding and settles the severity. The report is then assembled and issued, inside a week of payment for standard scopes. If something critical is found during testing, you hear about it the same day rather than at the end.
What the report looks like
Two readers, one document. An executive summary states the overall exposure, the findings that matter most and what to do first, in plain language on a few pages. The technical section gives each finding its description, severity and reasoning, reproduction steps, evidence and recommended fix. A prioritised fix list closes the report, ordered by risk and effort. The scope, dates, depth and the accounts used are recorded so the reader knows exactly what was and was not tested.
Once the fixes are in, a retest confirms them and the report is reissued with a closure summary. That is the document you hand to the customer, auditor or board who asked for the test in the first place.
Why it matters
The value of a security test is not the list. It is the confidence that the list is complete within its scope and correct in every entry. Human verification is how we earn that confidence, and it is the reason a Frontier Verify report can be shorter than the scanner output and worth more.