Publishing under AGPL without a CLA closes the door on ever offering
commercial terms: every merged PR would be copyright we cannot relicense,
and asking dozens of contributors for permission after the fact does not
work. CLA.md section 2 grants the maintainer a license "under any license
terms, including proprietary" — that clause is the whole point.
LICENSING.md states the open-core boundary up front rather than carving
features out later, which is the move that has burned trust elsewhere. The
entire detection and enrichment engine stays AGPL; Enterprise is limited to
SSO, audit trail, compliance reporting, SIEM forwarding and multi-tenancy,
under a stated two-part rule for what may ever go there.
SECURITY.md gives a private disclosure path — a vulnerability scanner whose
own bugs land as public issues is a poor advertisement.
The CLA bot runs as a GitHub Action writing signatures to a cla-signatures
branch, so there is no third-party service to sign up for.
Placeholders {{LICENSOR}}, {{CONTACT}}, {{GH_OWNER}} and {{GH_REPO}} are
filled in once the legal entity and the GitHub location are settled.
55 lines
2.2 KiB
Markdown
55 lines
2.2 KiB
Markdown
# Security Policy
|
|
|
|
## Reporting a vulnerability
|
|
|
|
**Do not open a public GitHub issue for a security vulnerability in TrueVuln.**
|
|
|
|
Report it privately through GitHub's
|
|
[private vulnerability reporting](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability)
|
|
(Security tab → Report a vulnerability), or by email to {{CONTACT}}.
|
|
|
|
Please include:
|
|
|
|
- Affected version or commit
|
|
- What an attacker can do with it
|
|
- Reproduction steps or a proof of concept
|
|
- Whether it is already public anywhere
|
|
|
|
## What to expect
|
|
|
|
| | |
|
|
|---|---|
|
|
| Acknowledgement | within 72 hours |
|
|
| Initial assessment | within 7 days |
|
|
| Fix or mitigation for confirmed high/critical issues | target 30 days |
|
|
| Credit | in the advisory, unless you prefer not to be named |
|
|
|
|
This project is maintained by a small team. Timelines are targets made in good faith,
|
|
not a contractual commitment.
|
|
|
|
## Scope
|
|
|
|
**In scope:** authentication and authorisation bypass, privilege escalation between
|
|
roles, injection (SQL, command, template), SSRF via configurable feed or scanner URLs,
|
|
credential exposure in logs, API responses, or reports, secrets handling in
|
|
`app/auth/setting_crypto.py`, tampering with the audit trail, XSS in the frontend.
|
|
|
|
**Out of scope:** vulnerabilities in third-party dependencies without a demonstrated
|
|
exploit path through TrueVuln (report those upstream), issues that require an already
|
|
compromised host or an existing admin session, missing security headers with no
|
|
demonstrated impact, findings from automated scanners with no working proof of concept,
|
|
denial of service through deliberate resource exhaustion on a self-hosted instance,
|
|
and social engineering.
|
|
|
|
## Supported versions
|
|
|
|
TrueVuln is in beta. Security fixes are applied to the latest release on `main`. There
|
|
are no backports to older releases yet.
|
|
|
|
## A note on deployment
|
|
|
|
TrueVuln holds credentials for Wazuh, Nessus, Microsoft Graph, and your mail server, and
|
|
a complete map of every unpatched vulnerability in your estate. **Treat the instance as a
|
|
tier-0 asset.** Do not expose it directly to the internet, restrict access to the
|
|
administrative network, and enable MFA.
|