Security by Design: princípios, abordagens e como aplicar no desenvolvimento seguro

Introdução

Security by Design é a abordagem de engenharia de software que incorpora requisitos e controles de segurança desde a concepcao de um sistema, em vez de trata-los como complemento após a entrega. A premissa é direta: corrigir vulnerabilidades em produção custa entre 30 e 100 vezes mais do que preveni-las durante o design. Apesar disso, a maioria das organizações ainda opera no modelo reativo, descobre falhas depois que o código já está em execução, frequentemente por meio de incidentes reais.

O conceito não é novo. O NIST já articulava princípios de segurança em design de sistemas na década de 1970. Frameworks como OWASP SAMM, Microsoft SDL é o pledge CISA Secure by Design (2023) consolidaram a abordagem como prática esperada para qualquer organização que desenvolva ou opere software.

Para o analista de segurança que atua em programas de Continuous Threat Exposure Management (CTEM), Security by Design é o ponto em que prevencion e validação se encontram. Este artigo detalha os princípios fundamentais, mostra como implementa-los em cada fase do SDLC, aborda os drivers regulatórios (LGPD, GDPR), identifica anti-padrões comuns e explica como testes continuos, especialmente DAST via WebAppScan da EcoTrust, válidam se a segurança projetada está de fato funcionando em produção.

---

O que é Security by Design, definição e origem

Leia também: OWASP Top 10 (2025): as vulnerabilidades mais críticas em...

Security by Design é a disciplina de projetar sistemas, aplicações e infraestrutura de modo que a segurança seja um atributo arquitetural, integrado desde os requisitos iniciais até a operação contínua, e não uma camada adicionada posteriormente.

A abordagem se contrapoe ao modelo histórico de "build first, secure later", no qual equipes de desenvolvimento entregam funcionalidades e equipes de segurança tentam remediar vulnerabilidades depois, frequentemente com custos elevados e janelas de exposição prolongadas.

Marcos históricos

• 1975, Saltzer e Schroeder (NIST/MIT): Públicaram os princípios fundamentais de proteção de informação em sistemas computacionais, incluindo menor privilegio e mediação completa.
• 2004, Microsoft SDL: Formalizou o Security Development Lifecycle, institucionalizado segurança no processo de desenvolvimento.
• 2008, OWASP SAMM: Framework aberto para avaliar e melhorar práticas de segurança em desenvolvimento de software.
• 2020, NIST SP 800-160 Vol. 1 Rev. 1: Reafirmou que segurança deve ser uma propriedade emergente do design do sistema.
• 2023, CISA Secure by Design Pledge: Compromisso público para que fabricantes adotem práticas de Security by Design, incluindo eliminação de senhas padrão, adoção de MFA e redução de classes inteiras de vulnerabilidades.

---

Os 5 princípios fundamentais do Security by Design

Leia também: DevSecOps: o que é, pilares e como implementar segurança ...

A seguir, os cinco princípios que formam a base de qualquer implementação de Security by Design. Cada um deles deve ser considerado como requisito arquitetural, não como recomendação opcional.

Princípio 1, Menor privilegio (Least Privilege)

Cada componente, usuário, serviço ou processo deve operar com o conjunto mínimo de permissões necessário para executar sua função. Nenhuma permissão adicional deve ser concedida "por conveniencia" ou "por precaução".

Na prática: contas de serviço de aplicações web devem ter acesso somente as tabelas de banco de dados que utilizam, e somente com as operações necessárias (SELECT, INSERT), nunca com permissões de administrador do banco.

Princípio 2, Defesa em profundidade (Defense in Depth)

Nenhum controle único é suficiente. A segurança deve ser implementada em múltiplas camadas independentes, de modo que a falha de um controle não comprometa todo o sistema.

Na prática: uma aplicação web deve combinar validação de entrada no frontend, validação no backend, prepared statements no banco de dados, WAF na borda e monitoramento de anomaliás, cada camada protege contra cenários diferentes e complementa as demais.

Princípio 3, Falha segura (Fail Secure)

Quando um sistema falha, ele deve falhar em um estado seguro. Erros não devem expor dados sensíveis, conceder acesso indevido ou revelar informações internas da arquitetura.

Na prática: se o serviço de autorização de uma aplicação estiver indisponível, o comportamento padrão deve ser negar acesso (deny by default), e não permitir acesso irrestrito. Mensagens de erro devem ser genéricas para o usuário e detalhadas apenas em logs internos.

Princípio 4, Separação de funções (Separation of Duties)

Funções críticas devem exigir a participação de mais de uma entidade ou processo. Nenhum usuário ou componente individual deve ter controle total sobre uma operação sensível.

Na prática: o desenvolvedor que escreve o código não deve ser o mesmo que aprova o merge em produção. Transações financeiras acima de um determinado valor devem exigir dupla aprovação. Chaves criptográficas devem ser gerenciadas por serviços dedicados (KMS), não embutidas no código.

Princípio 5, Zero Trust

Nenhuma entidade, interna ou externa, deve ser considerada confiável por padrão. Toda requisição deve ser autenticada, autorizada e válidada, independentemente de sua origem na rede.

Na prática: mesmo serviços internos que se comunicam dentro da mesma VPC devem utilizar autenticação mutua (mTLS). Tokens de acesso devem ter escopo limitado e tempo de expiração curto. A posição na rede não substitui a verificação de identidade.

---

Comparação: abordagem reativa vs. proativa (Security by Design)

---

Implementação por fase do SDLC

Security by Design não é uma atividade pontual. Ele se manifesta como práticas específicas em cada fase do ciclo de desenvolvimento de software.

Fase 1, Requisitos

• Definir requisitos de segurança junto com requisitos funcionais (abuse cases, security user stories).
• Classificar dados que o sistema processara (dados pessoais, dados financeiros, PII) conforme LGPD e políticas internas.
• Estabelecer critérios de aceitação de segurança: "nenhuma vulnerabilidade crítica ou alta pode existir em produção".

Fase 2, Design e arquitetura

• Conduzir sessões de threat modeling (ver seção dedicada abaixo).
• Selecionar padrões arquiteturais seguros: autenticação centralizada, gerenciamento de segredos via cofre, comunicação criptografada entre serviços.
• Documentar decisões de segurança em ADRs (Architecture Decision Records).

Fase 3, Implementação

• Aplicar guidelines de codificação segura (OWASP Secure Coding Practices).
• Utilizar SAST (Static Application Security Testing) integrado ao IDE e ao pipeline para detectar vulnerabilidades no código antes do commit.
• Realizar code review com checklist de segurança.

Fase 4, Testes

• Executar DAST autenticado com o módulo WebAppScan da EcoTrust para validar a aplicação em tempo de execução.
• Executar SCA (Software Composition Analysis) para identificar vulnerabilidades em dependências de terceiros.
• Conduzir testes de penetração manuais para cenários de lógica de negócio que ferramentas automatizadas não cobrem.

Fase 5, Deploy e operação

• Válidar configurações de infraestrutura com VulScan da EcoTrust para garantir que servidores, containers e serviços de nuvem não possuam vulnerabilidades conhecidas.
• Monitorar continuamente a superfície de ataque com escaneamento periódico.
• Manter um processo estruturado de gestão de vulnerabilidades para priorizar e remediar achados com base em risco real.

Fase 6, Descontinuação

• Garantir destruição segura de dados armazenados.
• Revogar credenciais, certificados e acessos associados ao sistema descontinuado.
• Documentar licoes aprendidas para alimentar requisitos de segurança de projetos futuros.

---

Checklist de implementação de Security by Design

Use está lista para avaliar a maturidade da sua organização:

1. Requisitos de segurança são documentados junto com requisitos funcionais.
2. Threat modeling e conduzido para novas funcionalidades e mudanças arquiteturais.
3. Dados são classificados por sensibilidade antes do design do banco de dados.
4. Padrões de codificação segura são definidos e verificados via SAST no pipeline.
5. Dependências de terceiros são escaneadas por SCA em cada build.
6. DAST autenticado e executado em ambiente de homologação antes de cada release.
7. Infraestrutura e escaneada periodicamente por ferramentas de vulnerability assessment.
8. Vulnerabilidades críticas e altas bloqueiam o deploy automaticamente (quality gate).
9. Segredos (chaves, tokens, senhas) são gerenciados via cofre, nunca em código.
10. Incidentes de segurança alimentam retroativamente os requisitos e o threat model.
11. Métricas de segurança (MTTR, densidade de vulnerabilidades, cobertura de scan) são acompanhadas pela liderança.
12. Conformidade com LGPD Art. 46 e demais regulamentos e evidênciada com relatórios de scan e remediações.

---

Threat modeling: a prática central do Security by Design

Threat modeling é o exercício estruturado de identificar ameaças, vetores de ataque e controles necessários para um sistema antes que ele seja construido, ou quando mudanças significativas são introduzidas.

Metodologias principais

• STRIDE (Microsoft): Classifica ameaças em seis categorias, Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service e Elevation of Privilege.
• PASTA: Abordagem de sete etapas orientada a risco de negócio, conectando ameaças técnicas a impactos organizacionais.
• LINDDUN: Focado em ameaças a privacidade, complementar ao STRIDE para cenários de LGPD ou GDPR.

Como conduzir na prática

1. Desenhar o diagrama de fluxo de dados (DFD) do sistema.
2. Identificar limites de confiança (trust boundaries).
3. Aplicar a metodologia escolhida a cada componente e fluxo.
4. Classificar cada ameaça por probabilidade e impacto.
5. Definir controles mitigadores para cada ameaça relevante.
6. Válidar se os controles estão implementados via DAST, SAST e testes de infraestrutura.

---

Drivers regulatórios: LGPD e GDPR exigem Security by Design

LGPD, Art. 46

O Art. 46 da Lei Geral de Proteção de Dados (Lei 13.709/2018) determina que "os agentes de tratamento devem adotar medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais". O paragrafo primeiro vai além: essas medidas devem ser observadas "desde a fase de concepcao do produto ou serviço até a sua execução". Isso é, literalmente, Security by Design na legislação brasileira.

Organizações que não evidenciam controles preventivos de segurança, como threat modeling, testes DAST/SAST, gestão de vulnerabilidades e criptografia adequada, enfrentam risco regulatório concreto perante a ANPD, além de responsabilidade civil em caso de incidentes com dados pessoais.

GDPR, Art. 25 (Data Protection by Design and by Default)

O Art. 25 do GDPR exige "data protection by design and by default", obrigando controladores a implementar medidas técnicas e organizacionais adequadas desde o início do processamento. Para organizações brasileiras que processam dados de residentes da UE, o GDPR se aplica extraterritorialmente.

Implicações práticas para o analista

• Manter evidências de testes de segurança regulares (relatórios DAST é de infraestrutura).
• Documentar threat modeling e decisões de mitigação.
• Demonstrar que vulnerabilidades críticas são tratadas dentro de SLAs, utilizando plataformas de gestão de vulnerabilidades com ciclo completo de descoberta, priorização e remediação.

---

Anti-padrões comuns: o que não fazer

Reconhecer anti-padrões e tao importante quanto conhecer as boas práticas. A seguir, os erros mais frequentes que comprometem iniciativas de Security by Design.

1. Security as a checkbox. Tratar segurança como item de auditoria sem integração real ao desenvolvimento. Documentos que não refletem a realidade do sistema.

2. Segurança apenas no perímetro. Confiar exclusivamente em firewalls e WAFs. Quando o perímetro e comprometido, não há controles internos para conter o atacante.

3. Scan único antes do go-live. Executar um scan antes do lançamento e nunca mais testar. Aplicações mudam; vulnerabilidades surgem diariamente. Testes devem ser continuos.

4. Ignorar dependências de terceiros. Focar no código próprio sem monitorar bibliotecas. Log4Shell (CVE-2021-44228) demonstrou que a cadeia de suprimentos e vetor crítico.

5. Segredos no código-fonte. Armazenar chaves de API e senhas no repositório. Um vazamento compromete toda a infraestrutura.

6. Assumir que a rede interna e segura. Operar sem autenticação entre serviços internos viola zero trust e fácilita movimentação lateral.

7. Tratar segurança como responsabilidade exclusiva de um time. Quando apenas o time de segurança "cuida" de vulnerabilidades, desenvolvedores não incorporam práticas seguras e o backlog cresce indefinidamente.

---

O papel dos testes continuos: DAST e SAST como validação do design

Security by Design define a intenção. Testes continuos válidam se a intenção foi materializada corretamente. Sem validação, princípios de segurança são apenas documentos.

SAST, validação estática

SAST analisa o código-fonte sem executa-lo, identificando padrões vulneráveis como SQL Injection por concatenação de strings, uso de funções criptográficas obsoletas e ausência de validação de entrada. E mais eficaz quando integrado ao IDE do desenvolvedor e ao pipeline de CI.

DAST, validação dinâmica

DAST testa a aplicação em execução, simulando um atacante real. Válida se os controles projetados funcionam quando a aplicação recebe requisições maliciosas. Identifica falhas que SAST não detecta: configuração de servidor, autenticação e autorização em runtime, headers ausentes e vulnerabilidades que só se manifestam em execução.

O módulo WebAppScan da EcoTrust executa DAST autenticado, testando fluxos completos incluindo áreas protegidas por login. Cada vulnerabilidade inclui evidência técnica com request/response, classificação por severidade, mapeamento OWASP Top 10 e sugestão de correção.

A combinação SAST + DAST

SAST válida o código; DAST válida o comportamento. Security by Design exige ambos: o primeiro para garantir que o código segue padrões seguros, o segundo para confirmar que a aplicação se comporta de forma segura quando exposta a ataques reais.

---

Como a EcoTrust válida a postura de Security by Design

A EcoTrust é uma plataforma de IA Agêntica para Continuous Threat Exposure Management (CTEM) que conecta as diferentes fases de validação de segurança em um fluxo unificado.

WebAppScan, validação DAST de aplicações

O módulo WebAppScan executa testes DAST autenticados e não autenticados, gerando evidências técnicas completas para cada vulnerabilidade. Para equipes que praticam Security by Design, o WebAppScan funciona como o ponto de verificação que confirma se os controles projetados estão efetivamente protegendo a aplicação em tempo de execução.

VulScan, validação de infraestrutura

O módulo VulScan escaneia servidores, containers e serviços de nuvem para identificar vulnerabilidades de infraestrutura. Security by Design não se limita ao código da aplicação, a infraestrutura subjacente também precisa ser projetada e mantida com segurança.

Gestão de Vulnerabilidades, priorização por risco

O módulo de Gestão de Vulnerabilidades consolida achados de WebAppScan, VulScan e outras fontes, prioriza por risco real (considerando explorabilidade, criticidade do ativo e contexto de negócio) e acompanha o ciclo de remediação. Esse fluxo fecha o loop do Security by Design: o que foi projetado e válidado continuamente, e desvios são identificados e corrigidos com base em prioridade de risco.

A combinação WebAppScan + VulScan + Gestão de Vulnerabilidades na plataforma EcoTrust oferece a validação contínua que Security by Design exige, como processo permanente integrado ao CTEM.

Conheça o WebAppScan e valide se sua aplicação está realmente segura por design

---

Perguntas frequentes (FAQ)

O que é Security by Design?

Security by Design e a abordagem de engenharia que incorpora requisitos e controles de segurança desde a fase de concepcao de um sistema, garantindo que a segurança seja um atributo arquitetural e não um complemento posterior. Os princípios fundamentais incluem menor privilegio, defesa em profundidade, falha segura, separação de funções e zero trust.

Qual a diferença entre Security by Design e Security by Default?

Security by Design refere-se a incorporar segurança durante o projeto e desenvolvimento do sistema. Security by Default significa que o sistema, quando entregue ao usuário, já vem configurado com as opções mais seguras habilitadas, sem exigir que o usuário faca ajustes para atingir um nível básico de proteção. São conceitos complementares.

A LGPD exige Security by Design?

Sim. O Art. 46, paragrafo 1o da LGPD determina que medidas de segurança devem ser observadas "desde a fase de concepcao do produto ou do serviço até a sua execução". Organizações que processam dados pessoais devem evidenciar que adotam práticas preventivas de segurança, incluindo threat modeling, testes de segurança continuos e gestão de vulnerabilidades.

Qual a relação entre Security by Design e o CISA Secure by Design Pledge?

O pledge da CISA (2023) é um compromisso público de fabricantes de software para adotar práticas de Security by Design. Ele inclui metas concretas como eliminar senhas padrão, adotar MFA, reduzir classes inteiras de vulnerabilidades (como SQL Injection) e aumentar a instalação de patches de segurança pelos clientes. O pledge operacionaliza os princípios de Security by Design em ações mensuráveis.

Como validar se minha organização está aplicando Security by Design?

A validação passa por três pilares: (1) evidência de que requisitos de segurança é threat modeling são realizados antes do desenvolvimento; (2) execução de testes SAST e DAST no pipeline de CI/CD; e (3) gestão contínua de vulnerabilidades com priorização por risco e SLAs de remediação. Ferramentas como o WebAppScan é o VulScan da EcoTrust fornecem as evidências técnicas necessárias para essa validação.

Security by Design elimina a necessidade de testes de segurança?

Não. Security by Design reduz vulnerabilidades, mas erros de implementação, mudanças em dependências e novos vetores de ataque exigem validação contínua. DAST, SAST e pentests continuam essenciais.

---

Para aprofundamento, consulte a referência oficial: Gartner — How to Manage Cybersecurity Threats.

Conclusão

Security by Design não é um framework pontual, mas uma mudança de mentalidade em todas as fases do desenvolvimento e operação. Os princípios, menor privilegio, defesa em profundidade, falha segura, separação de funções e zero trust, são a base. Threat modeling traduz esses princípios em controles concretos. LGPD e GDPR transformaram a abordagem em obrigação legal.

Princípios sem validação são apenas intencoes. A diferença entre declarar e praticar Security by Design está na capacidade de testar continuamente e corrigir com agilidade.

A EcoTrust, como plataforma de IA Agêntica para CTEM, oferece exatamente essa capacidade de validação contínua: WebAppScan para aplicações, VulScan para infraestrutura e Gestão de Vulnerabilidades para fechar o ciclo de priorização e remediação.

Solicite uma demonstração da EcoTrust e valide sua postura de Security by Design com evidências reais