research disclosure policy

coordinated disclosure for 1seal research.

policy governing reports submitted by 1seal to vendors, maintainers, and coordinators.

version: 5.0 effective: 26 April 2026 scope: research disclosure and publication

1. scope

this policy governs vulnerability reports submitted by 1seal (Oleh Konko) to upstream maintainers, vendors, and coordinating bodies. it applies to all reports identified with an F-* reference or submitted through GitHub Security Advisory (GHSA), vendor security contact, or equivalent private channel.

for vulnerabilities in 1seal-operated systems, use the 1seal systems security policy.

1A. research methodology

1seal employs computer-assisted research methodology, including the use of language models and other automated analysis tools as part of the vulnerability research workflow. all findings undergo manual validation by 1seal before submission to vendors. reports contain substantive analysis with reproducible evidence and proof-of-concept where applicable.

1seal distinguishes computer-assisted research from automated unsupervised vulnerability scanner output; the latter is not 1seal's practice. vendors and coordinators may rely on this declaration as a good-faith representation of methodology. the volume of 1seal's published research is consistent with this methodology and is not an indicator of automated low-quality submission.

2. coordinated disclosure

all reports follow coordinated vulnerability disclosure (CVD) by default. 1seal does not publish vulnerability details unilaterally while a coordinated process is active and progressing.

public statements by 1seal are limited to information that is independently and publicly confirmable at the time of the statement, including published commits, merged pull requests, tagged releases, public advisories, and CVE/GHSA records.

vendor obligations under applicable cybersecurity regulations, including EU Cyber Resilience Act article 14 reporting to ENISA, NIS2, and sector-specific reporting regimes, take precedence and do not constitute breach of coordinated disclosure under this policy.

embargo terminates upon any independent public disclosure of the vulnerability by a third party, confirmed leak from any embargoed party, or evidence of active exploitation per section 6.

2A. regulatory context — EU CRA

as of 11 September 2026, vendors covered by EU Cyber Resilience Act (Regulation 2024/2847, article 14) have legal obligations to notify the European Union Agency for Cybersecurity (ENISA) and their main-establishment CSIRT of actively exploited vulnerabilities within 24 hours of awareness, with full notification within 72 hours and final reports within prescribed timelines.

1seal recognizes that these regulatory obligations of vendors take precedence over 1seal's coordinated disclosure timelines. where 1seal reports a vulnerability that subsequently meets the CRA actively exploited threshold, the vendor's 24-hour ENISA notification obligation may compress this policy's standard timelines accordingly.

1seal does not directly notify ENISA; ENISA reporting under CRA is the manufacturer's responsibility. where research concerns products manifestly outside CRA scope, CRA framework does not apply and standard 1seal timelines proceed.

3. attribution

1seal expects public attribution in any advisory, changelog, release note, commit message, or other public record associated with a reported issue. the expected credit format is:

reported by Oleh Konko (@1seal)

attribution is independent of any financial compensation, bounty, or non-disclosure agreement. declining a bounty or nda does not waive the expectation of public credit.

1seal does not accept non-disclosure agreements (NDAs) or similar contractual restrictions as a precondition for the vendor receiving or reviewing vulnerability reports. submission of a vulnerability report by 1seal does not constitute consent to NDA terms.

1seal may agree to limited confidentiality during the coordinated disclosure period, covering specific technical details of the unfixed vulnerability, where such confidentiality is mutually agreed and time-bound to the disclosure timeline. 1seal does not accept indefinite confidentiality commitments or NDAs that would persist after public disclosure of the vulnerability.

where a vendor proposes mass-market clickwrap terms that purport to restrict security research or disclosure, 1seal does not treat such terms as binding limitations on coordinated disclosure activities conducted in good faith.

if the vendor intends not to provide attribution, 1seal requests written confirmation of that decision.

3A. safe harbor expectations

1seal conducts research in good faith for purposes of testing, investigation, and disclosure of security flaws, in a manner designed to avoid harm to individuals, systems, or data beyond what is necessary to verify a vulnerability's existence and impact.

1seal expects vendors to provide explicit safe harbor for good-faith security research consistent with this policy and the vendor's stated rules of engagement, to refrain from civil or criminal action against 1seal for activities consistent with coordinated disclosure principles, and not to condition safe harbor on NDAs or similar gag agreements beyond limited time-bound embargo confidentiality.

where a vendor's policy fails to provide safe harbor, or where a vendor attempts to retract previously extended safe harbor, 1seal documents this as a factor in coordinated disclosure timeline calculation and may seek consultation from the EFF Coders' Rights Project, local cybersecurity counsel, or coordinator-mediated resolution.

4. response timeline

1seal expects an initial substantive response within 14 calendar days of report submission. a substantive response is one that acknowledges receipt and provides a triage determination or a timeline for one.

if no substantive response is received within 30 calendar days, 1seal reserves the right to seek third-party coordination as described in section 7.

acknowledgment of receipt, status assignment without disposition, and silence do not constitute a substantive response.

active blocking of researcher communication channels, systematic removal of the ability to file through a vendor's stated channel, or insistence on a structurally inaccessible disclosure platform constitutes constructive refusal of substantive engagement and is treated equivalent to silence for purposes of timeline calculation.

5. silent fix

if a public code change correlating temporally and structurally to the reported issue appears without acknowledgment of the report, 1seal will seek written confirmation of the relationship between the report and the fix, and will request attribution through available channels.

the existence of a public fix without acknowledgment does not, by itself, terminate the coordinated disclosure process. the process concludes when the vendor provides written disposition, or when third-party coordination produces one.

5A. vendor unreachable or hostile

where 1seal cannot establish a working communication channel with the vendor through publicly stated channels, 1seal documents the failure and pursues alternative paths. good-faith effort means at least two canonical channel attempts over not less than seven calendar days, with timestamps and error evidence preserved.

where canonical channels fail, 1seal may engage CERT-UA, CERT/CC, and sectoral ISACs as appropriate based on case context. the coordinator then becomes the primary channel for further coordination.

documented banning, systematic blocking, retaliatory removal of researcher access, or insistence on a third-party platform that is structurally inaccessible to 1seal is treated as constructive refusal of substantive engagement and triggers immediate escalation. determinations of active hostility are made by 1seal based on reasonable documented evidence, including ban notices, support responses inconsistent with stated platform policy, repeated email rejection patterns inconsistent with technical bounce, or express refusal to engage after good-faith contact attempts.

where active hostility, channel failure, or platform inaccessibility is documented and no coordinator can establish a channel, the disclosure timeline is calculated from the date of original attempt, not from any later refused or impossible communication.

6. active exploitation

if 1seal obtains credible evidence that a reported vulnerability is being actively exploited in the wild during a coordinated process, the disclosure timeline is reduced to 7 calendar days from the date of confirmed exploitation, regardless of vendor remediation status. 1seal will notify the vendor and any engaged coordinator of the evidence and prioritize publication of mitigation guidance and indicators of compromise over detailed exploitation technique. evidence includes vendor advisories citing in-the-wild exploitation, KEV catalog inclusion, documented incident reports, or direct observation by 1seal.

7. escalation

if direct communication with the vendor does not produce a disposition within a reasonable timeframe, 1seal may pursue the following escalation path:

  1. direct follow-up to the vendor, referencing the original report and requesting written status confirmation
  2. CERT/CC VINCE referral for third-party coordination when the vendor is unresponsive or when the report disposition is disputed
  3. MITRE CNA-of-last-resort for CVE assignment when the vendor CNA is unresponsive and a CVE is warranted
  4. legal-threat trigger for immediate CERT/CC VINCE referral when a vendor makes legal threats against 1seal or coordinating bodies in connection with a report submitted under this policy; legal threats do not pause the disclosure timeline

as a Ukrainian-resident researcher, 1seal engages national and international coordinators based on case context: CERT-UA, CERT/CC, and sectoral ISACs where applicable. for cases involving CRA-scope products, the relevant coordinator's role includes onward dissemination through the EU CSIRT network; ENISA receives CRA notifications through the vendor-side reporting path, not from 1seal as primary coordinator.

at each stage, 1seal does not publish vulnerability details beyond what is publicly confirmable. escalation is a coordination mechanism, not a disclosure threat.

if 90 calendar days pass from original report submission without the vendor producing a substantive written disposition, 1seal reserves the right to publish technical details concurrent with final vendor notification. the clock pauses while the vendor actively engages with remediation in good faith, including through coordinator-mediated processes such as CERT/CC VINCE, and resumes if engagement lapses. publication under this clause remains coordinated with CERT/CC or the relevant CNA where one is engaged.

8. duplicate determinations

if a report is determined to be a duplicate of an earlier submission, 1seal may request written confirmation that the duplicate determination was based on a prior report that:

  • was received before the 1seal submission
  • covered the same root cause
  • addressed the same affected component and exploit path

if confidentiality prevents identification of the prior report, 1seal requests confirmation that the determination was independently validated.

9. what this policy does not cover

  • legal advice or legal obligations beyond professional norms
  • automatic public disclosure timelines
  • financial compensation, bounties, or reward programs governed by vendor-specific terms
  • information obtained through means other than good-faith security research

this policy operates as an individual researcher's coordinated disclosure framework. it does not substitute for vendor-side disclosure programs, governmental coordinator policies, or platform-mediated bug bounty programs. response capacity is bounded by single-operator constraints; complex multi-vendor cases are routed to CERT/CC VINCE or relevant CNAs for coordination. this policy reflects current practice and may evolve with regulatory and industry developments.

1seal's research is conducted by Oleh Konko, resident in Ukraine. Ukrainian law, including Criminal Code article 361, applies to research conduct. 1seal's research is conducted within applicable laws; vendor safe harbor remains necessary for specific authorized testing within vendor-controlled systems.

10. good faith

all research conducted under this policy is performed in good faith, with the intent to improve the security of the affected software.

  • 1seal does not access, exfiltrate, or retain user data
  • 1seal does not exploit vulnerabilities beyond what is necessary to demonstrate the issue
  • 1seal does not demand compensation as a condition for coordinated disclosure

11. contact

PGP key for encrypted reports: 1seal.org/.well-known/pgp-key.txt. fingerprint: 509D 9214 8FBB 7FAC FF53 AF25 5D42 2A73 4CEC C012. this key is also referenced from security.txt.

changelog

version date changes
1.0 2026-03-27 initial policy: coordinated disclosure by default; public statements limited to publicly confirmable information
2.0 2026-04-04 added attribution expectation, 14/30-day response timeline, silent-fix clause, escalation path with CERT/CC VINCE and MITRE CNA-of-last-resort, duplicate-determination process, scope exclusions, and good-faith statement. restructured from informal statement to numbered sections.
3.0 2026-04-26 added 90-day terminal disclosure clause to section 6: 90 calendar days from original report submission without substantive vendor disposition triggers the right to publish concurrent with final vendor notification. the clock pauses on good-faith vendor engagement, including coordinator-mediated processes such as CERT/CC VINCE, and resumes if engagement lapses. clarified section 4 that acknowledgment, status assignment without disposition, and silence do not constitute substantive response. aligns disclosure timing with report-submission-based industry norms while preserving coordinated disclosure through the pause mechanism.
4.0 2026-04-26 added embargo carve-outs in section 2 for vendor regulatory reporting and embargo termination on independent disclosure, leak, or active exploitation. added NDA boundary in section 3. added section 6 active exploitation with a 7-day accelerated disclosure timeline. added legal-threat trigger to the escalation list in section 7. added single-operator limitations and coordinator-routing note in section 9. updated contact email to security@1seal.org. section renumbering applied: previous sections 6-10 shifted to 7-11.
4.1 2026-04-26 published the PGP key for encrypted vulnerability reports at /.well-known/pgp-key.txt, added the encryption and policy directives to security.txt, expanded preferred languages to en and uk, and referenced the key and fingerprint in section 11 contact.
5.0 2026-04-26 added section 1A research methodology, section 2A EU CRA regulatory context, section 3A safe harbor expectations, and section 5A vendor unreachable or hostile. refined the NDA boundary, added constructive-refusal handling for blocked or inaccessible disclosure channels, clarified the Ukrainian researcher coordinator model around CERT-UA and CERT/CC, and added the Ukrainian legal-context note in section 9.