Organisation-wide default for github.com/vul-os. A repository's own SECURITY.md overrides this one — most Vulos repos carry their own with a scope section specific to what they actually do. Read that if it exists; this file covers the repos that do not.

Do not open a public issue.

Preferred: the Report a vulnerability button under the Security tab of the affected repository (GitHub private security advisories). It keeps the report, the discussion and the fix in one place and lets us credit you on publication.

Email: security@vulos.org — use this if private advisories are unavailable on the repo, or if you are unsure which repository is affected.

Please include:

• the repository and version, tag or commit
• what an attacker gains, and what access they need to start
• steps to reproduce, ideally a minimal proof of concept
• any mitigation you have already identified

If you need to send something sensitive, say so in a first email and we will arrange an encrypted channel before you send details.

Vulos is a small project. If a deadline is going to slip you will hear that from us rather than hearing nothing.

In scope: anything in a Vulos repository that lets an attacker read or alter data they should not reach, escape a sandbox or tenant boundary, forge or bypass an identity or signature, escalate privilege, or execute code — plus committed secrets and dependency vulnerabilities that are actually reachable from our code.

Because these are self-hosted applications, the interesting boundaries are usually: the HTTP surface a user exposes, the signed-object and key handling in kotva, and anything that parses untrusted input from another node.

Out of scope:

• Machines you run. A misconfigured deployment of Vulos software — an open port, a default password you set, a missing reverse-proxy — is an operational issue, not a vulnerability in the software. Reports that amount to "I made it insecure and it was insecure" will be closed.
• Findings that depend on the attacker already having root, or on a modified build of our own software.
• Volumetric denial of service, and rate-limiting on software the reporter hosts themselves.
• Automated scanner output with no demonstrated impact, missing hardening headers on a static page, and best-practice suggestions with no attack attached.
• Social engineering, phishing, and physical access.
• Third-party services. There is no central Vulos service to attack: the project runs no hosted product, no user accounts and no user data.

We will not pursue legal action against you for security research conducted in good faith, provided you:

• test only against your own installation, never against someone else's,
• access no more data than needed to prove the issue, and destroy what you collect,
• do not degrade service for anyone else,
• give us reasonable time to ship a fix before publishing.

We ship the fix, publish an advisory describing the impact, and credit the reporter by name or handle unless they ask otherwise. We will not sit on a fixed issue to delay disclosure.

There is no paid bounty programme. This is an independent open-source project; what we can offer is a fast response, public credit, and a fix that actually lands.