Protecting the .env file
.env holds secrets, so treat the file itself as a secret:
- Never check it into version control — add
.env to .gitignore.
- Limit who you share it with; don’t paste it into Slack, tickets, or screenshots.
- Prefer generating it on the target host. If you generate it elsewhere, transfer it over an authenticated channel and wipe the source copy.
- If your organization uses a secrets manager, fetch
.env at deploy time rather than storing it on disk long-term. The stack does not integrate with these, so that is your responsibility.
Database least privilege
Give each database a dedicated role with:
USAGE, CREATE ON SCHEMA publicSELECT, INSERT, UPDATE, DELETE on its tablesUSAGE, SELECT ON ALL SEQUENCES IN SCHEMA public
control also needs the pg_trgm extension:
pg_trgm is a trusted extension, so a role with CREATE ON DATABASE control can create it. Otherwise, have an administrator run CREATE EXTENSION pg_trgm once before the first start.
Network exposure
Deploy the stack to a trusted environment and ensure the exposed network ports (see Installation → Networking) are only reachable by authorized clients.
Egress
Every outbound integration is off by default (see Installation → Optional features to enable them). The ones that connect outbound are Slack alert delivery, EDR device detection, and LLM alert assessment. For LLM assessment, ANTHROPIC_BASE_URL routes requests through an Anthropic-compatible in-network gateway instead of calling Anthropic directly.
Encryption in transit
Session cookies carry the Secure flag, so plain-HTTP logins work only on localhost. Serve every other host over HTTPS through your load balancer. When the public URL changes, update the redirect URI registered at your IdP to match the new public URL.
Encryption at rest
Deploy the stack to infrastructure with encrypted disks so local state is encrypted on disk.
Reporting vulnerabilities
Report suspected security issues to security@osohq.com.
