Internet standards contain ambiguities that make different implementations disagree on the same input. Those disagreements are security holes — and almost nobody is looking for them.
The blind spot
Your team tests its code. Your scanners check your dependencies. But the written standards your software implements — the documents that define how login tokens work, how encrypted connections are set up, how APIs talk to each other — are treated as settled ground. They aren't. They're written in natural language, and where the language is ambiguous, different vendors quietly build the same clause differently. Think of it as a contract written in slightly vague language: two companies read the same clause and build different things. When one of those things is more permissive than the other, an attacker walks through the gap.
The same input. Different software. One reads the standard more permissively — and the gap between them is where attackers get in. No code scanner finds this, because the flaw isn't inside any single codebase.
Why existing tools miss this
Static analysis, dependency scanning, and fuzzing all assume the bug lives inside one codebase. This one doesn't. The flaw lives in the gap between implementations — when your library and your counterparty's library both look correct in isolation but interpret the same standard differently. Finding it requires testing the standard itself: giving the same input to multiple real-world libraries and watching for who agrees with whom.
The proof — a real vulnerability, end to end
A method we built (HUNTER) found exactly this kind of flaw in PyJWT — a Python library used by millions of services to verify login tokens. Here is how the finding worked, step by step:
A real finding, end to end. The standard was silent on which URL types to allow; one library inherited a permissive default; the others didn't. The maintainers confirmed and fixed the bug. That finding came from testing the standard, not the code.
That vulnerability had been sitting in a widely-used library, undetected by any code scanner, because it wasn't a bug in the code — it was a gap between how five libraries interpreted the same standard. This isn't a one-off. The same kind of cross-implementation disagreement turns up repeatedly across the protocols we've tested — wherever a standard leaves room for interpretation.
What you get
A targeted audit of the standards your product relies on.
Find the vulnerabilities no code scanner catches.The flaw isn't inside any one codebase — it's in the gap between how your software and your counterparties interpret the same standard.
Cover the surface your existing tools cannot reach.Static analysis, dependency scanning, and penetration testing all assume the bug lives inside one product. Standard-level divergence sits underneath all three.
Get findings with evidence, not alerts with noise.Every finding is verified against multiple real implementations. When the method finds agreement instead of divergence, we report that too — honestly.
Disclosure support included.For findings that require vendor contact or coordination with a standards body, we handle it — or hand you a package ready to file.
Built for teams shipping software on authentication, identity, cryptographic, or protocol standards — and for security teams that have exhausted code-level scanning and want to look at the layer underneath.
If your product depends on internet standards, the standards themselves are an attack surface.
Engage BoxSight for a targeted audit of the standards your product relies on. We'll tell you which parts are exposed.