Segurança não é um recurso.
É a fundação.
Cada afirmação desta página corresponde a código real do sh0. Uma auditoria interna de 17 de março de 2026 encontrou 34 problemas; os 6 críticos estavam corrigidos na data do relatório.
Resultados da auditoria
Auditoria de segurança interna de autenticação, criptografia, superfície de API e interface.
Auditoria interna de 17 de março de 2026: 34 problemas encontrados (6 críticos, 10 altos, 12 médios, 6 baixos). Na data do relatório, os 6 críticos e 8 dos 10 altos estavam corrigidos; os demais estavam previstos para uma fase de reforço. A partir de 5 de outubro de 2026, as falhas corrigidas são publicadas aqui.
O que protegemos
Seis camadas de segurança centrais, cada uma verificada no código-fonte Rust.
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.
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.
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.
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.
RBAC & Project Permissions
Owner, Admin, Developer, Viewer roles with per-project membership. Dedicated extractors (AuthUser, AdminUser, ProjectAccess) verify authorization on every API endpoint.
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.
Defesa em profundidade
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.
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.
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.
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.
O stack de segurança
Cada camada reforça a próxima -- comprometa uma e as demais ainda se mantêm
Dependências criptográficas
Sem criptografia customizada. Apenas crates Rust testados em batalha.
Verificado no código-fonte
Cada descoberta mapeada para o crate onde é implementada.
Sem 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
Com 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
Perguntas e respostas
O sh0 passou por auditoria de segurança? +
How are secrets stored? +
How does authentication work? +
What about two-factor authentication? +
Can one user access another user's containers? +
What about container security? +
Quem responde pela segurança dos templates de um clique? +
Which cryptographic libraries do you use? +
Relatar uma vulnerabilidade
Escreva para o endereço abaixo. Informe a versão do sh0, os passos para reproduzir e o impacto observado. Não abra uma issue pública.
Sem resposta, use também o formulário de contato: sh0.dev/contact
Nossos compromissos
- Confirmação de recebimento em até 72 horas.
- Correção prevista em 7 dias para uma falha crítica, 30 dias para uma alta e 90 dias nos demais casos.
- Para falhas críticas e altas, um pré-aviso de 48 a 72 horas antes da correção: apenas data, gravidade e componente. Os detalhes são publicados com a correção.
- As correções de segurança sairão como versões de patch, sem novas funcionalidades misturadas, para que a atualização automática em modo patch possa instalá-las sozinhas.
Pesquisa de boa-fé
Não tomaremos medidas legais contra pesquisas feitas de boa-fé na sua própria instância do sh0: sem acesso a dados de terceiros, sem interromper um serviço que não é seu e dando-nos um prazo razoável para corrigir antes de qualquer publicação.
Recompensas
Não há recompensa em dinheiro no lançamento: agradecemos publicamente aos pesquisadores nesta página, com o consentimento deles. Um programa de recompensas poderá vir após o teste de intrusão externo.
Agradecimentos
Nenhum relato recebido até agora. Os primeiros nomes aparecerão aqui.
Avisos de segurança
Os avisos publicados e um feed legível por máquina que o painel do sh0 consultará a cada verificação de atualização.
Segurança de nível enterprise, integrada
AES-256-GCM, Argon2id, TOTP 2FA, RBAC, logs de auditoria, limitação de taxa. Uma segurança que você pode verificar no código-fonte, e falhas relatadas segundo uma política de divulgação pública.