Coordinated Disclosure Policy

1. Purpose

Watchdogs agents and the people who supervise them spend every day looking for security weaknesses. Sometimes we find a vulnerability that is not specific to one customer but sits in software many others use, such as an open-source library, a CMS plugin, a commercial product or a cloud service. This policy explains how we report those vulnerabilities to the people who can fix them, how long we wait before going public, and how we protect everyone affected along the way.

Watchdogs is operated by koderAI Corp. ("Watchdogs," "we," "us"). To report a vulnerability in Watchdogs itself, see our Vulnerability Disclosure Policy.

2. Two kinds of findings, handled differently

When a product vulnerability is discovered while monitoring a customer's environment, we never name the customer, include their data, or reveal that they run the affected software in any report or advisory, unless they give us written permission.

3. We only test what we are allowed to test

• Watchdogs agents test only the systems our customers own or have authorized us to test, within the scope they configure.
• When we research software for new vulnerabilities, we do it on copies we run in our own environments, such as open-source code, trial versions and lab installs, not on other people's production systems.
• We follow the terms of any bug bounty or disclosure program that covers the software we are researching.

4. A human verifies every finding before we report it

AI makes us fast, but maintainers deserve accurate reports, not guesses. Before we contact any vendor or maintainer:

• A qualified member of our security team reproduces the vulnerability on a version we control.
• We confirm it is new by checking existing CVE records, vendor advisories, the GitHub Advisory Database and OSV.
• We rate its severity with CVSS v4.0 and classify it with a CWE identifier.
• We write a clear report with reproduction steps and a minimal proof of concept.

Our reports state that the issue was found with the help of AI tooling and confirmed by a human. We do not send unverified, automatically generated reports to maintainers.

5. How we contact vendors

We look for the right contact in this order:

• The vendor's published security policy, security.txt file or bug bounty program.
• The vendor's CVE Numbering Authority contact, if it is a CNA.
• Private vulnerability reporting on the project's source code host (for example, GitHub Security Advisories).
• A maintainer's or company's published security or support address.

If we receive no acknowledgment after at least three attempts over 14 days, we ask a coordinator, such as CERT/CC or the relevant national CERT, to help reach the vendor. We share details only through private channels and never in public issue trackers.

6. Disclosure timeline

Vendors can ask us to publish earlier. We may move the date when users' safety calls for it, and we will tell the vendor before we do.

7. Protecting users before disclosure

Until the vulnerability is public, we keep its details confidential inside a small team. During that period we may deploy protections for affected Watchdogs customers, such as configuration changes, firewall rules or detections, only when they do not reveal the details of the vulnerability. We tell the vendor when we do this.

8. CVE IDs

• If the vendor is a CVE Numbering Authority (CNA), we ask the vendor to assign the CVE ID.
• Otherwise, we request one through the appropriate CNA, such as GitHub for projects hosted there or the MITRE CNA of Last Resort.
• We ask that the CVE record credit Watchdogs (koderAI Corp.) as the finder.
• Customer-specific findings never receive CVE IDs.

As our research program grows, we plan to apply to become a CNA so that we can assign CVE IDs for vulnerabilities we find in third-party software that no other CNA covers.

9. Public advisories

After disclosure we publish an advisory at koder.com/security/advisories. Each advisory includes:

• A Watchdogs advisory ID and the CVE ID, if assigned.
• The affected product, affected versions and fixed version.
• Severity (CVSS v4.0) and weakness type (CWE).
• How to fix the issue or reduce the risk.
• A timeline from discovery to publication.
• Credit to the people involved, including the vendor's response.

We do not publish ready-to-use exploits. When a technical write-up helps defenders, we publish it after most users have had a chance to update.

10. Talking about our findings

We only discuss a vulnerability in blog posts, talks, social media or sales materials after its advisory is public. We never name or identify a customer in connection with a finding without their written permission.

11. Exceptions and contact

Any departure from this policy must be approved by koderAI Corp.'s Founder & CEO and recorded with the reason. Vendors with questions about a report, and anyone who wants to reach us about our research, can write to security@koder.com.