Security · Responsible disclosure

Security & responsible disclosure

If you believe you have found a security issue in hosn.om or an explicitly authorised Hosn test scope, send a concise report through the public contact channel below.

How to report

Email info@hosn.om. Please include:

A short description of the issue and its impact
Reproduction steps, or a proof-of-concept (text, screenshot, or short video)
The URL, request, or appliance build affected
Whether the test was authorised and the boundary of that authorisation

Do not include customer data, production credentials, private keys or other sensitive records. We will provide a safer transfer method if it is required for validation.

How reports are handled

The report is reviewed against the stated scope and reproduction evidence.
We may ask for clarification or a reduced proof that does not expose real data.
Validated issues are prioritised according to impact and the affected delivery boundary.
Disclosure timing is coordinated after the remediation path is understood.

Scope

In scope:

The public hosn.om website
The contact-form endpoint at /api/contact
Any test environment explicitly identified in your written authorisation

Out of scope:

Third-party infrastructure not identified in the written test scope
Vulnerabilities requiring physical access outside the scope of an authorised test
Issues in upstream open-weight models or third-party libraries that are already publicly disclosed
Best-practice findings (missing security headers, low-severity TLS configuration) without a demonstrable exploit

Machine-readable record

The canonical RFC 9116 file lives at /.well-known/security.txt. It is what automated scanners and bug-bounty platforms read.

Other ways to reach us

For privacy or commercial questions, use info@hosn.om or +968 9889 9100.

Configuration-specific security boundary

A public page cannot define the implemented controls for every deployment. The security boundary is reviewed during discovery and recorded in the delivery scope for the institution.

Network boundary. Required routes and an air-gapped option are documented before implementation.
Identity. Local roles and any directory integration are defined in the approved scope.
Logging. Events, retention, access and export requirements are agreed with the institution.
Updates. The update and validation process follows the selected operating boundary.
Acceptance. Security controls are tested against written criteria for the delivery.

Coordinated disclosure timeline

Timing depends on reproducibility, severity, the affected boundary and the remediation path. Please allow coordination before public disclosure so the issue can be validated and affected parties can be protected.

If you are testing on behalf of a customer

An appliance sitting inside an institution is that institution's property, and its consent is what makes a test authorised, not ours. If you hold a testing mandate from a Hosn customer, tell us so in the report and we will coordinate with them directly rather than ask you to be the intermediary. Findings against a customer deployment are shared with that customer as a matter of course.