Verificado contra el código fuente

La seguridad no es una función.
Es la base.

Cada afirmación de esta página corresponde a código real de sh0. Una auditoría interna del 17 de marzo de 2026 detectó 34 problemas; los 6 críticos estaban corregidos en la fecha del informe.

Obtener sh0 Cómo funciona

Resultados de auditoría

Auditoría de seguridad interna de autenticación, criptografía, superficie de API e interfaz.

34
Problemas detectados
Auditoría interna, 17 de marzo de 2026
6/6
Críticos corregidos
En la fecha del informe
8/10
Altos corregidos
En la fecha del informe
17/34
Problemas corregidos
En la fecha del informe

Auditoría interna del 17 de marzo de 2026: 34 problemas detectados (6 críticos, 10 altos, 12 medios, 6 bajos). En la fecha del informe, los 6 críticos y 8 de los 10 altos estaban corregidos; los demás estaban previstos para una fase de refuerzo. A partir del 5 de octubre de 2026, las fallas corregidas se publican aquí.

Qué protegemos

Seis capas de seguridad fundamentales, cada una verificada en el código fuente de Rust.

sh0-auth

AES-256-GCM Encryption

All secrets, env vars, SSH keys, and API tokens -- and backup files when backup encryption is enabled -- encrypted with AES-256-GCM via the ring crate. Nonce format: nonce(12) || ciphertext || tag(16). Authenticated encryption ensures both confidentiality and integrity.

sh0-auth

Argon2id Password Hashing

OWASP-recommended Argon2id for all password storage. PHC-format hash output with unique random salt per password. TOTP backup codes also hashed with Argon2id.

sh0-api

HTTP-Only Cookie Auth

Access tokens (15 min) and refresh tokens (30 days) stored in HTTP-only cookies with SameSite=Strict. Secure flag auto-enabled in production. CSRF double-submit cookie pattern.

sh0-auth

API Key Security

Format: sh0_ prefix + 32 random chars. SHA-256 hashed storage, prefix-based lookup (first 8 chars). Constant-time comparison via the subtle crate to prevent timing attacks.

sh0-api

RBAC & Project Permissions

Owner, Admin, Developer, Viewer roles with per-project membership. Dedicated extractors (AuthUser, AdminUser, ProjectAccess) verify authorization on every API endpoint.

sh0-auth

TOTP Two-Factor Auth

RFC 6238 compliant, 6-digit codes, 30-second step, SHA-1 with +/-1 skew tolerance. 8 backup codes per user, each Argon2id-hashed. Provisioning URI for QR code setup.

Defensa en profundidad

01

Encrypted at rest

Master key derived via PBKDF2-HMAC-SHA256 with 100,000 iterations and a 16-byte salt. Every secret -- env vars, SSH private keys, backup dumps, API tokens -- is AES-256-GCM encrypted before touching disk.

02

Authenticated at every layer

JWT (HS256) from Bearer header or HTTP-only cookie, with API key fallback. Refresh tokens SHA-256 hashed in the database. Expired tokens caught with specific error codes. Multi-strategy auth on every request.

03

Rate-limited and throttled

Per-IP sliding window: 10 login attempts/15 min, 5 TOTP attempts/5 min, 50 invitations/min. Global read/write rate limits with automatic cleanup. Health and webhook paths exempt.

04

Audited and traceable

Every significant action logged: user ID, action, resource type/ID, IP address (X-Forwarded-For aware), timestamp. Paginated queries with filtering by user, resource type, and resource ID.

El stack de seguridad

PBKDF2 (100k iter.)
AES-256-GCM
Argon2id
HTTP-Only Cookies
CSRF Double-Submit
RBAC (4 roles)
Audit Log
Rate Limiting

Cada capa refuerza la siguiente -- compromete una y el resto se mantiene

Dependencias criptográficas

Sin criptografía personalizada. Solo crates de Rust probados en producción.

ring 0.17
AES-GCM, PBKDF2, SHA-256, CSPRNG
argon2 0.5
Argon2id password hashing
subtle 2.6
Constant-time comparison
jsonwebtoken 9
JWT sign/verify (HS256)
totp-rs 5
RFC 6238 TOTP generation
rustls 0.23
TLS for remote connections

Verificado en el código fuente

Cada hallazgo mapeado al crate donde se implementa.

Argon2id password hashing with random salt per password (sh0-auth)
AES-256-GCM authenticated encryption for all secrets (sh0-auth)
PBKDF2-HMAC-SHA256 with 100,000 iterations for key derivation (sh0-auth)
Constant-time API key comparison (subtle crate) (sh0-auth)
Parameterized SQL queries throughout (zero SQL injection) (sh0-db)
Refresh token hashed with SHA-256, never stored in plaintext (sh0-db)
TOTP backup codes hashed with Argon2id (sh0-auth)
Docker socket communication via Unix socket only (sh0-docker)
Exec commands use array format, never shell interpolation (sh0-docker)
Foreign key constraints and WAL mode enforced on every connection (sh0-db)
Optional backup encryption with the master key before storage (sh0-backup)
SSH private keys encrypted at rest, loaded in-memory only (sh0-git)
Upload size capped at 500 MB, pagination clamped to 1-200 (sh0-api)
Input validation on database names, compose files, port strings (sh0-backup)

Sin sh0

  • x Store tokens in localStorage (XSS-vulnerable)
  • x Write custom encryption per service
  • x Manage SSH keys in plaintext on disk
  • x Hope nobody SQL-injects your queries
  • x Share root credentials across team
  • x No audit trail of who did what

Con sh0

  • HTTP-only cookies, SameSite=Strict, CSRF protection
  • AES-256-GCM for everything, master key with PBKDF2
  • SSH keys encrypted at rest, loaded in-memory only
  • Parameterized queries + input validation everywhere
  • RBAC with 4 roles + per-project permissions
  • Full audit log with IP, user, action, resource tracing

Preguntas y respuestas

¿Se ha auditado la seguridad de sh0? +
Sí, de forma interna. Una auditoría en tres partes del 17 de marzo de 2026 (autenticación y criptografía, superficie de API, interfaz) detectó 34 problemas: 6 críticos, 10 altos, 12 medios y 6 bajos. En la fecha del informe, los 6 críticos y 8 de los 10 altos estaban corregidos; el resto estaba previsto para una fase de refuerzo. A partir del 5 de octubre de 2026, las fallas corregidas se publican como avisos de seguridad en este sitio.
How are secrets stored? +
All secrets (env vars, API tokens, SSH keys, backup credentials) are encrypted with AES-256-GCM using a master key derived via PBKDF2-HMAC-SHA256 with 100,000 iterations and a 16-byte salt. The master key file is generated once and encrypted at rest.
How does authentication work? +
JWT access tokens (15 min) in HTTP-only cookies with SameSite=Strict. Refresh tokens (30 days) SHA-256 hashed in the database. API key fallback with constant-time comparison. CSRF protection via double-submit cookie pattern. Bearer tokens supported for CLI.
What about two-factor authentication? +
TOTP (RFC 6238) with 6-digit codes, 30-second step, and +/-1 skew tolerance. 8 backup codes per user, each Argon2id-hashed. Rate-limited to 5 attempts per 5 minutes to prevent brute force.
Can one user access another user's containers? +
No. Every API endpoint that touches containers verifies project membership through the ProjectAccess extractor. Global owners/admins can access all projects, but developers and viewers must have explicit per-project membership.
What about container security? +
Docker Engine communication uses Unix socket only (no TCP exposure). All container commands use exec arrays, never shell interpolation. Compose files are structurally validated before deployment, including volume mounts, port strings, and dependency graphs.
¿Quién responde de la seguridad de las plantillas de un clic? +
Es compartida. sh0 mantiene las definiciones de las plantillas y corrige una plantilla cuando se informa de una falla. Las imágenes las publica cada proyecto de origen, y la seguridad de una aplicación desplegada (versión de la imagen, actualizaciones, sus propios usuarios y contraseñas) corresponde a quien opera el servidor.
Which cryptographic libraries do you use? +
ring 0.17 (hardware-accelerated AES-GCM, PBKDF2, SHA-256), argon2 0.5 (password hashing), subtle 2.6 (constant-time comparison), jsonwebtoken 9 (JWT), totp-rs 5 (TOTP), and rustls 0.23 (TLS). No custom cryptography.

Informar de una vulnerabilidad

Escríbanos a la dirección indicada abajo. Incluya la versión de sh0, los pasos para reproducirlo y el impacto observado. No abra una incidencia pública.

[email protected]

Si no recibe respuesta, use también el formulario de contacto: sh0.dev/contact

Nuestros compromisos

  • Acuse de recibo en un plazo de 72 horas.
  • Corrección prevista en 7 días para una falla crítica, 30 días para una alta y 90 días en los demás casos.
  • Para fallas críticas y altas, un preaviso de 48 a 72 horas antes de la corrección: solo fecha, gravedad y componente. Los detalles se publican con la corrección.
  • Las correcciones de seguridad saldrán como versiones de parche, sin funciones nuevas mezcladas, para que la actualización automática en modo parche pueda instalarlas solas.

Investigación de buena fe

No emprenderemos acciones legales contra una investigación realizada de buena fe en su propia instancia de sh0: sin acceder a datos ajenos, sin perturbar un servicio que no le pertenece y dejándonos un plazo razonable para corregir antes de cualquier publicación.

Recompensas

No hay recompensa en dinero en el lanzamiento: agradecemos públicamente a los investigadores en esta página, con su consentimiento. Un programa de recompensas podría llegar después de la prueba de intrusión externa.

Agradecimientos

Todavía no hemos recibido ningún informe. Los primeros nombres aparecerán aquí.

Avisos de seguridad

Los avisos publicados y un feed legible por máquina que el panel de sh0 consultará en cada comprobación de actualizaciones.

Seguridad de nivel empresarial, integrada

AES-256-GCM, Argon2id, TOTP 2FA, RBAC, registros de auditoría, limitación de tasa. Una seguridad que puede verificar en el código fuente, y fallas comunicadas según una política de divulgación pública.

Obtener sh0 Mira cómo funciona