Do not create a public GitHub issue for security vulnerabilities.

Instead, please email security@example.org with:

1. Description of the vulnerability
2. Affected versions (e.g., commits, tags)
3. Steps to reproduce (if possible)
4. Impact assessment
5. Proposed fix (if you have one)

We will acknowledge receipt within 48 hours and provide an estimated timeline for resolution.

GERTIE-Qt is designed for air-gapped deployment:

• All code runs on local Raspberry Pi network (192.168.1.0/24)
• No internet connectivity required for operation
• Camera node code is read-only after deployment
• Configuration is centralized and immutable after boot

All code changes go through:

1. Local verification — ruff linting, format checks
2. Git history tracking — All commits are signed and traceable
3. Hardware testing — Changes tested on physical hardware before deployment
4. Rollback capability — Every deployment is tagged and reversible

• No credentials in code — Configuration files are .gitignore'd
• No hardcoded keys — SSH keys managed via operating system
• No API tokens — System is air-gapped (no external APIs)

• Network segmentation — Camera nodes isolated to 192.168.1.0/24
• SSH authentication — RSA keys required, password login disabled
• Service hardening — systemd services run as unprivileged pi user
• Logging — All service activity logged via journalctl (reviewable via SSH)

Dependencies are installed from:

• Python Package Index (PyPI) — PySide6, picamera2, numpy, etc.
• Raspberry Pi repositories — System packages via apt
• Local bundling — Large dependencies can be bundled in tarball for air-gapped installs

To audit dependencies:

pip3 show -f PySide6 picamera2 numpy Pillow
pip3 freeze > requirements.txt

• Code is always reviewed before execution
• Pip packages are pinned to tested versions
• No automatic updates; all changes are deliberate and tested

• Verify checksums of released code
• Review git commit history before deployment
• Test changes on non-production hardware first
• Keep SSH keys secure and backed up

• Use strong SSH key passphrases
• Restrict network access to control1 (firewall rules)
• Monitor logs regularly for anomalies
• Disable SSH password login entirely
• Use sudo sparingly; prefer sudoers rules

• Captured images are stored locally
• Telemetry data is local (no cloud sync)
• Database exports are your responsibility
• No automatic backups; users should implement their own

1. Day 0 — Vulnerability reported
2. Day 0-1 — Triage and confirmation
3. Day 1-5 — Fix developed and tested
4. Day 5-7 — Security advisory published
5. Release — Patched version released

High-severity issues may be expedited.

Security updates are released as tagged versions (e.g., v1.2.3). All users should:

1. Review the security advisory
2. Test the patch on non-production hardware
3. Deploy to production during maintenance window

• Security issues → security@example.org
• Code of Conduct violations → conduct@example.org
• General questions → maintainers@example.org

This project was last audited [DATE]. Contact maintainers for audit reports or to propose a security audit.