From 239a63f825757c418e7e9a8b92427ce05ec832d6 Mon Sep 17 00:00:00 2001 From: itzzdev09 Date: Mon, 31 Aug 2026 19:50:57 +0530 Subject: [PATCH] docs: add a security policy There is no SECURITY.md in any of the three locations GitHub reads, so the repository has no Security policy link and no documented private channel. A reporter is left choosing between a public issue, Discord, or the general hi@usestrix.com inbox. Add a SECURITY.md pointing at GitHub private vulnerability reporting and the public org address, with what to include, scope, and disclosure expectations. Scope is written around the boundary that matters for this project: Strix runs untrusted target content through an agent and writes artifacts a human later opens, so sandbox escape, credential and CA-key exposure, injection reached through the generated reports, and prompt injection escalating outside the sandbox are called out explicitly. It also states that findings Strix reports about a user's own target are not vulnerabilities in Strix. --- SECURITY.md | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000..fac52a5e --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,58 @@ +# Security Policy + +## Reporting a vulnerability + +**Please do not report security vulnerabilities through public GitHub issues, +pull requests, or Discord.** + +Report privately through one of these channels: + +1. **GitHub private vulnerability reporting** — open the + [Security tab](https://github.com/usestrix/strix/security) and use *Report a + vulnerability*. This keeps the report private, gives you a thread with the + maintainers, and can lead to a published advisory and a CVE. +2. **Email** — [hi@usestrix.com](mailto:hi@usestrix.com), with `SECURITY` in the + subject line. + +## What to include + +A report is easiest to act on when it contains: + +- the affected component — the CLI, the sandbox container, the agent runtime, + the report writer, or the viewer; +- the version, from `strix --version`, and how it was installed; +- what an attacker gains, and what access they need to start; +- steps to reproduce, ideally a minimal case; +- any logs, scan artifacts, or proof-of-concept output. + +Redact scan artifacts before sending them. A run directory can contain target +hostnames, captured credentials, and request bodies from whatever was scanned. + +## Scope + +Strix runs untrusted target content through an agent and writes artifacts a +human later opens, so the parts most worth reporting are the ones crossing that +boundary: + +- sandbox escape, or anything giving the container more host access than the + documented mounts and network policy; +- exposure of LLM API keys, proxy-captured credentials, or the MITM CA key; +- code execution or injection reached through scanned target content, including + the generated reports — CSV, Markdown, PDF, SARIF and JSON; +- prompt injection from a target that escalates into actions outside the + sandbox. + +Findings that Strix reports about *your own* scan target are not +vulnerabilities in Strix. Neither is a scan running against a host you are not +authorised to test. + +## Supported versions + +Fixes land on the latest release. Given the current release cadence, upgrading +to the newest version is the supported path rather than backports to older +tags. + +## Disclosure + +Please give the maintainers a chance to ship a fix before publishing details. +If you would like credit in the advisory, say so in your report.