Why this exists

Our researchers find previously unknown vulnerabilities in third-party software, both during independent research and during authorised testing for clients. This document sets out exactly how we handle them, so vendors, clients and the wider community know what to expect from us before it happens.

Scope

This policy applies to vulnerabilities in third-party products or services that Signal 11 identifies through:

  • Independent security research conducted by Signal 11 staff.
  • Authorised penetration testing engagements, where the vulnerability lies in a product the client uses rather than in the client's own code or configuration.

It does not apply to findings in a client's own systems. Those belong to the client and are governed by the engagement contract.

Findings from client engagements

When we find a third-party vulnerability during a client engagement, the client hears about it first, in writing, before we contact anyone else.

The client then chooses one of two paths:

  1. Signal 11 coordinates. We handle vendor contact, tracking and publication under this policy. This is our recommendation, because we do it regularly and have the process ready.
  2. The client coordinates. The client owns the vendor relationship and the timeline. We provide the technical detail and support on request.

In either case, the client is never identified in any vendor communication or public advisory unless they choose to be.

Timeline

Day 0 is the date of our first contact attempt to the vendor through a documented channel. We attempt contact via, in order: a published security contact or security.txt, a bug bounty or VDP program, a generic security@ or support address, and named security staff on professional networks. We record every attempt.

Day 90 is the public disclosure date. We publish whether or not the vendor has responded.

We would rather never reach day 90. Vendors who engage with us early get a collaborative process. Vendors who don't get the deadline.

Extensions

We will extend the deadline for a vendor who is actively working on a fix. Extensions are:

  • Agreed in writing.
  • Given a specific end date. We do not grant open-ended extensions.
  • Capped at a total of 180 days from day 0.

The one exception to the cap is a vulnerability with a direct physical safety impact (for example, in medical devices or industrial control systems), where a longer coordinated timeline may be justified. These cases are assessed individually and any extension beyond 180 days must be approved under the exceptions process below.

Late engagement

A vendor who first responds after day 60, with no earlier engagement, does not pause or reset the clock. We will still work with them, but the day 90 date stands.

Active exploitation

If we see evidence the vulnerability is being exploited in the wild, the deadline moves to 7 days from that evidence. In that case we publish enough for defenders to detect and mitigate. Proof-of-concept code is withheld until a fix is available.

Early fix

If the vendor releases a fix before day 90, we publish once the fix is generally available. If the vendor asks for a short delay to allow customers to deploy, we will consider it, but not beyond the original day 90.

Unresponsive vendors

If we cannot reach a vendor, or they acknowledge and then go silent, we escalate before the deadline to a coordinating body:

  • Australian Cyber Security Centre (ACSC) for Australian vendors.
  • CERT/CC for international vendors.

Escalation does not extend the deadline.

What we publish

At disclosure we publish, on our blog:

  • A technical advisory describing the vulnerability, affected versions and impact.
  • The full disclosure timeline, including every contact attempt and any extensions granted. If we made an exception to this policy, it will be visible here.
  • Detection and mitigation guidance where we can provide it.
  • Proof-of-concept code, released only once a fix is available. If no fix is available, we will assess whether to release proof-of-concept code on a case-by-case basis.

Credit and CVEs

Credit goes to the Signal 11 researcher or researchers who found the vulnerability, by name. Clients from whose engagement a finding originated remain anonymous by default and may opt in to co-credit.

Signal 11 requests CVE identifiers for vulnerabilities we disclose and includes them in our advisories.

Exceptions

Any departure from this policy requires the approval of a Signal 11 Director. Exceptions are documented and noted in the published timeline.

Contact

Vendors, clients and coordinators with questions about an active disclosure can contact us at disclosure@signal11.io. For sensitive information, you can encrypt your message using our PGP public key.