Report suspected vulnerabilities privately through GitHub Security Advisories. Please do not open a public issue for a suspected vulnerability.

Include, where you can: affected version or commit, a description of the impact, and the smallest reproduction you have. A concrete reproduction is far more useful than a description of one.

What to expect. This is a single-maintainer project, so the honest numbers are: an acknowledgement within five business days, and an assessment of whether the report is in scope within ten. There is no fix-time commitment. If a report is valid and serious, it gets worked before anything else; if it is valid and minor, it may wait. You will be told which. Credit is offered by default in the advisory unless you ask otherwise.

If you have not heard back in ten business days, assume the notification was missed rather than ignored, and email mark@chmarny.com.

Only the latest release receives fixes, along with main. There are no long-term support branches and no backports to older minors. Given the size of the project, maintaining more than one supported line would mean doing both badly.

https://devtrace.thingz.io is a reference deployment run by the maintainer. A report against the hosted instance is welcome through the same channel. Please do not test against it in ways that would degrade it for other users or touch data that is not yours — run a local instance instead (see CONTRIBUTING.md). Testing against your own local deployment is always in scope and always welcome.

• Any path by which one tenant can read, infer, or modify another tenant's data. This is the most serious class of bug the project can have.
• Authentication or session handling flaws: session fixation, cookie scope or lifetime errors, or a way to act as another user.
• Anything that lets a contributor influence their own trust score, or another contributor's, beyond what the documented signals intend. The score is the product; forging it is the highest-value attack against it.
• Mishandling of GitHub App credentials, OAuth secrets, or webhook secrets, including unverified webhook payloads being trusted.
• Injection reachable through contributor-controlled data — profile fields, commit metadata, or third-party profile sources — including into prompts sent to the configured LLM, where the output is then trusted.
• Secrets or tokens leaking into logs, error messages, API responses, or exported data.

• Findings from automated scanners with no demonstrated impact on this codebase. A dependency CVE report is welcome, but please say why it is reachable here.
• Vulnerabilities in third-party services the project integrates with — report those to the service.
• Missing hardening headers, cookie flags, or TLS configuration on the hosted instance without a described attack. These are worth fixing and a plain issue is the right venue.
• Social engineering, physical access, and denial of service through sheer volume.
• Anything requiring a compromised maintainer machine or a malicious administrator of your own tenant.

Coordinated. A fix is prepared privately, released, and the advisory published with the details. If a report is being actively exploited, that timeline compresses. Please give a reasonable window before publishing independently — and if the response times above are not met, say so in the advisory thread rather than waiting indefinitely.