Vulnerability Disclosure Policy

Last updated: 23 June 2026

This policy explains what we accept reports on, how to send one, and what you can expect in return.

Scope

We accept vulnerability reports for products and services that RedEye Security builds and operates:

Caver — our Splunk-compatible SIEM built on an open OCSF Parquet lakehouse.
Caver Lighthouse — our free attack-surface and exposure scanner.
RedEye ICS Exposure Scanner — our industrial control system exposure scanner.
RedEye Intel Feeds — our STIX 2.1 / TAXII 2.1 threat-intelligence and CVE detection feeds, including feeds.redeyesecurity.com.
RedEye web properties — redeyesecurity.com and its subdomains, where a finding represents a genuine security risk to RedEye or its users.

If you are unsure whether something is in scope, send the report anyway. We would rather receive a borderline report than miss a real issue.

CVE assignment scope

RedEye Security is establishing a CVE Numbering Authority (CNA) program. Our intended CNA scope will be limited to vulnerabilities in RedEye Security's own products — the products listed above. We assign CVE IDs only for issues in our own products. Reports about our web properties or feed data are accepted and fixed, but are not CVE-eligible. For a vulnerability outside our scope, we will refer you to the appropriate CNA or to the CVE Program, and we will not assign a CVE ID ourselves.

How to report

Email [email protected] with as much of the following as you can provide:

The affected product, version, or URL.
A clear description of the vulnerability and its impact.
Step-by-step instructions to reproduce it, including any proof-of-concept code, requests, or screenshots.
Your assessment of severity, if you have one.
How you would like to be credited (or whether you prefer to remain anonymous).

If your report contains sensitive details and you require an encrypted channel, say so in a first email to [email protected] and we will arrange one. Please send one report per vulnerability, and please report the issue to us before disclosing it anywhere else.

Safe harbor — good-faith research

RedEye Security supports security research conducted in good faith. If you make a sincere effort to comply with this policy during your research, we will consider that research authorized, we will work with you to understand and resolve the issue quickly, and we will not pursue or support legal action against you.

To stay within good faith, you must:

Make a genuine effort to avoid privacy violations, data destruction, service degradation, and interruption or harm to our systems, our users, or third parties.
Access, copy, or store only the minimum amount of data needed to demonstrate the vulnerability — never more than necessary, and never another person's data beyond what is strictly required to prove the issue.
Stop immediately and tell us if you encounter sensitive data (personal data, credentials, proprietary information, or anything similar).
Give us a reasonable opportunity to investigate and remediate before disclosing publicly.
Not exploit a finding beyond what is necessary to confirm it, and not use it to pivot to other systems or to maintain persistence.

This safe harbor applies only to RedEye Security's own conduct. It cannot waive the rights of third parties, and it does not authorize activity against systems we do not own or operate. If a third party brings legal action against you for activity that complied with this policy, we will make our authorization of that research known.

Coordinated disclosure and timelines

We practice coordinated disclosure. We ask that you keep findings confidential until we have published a fix or advisory, and we commit in return to clear, predictable handling. Our target timelines from receipt of a valid report:

Stage	Target
Acknowledgement	Within 3 business days
Triage and initial assessment	Within 10 business days
Status updates	At least every 14 days while the issue is open
Fix and advisory	Within 90 days, depending on severity and complexity
CVE assignment	At validation, with the CVE ID published in the advisory at disclosure

For most issues we aim to coordinate a public disclosure date with you once a fix is available. If we cannot meet the 90-day target — for example, a deep architectural fix — we will explain why and agree on a revised timeline with you.

If a vulnerability is being actively exploited, we may disclose sooner to protect users. And if a vulnerability for which we have reserved a CVE ID is publicly disclosed by another party before our coordinated date, we will publish the corresponding CVE record within 72 hours, as required by the CVE Program. We will tell you if either happens.

We publish our security advisories openly, with no login or registration required, at https://redeyesecurity.com/security/advisories.

What you can expect from us

A timely, human acknowledgement of your report.
An honest assessment of whether the issue is in scope and valid.
Regular updates on our progress through remediation.
Credit for your discovery in the published advisory, unless you ask us not to be named.
A coordinated disclosure date that gives you a fair opportunity to publish your own findings alongside ours.

RedEye Security does not currently operate a paid bug-bounty program. We recognize researchers through public credit in our advisories.

Out of scope

The following are generally not eligible under this policy. Reports limited to these will usually be closed without action:

Findings in third-party products, services, or dependencies we do not control. (We will, where we can, help route your report to the right vendor.)
The content of our threat-intelligence feeds, CVE detection feeds, or blog — that is, disagreements about indicators, detections, or published research. Report a security flaw in how the feeds are served or delivered under this policy; report a data-quality concern to us directly instead.
Reports from automated scanners with no demonstrated, exploitable impact.
Missing security headers, cookie flags, or TLS/cipher configuration with no demonstrated exploit.
Denial-of-service, volumetric, or resource-exhaustion attacks, and any testing that degrades or disrupts our services or those of our users.
Social engineering, phishing, or physical attacks against RedEye Security, our staff, or our users.
Self-XSS, clickjacking on pages with no sensitive action, and other issues requiring unlikely user interaction or already-compromised devices.
Vulnerabilities affecting only end-of-life or unsupported product versions.
Use of leaked or stolen credentials, or access obtained through unauthorized means.

Activity that falls outside good-faith research — destroying data, degrading service, accessing more data than needed to prove an issue, or extorting RedEye Security — is not authorized and is not protected by the safe harbor above.

Changes to this policy

We may update this policy as our products and the disclosure landscape evolve. The current version always lives at https://redeyesecurity.com/security. Material changes apply only to reports received after the change is published.

RedEye Security · [email protected] · security.txt · CVE Numbering Authority (CNA) — application in progress