Security policy

How we handle vulnerabilities and your data.

RackWatch is monitoring software that runs on hardware you own. We take this responsibility seriously. This page describes how to report an issue, what's in scope, and how the platform handles your fleet data.

Reporting a vulnerability

If you've found a security issue in the RackWatch platform or agent, please email security@rackwatch.io with a description, reproduction steps, and any proof-of-concept. For sensitive reports, request a PGP key in your initial mail and we'll respond with one before you send details.

You can also open a private security advisory on GitHub at github.com/rackwatch/rackwatch-agent/security/advisories for issues in the agent.

What you can expect

Within 48 hours: acknowledgement of your report.

Within 7 days: initial triage and severity assessment.

Within 90 days: coordinated disclosure target — earlier for critical issues, longer if a fix requires architectural changes (we'll communicate either way).

Scope

In scope

Authentication, authorization, and session handling on the platform
Agent-to-platform protocol (AGENT_API_KEY validation, payload handling)
Privilege escalation in the agent's install or runtime
SQL injection, XSS, CSRF, SSRF, RCE, path traversal in any HTTP surface
Cryptographic weaknesses (JWT signing, password hashing, TLS posture)
Patch-database tampering or CVE-mapping integrity

Out of scope

Findings that require physical access to a server already running the agent as root
Self-DoS through misconfiguration of your own deployment
Vulnerabilities in third-party dependencies that are already patched in a current release
Issues in our marketing site (rackwatch.io) that don't affect the platform binary
Findings against the public demo dashboard at rackwatch.io/dashboard.html using its public credentials

Build provenance

Platform binary: .NET 8 self-contained build, published from RackWatch.Platform.csproj. Each release is tagged in the platform repository and the SHA-256 of the binary is published in the release notes.
Agent binary: Source on GitHub at github.com/rackwatch/rackwatch-agent. Built and signed in CI from a tagged commit. SHA-256 published per release.
Reproducible builds: Target — we are not yet able to claim full reproducibility for the .NET self-contained output. Goal is to ship deterministic agent builds before the 1.0 release. Status will be updated here.
Dependencies: Tracked via Dependabot on the agent repo. Platform dependencies are reviewed on each release. Critical CVEs in dependencies trigger a patch release within 7 days.

How RackWatch handles your data

The whole point of self-hosted monitoring is that fleet telemetry doesn't leave your network. RackWatch is built to honor that:

No outbound telemetry. The platform does not phone home. Patch databases are downloaded from your distribution's mirrors (or yours, if mirrored).
Agent → platform only. The agent posts telemetry to one URL — your platform — over HTTPS, authenticated by a per-tenant key.
No third-party analytics in the dashboard. No Google Analytics, no LogRocket, no Sentry on the platform UI.
Air-gap supported. Once the platform binary is on your network, no internet egress is required for normal operation. CVE feeds — distro security trackers (Ubuntu USN, Debian DSA, RHEL RHSA, Alpine secdb, Microsoft MSRC), plus NVD and OSV as fallback — can be mirrored offline. See the risk-score doc for source order and update cadence.
Encryption at rest. Platform stores telemetry in SQLite (default) or SQL Server. Encryption is the responsibility of the underlying storage volume — recommended on hardware you don't physically control.

Cryptography

Authentication: ASP.NET Core Identity, PBKDF2-HMAC-SHA512 password hashing (Identity v3 format), 210,000 iterations — OWASP's current recommendation for SHA-512. Existing accounts created at the previous 100,000-iteration setting are auto-rehashed on next successful sign-in. Migration to Argon2id is on the roadmap; current iteration count is a defensible interim.
Sessions: JWT signed with HS256. The signing key is operator-supplied via Jwt__Key.
Agent auth: Static API key per tenant. Validated on every push.
Transport: TLS termination is the operator's responsibility — typically a reverse proxy (nginx, Caddy, HAProxy), a managed proxy or load balancer, or the platform's Kestrel HTTPS endpoint directly.

If your deployment is internet-facing, you should also rotate Jwt__Key and AGENT_API_KEY from any defaults that were set during initial bootstrap.

Acknowledgements

We credit reporters in release notes unless you'd prefer to remain anonymous. We don't currently run a paid bug bounty — early-stage product — but we'll send merch and a public thank-you for any report that leads to a fix.