towerops/policies/SECURITY_AND_VULNERABILITY.md

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.