Security works better with outside eyes

We launched a bug bounty program to make Hivenet safer, giving security researchers a clear way to report vulnerabilities in Store and Compute.

Cloud services depend on trust. That trust has to be earned in practical ways: by designing carefully, testing continuously, fixing what we find, and giving people outside the company a clear way to report what we may have missed.

That is why we have launched the Hivenet bug bounty and responsible disclosure program.

The program gives independent security researchers a defined path to test eligible Hivenet products and report vulnerabilities directly to our Security team. It covers selected Store with Hivenet applications and the Compute with Hivenet console, with clear rules on scope, severity, rewards, disclosure, and safe harbor.

You can read the full program details on our bug bounty and responsible disclosure page.

Security is not a claim we want to make once and leave untouched. Hivenet provides cloud storage, file sharing, and compute services for individuals and businesses, which means our systems have to protect user data, account access, infrastructure, and workload isolation. That kind of responsibility needs more than internal review. It needs outside scrutiny from people who know how systems fail.

A good bug bounty program does two useful things.

First, it gives researchers a safe and legitimate route to report vulnerabilities. Security research can get messy when expectations are unclear. A public policy reduces that ambiguity. It says what can be tested, what cannot be tested, how to report a finding, what evidence is needed, and what researchers can expect from us in return.

Second, it helps us improve before problems reach users. No product team catches everything. Complex systems involve web applications, APIs, mobile apps, desktop apps, infrastructure, permissions, authentication, cryptography, and many small decisions that interact over time. The responsible thing is to invite careful testing, not pretend that careful design removes the need for it.

For Hivenet, this matters because our model brings together several layers of infrastructure. Store with Hivenet protects files across a distributed storage network. Compute with Hivenet gives users access to cloud instances for AI, development, rendering, notebooks, APIs, and other workloads. These products solve different problems, but they share the same basic requirement: users need to know that security is being treated as ongoing work.

The new program asks researchers to focus on vulnerabilities with real impact, such as authentication and authorization flaws, sensitive data exposure, privilege escalation, insecure app behavior, API vulnerabilities, tenant isolation issues, and weaknesses that could affect confidentiality, integrity, or availability.

It also sets expectations for how we handle reports. Good-faith submissions will be reviewed by the Hivenet Security team, with acknowledgment, triage, transparency during remediation, and coordinated disclosure. Researchers who follow the program rules are covered by safe harbor for eligible activity on in-scope systems.

This is the kind of security work that rarely looks dramatic from the outside. It is procedural, detailed, and sometimes uncomfortable. That is also why it matters. A serious security posture is not built from broad promises. It is built from boring, repeatable habits: define the surface, invite review, verify impact, fix issues, credit researchers, and keep improving.

You can learn more about Hivenet’s broader approach to infrastructure, control, and transparency on our Trust page.

If you are a security researcher and you find a vulnerability in an in-scope Hivenet product, we want to hear from you.

Review the full bug bounty and responsible disclosure program before testing, then send your report to the our Security team using the instructions on that page.