RunSybil's Approach to Coordinated Disclosure

When we find a vulnerability, we report it privately to the people who can fix it. Then we wait 30 days before we publish the details. The embargo period gives project owners time to ship a fix. The deadline ensures users learn about potential risks, whether or not a fix ships.

This policy applies exclusively to our independent security research. Findings from client-authorized engagements are governed by separate confidentiality agreements and will not be published.

Findings

We test third-party software only in our own environments or where we have authorization to test. We reproduce every issue before we report it, and we strictly separate verified impact from theoretical risk. Each report includes the versions or configurations we tested, steps to reproduce the issue, and mitigation suggestions when we have them.

Our research is AI-driven. That doesn't lower the bar for a report. We  validate every issue ourselves and we stand behind our findings. Each report should be evaluated on the evidence provided, not the tooling used to find it. 

Reporting

We report through the project's or vendor's published security channel, such as a SECURITY.md, a security.txt contact, or a vendor disclosure program. After submitting our initial report, we are available to answer questions, share additional evidence, and help test fixes.

Some vulnerabilities span multiple projects. For example, a flaw in an upstream library may only be exploitable because of the way a downstream service uses it, or when a downstream flaw stems from upstream design choices. When this happens, we initiate a multi-party disclosure, providing our findings to both teams so they can coordinate remediation. 

Timeline

We publish 30 calendar days after our initial private report, and our first report clearly states the planned publication date. 

If a vendor fails to respond to our private report, the disclosure window is shortened from 30 calendar days to 14 calendar days. A disagreement about severity or a decision not to fix does not pause the clock. If coordination stalls, we make a reasonable effort to reach the right people and let them know when we plan to publish.

We extend the deadline when there is a concrete remediation plan and a specific reason to believe more time will protect users. 

We may disclose ahead of schedule if the affected party agrees, or if active attacks require an immediate public warning. If the release date shifts, we make every effort to notify the affected parties in advance. 

What we publish

The public disclosure details the vulnerability, who is affected, demonstrated impact, and suggested resolutions. We also note if a fix only partially resolves the issue or if it remains unmitigated. 

Affected parties are given the chance to review drafts for factual accuracy prior to publication but cannot unilaterally block or delay disclosure. We document the coordination timeline transparently, credit the people who assisted in the investigation and the remediation, and update if new evidence or verified details become available.

We are careful about what proof-of-concept details we publish. We share technical details to help defenders fix issues, not to make it easier for attackers to exploit it. That might mean walking through the bug conceptually rather than dropping a working exploit.