Governança, risco e compliance em português · gratuito, cadastro opcional
Entrar

Security by Design Prática de engenharia

31 controles, organizados por grupo, com resumo em português.

Fazer a avaliação

Segurança desde a concepção, e não como remendo no final. Reúne os princípios clássicos de design seguro (menor privilégio, defesa em profundidade, falhar em estado seguro) com o ciclo de vida do NIST SSDF: preparar a organização, proteger o software, produzir software bem protegido e responder a vulnerabilidades. Serve para avaliar como o time constrói, não só o que já está construído.

Fonte oficial · A cor indica o perfil em que cada controle entra: Básico Intermediário Avançado.

Prática de engenharia, não norma certificável. Estrutura baseada em fontes públicas (princípios de design seguro de Saltzer & Schroeder/OWASP e NIST SSDF SP 800-218), com texto próprio em português pela InfoCuestaSec. A codificação SBD.x.y e a divisão em perfis são didáticas e não correspondem à numeração oficial dessas fontes.

SBD.1 Princípios de design seguro

  • SBD.1.1
    Menor privilégio: cada usuário, serviço e componente recebe só o acesso de que precisa. Contas e serviços costumam nascer com mais poder do que precisam, e ninguém revisa depois. Dê o acesso mínimo e revise periodicamente — isso limita o estrago quando uma conta é comprometida. Exemplo: O serviço do site conecta no banco com um usuário que é dono de tudo; uma falha de injeção que devia expor uma tabela acaba permitindo apagar o banco inteiro.
    Básico
  • SBD.1.2
    Padrão seguro: a configuração de fábrica já é a segura; endurecer não pode ser opcional. Se a opção segura exige que alguém lembre de ligar, uma hora não vai ser ligada. O sistema deve já vir seguro, e afrouxar é que deve ser uma decisão consciente. Exemplo: O produto é entregue com TLS desligado e uma nota no manual dizendo 'recomendamos ativar' — metade das instalações fica em texto claro para sempre.
    Básico
  • SBD.1.3
    Falhar em estado seguro: quando algo dá errado, o sistema nega o acesso em vez de liberar. Quando um controle falha ou fica indisponível, a resposta correta é negar. Sistemas que liberam o acesso ao falhar (fail-open) entregam a porta justamente no pior momento. Exemplo: O servidor de autorização fica fora do ar e a aplicação, sem resposta, decide liberar o acesso 'para não travar o negócio' — a indisponibilidade virou porta aberta.
    Básico
  • SBD.1.4
    Defesa em profundidade: mais de uma camada de controle, para que uma falha não derrube tudo. Nenhum controle é perfeito, então não dependa de um só. Camadas independentes fazem com que a falha de uma não signifique invasão. Exemplo: A única proteção do painel é ele estar numa URL secreta; quando o endereço aparece num log de referer, não sobra nenhuma outra camada.
    Intermediário
  • SBD.1.5
    Superfície de ataque mínima: só expor a funcionalidade, porta e permissão realmente necessárias. Cada funcionalidade, porta e permissão a mais é uma porta a mais para atacar. O que não existe não pode ser explorado. Exemplo: O container sobe com um servidor de debug na porta 8000 que ninguém usa há dois anos — e é por ele que o atacante entra.
    Intermediário
  • SBD.1.6
    Simplicidade: design simples e auditável; complexidade esconde falha. Design complexo esconde falha e ninguém consegue auditar de verdade. Prefira o simples, que dá para revisar e entender inteiro. Exemplo: A regra de permissão tem seis flags que se sobrepõem; ninguém no time sabe dizer quem enxerga o quê, e uma combinação libera dado de outro cliente.
    Intermediário
  • SBD.1.7
    Segregação de funções: nenhuma pessoa concentra todas as etapas de uma operação crítica. Quem pede não aprova, quem desenvolve não sobe para produção sozinho. Separar as etapas evita que uma pessoa (ou uma conta invadida) execute a fraude do início ao fim. Exemplo: O mesmo desenvolvedor cria o fornecedor, aprova o pagamento e sobe a alteração para produção — sozinho, ele fecha o ciclo inteiro de uma fraude.
    Avançado
  • SBD.1.8
    Sem segurança por obscuridade: o sistema resiste mesmo se o atacante conhecer o design. Esconder o design não é controle: o atacante descobre por engenharia reversa ou vazamento. A segurança tem que estar na chave e no controle, não no segredo do funcionamento. Exemplo: A API 'protege' o endpoint interno só por ele não estar documentado; um scanner de rotas encontra em minutos.
    Avançado

SBD.2 Preparar a organização (SSDF PO)

  • SBD.2.1
    Requisitos de segurança definidos antes de construir, junto com os requisitos funcionais. Segurança tratada como requisito no início custa barato; virada de arquitetura depois de pronto custa caro e às vezes não acontece. Escreva os requisitos de segurança junto com os funcionais. Exemplo: O sistema é construído sem requisito de trilha de auditoria; na primeira investigação, descobre-se que não dá para saber quem alterou o registro — e agora é reescrever.
    Básico
  • SBD.2.2
    Papéis e responsabilidades de segurança definidos para o time de desenvolvimento. Quando segurança é responsabilidade de todos de forma vaga, não é de ninguém na prática. Defina quem decide, quem revisa e quem responde. Exemplo: Todo mundo acha que a revisão de segurança é do outro time; o release sobe sem ninguém ter olhado.
    Básico
  • SBD.2.3
    Time treinado em desenvolvimento seguro, com reciclagem periódica. Não dá para exigir do time uma prática que ele nunca aprendeu. Treinamento periódico é o que sustenta o resto dos controles. Exemplo: O time nunca ouviu falar de consulta parametrizada e segue concatenando SQL porque 'sempre funcionou assim'.
    Intermediário
  • SBD.2.4
    Padrões e bibliotecas seguras aprovadas, para o time não reinventar controle crítico. Controle crítico feito à mão (criptografia, autenticação, sessão) costuma sair errado. Ofereça bibliotecas e padrões aprovados, para o caminho fácil ser o caminho seguro. Exemplo: Cada squad implementou seu próprio hash de senha: um usa bcrypt, outro usa SHA1 puro, e ninguém sabia que era para padronizar.
    Intermediário
  • SBD.2.5
    Critérios de aceite de segurança que barram a entrega quando não são atendidos. Critério de aceite que nunca barra nada é decoração. Defina o que impede a entrega e sustente a decisão. Exemplo: O critério diz 'sem vulnerabilidade alta', mas a entrega sobe com três altas em aberto porque a data era mais importante — o critério nunca barrou nada.
    Avançado

SBD.3 Proteger o software (SSDF PS)

  • SBD.3.1
    Código-fonte com acesso controlado e alterações rastreáveis. O código é o ativo: quem acessa e o que mudou precisa ser rastreável. Sem isso, uma alteração maliciosa passa sem deixar rastro. Exemplo: O repositório é aberto para toda a empresa com permissão de escrita; uma alteração maliciosa entra sem revisão e sem dono identificável.
    Básico
  • SBD.3.2
    Integridade das entregas: artefatos assinados ou com hash verificável. Sem assinatura ou hash, ninguém consegue provar que o que está em produção é o que foi testado. Verificar integridade fecha a porta da troca de artefato. Exemplo: O artefato é baixado de um servidor de arquivos sem hash; ninguém percebe que o binário em produção não é o que saiu do build.
    Intermediário
  • SBD.3.3
    Segredos fora do código: chaves e senhas em cofre, nunca no repositório. Segredo commitado no repositório vaza — em fork, em backup, no histórico que ninguém limpa. Use cofre e rotacione o que já foi exposto. Exemplo: A chave da API foi commitada, o repositório virou público por engano e o histórico do git guarda a chave mesmo depois do commit que a removeu.
    Intermediário
  • SBD.3.4
    Proveniência do build registrada, permitindo saber de onde veio cada artefato. Registrar de onde veio cada artefato (fonte, build, dependência) é o que permite responder rápido quando um componente se revela comprometido. Exemplo: Um pacote é anunciado como comprometido e o time passa uma semana sem conseguir responder se aquele pacote estava ou não em produção.
    Avançado

SBD.4 Produzir software bem protegido (SSDF PW)

  • SBD.4.1
    Modelagem de ameaças no design, antes de codificar (o que pode dar errado e quem atacaria). Modelagem de ameaças é sentar antes de codificar e perguntar o que pode dar errado e quem atacaria. É a prática que mais evita falha de design, que é a mais cara de corrigir. Exemplo: Ninguém se perguntou o que aconteceria se dois pedidos chegassem ao mesmo tempo; a corrida no saldo só aparece em produção, explorada.
    Intermediário
  • SBD.4.2
    Validação de entrada no servidor, tratando todo dado externo como não confiável. Validação só na tela não vale nada: o atacante fala direto com a API. Todo dado externo é hostil até ser validado no servidor. Exemplo: A validação de CPF está só no JavaScript da tela; quem chama a API direto cadastra o que quiser.
    Básico
  • SBD.4.3
    Autenticação e controle de acesso verificados no servidor, a cada requisição. A permissão precisa ser conferida no servidor, a cada requisição, e não deduzida do que a interface mostrou. Esconder o botão não impede ninguém de chamar a rota. Exemplo: O botão de excluir é escondido para quem não é admin, mas a rota DELETE responde para qualquer usuário logado.
    Básico
  • SBD.4.4
    Dados sensíveis protegidos em trânsito e em repouso, com criptografia forte. Dado sensível trafega e descansa em lugares que você não controla. Criptografia forte em trânsito e em repouso é o que sobra de proteção quando o resto falha. Exemplo: O backup do banco fica num bucket sem criptografia e sem restrição; o vazamento não vem da aplicação, vem do backup.
    Básico
  • SBD.4.5
    Tratamento de erro que não vaza detalhe interno nem deixa o sistema em estado inconsistente. Erro mal tratado vaza caminho de arquivo e versão para o atacante, ou pior, deixa a transação pela metade. Trate na origem, feche em estado seguro e reverta por completo. Exemplo: A tela de erro mostra o stack trace com o caminho dos arquivos e a versão do banco, entregando o mapa para o atacante.
    Intermediário
  • SBD.4.6
    Revisão de código com olhar de segurança antes do merge. Revisão com olhar de segurança pega o que o teste automático não pega — decisão de lógica e de confiança. Faça antes do merge, quando ainda é barato. Exemplo: O merge passou porque os testes ficaram verdes; ninguém reparou que a nova rota não checa o dono do registro.
    Intermediário
  • SBD.4.7
    Dependências inventariadas e atualizadas, com origem confiável. A maior parte do seu software é de terceiros. Sem inventário e atualização, você herda a vulnerabilidade sem nem saber que a tem. Exemplo: A aplicação depende de uma biblioteca abandonada há quatro anos, com CVE conhecida e exploit público, e ninguém sabia que ela estava lá.
    Intermediário
  • SBD.4.8
    Privacidade desde o design: coletar o mínimo, definir retenção e permitir exclusão. Dado que você não coletou não vaza. Defina o mínimo necessário, o prazo de retenção e como excluir — e desenhe isso no início, não como remendo. Exemplo: O cadastro pede data de nascimento e CPF 'porque pode ser útil um dia'; no vazamento, é exatamente esse dado que vira problema de LGPD.
    Avançado
  • SBD.4.9
    Logs de eventos de segurança desenhados junto com a funcionalidade, não depois. Log de segurança pensado depois sai incompleto e sem o contexto que a investigação precisa. Decida o que registrar junto com a funcionalidade. Exemplo: Houve um acesso indevido, mas o log só registra 'erro 500' sem usuário, sem IP e sem horário útil — a investigação morre aí.
    Avançado

SBD.5 Responder a vulnerabilidades (SSDF RV)

  • SBD.5.1
    Correção de vulnerabilidade com prazo definido por severidade. Vulnerabilidade conhecida e sem prazo de correção vira dívida permanente. Amarre o prazo à severidade e acompanhe o cumprimento. Exemplo: Uma falha crítica é registrada no backlog como 'melhoria' e fica dezoito meses aberta, sem prazo e sem dono.
    Básico
  • SBD.5.2
    Testes de segurança automatizados no pipeline (SAST/DAST/dependências). Teste automatizado no pipeline pega o erro repetitivo cedo e barato, liberando o time para o que exige análise humana. Não substitui revisão, complementa. Exemplo: O scanner de dependência só roda quando alguém lembra; a versão vulnerável fica meses em produção sem ninguém ver.
    Intermediário
  • SBD.5.3
    Canal para receber report de vulnerabilidade de fora da organização. Quem acha uma falha no seu sistema precisa de um lugar óbvio para avisar. Sem canal, o achado vira post público ou vai para quem paga mais. Exemplo: Um pesquisador acha uma falha, não encontra e-mail de contato, tenta pelo comercial, não é respondido e publica o achado sem aviso.
    Intermediário
  • SBD.5.4
    Análise de causa raiz: corrigir a classe do problema, não só a ocorrência. Corrigir só a ocorrência faz a mesma falha voltar em outro lugar. Pergunte por que a classe do problema foi possível e trate a causa. Exemplo: A injeção foi corrigida naquele endpoint específico; três meses depois, a mesma falha aparece em outro, porque a causa (concatenar SQL) nunca foi tratada.
    Avançado
  • SBD.5.5
    Teste de intrusão periódico em mudanças relevantes de arquitetura. Mudança relevante de arquitetura muda a superfície de ataque. Teste de intrusão periódico valida na prática o que o design assumiu na teoria. Exemplo: A empresa migrou para microserviços e só testou a segurança um ano depois — o barramento interno estava aberto desde o primeiro dia.
    Avançado