104 findings. Full bundle in 34.4 seconds. How do you like them apples? (27 June 2026)
- 417360

- Jun 27
- 4 min read
Updated: Jul 6
By DNSystems LLC (dnsystemsllc.com/ptrg)
TL;DR — DNSystems' PTRG just stress-tested the entire OWASP / bWAPP Top-10 surface — 104 validated vulnerabilities plus 5 suspected — and packaged the complete deliverable bundle (PDF report plus slide deck plus DOCX appendix) in 34.4 seconds of wall-clock. That's 0.32 seconds per finding, measured with Python's perf_counter() against a cold cache. Not a marketing pitch. A timer.


What just happened
Yesterday our sample-report library carried hardcoded timing values that we frankly guessed at. Somewhere in the 38 to 71 second range per target. Then a customer asked us how those numbers were measured.
Long pause.
So we replaced the guesses with the real thing. Every autonomous engagement in our public sample-report catalog now runs through perf_counter instrumentation at backend boot. PDF plus slides plus DOCX. Cold cache. End-to-end:
bWAPP firehose stress test — 109 findings — 34.4 seconds — 0.32 sec / finding OWASP Juice Shop — 35 findings — 16.7 seconds — 0.48 sec / finding OWASP IoTGoat — 7 findings — 10.8 seconds — 1.54 sec / finding Zero Bank — 6 findings — 10.2 seconds — 1.71 sec / finding AltoroMutual — 6 findings — 9.6 seconds — 1.60 sec / finding BMC hardware demo — 6 findings — 9.9 seconds — 1.66 sec / finding testphp.vulnweb.com — 6 findings — 9.1 seconds — 1.52 sec / finding scanme.nmap.org — 5 findings — 10.0 seconds — 2.01 sec / finding HackThisSite — 4 findings — 9.8 seconds — 2.44 sec / finding example.com — 2 findings — 9.1 seconds — 4.53 sec / finding
Average across all ten reports — 12.3 seconds per full bundle.
The bWAPP stress test, specifically
bWAPP is ITSEC Games' intentionally-vulnerable PHP and MySQL training app. It surfaces every OWASP Top-10:2025 category — SQL injection, cross-site scripting in reflected, stored, and DOM-based flavors, command injection, file inclusion (local and remote), CSRF, broken authentication, XXE, SSRF, weak crypto, misconfigurations, IDOR, even native-code memory corruption in the support CGIs.
We modelled the full surface as 10 hero findings — each with full payload, reproduction steps, fix recommendation, CVSS v4.0 vector, DREAD score, MITRE ATT&CK technique, and NIST 800-53 control mapping — plus 94 variant findings that map back to the hero root causes so the report stays readable at scale.
Total — 109 findings. Full deliverable bundle in 34.4 seconds.
Try that on any traditional pentest-as-a-service platform. The pen-tester teams we have worked with spend half a day formatting the executive summary alone for an engagement that size.
But what exactly does that 34.4 seconds measure?"
Honest answer — the full report packaging wall-clock. From "we have a findings list" to "client has a signed PDF, slide deck, and DOCX in hand." That includes LaTeX typesetting, severity-matrix and kill-chain chart generation, per-finding CVSS QR code rendering, two pdflatex passes for cross-references, the Beamer slide compile, and the DOCX build via python-docx. End to end. Three deliverable artifacts.
What is NOT in the 34.4 second figure — the bWAPP findings themselves. Those 109 entries (10 hero findings plus 94 variants) were hand-authored offline and live as static Python data in our catalog. bWAPP is a downloadable training app, not a hosted target — so there is no live recon or exploitation happening when the timer runs against this specific sample.
For real engagements against customer infrastructure, the pipeline looks different. DeepScope handles reconnaissance. DeepStrike handles validated exploitation. Then this same packaging engine produces the deliverable bundle. Each phase gets its own perf_counter wrapper.
Heads-up — a second benchmark slot is already wired into the platform. Live engagement total (DeepScope plus DeepStrike plus packaging) has its own field in our benchmark cache and will publish under its own MEASURED badge on every catalog card the moment the upstream instrumentation lands. We are adding that next. Buyers will see both numbers cleanly separated. Packaging speed on its own. Full live-engagement speed when both upstream phases are running against legally-pentestable targets (scanme.nmap.org, testphp.vulnweb.com, OWASP Juice Shop on Heroku, et cetera).
The reason this 34.4 second figure still matters today, even before the live-engagement benchmark publishes — packaging IS the bottleneck on traditional PTaaS engagements. It is the phase where reports sit on a senior consultant's desk for two weeks after the engagement closes.
We just collapsed it to under a minute, with 109 findings, with DREAD plus MITRE plus NIST 800-53 plus per-finding CVSS QR codes plus a four-column hyperlinked table of contents, automatically.
Why this matters
Three sample reports in our catalog are explicitly synthetic — historical CVE walkthroughs reconstructed from publicly disclosed Zscaler, Netskope, and Cloudflare One advisories. Buyers see PTRG's report format applied to the (Secure Access Service Edge) SASE vendor they already deploy. Without us ever touching their production infrastructure.
When a procurement officer asks "what does a PTRG deliverable look like on the vendor we already use" — we have the answer ready. In the same library. With the same DREAD plus MITRE plus NIST 800-53 formatting.
How to verify
Every per-card seconds figure on the sample-reports library carries a MEASURED badge with a hover tooltip showing the exact build timestamp. The benchmark methodology is documented in our FAQ. Source code for the instrumentation lives in services/sample_benchmarks.py. We are transparent because we have to be — buyers do not trust marketing numbers, and frankly neither should you.
What's next
A live demo. Bring us your favorite intentionally-vulnerable target and we will generate the bundle in real time while you watch the timer count up.
109 findings. 34.4 seconds. How do you like them apples?

PTRG. For Pentesters, By Pentesters.


Comments