Report a vulnerability
Please report security problems privately, not in a public issue: open the Security tab of the repository and click Report a vulnerability, with the affected version and how to reproduce it. We confirm reports within a few working days, fix confirmed problems in a new release and credit the reporter in the release notes unless they prefer otherwise.
Security fixes are released for the newest version. Machine-readable contact: security.txt.
How BackupZit protects your data
Backups
AES-256-GCM encryption, keys sealed with a recovery key (Argon2id), every chunk verified by its SHA-256 hash on restore. Immutable storage with S3 Object Lock or the hardened repository; ransomware detection and automatic restore tests.
Console
HttpOnly, SameSite=Strict session cookies, CSRF and clickjacking protection, a strict Content-Security-Policy, rate limits on sign-in, two-factor sign-in, roles, optional four-eyes approval and a hash-chained audit log that can be sent to a syslog server or SIEM.
Agents
Agents connect out to the console — no open ports on protected machines — and pin the console's certificate when they enroll. Each agent has its own secret; secrets on the console are stored encrypted.
Your network only
No cloud service, no telemetry, no account with us. Update checks fetch signed releases from GitHub; consoles without internet access are updated by uploading the release files.
How releases are protected
- Every release is signed with the BackupZit Ed25519 release key; consoles and agents verify the signature and checksums before installing an update.
- The install script verifies the signature and checksum of the release it downloads.
- Packages are built from tagged commits; images carry a written source offer (
SOURCE-CODE.txt). - A console update backs up the database first and rolls back automatically if the new version does not start.
How BackupZit is tested
On every change (GitHub Actions)
| Check | What it finds |
|---|---|
| CI | go vet and the full test suite against embedded PostgreSQL and in-process SFTP, S3 and vSphere simulators; Windows build |
| CodeQL | Injection, path traversal, unsafe redirects and other data-flow bugs (Go, JavaScript, workflows) |
| govulncheck | Known vulnerabilities in Go and in the dependencies the code actually calls |
| staticcheck | Bugs and dead code |
| Dependabot | Vulnerable or outdated Go modules and actions |
| Secret scanning | Credentials committed by mistake (with push protection) |
| OpenSSF Scorecard | Supply-chain practices of the repository |
Before releases (in a test lab)
| Check | What it finds |
|---|---|
| gosec | Insecure Go patterns: command execution, file permissions, weak cryptography |
| Semgrep | Injection, XSS, insecure cookies, open redirects (Go, JavaScript, secrets, OWASP Top 10 rules) |
| Trivy | Vulnerable dependencies, secrets and misconfigurations |
| Gitleaks | Secrets in the whole git history |
| OWASP ZAP | Full scan signed in as an administrator: XSS, SQL injection, CSRF, path traversal, header problems |
| OpenVAS and nmap | Network-level vulnerabilities, open ports and TLS settings of the appliance |
| End-to-end QA | Backups and restores of every supported source to every storage type on real systems; roles, LDAP/SSO, API |
Findings are fixed before the release; accepted risks are documented in the release notes.
This website
backupzit.com is a static site: no cookies, no analytics, no trackers, no third-party scripts or fonts, and a Content-Security-Policy that allows no scripts at all. See the privacy policy.