Four channels, and one of them is private on purpose.
Where to ask a question, where to report a bug or a false positive, how to disclose a vulnerability in SecHelix privately rather than in a public issue, and how to raise a business enquiry.
Pick the right channel
One maintainer reads all of these. Choosing the right one is not a formality — a vulnerability report in the wrong channel is published to the world at the moment you press submit.
| You want to | Go to | Public? |
|---|---|---|
| Ask a question or get help | GitHub Discussions | Public |
| Report a bug | Bug issue template | Public |
| Report a false positive | False-positive issue template | Public |
| Report a vulnerability in SecHelix | Private security advisory | Private — never a public issue |
| Raise a business or partnership enquiry | [email protected] | Private |
Support and questions
SUPPORT.md is the routing document in the repository, and it is more detailed than this page: it maps each kind of question to a destination and explains the status vocabularies that cause most of the confusion — the difference between UNKNOWN and NOT_APPLICABLE, or between BLOCKED and FALSE_POSITIVE.
What makes a false-positive report actionable:
- The finding id and what it claimed.
- The smallest reproduction you can share. A redacted synthetic snippet is fine, and often better than real code.
- Why it is wrong: the compensating control, the unreachable path, or the framework behaviour that neutralises it.
- Which catalog hypothesis produced it, if you can tell.
Security disclosure
Include, as far as you can:
- The affected version or commit.
- The affected file or path.
- The threat model and the prerequisites an attacker needs.
- A safe reproduction.
- The impact.
- A suggested mitigation, if you have one.
The published response targets are below. They are good-faith targets from a single maintainer, not a contractual SLA. If a deadline slips you will be told why rather than ignored.
| Stage | Target |
|---|---|
| Acknowledgement | 3 business days |
| Initial triage and severity assessment | 10 business days |
| Fix or documented mitigation | 90 days from acknowledgement |
| Public disclosure | After a fix ships, or by mutual agreement |
- Safe harbour
- Good-faith security research on SecHelix itself will not be met with legal action. Good faith means you test only against your own copy, you do not access or exfiltrate anyone else’s data, you do not degrade a service other people rely on, and you give the maintainer a reasonable window before public disclosure.
- Credit
- Reporters are credited in the advisory and the changelog by default. Say so if you would rather stay anonymous.
- Someone else’s system
- If the vulnerability is in a third party’s system that you found while using SecHelix, complete responsible disclosure with that party first. This project is not a disclosure intermediary and cannot grant you authorization to test anything.
Business enquiry
For implementation help, evaluation support, partnerships, or private application-security work, email [email protected]. It reaches one person directly.
- There is no sales team, no sales pipeline, and no automated sequence behind this address. A reply comes from the maintainer or it does not come.
- Nothing is currently for sale. There is no paid tier, no licence to buy, and no billing anywhere on this site — the framework is Apache-2.0 and stays that way.
- A hosted SecHelix Cloud has been sketched but does not exist. If that is what you are writing about, /early-access describes exactly what is and is not built.