Auditoria - SRARS

Por que esta página existe

Prometemos auditorias em dias, não em trimestres. Promessas precisam de provas, por isso esta página é nosso compromisso público: cada afirmação é respaldada por um artefato concreto do conjunto de evidências de auditoria da SRARS. Quando um dado ainda está sendo medido, deixamos isso claro — não publicamos estimativas como fatos.

Lista de verificação da auditoria

Todo sistema SRARS pode ser verificado com esta lista. Cada item corresponde a um artefato real e inspecionável — não a um documento escrito depois do ocorrido. Os artefatos abaixo são deste próprio site.

Modelo de dados explícito. O esquema completo são algumas migrações SQL legíveis: posts e mensagens de contato em 002_site_content.sql, usuários e sessões de admin em 003_admin_auth.sql. Cada coluna é nomeada, tipada e comentada.
Contratos tipados. Cada página é uma função Go gerada (Templ): um template que não compila é um build que não sai. Os dados fluem por structs simples — o handler preenche, o componente renderiza, nada é implícito.
Comportamento observável. A faixa de métricas no rodapé deste site é a amostra ao vivo: contagens de requisições e erros, percentis de latência, visitantes únicos e tempo de atividade, publicados pelo próprio servidor a cada cinco segundos.
Histórico completo de alterações. As migrações são somente-aditivas e registradas por nome em schema_migrations: qualquer estado do banco pode ser rastreado até a migração exata que o produziu. As escritas de admin são protegidas por sessão e validadas com CSRF.
Superfície de ataque mínima. A imagem de produção é construída FROM scratch: sem shell, sem gerenciador de pacotes, sem interpretador — um binário estático, certificados CA e dados de fuso horário, executando como não-root (uid 65532). Não há nada dentro do contêiner para explorar.
Builds reproduzíveis. Um único comando vai do código-fonte ao binário estático: make build (CGO desabilitado, caminho aparado, símbolos removidos). O mesmo comando produz o mesmo binário em qualquer máquina com o toolchain Go.

Tempo de verificação medido

A afirmação: uma auditoria completa de um sistema SRARS leva dias, não trimestres. Este site já passou por dois ciclos de verificação:

Revisão externa: uma revisão de segurança independente de todo o código, container e modelo de autenticação, por um revisor sem familiaridade prévia com o código — o pior caso para o tempo de auditoria. Escopo: injeção de SQL, XSS, CSP, hash de senhas, sessões, CSRF, limitação de taxa, confiança em headers de proxy, IDOR, endurecimento do container e versões de dependências. Resultado: zero achados críticos ou altos; três médios e dois baixos, todos corrigidos na mesma sessão. O relatório completo está no repositório (docs/SECURITY.md).
Ciclo de endurecimento em produção: uma segunda verificação no lançamento: o scan automatizado de vulnerabilidades (govulncheck) encontrou dez CVEs da biblioteca padrão — atualizado e re-escaneado para zero; a senha do admin foi rotacionada para um segredo de 256 bits com parâmetros argon2id endurecidos (128 MiB, duas passagens); a proteção de borda (HSTS preload, Cloudflare Access na superfície admin) foi adicionada e verificada ao vivo em todas as rotas admin.
Evidência de regressão: correções do dia do lançamento (um soft-404 no roteador que servia páginas com HTTP 200, uma versão de cache-bust desatualizada que prendia clientes a uma folha de estilo quebrada) estão cobertas por testes de regressão no repositório — a mesma classe de bug não pode retornar silenciosamente.

Os dois ciclos foram medidos em dias, não trimestres — a revisão externa em uma sessão, o endurecimento em uma tarde. O código é pequeno o suficiente para uma pessoa re-verificar de ponta a ponta em uma tarde. Essa é a promessa de auditoria, demonstrada.

O histórico de alterações

Toda mutação em um sistema SRARS é registrada: quem, o quê, quando e por quê. Neste site, o histórico é estrutural:

As alterações de esquema são migrações somente de acréscimo, registradas por nome — o próprio banco de dados é o log de alterações.
As alterações de conteúdo (posts, seções, projetos) passam pela área de administração: sessão Argon2id, token CSRF em cada escrita e IDs numéricos parseados.
As alterações de código ficam no controle de versão com os templates gerados confirmados — cada página renderizada remete à sua origem.

Execute por conta própria

A evidência de auditoria mais forte é um sistema que você pode inspecionar sem nossa presença. Sistemas SRARS são binários estáticos únicos com bancos de dados embarcados: clone, compile, execute e verifique.

Repositório público: github.com/WhoseBiasDoYallSeek/fgoths-framework — a estrutura que gera sistemas como este.
Comando de build: make build — um único comando do clone até um binário Linux estático em bin/app.
Roteiro de verificação: o modelo de dados está em database/migrations/*.sql; o relatório de segurança está em docs/SECURITY.md; a metodologia de design está em docs/DESIGN.md; os testes rodam com go test ./...