Graham McIntie
26c7b0b993
- Commented out 'View RF Links' button in network map node detail panel - Commented out RF Link health legend (Good/Degraded/Critical) from map legend - Backend code (topology.ex) left intact per instructions - No RF tab found on device show page (nothing to hide there) - All tests pass, compiles clean with --warnings-as-errors Reviewed-on: graham/towerops-web#46
64 lines
3.1 KiB
Markdown
64 lines
3.1 KiB
Markdown
# Security & Vulnerability Prevention Policy
|
|
|
|
**Effective:** 2026-03-15
|
|
**Owner:** Engineering
|
|
|
|
## Purpose
|
|
|
|
Every commit must be evaluated for security implications before merge. TowerOps handles network infrastructure data — a breach could expose customer network topologies, credentials, and operational data.
|
|
|
|
## Pre-Commit Security Checklist
|
|
|
|
Before committing, verify:
|
|
|
|
1. **No hardcoded secrets.** No API keys, tokens, passwords, or SNMP community strings in source. Use environment variables or runtime config.
|
|
2. **No SQL/HQL injection.** All database queries use parameterized Ecto queries — never string interpolation in queries.
|
|
3. **No LIKE injection.** Sanitize `%` and `_` in user-provided LIKE patterns using `Towerops.Helpers.sanitize_like/1`.
|
|
4. **Input validation.** All user input passes through Ecto changesets with explicit casting and validation before reaching business logic.
|
|
5. **Authorization checks.** Every controller/LiveView action verifies the current user has access to the requested resource via org membership.
|
|
6. **No mass assignment.** Changesets explicitly list permitted fields — never pass raw params to `cast/3` without filtering.
|
|
7. **Credential stripping.** API responses that include integration configs must strip `password`, `token`, `secret`, `api_key`, and `community` fields.
|
|
|
|
## Dependency Security
|
|
|
|
- Run `mix deps.audit` (via `mix_audit`) weekly and before releases.
|
|
- Run `mix sobelow` for static security analysis on every PR.
|
|
- Update dependencies monthly; patch critical CVEs within 48 hours.
|
|
- Erlang/OTP and Elixir versions must be on supported release tracks.
|
|
|
|
## Authentication & Sessions
|
|
|
|
- All sessions use secure, HTTP-only, SameSite=Lax cookies.
|
|
- Session tokens are rotated on privilege escalation (login, role change).
|
|
- API tokens are bearer tokens — never transmitted in query strings.
|
|
- Failed login attempts are rate-limited.
|
|
- Passwords hashed with `bcrypt` (Argon2 acceptable alternative).
|
|
|
|
## Network Security
|
|
|
|
- All external traffic over TLS. No exceptions.
|
|
- SNMP community strings treated as secrets — stored encrypted at rest, never logged.
|
|
- Agent-to-server communication uses mTLS or token-based auth with TOFU host key verification.
|
|
- Webhook endpoints validate signatures where supported.
|
|
- GraphQL introspection disabled in production.
|
|
|
|
## Logging
|
|
|
|
- Log security-relevant events: login, logout, failed auth, permission changes, data export.
|
|
- Never log credentials, tokens, full request bodies with sensitive fields, or PII.
|
|
- Retain security logs for 90 days minimum.
|
|
|
|
## Vulnerability Response
|
|
|
|
| Severity | Response Time | Action |
|
|
|----------|--------------|--------|
|
|
| Critical (RCE, auth bypass, data leak) | 4 hours | Patch, deploy, notify affected customers |
|
|
| High (privilege escalation, injection) | 24 hours | Patch, deploy |
|
|
| Medium (information disclosure, DoS) | 1 week | Patch in next release |
|
|
| Low (best practice deviation) | 1 month | Track in backlog |
|
|
|
|
## Enforcement
|
|
|
|
- CI runs `mix sobelow --exit` on every PR.
|
|
- `mix deps.audit` integrated into CI pipeline.
|
|
- Security-sensitive PRs (auth, crypto, data access) require explicit review from a senior engineer.
|