pistra is an enforcement point on a request path, so the thing to report is a control that does less than the threat model says it does. That page also states what pistra does not defend against, and a report of one of those is a documentation question rather than a finding.
Do not report a vulnerability through a public channel. That means no GitHub issue, pull request or discussion. Send it to security@pistra.ai, which reaches the maintainer directly.
What to include
A report is easier to act on with these. Only the first three are needed to start.
- A title. One line saying what the issue is.
- A technical description. What the flaw is and where it lives.
- Reproduction steps. The smallest configuration and request that
shows it. A
pistra -test-rulescase or a config fragment is ideal. - Affected versions. The tag, commit or image digest you tested.
- Who you are. A name or handle, and an affiliation if there is one.
- Impact. The exploit scenario as you see it, and how severe you think it is. Optional, and useful when it is not obvious.
- A suggested fix. Optional.
- Disclosure status. Whether anybody else has this, and when you plan to publish or present it.
What happens next
An acknowledgement within three working days. An assessment after that, saying whether the report is confirmed, what the severity looks like, and when a fix is expected.
Fixes and disclosure are coordinated with you. Publication waits for a release carrying the fix, unless the issue is already public or being exploited, in which case it goes out with whatever mitigation exists. Reporters are credited by name in the changelog and the advisory unless they ask not to be.
Supported versions
The repository is pre-release and has no tagged release. Until it does,
main is the only version there is, and a fix lands there.
Once releases begin, the newest tag carries security fixes. Older tags get critical fixes on a best-effort basis, and releases and compatibility is where any support commitment beyond that will be written.
What counts as a vulnerability here
pistra is an enforcement point in a request path. A control that does less than the threat model says it does is the thing to report. Findings in credential handling, key storage, the admin plane’s default-deny, or the inspector’s separation from routing are security-relevant whatever their severity looks like.
The threat model already states what pistra does not do. A report of one of these is a documentation question:
- Pattern detection does not catch paraphrase, unusual encodings, or a description of a secret. Guardrails are not an adversary-resistant filter and are not claimed to be.
- The prompt injection detectors reduce rather than prevent, and the
llmjudge reads exactly the text an attacker wrote. - A body over
max_body_bytesis not inspected. It is counted inpistra_guardrail_uninspected_totalinstead. - An attacker with the configuration file, the cluster secret, or root on the host has already won, and the page says so.
What it does not defend against is the full list. Report anything that is worse than documented, or reaches further than the page says.
Regulatory reporting
pistra is distributed under the Business Source License 1.1, which is not an OSI-approved open source licence, and is offered commercially. Reports of a vulnerability being actively exploited reach us fastest at the address above, and are handled ahead of everything else.
Contact
- Email: security@pistra.ai
- Security documentation: threat model and threat model disclosure