Responsible disclosure.
What we do when we find a vulnerability — in our own systems, in a client's environment, or in third-party software during an engagement. Written in plain English, and signed by every practitioner at the lab.
Scope
This policy covers three classes of finding:
- Vulnerabilities in our own infrastructure — anything reachable at stealthbytelabs.com, our subdomains or our developer-facing services. If you found one, jump to §04.
- Vulnerabilities discovered during engagements in a client environment — handled per the engagement contract and §02 below.
- Vulnerabilities discovered in third-party software during research or engagements — coordinated with the affected vendor per §03 below.
If you are a security researcher acting in good faith under this policy, we will not pursue civil or criminal action against you, and we will not request that law enforcement do so. The detailed conditions for good-faith research are in §05.
Findings during client engagements
During an engagement we may discover vulnerabilities that fall outside the client's own software — in vendor products, third-party libraries, hosted services or open-source components. Handling of these is governed by the engagement contract and by the principles below.
What we do- The client is notified immediately, with full technical detail and a private mitigation guide.
- The affected vendor is contacted via their coordinated disclosure channel within 5 business days of the client notification.
- Public disclosure follows industry-standard 90-day windows from vendor notification, extendable by mutual agreement when patch development reasonably requires it.
- The vendor receives a complete technical writeup, proof of concept, and proposed CVSS scoring.
- The client environment is the first priority for mitigation, before any other affected user.
- We will not sell vulnerability information to brokers, governments, or any third party.
- We will not retain weaponised exploit code beyond the disclosure window.
- We will not publish identifying detail about the affected client without explicit written permission.
- We will not coordinate with parties that conduct offensive operations against unwilling targets.
Every practitioner at the lab signs an internal version of this policy as a condition of employment. We have refused two acquisition offers in part because the acquirer's disclosure practices were incompatible with these commitments.
Coordinated disclosure timeline
For vulnerabilities we report to third-party vendors, this is the timeline we follow. Days are calendar days unless otherwise noted.
Vendor notification
We send a full technical report — proof of concept, affected versions, suggested CVSS — via the vendor's published security contact (security.txt, PSIRT, or a bug bounty platform where available). We request acknowledgement within 5 business days.
Acknowledgement expected
If we have heard nothing, we send a follow-up to a second channel. If we have still heard nothing by day 14, we escalate to CERT/CC or the relevant national CERT.
Engagement window
By this point we expect regular technical correspondence with the vendor's security team. We share additional artefacts, answer reproduction questions, and discuss CVSS scoring jointly.
Mid-window review
We check in on patch progress. If the vendor needs an extension beyond day 90, we request a written explanation and target patch date. Extensions are granted in good faith — typically once.
Public disclosure
By day 90 the vendor has typically shipped a patch and a CVE has been assigned. We publish a writeup on the intel feed with full technical detail. If the patch is in active deployment and broad disclosure would cause harm, we will delay technical detail by mutual agreement.
If no patch is available
If 90 days have elapsed and no patch has shipped, we publish an advisory containing affected products, observable indicators, mitigation guidance and severity assessment — but we withhold weaponised proof of concept until a patch is available, or until further delay would itself cause greater harm. This is a judgement call we make publicly and document in the advisory.
Reporting a vulnerability to us
If you have discovered a vulnerability in our own infrastructure — the website, our developer tooling, or anything else we operate — we want to hear from you. We treat researchers reporting in good faith as collaborators, not threats.
In scope- stealthbytelabs.com and all subdomains we operate
- Our internal authentication, identity and code-signing infrastructure
- Any open-source code we publish under the stealthbyte-labs organisation
- Findings that require physical access to our premises or personal devices
- Issues in third-party services we use — please report those directly to the affected vendor
- Social engineering attempts against us (we run our own internal tests for this)
- Volumetric denial of service, password spraying, and other noise generation
Email ops@stealthbytelabs.com, or use the contact form for initial coordination. Include reproduction steps, affected versions or endpoints, and any artefacts that help us verify. If you need an encrypted channel before sending technical detail, say so in your first message and we'll arrange one.
Safe harbour for good-faith research
Research meeting all of the conditions below is research we treat as authorised under this policy:
- You operate within the scope defined in §04 above.
- You do not access, modify or delete data belonging to anyone other than yourself or accounts you control.
- You make a good-faith effort to avoid privacy violations, service disruption and data destruction.
- You report the finding promptly, give us reasonable time to remediate, and do not disclose to third parties before our agreed window.
- You do not exploit the vulnerability beyond what is necessary to demonstrate it.
- You do not use the research for extortion, brokerage, or any form of unauthorised commercial gain.
For research conducted under these conditions we will not initiate civil or criminal action, will not request law enforcement involvement, and will publicly thank you in the advisory if you wish to be credited.
Safe harbour does not extend to extortion, data theft for resale, lateral expansion beyond the affected system, social engineering of staff, or research designed to harm our users. We will respond to those activities under all available legal options.
Recognition
We do not run a paid bug bounty programme. Researchers who report verified findings in good faith are credited publicly when we publish the finding — with your preferred name and affiliation, or anonymously if you'd rather.
For high-severity findings that require significant research effort we may also offer one of: a swag package, a discretionary payment from our research budget, or — for researchers who'd find it more valuable — co-authorship on the resulting writeup.
This is not a substitute for a paid programme, and we know that. If structured bounty payments matter to you, please consider whether reporting here is the right fit. We will still treat your report with the diligence and respect a paid programme would.
Changes to this policy
This policy is reviewed at least once per year, and any time material changes are warranted. Version history is maintained in our public policy repository. Researchers are bound by the version in effect at the time their research was conducted.
Material changes — anything affecting scope, safe harbour or disclosure timelines — are announced on the intel feed at least 30 days before taking effect.
Authority
This policy is signed off by the leadership of the lab and applies to every engagement, every researcher and every member of staff. Internal signatures are maintained in our PKI. Questions about authority or scope can be directed to ops@stealthbytelabs.com.
End of policy. Last reviewed 2026-04-21.
Found something? Tell us.
Email or the contact form. We acknowledge every report, and we credit every researcher who wants to be credited.