Published 2026-04-28 — v1.0

Coordinated disclosure policy

CipherCue operates a continuous external observation programme. When an observation indicates a catalogued security issue against an organisation's publicly-exposed software, we attempt to notify that organisation before exposing the observation on any CipherCue customer surface. This page specifies the scope, timing, channels, and commitments of that process.

Scope

This policy covers observations CipherCue generates itself — principally KEV matches against observed fingerprints and suspected-incident patterns (e.g. emergency certificate rotation, unplanned DNS authority change, new exposed admin-path). It does not cover public authority records (e.g. state AG breach notifications, SEC 8-K Item 1.05, CISA KEV entries themselves): those are already public and are treated as authority-sourced fact, not CipherCue-originated observation.

Silent window

When a new pre-disclosure observation is recorded:

1. A DisclosureAttempt record is created. The observation is tagged disclosed_at = null.
2. CipherCue attempts to contact the target (see "Channels" below).
3. 48 hours after the attempt — regardless of whether a response was received — the observation is released to customer-facing surfaces and disclosed_at is populated.
4. If the target acknowledges and requests an extended window, we honour a single 14-day extension on written request.

Channels

In priority order:

1. security.txt contact (RFC 9116). If the domain publishes a .well-known/security.txt and it contains a Contact: field, that is used.
2. WHOIS abuse contact, where resolvable.
3. security@{domain} as a fallback to the registered domain.

If none of the above resolves to a deliverable address (bounces, mailbox unknown), the 48-hour window still applies and the observation is released with contact_unresolvable = true. We make a best-effort attempt; we do not delay customer exposure indefinitely waiting on a non-existent mailbox.

Disclosure content

Our disclosure email is neutral and factual:

• Our identity, contact details, links to this page and the methodology.
• The specific observation: the detected vendor/product, the matching authority entry (e.g. CISA KEV #CVE-xxxx), the observed host.
• The authority source and its reference URL.
• The date the customer surface will become visible (release date = attempt date + 48h).
• An invitation to respond: correct the observation, request an extension, or confirm remediation.

The email contains no embedded tracking, no link shorteners, no obfuscated URLs.

Standards alignment

• CERT/CC coordinated disclosure norms.
• ISO/IEC 29147 — Vulnerability disclosure.
• FIRST.org disclosure practice guidelines.
• RFC 9116 — security.txt, which we both publish and consume.

Response commitments

• We log every disclosure attempt: target, channel, sent timestamp, any response received, and final release timestamp.
• We do not profit commercially from any finding we have not first attempted to disclose.
• If a target formally disputes the underlying observation, we withdraw the CipherCue-originated claim until the dispute is resolved. The disclosure attempt log is retained.
• We do not publish proof-of-concept exploit code. Our observations are fingerprint and matching, not exploitation.

Contact for coordinated disclosure

security@ciphercue.com is the single address for coordinated disclosure matters, including requests for extension and notices of remediation.

Not in scope for this policy

• Vulnerability reports against CipherCue itself: submit those to the same address; we commit to acknowledging within 48 hours and coordinating fix publication.
• General correction requests (e.g. a mis-identified vendor alias): corrections@ciphercue.com.
• Opt-out from observation entirely: /opt-out.

Changelog
v1.0 — 2026-04-28 — Initial publication. 48-hour silent window, three-channel contact resolution, standards alignment with CERT/CC, ISO/IEC 29147, FIRST.org, RFC 9116.