Please do not report security vulnerabilities through public GitLab issues.
Report vulnerabilities privately through either channel:
- Email — security@trueppm.com (preferred).
- Confidential GitLab issue — open an issue in
trueppm/trueppmand tick "This issue is confidential" so it is visible only to project members. Use this if you cannot send email or want the discussion tracked in GitLab.
Include:
- Description of the vulnerability and its potential impact
- Steps to reproduce or a proof-of-concept
- Affected version(s)
- Any suggested mitigations you have identified
| Stage | Target |
|---|---|
| Acknowledgement | 2 business days |
| Initial assessment | 5 business days |
| Status update | Every 7 days until resolved |
| Patch release | Within 30 days for Critical/High; 90 days for Medium/Low |
We will credit reporters in the release notes unless anonymity is requested.
We support responsible security research and want to make it safe to report what you find. We will not pursue or support legal action against you for security research and vulnerability disclosure conducted in good faith and consistent with this policy — that is, research that:
- respects user privacy and does not access, modify, or destroy data beyond the minimum needed to demonstrate the vulnerability;
- does not degrade, disrupt, or deny service to others (no denial-of-service, no automated high-volume scanning against shared infrastructure);
- targets only assets in the Scope section below, on infrastructure you own or are explicitly authorized to test; and
- gives us a reasonable opportunity to remediate before any public disclosure.
If you are unsure whether a specific test is authorized, ask first at security@trueppm.com and we will clarify. This safe harbor does not extend to actions that violate applicable law, and it does not waive the rights of third parties who are not party to this policy.
| Version | Security patches |
|---|---|
main (unreleased) |
✅ Active |
0.3.x (current alpha) |
✅ Active |
< 0.3.0 |
❌ No support |
Once 1.0.0 is released, the two most recent minor versions will receive security backports.
TruePPM follows coordinated disclosure:
- Reporter submits privately.
- We confirm, investigate, and develop a fix.
- We agree on a disclosure date — typically 90 days from report, sooner if a patch is ready.
- We publish a GitLab Security Advisory and release a patch.
- Reporter may publish their own write-up after the advisory is public.
In scope: the TruePPM API (packages/api), web frontend (packages/web), scheduling engine (packages/scheduler), Helm chart (packages/helm), and the Docker Compose production stack.
Out of scope: the documentation website itself (packages/website), third-party dependencies (report those upstream), and findings that require physical access to the host.
Every merge request and every push to main runs a layered set of automated,
merge-blocking checks so security regressions are caught before release:
| Check | Tool | What it catches |
|---|---|---|
| Secret scanning | gitleaks | Hardcoded credentials, keys, and tokens (also a pre-commit hook) |
| Static analysis (SAST) | bandit, semgrep | Insecure Python/JS/TS/Django patterns |
| Dependency CVEs (SCA) | osv-scanner, cargo-deny | Known-vulnerable Python, npm, and Rust dependencies |
| Container / IaC | trivy | Dockerfile and Helm misconfigurations; image CVEs before push |
| License compliance | pip-licenses, license-checker, cargo-deny | Copyleft licenses incompatible with the Apache-2.0 core |
These are enforcement gates, not advisories: a pipeline that surfaces an
unignored finding blocks the merge. Suppressions are scoped and documented in
the relevant config (.gitleaks.toml, osv-scanner.toml, .trivyignore.yaml,
deny.toml) so they stay auditable rather than silently masking findings.
We gratefully acknowledge all responsible disclosures. A Hall of Fame will be maintained here once contributions are received.