How We Approach Responsible Vulnerability Disclosure

Client engagements are most of what our team works on, but a meaningful part of our research time goes toward independent vulnerability research in widely used software and infrastructure — the kind of work that's resulted in dozens of CVE assignments across our researchers' careers. Here's how we actually run that process.

Discovery

Independent research starts the same way most real attacker research does: picking a target with a large blast radius (something used by enough organizations that a vulnerability actually matters), then testing it the way an attacker would — not just running an automated scanner and calling it research.

Verification

A finding isn't a finding until it's reproducible. We build a minimal proof-of-concept, confirm impact under realistic conditions, and rule out the vulnerability being already-known or already-patched in a newer release. This step alone kills more "discoveries" than any other — a lot of what looks novel at first glance turns out to be documented behavior or a already-fixed edge case.

Coordinated Disclosure

Once a finding is verified, we follow standard coordinated disclosure practice: report to the vendor or maintainer first, agree on a reasonable remediation timeline, and hold public details until a fix is available or the agreed disclosure window closes — whichever comes first. We don't drop details early for attention, and we don't sit on a finding indefinitely if a vendor goes silent past a reasonable window.

Why This Matters for Clients

The same instincts that drive independent research — thinking like an attacker instead of running a checklist — are what show up in client engagements. A team that's found and reported real vulnerabilities in production software brings a different level of scrutiny to your environment than a team that's only ever run scanners against scoped test systems.

Talk to our team about what offensive, research-driven testing looks like for your environment.