We've spent the last few weeks trying to break our own plugin. We fuzzed the WebAuthn decoder with 200,000 adversarial inputs, found a bug where brute-force lockout could silently lock out every legitimate visitor sharing a CDN's IP, and once we went looking, found and fixed six separate places in the codebase making that same mistake. All of it is documented, versioned, and dated: https://secondgatewp.com/security-testing-methodology/
SecondGate is built local-first: no Composer dependencies, no third-party WebAuthn library, and nothing about your visitors is ever sent anywhere. All matching – country, IP, bot verification – happens on your own server against locally cached data. To be upfront about the outbound calls that do exist: Pro downloads curated IP blocklists for Microsoft Azure, DigitalOcean, Hetzner, and OVH on a schedule, and the vulnerability scanner checks your installed plugin/theme names against a public vuln database. That's data coming in, and software names going out – never anything about your visitors or their traffic.
Now we want 100 technical testers, free full Pro access, to find what we haven't.
What's actually been tested, not just built:
Passkey/WebAuthn support with a custom CBOR decoder, checked against official RFC 8949 conformance vectors, real authenticator-captured data, and 200,000 fuzzed adversarial inputs.
