Ctrl K
ComunidadGuías…

SECURITY.md

Rama main · réplica de lectura del repositorio original.

Archivo original ↗Preguntar a KiBot
# Security Policy

## Reporting a Vulnerability

We take security reports seriously and aim to acknowledge within 48 hours.

**Preferred — GitHub Security Advisories:**
[github.com/lynox-ai/lynox/security/advisories/new](https://github.com/lynox-ai/lynox/security/advisories/new) — private, CVE-numbered, lets us coordinate a release. This is the path we'd like every researcher to use.

**Alternative — Email:** security@lynox.ai — for reporters who can't use GitHub Advisories.

Please include in your report:
- Description of the vulnerability
- Steps to reproduce
- Potential impact (data exposure / privilege escalation / etc.)
- Suggested fix (if any)
- Your preferred attribution (handle, name, or anonymous)

We aim to provide a fix within 7 days for critical issues, 14 days for high-severity, 30 days for medium. Lower-severity issues are addressed in the next regular release.

**Do not** open a public GitHub issue for security vulnerabilities.

## Safe Harbor

We will not pursue legal action against researchers who act in good faith. Specifically, you have our authorization to:

- Test any lynox release running on infrastructure you control (self-hosted, your dev box, a fresh `docker compose up`).
- Perform automated vulnerability scanning against your own self-hosted instance.
- Probe edge cases in the public Web UI / API of your own self-hosted instance.

This authorization does not extend to:

- The managed hosting service (`control.lynox.cloud`, `*.lynox.cloud` per-tenant instances). Testing there affects other customers' data — out of scope.
- The website (`lynox.ai`) — out of scope.
- Social engineering of lynox staff, customers, or contractors.
- Denial-of-service attacks, even against your own self-hosted instance, when the attack would degrade GitHub / npm / Anthropic / Mistral infrastructure.
- Physical attacks against infrastructure.

Researchers acting in good faith under this policy: we will work with you, credit you (if you want), and won't notify law enforcement. If you're unsure whether your planned testing is covered, email security@lynox.ai before you start and we'll clarify within 24 hours.

## Supported Versions

| Version | Supported |
|---------|-----------|
| 1.x     | Yes       |
| < 1.0   | No        |

## Security Model

For the technical security architecture (cryptography, authn/authz, SSRF protections, sandboxing, permission guards) see [`docs/developers/security-model.md`](docs/src/content/docs/developers/security-model.md) — that document tracks the actual code paths and is updated when they change.

### API Keys

lynox uses a Bring Your Own Key (BYOK) model. Your Anthropic API key is stored locally in `~/.lynox/config.json` and never transmitted to any server other than the Anthropic API (or your configured `ANTHROPIC_BASE_URL`).

### Secret Vault

Sensitive values can be stored in an encrypted vault (`~/.lynox/vault.db`):
- AES-256-GCM encryption
- PBKDF2 with 600,000 iterations (SHA-512)
- Requires `LYNOX_VAULT_KEY` environment variable

### Bash Tool

The bash tool blocks known destructive commands:
- `rm -rf /` and variants
- Force push to main/master
- Other dangerous patterns

### HTTP Tool

The HTTP tool includes SSRF protection to prevent requests to internal networks and metadata endpoints.

### Workspace Sandbox

When running in Docker, lynox operates in a sandboxed workspace:
- Write access limited to `/workspace` and `/tmp`
- Read-only root filesystem
- Non-root user (uid 1001)
- `no-new-privileges` security option

### Plugin Isolation

Plugins are loaded only from `~/.lynox/plugins/node_modules/` with validated package names. Secret content is stripped from plugin context.