Security

Maran installs a daemon that runs as root and a panel that provisions system users. A defect here is not an inconvenience, so a report about one is welcome and will be answered.

Reporting a vulnerability

Write to security@innovayse.com. Do not open a public issue, and do not describe the problem in a pull request before it is fixed. If you would rather encrypt, say so in a first message with no details and a key will be sent.

Reports are acknowledged within 48 hours. Critical issues target a fix or a documented mitigation within 14 days; less severe ones are scheduled and you are told when. Coordinated disclosure is honoured, and you are credited by the name you choose unless you ask not to be.

What to include

Enough to reproduce it, and nothing that is not yours to send:

• what an attacker gains — reading another tenant's files, escalating to root, bypassing a limit;
• the smallest sequence that shows it, and which distribution and version you saw it on;
• whether it needs an authenticated session, and at which role;
• logs if they help, with tokens, hostnames and customer data removed.

Test against your own installation

Probing somebody else's server running this software is not research, and no finding excuses it. A report obtained that way is not accepted, and it may be a crime where you or they are. Installing your own is one command.

Scope

In scope — everything the project ships: the panel API, the single-page application, the Rust agent and its socket, the installer, and the templates the agent renders. Reports about the design are in scope too: if a rule that was written down is the wrong rule, that is worth more than a bug.

Out of scope — findings that require an attacker to already be root on the host, denial of service by exhausting the machine's own resources, missing hardening headers with no demonstrated impact, and reports produced only by a scanner with no reasoning attached.

Supported versions

Until 1.0, only the latest release receives fixes. After 1.0 the policy will name the versions that do.

What the project does on its own side

Changes to authentication, sessions and tokens, to the agent's privilege handling, to licence verification, or to a privileged step in the installer require a second reviewer and a written threat note before they merge. Dependencies are pinned and updated deliberately rather than by a bot, and secrets are never committed.

The architecture is the first line of this: the panel runs unprivileged, one small daemon holds root, and the contract between them has no operation that runs a caller-supplied program. See how it is built for what that means in practice.