103 lines
4.6 KiB
Markdown
103 lines
4.6 KiB
Markdown
# Security Policy
|
|
|
|
## Supported Versions
|
|
|
|
| Version | Security patches |
|
|
|---|---|
|
|
| 1.5.x | ✅ Active |
|
|
| 1.4.x | ⚠️ Critical fixes only |
|
|
| < 1.4 | ❌ Not supported |
|
|
|
|
---
|
|
|
|
## Reporting a Vulnerability
|
|
|
|
**Do not open a public GitHub Issue for security vulnerabilities.**
|
|
|
|
Report security issues directly to the CTO via the private Slack channel `#brunix-security` or by email to the address on file. Include:
|
|
|
|
1. A clear description of the vulnerability and its potential impact.
|
|
2. Steps to reproduce (proof-of-concept if applicable).
|
|
3. Affected component(s) and version(s).
|
|
4. Suggested remediation, if known.
|
|
|
|
You will receive an acknowledgement within **48 hours** and a resolution timeline within **7 business days** for confirmed issues.
|
|
|
|
---
|
|
|
|
## Security Model
|
|
|
|
### Transport
|
|
|
|
The gRPC server currently runs with `add_insecure_port` — **there is no TLS in the current dev configuration.** This is intentional for the local development setup where all traffic flows through authenticated kubectl tunnels.
|
|
|
|
**For any production or internet-exposed deployment, TLS must be enabled.** See ADR-0003 for context.
|
|
|
|
### Authentication & Authorization
|
|
|
|
The current version has **no authentication layer** on the gRPC API. Any client with network access to port `50052` can call any RPC method and access any session by session ID.
|
|
|
|
Acceptable risk boundaries for the current deployment:
|
|
- Port `50052` must be accessible **only** to authorized developers via firewall rules or VPN.
|
|
- Do not expose port `50052` on a public IP without an authenticating reverse proxy.
|
|
|
|
### Secrets Management
|
|
|
|
All secrets (API keys, database credentials) are managed exclusively via environment variables. The following rules are enforced:
|
|
|
|
- **Never commit real secret values** to any branch, including feature branches.
|
|
- Use placeholder values (e.g., `sk-ant-...`, `pk-lf-...`) in documentation and examples.
|
|
- The `.env` file is listed in `.gitignore` and must never be committed.
|
|
- The `kubernetes/kubeconfig.yaml` file grants cluster-level access and must never be committed.
|
|
- PRs containing secrets or committed `.env` / kubeconfig files will be **immediately closed** and the committer will be required to rotate all exposed credentials before resubmission.
|
|
|
|
**Environment variables that contain secrets:**
|
|
|
|
| Variable | Type |
|
|
|---|---|
|
|
| `LANGFUSE_PUBLIC_KEY` | API key |
|
|
| `LANGFUSE_SECRET_KEY` | API key |
|
|
| `ANTHROPIC_API_KEY` | API key |
|
|
| `ELASTICSEARCH_PASSWORD` | Credential |
|
|
| `ELASTICSEARCH_API_KEY` | API key |
|
|
| `HF_TOKEN` | API key |
|
|
|
|
### Container Security
|
|
|
|
- The container runs as a **non-root user** (Python 3.11 slim base image default).
|
|
- Using `root` as the container user is explicitly prohibited (see `CONTRIBUTING.md` §3).
|
|
- The `/workspace` directory is deprecated. All application code runs from `/app`.
|
|
- The `.dockerignore` ensures that development artifacts (`.git`, `.env`, `tests/`, `docs/`) are excluded from the production image.
|
|
|
|
### Data Privacy
|
|
|
|
- All LLM inference (text generation and embeddings) is performed within the **private Devaron Kubernetes cluster** on Vultr infrastructure. No user query data is sent to external third-party APIs during normal operation.
|
|
- The exception is the `EvaluateRAG` endpoint, which sends **golden dataset questions and generated answers** to the Anthropic API (Claude) for evaluation scoring. No real user queries from production sessions are used in evaluation.
|
|
- Conversation history is stored **in-memory only** and is never persisted to disk or an external database.
|
|
|
|
### Dependency Security
|
|
|
|
- Dependencies are pinned via `uv.lock` and exported to `Docker/requirements.txt`.
|
|
- Dependency updates should be reviewed for security advisories before merging.
|
|
- Run `pip audit` or `safety check` against `Docker/requirements.txt` before major releases.
|
|
|
|
```bash
|
|
pip install pip-audit
|
|
pip-audit -r Docker/requirements.txt
|
|
```
|
|
|
|
---
|
|
|
|
## Known Security Limitations
|
|
|
|
These are acknowledged risks accepted for the current development phase. They must be addressed before any production internet-facing deployment.
|
|
|
|
| ID | Limitation | Risk | Mitigation required |
|
|
|---|---|---|---|
|
|
| SEC-001 | No gRPC TLS | Traffic interception | Enable TLS with server certificate |
|
|
| SEC-002 | No API authentication | Unauthorized access | Add JWT / mutual TLS authentication |
|
|
| SEC-003 | Session IDs are guessable | Session hijacking | Enforce UUIDs; validate ownership |
|
|
| SEC-004 | No rate limiting | DoS / cost amplification | Add gRPC interceptor rate limiter |
|
|
| SEC-005 | In-memory session store | Data loss on restart | Acceptable for dev; requires Redis for prod |
|
|
| SEC-006 | `ELASTICSEARCH_USER/PASS` optional | Unauthenticated ES access | Make auth required in prod; fail-fast if absent |
|