Hayami

Vulnerability disclosure policy

Effective date: 18 August 2026

The short version

If you believe you have found a security vulnerability in our websites or in Hayami DTM, email[email protected]. Do not open a public issue or post details publicly before we have had a chance to fix it. We welcome good-faith research within the scope below and will not pursue legal action against it.

How to report

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

  • What you found, and where (URL, or the DTM version and component).
  • Steps to reproduce, a proof of concept, or the request/response.
  • Your assessment of the impact.
  • A suggested fix, if you have one.
  • Whether you would like public credit once the issue is resolved, and the name to credit.

This inbox reaches the people who fix things directly. There is no web form to fill in, and none of the fields above are mandatory: a short email with what you know is better than no email.

What we commit to

  • We aim to acknowledge your report within 48 hours.
  • We will send a status update at least every5 business days until the report is closed.
  • Our first substantive assessment comes with the initial response. We do not commit to a fix date before we understand the issue; a target date follows once the scope is clear.
  • If you would like it, we will credit you when the fix is released. If you would rather stay anonymous, we respect that too.

We do not operate a bug bounty and do not pay for reports. We say this plainly so nobody invests time expecting otherwise.

Scope

The assets in scope for unsolicited security testing are:

  • hayami.io (this site)
  • docs.hayami.io (the documentation site)

Both are static sites, which is the entire publicly hosted attack surface today: Hayami operates no hosted DTM service.

Out of scope

  • Customer DTM deployments. Hayami DTM runs inside each customer's own Azure subscription. A customer's deployment is theirs, not ours, and we cannot authorise testing against it. Testing a DTM deployment requires the permission of the customer who owns it (and Azure's own penetration-testing rules).
  • The Azure Marketplace and other Microsoft services, which are Microsoft's to authorise.
  • Denial of service, volumetric attacks, and physical or social-engineering attacks against any target.

Vulnerabilities in the DTM software itself are very much in scope forreporting: find them in your own deployment, or by analysis, and tell us. The out-of-scope list is about whose systems you may test, not about what you may report.

Safe harbour

We will not pursue or support legal action against you for security research that is conducted in good faith: research that stays within the scope above, makes a genuine effort to avoid privacy violations, data destruction, and service degradation, does not access or modify data that is not yours beyond the minimum needed to demonstrate the issue, and gives us a reasonable opportunity to fix the problem before any public disclosure. If you are unsure whether something is covered, ask first at[email protected].

Where this policy lives

This page is the policy referenced by oursecurity.txt (RFC 9116) files on both sites. How Hayami operates as a vendor is described atSecurity at Hayami, and the product's security design, protections, and operator responsibilities are documented atdocs.hayami.io/reference/security.

Changes

If this policy changes, we will post the new version here with a new effective date.