Vulnerability disclosure policy

Report a vulnerability

Please include the product and version (or the URL), what you found, the steps to reproduce it, the impact you expect, and whether you plan to publish. If you would like credit, tell us the name or handle to use.

Vulnerabilities in CyberXYZ products

In scope

• CyberXYZ Proxy, including npm-proxy.cyberxyz.io and pip-proxy.cyberxyz.io, and the Go and NuGet proxies
• CyberXYZ Gate (the CyberXYZSecurity/depalert-action GitHub Action and its GitLab and Azure equivalents)
• CyberXYZ Dashboard (app.cyberxyz.io) and the API behind it (api.cyberxyz.io)
• CyberXYZ Check (cyberxyz.io/check) and the package reports (packages.cyberxyz.io)
• xyz Scanner (the xyz command, PyPI cyberxyz-scanner), xyz for VS Code and xyz MCP
• This website, cyberxyz.io

Supported and end-of-life versions are both in scope.

Out of scope

• Denial-of-service and load testing, spam, and social engineering of our staff or customers
• Physical attacks on our offices or equipment
• Services we use but do not run (hosting, email, analytics and CRM providers): please report those to the provider
• Reports from automated scanners with no demonstrated impact, such as a missing header on its own
• Verdicts you disagree with: a package we allow or block is not a vulnerability. Email hello@cyberxyz.io and we will review it

What happens after you report

Please give us that time before you publish. If you plan to publish earlier, tell us and we will work with you on a date.

Good-faith research is welcome

If you research our products in good faith, respect customer data and keep our services available, we will not pursue or support legal action against you, and we will not ask anyone else to. In practice, good faith means you:

• use only your own accounts (a free account is enough) and test only data you own;
• stop as soon as you reach someone else's data, do not keep or share it, and tell us what you accessed;
• do not degrade the service for other users, and do not run denial-of-service tests;
• give us a reasonable chance to fix the issue before you disclose it, as set out above.

If you are unsure whether something is allowed, ask us first at security@cyberxyz.io. This commitment covers CyberXYZ's own systems; it cannot authorise testing of anyone else's.

Vulnerabilities we find in open-source packages

Our research covers npm, PyPI, Go, NuGet and GitHub Actions. When we find a problem in a package someone else maintains, we treat it in one of three ways:

The last row follows the CVE Program's own rule: deliberately malicious code is not a vulnerability, while a legitimate product modified to become malicious may be (CNA Operational Rules v4.2.1, rules 4.1.7 and 4.1.8).

How we contact maintainers

1. We follow the project's own SECURITY.md if it has one.
2. Otherwise, we open a private report through GitHub private vulnerability reporting, which creates a draft GitHub Security Advisory that only the maintainers and we can see. We work on the fix, the affected versions and the CVE ID there.
3. If that is not available, we email the maintainer listed on the registry.

If nobody acknowledges us within 14 days, we try the other channels. If nobody has responded after 30 days, we ask the registry's security team or the project's CNA for help reaching the project. Our reports state the affected versions, how to reproduce the issue and, where we can, a suggested fix.

Why 90 days

Ninety days is the most widely used deadline in coordinated disclosure, and it is the same deadline we hold ourselves to for our own products. Many open-source maintainers are volunteers, so they need enough time to fix an issue and publish a release. A fixed public deadline also protects users, so an unfixed issue does not stay secret indefinitely. We change the deadline in these cases:

• Extension: we extend the deadline by up to 30 days when the maintainer shows a fix is in progress and asks.
• Active exploitation: if we see a vulnerability being actively exploited, we may publish after 7 days, so users can protect themselves.
• Silent fixes: when a project has already released a fix without an advisory, the fix is public in its history. We ask the maintainer to publish an advisory and publish our own after 14 days if they have not.
• Tampered releases: 72 hours, as in the table above, because users are already being harmed.

Credit

Our advisories name who found an issue and who reported it first, including other companies and researchers whose work came before ours. We credit maintainers for their fixes. CVE Record descriptions do not carry credits under the CVE Program rules, so we use the record's credit fields and our advisory instead.

How we handle CVE IDs

When a vulnerability in our products or one we found in an open-source package warrants a CVE ID, we get one from the CVE Numbering Authority (CNA) with the right scope. If the supplier is a CNA, that is the supplier. If the maintainer uses a GitHub Security Advisory, it is GitHub. Otherwise, it is the MITRE CNA of Last Resort. If CyberXYZ is authorised as a CNA, we will assign IDs in our own scope, which is described below, and update this page.

Whoever assigns the ID, we follow the CVE Program rules:

• We assign IDs only for vulnerabilities that will become public.
• We give the reporter the ID, and we ask whether another CNA has already been asked, so the same issue never gets two IDs.
• We publish the CVE Record within 24 hours of the vulnerability becoming public.
• We list every advisory on our security advisories page. It is public and needs no login.
• We update records when fixed versions change, and we reject IDs we did not use.

Our proposed CNA scope

Disagreeing with a decision

If you disagree with a CVE decision we made, email security@cyberxyz.io with your reasoning and evidence. We follow the CVE Program Policy and Procedure for Disputing a CVE Record. That means we acknowledge a dispute within three business days and decide within five business days after that, or tell you if we need longer. You can escalate to the CVE Program if you still disagree.

Changes to this policy

We date every change at the top of this page. Reports already in progress keep the terms that applied when we received them.