Security

​

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 public
• SELECT, INSERT, UPDATE, DELETE on its tables
• USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public

control also needs the pg_trgm extension: The simplest arrangement is a single role that owns each database’s objects.

​

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.