Security policy and vulnerability disclosure
We welcome reports of vulnerabilities in Fendix. This page explains what is in scope, how to report privately, what happens next and the rules we ask researchers to follow.
How to report
Report privately — please do not open a public GitHub issue. Use the following channel:
Include in your report
- The affected component (CLI binary, Python engine, release pipeline, hosted workspace, website) and version (fendix version).
- Steps to reproduce or a minimal proof of concept.
- Your assessment of the impact: what an attacker can read, change or prevent, and what access they need.
- Whether you plan to publish a write-up, and when.
What happens next
- Acknowledgement within 72 hours.
- A triage response within 7 days: accepted, with next steps, or declined, with a written reason.
- Accepted reports get a fix and a release plan agreed with you. We aim to publish within 14 days of the fix landing, and you can ask for a longer embargo if downstream coordination needs it.
- Accepted engine vulnerabilities are published as a GitHub Security Advisory, with a CVE requested through GitHub where the issue qualifies, alongside a patched release and a Security entry in the changelog. Fixes ship on the current version line, and on the previous one for critical issues (see supported versions).
- Reporters are credited unless they ask to stay anonymous.
Scope
In scope
- The fendix CLI and its Python engine, built from github.com/Fendix-app/Fendix.
- The release pipeline and its outputs: signed binaries, Docker images, the Homebrew tap and the installer at get.fendix.dev.
- The hosted workspace and its API (api.fendix.dev) and this website (www.fendix.dev).
- Ways to make the active scanner exceed its documented safety envelope.
Out of scope
- Findings Fendix produces against third-party targets — report those to the target's vendor.
- Issues that require an attacker to already control the machine running the CLI.
- Crashing the CLI with oversized or malformed local input: a bug worth reporting, but not a security issue.
- Volumetric denial-of-service, and missing best-practice headers or settings without a demonstrated impact.
Rules for security research
- Test only against your own accounts and data. Stop and report as soon as you can access data that is not yours, and do not keep or share it.
- No denial of service, destructive testing, spam or social engineering of Fendix staff or users.
- Run Fendix's active probes only against targets you own or have written authorization to test.
- Redact credentials and personal data in what you send us.
- Give us a reasonable chance to fix the issue before you disclose it publicly.
Supported versions
The latest two minor versions of the engine receive security fixes: full fixes on the current minor version, critical fixes only on the previous one. Older versions are end of life — upgrade to the current release.
Bug bounty
Fendix does not currently run a paid bug bounty program.
Fendix scans are safe by default: active probes that send attack payloads are opt-in and require explicit enablement.