Desenvolvimento seguro: SDL, STRIDE, gestão de segredos

A ideia que organiza o assunto

A tentação natural é tratar segurança como uma etapa: constrói-se o software e, antes de publicar, alguém testa. Todo o assunto existe porque isso não funciona. A falha de segurança quase nunca nasce no teste — nasce numa decisão de arquitetura tomada meses antes, num requisito que ninguém escreveu, numa credencial que alguém colou no repositório. Um teste no fim encontra o sintoma quando o custo de corrigir já é máximo, e não encontra nada do que foi decidido errado lá atrás.

Daí a ideia que organiza tudo: o ciclo de desenvolvimento seguro não acrescenta uma fase; acrescenta uma atividade de segurança dentro de cada fase que já existia. Treinamento antes, requisitos de segurança junto dos requisitos funcionais, modelagem de ameaças no design, padrão de codificação e análise estática na implementação, teste dinâmico e revisão da superfície de ataque na verificação, plano de resposta a incidentes no lançamento, e resposta de fato quando a vulnerabilidade aparece em produção.

Por isso, diante de qualquer item do tópico, faça uma pergunta só: em que fase isso entra? A banca raramente inventa uma atividade que não existe; ela pega uma atividade verdadeira e a coloca na fase vizinha. Modelagem de ameaças é design, não requisitos. Revisão de código é implementação, não design. Análise estática é implementação, não “teste final”.

A segunda metade do tópico é nomenclatura institucional, e cai por confusão de siglas. Guarde os quatro nomes pelo que cada um é: o SDL da Microsoft é um ciclo com fases; o SSDF do NIST é um conjunto de práticas agrupadas em quatro famílias; o CLASP da OWASP é um processo organizado por papéis; o SSE-CMM é um modelo de maturidade — ele não diz o que fazer, mede o quanto a organização já sabe fazer. E o STRIDE não é nada disso: é uma taxonomia de ameaças usada dentro da modelagem de ameaças.

Por que se usa (e o que custa)

O argumento é econômico antes de ser técnico. O custo de corrigir um defeito cresce a cada fase que ele atravessa sem ser visto: mudar um diagrama custa uma reunião, mudar código custa uma sprint, mudar software em produção custa rollback, incidente, comunicação e, no setor financeiro, sanção. Shift-left é isso e apenas isso — antecipar a descoberta para a fase mais barata.

O que se paga é atrito. Modelagem de ameaças exige tempo de gente cara antes de existir uma linha de código. Análise estática no pipeline interrompe entregas e produz falsos positivos que alguém precisa triar. Padrões de codificação e ferramentas aprovadas restringem a liberdade do desenvolvedor. Gestão de segredos troca a conveniência de uma senha no arquivo de configuração por um cofre, uma rotação e um procedimento.

Há uma consequência que a banca explora: como o custo aparece em todas as fases, um SSDLC afeta todas as fases — não existe etapa do processo que fique intacta. E como nenhum controle isolado resolve, nenhuma ferramenta, por melhor que seja, dispensa as demais. Item que oferece um atalho — “usar framework que valida entradas dispensa testes”, “basta testar no fim” — está errado por construção.

Como funciona

O SDL da Microsoft, fase a fase. Treinamento (a equipe precisa saber o que evitar); requisitos (definem-se requisitos de segurança e privacidade, níveis de qualidade e barras de erro); design (modelagem de ameaças e requisitos de projeto, análise da superfície de ataque); implementação (ferramentas aprovadas, funções inseguras banidas, análise estática e revisão de código); verificação (análise dinâmica, fuzzing, revisão da superfície de ataque); lançamento (plano de resposta a incidentes, revisão final de segurança, arquivamento da versão); resposta (execução do plano quando a falha aparece). O SDL atual da Microsoft é publicado como um conjunto de práticas em vez de uma cascata rígida, e inclui coisas que a prova cobra diretamente: autenticação multifator, padrões criptográficos definidos, gestão do risco de terceiros e princípios de Zero Trust — presumir que o ambiente já está comprometido, verificar explicitamente cada acesso e conceder o menor privilégio a cada usuário, a cada identidade de serviço e a cada componente.

A modelagem de ameaças e o STRIDE. Modelar ameaças é olhar o sistema do ponto de vista de quem o ataca: desenha-se o fluxo de dados, marcam-se as fronteiras de confiança e, em cada ponto de travessia, pergunta-se o que pode dar errado. Ela se aplica ao sistema inteiro ou a um componente, e serve para escolher os recursos de segurança que valem o custo. O STRIDE é o vocabulário dessa pergunta — seis categorias, cada uma o espelho de uma propriedade de segurança:

Spoofing (falsificação de identidade) ataca a autenticação; Tampering (adulteração) ataca a integridade; Repudiation (repúdio) ataca o não repúdio; Information disclosure (divulgação indevida) ataca a confidencialidade; Denial of service ataca a disponibilidade; Elevation of privilege (elevação de privilégio) ataca a autorização.

Ao lado dele, dois nomes que a banca usa para trocar números: o DREAD classifica o risco já identificado em cinco fatores (dano, reprodutibilidade, explorabilidade, usuários afetados, descobribilidade); e o PASTA é a metodologia de sete etapas centrada em simulação de ataque e análise de risco de negócio.

O SSDF do NIST (SP 800-218). É um conjunto de práticas de alto nível, independente de linguagem e de metodologia, organizado em quatro grupos: PO — Preparar a Organização (definir requisitos, papéis, ferramentas e, em especial, proteger todos os componentes do ambiente de desenvolvimento contra ameaças internas e externas); PS — Proteger o Software (proteger o código contra acesso e adulteração, verificar integridade das versões, arquivar cada release); PW — Produzir Software Bem Protegido (projetar para atender aos requisitos de segurança, reusar componentes bem protegidos, revisar e testar o código repetidamente ao longo do ciclo, configurar a compilação com opções de endurecimento); e RV — Responder a Vulnerabilidades (identificar, analisar e corrigir vulnerabilidades já implantadas e tratar a causa-raiz). Duas recomendações do SSDF caem com frequência: acompanhar e atualizar continuamente bibliotecas e componentes de terceiros, e usar técnicas de integridade de código e de dados — isolamento de componentes, verificação de assinatura, mecanismos de controle de fluxo.

O CLASP da OWASP. É um processo leve, prescritivo e organizado por papéis: cada atividade de segurança tem um responsável nominal — gerente de projeto, especificador de requisitos, arquiteto, projetista (designer), implementador, analista de testes e auditor de segurança. É por isso que a prova pergunta “de quem é a atividade”: identificar a superfície de ataque — todas as partes expostas do sistema suscetíveis a ataque — é atribuição do designer; capturar requisitos de segurança é do especificador de requisitos; a revisão final independente é do auditor.

O SSE-CMM. Systems Security Engineering — Capability Maturity Model, normalizado como ISO/IEC 21827. Não prescreve atividades: avalia e melhora a capacidade de engenharia de segurança de uma organização, em níveis de capacidade que vão do processo não executado ao processo continuamente melhorado. É o equivalente, para segurança, do que o SAMM faz para o processo de desenvolvimento.

Gestão de segredos. Segredo é credencial, chave, token e certificado — e o problema deles é que vazam por descuido, não por criptanálise. As regras que a prova cobra: segredo não vai para o repositório nem para o código-fonte; segredo não se reaproveita entre ambientes (desenvolvimento, homologação e produção têm credenciais distintas, justamente para que o comprometimento de um ambiente menos protegido não entregue a produção); segredo se guarda em cofre, com controle de acesso e rotação periódica; acesso a ambiente de desenvolvimento e a repositório exige autenticação multifator e menor privilégio; e senha de usuário nunca é armazenada em texto puro — guarda-se o hash com sal.

Programação defensiva. Assumir que toda entrada é hostil: validar e sanear o que chega, preferir lista de permissão a lista de bloqueio, validar no lado do servidor, canonizar antes de comparar, escapar no ponto de uso, tratar exceções sem vazar detalhe interno e falhar de modo seguro. A validação é dependente de contexto: o que é perigoso numa consulta SQL não é o mesmo que é perigoso em HTML ou num nome de arquivo — e um apóstrofo é caractere legítimo num sobrenome. Por isso não existe filtro universal que recuse, em qualquer circunstância, todo caractere “potencialmente perigoso”.

O que decide os itens

Fase → atividade. A tabela que decide a maior fatia do tópico:

fase do SDL	a atividade que é dela
Treinamento	capacitação da equipe em desenvolvimento seguro
Requisitos	requisitos de segurança e privacidade, níveis de qualidade, avaliação de risco
Design	modelagem de ameaças, requisitos de projeto, análise da superfície de ataque
Implementação	padrões de codificação, ferramentas aprovadas, funções banidas, análise estática, revisão de código, testes
Verificação	análise dinâmica, fuzzing, revisão da superfície de ataque
Lançamento	revisão final de segurança, plano de resposta a incidentes, arquivamento
Resposta	execução do plano, correção e comunicação

STRIDE → propriedade violada → contramedida:

ameaça	viola	contramedida típica
Spoofing	autenticação	autenticação forte, multifator, certificados
Tampering	integridade	hash, assinatura digital, controle de acesso a escrita
Repudiation	não repúdio	registro de auditoria, assinatura, carimbo de tempo
Information disclosure	confidencialidade	cifra em trânsito e em repouso, menor privilégio
Denial of service	disponibilidade	limitação de taxa, redundância, filtragem
Elevation of privilege	autorização	verificação de autorização no domínio, menor privilégio

Quem é o quê:

	é	não é
SDL (Microsoft)	ciclo de vida de desenvolvimento seguro, com fases e práticas	não é taxonomia de ameaça
SSDF (NIST SP 800-218)	práticas de alto nível em 4 grupos: PO, PS, PW, RV	não é metodologia nem ferramenta
CLASP (OWASP)	processo leve organizado por papéis e atividades	não é um conjunto de testes
SSE-CMM (ISO/IEC 21827)	modelo de maturidade: avalia capacidade	não prescreve atividades
STRIDE	taxonomia de 6 categorias de ameaça	não é processo de etapas
DREAD	classificação de risco em 5 fatores	não identifica ameaça
PASTA	metodologia de 7 etapas centrada em simulação de ataque	não é o STRIDE

Fronteiras que a banca repete: modelagem de ameaças é do design, não dos requisitos; revisão de código é da implementação, não do design; teste e revisão de segurança ocorrem ao longo de todo o ciclo, nunca “apenas no teste final”; o SSDLC afeta todas as fases, não algumas; ambiente de desenvolvimento é alvo e precisa ser protegido como produção; credencial não se reaproveita entre ambientes; nenhum framework, biblioteca ou ferramenta dispensa testes automatizados e manuais; validação de entrada é dependente de contexto, e não uma recusa cega de caracteres.

Números que caem

STRIDE	6 categorias de ameaça
DREAD	5 fatores de classificação de risco
PASTA	7 etapas
SSDF (NIST SP 800-218)	4 grupos de práticas: PO, PS, PW, RV
SDL (Microsoft)	7 fases, de treinamento a resposta
CLASP	24 atividades, 7 melhores práticas, 5 visões, 7 papéis
SSE-CMM	ISO/IEC 21827; níveis de capacidade de 0 a 5
Zero Trust	NIST SP 800-207

Como a CEBRASPE derruba você aqui

Medido sobre os 23 itens do assunto: 9 são Errados — inversão 3, generalização 3, atribuição errada 2, número errado 1. Antes de qualquer rótulo, duas constatações que mudam o que se deve estudar aqui.

A primeira é sobre o próprio recorte. O título do assunto promete STRIDE e o corpus não cobra STRIDE. Ele aparece em 1 dos 23 itens, e mesmo nesse a pergunta não é o que significa cada letra: é a contagem (“processo de sete etapas”). Quem cai com frequência é o SSDF do NIST — 7 dos 23 itens, seis deles em cadernos de 2024 e 2025. A tabela do STRIDE acima vale como fundamento e como vocabulário da modelagem de ameaças, mas se o tempo for curto, os quatro grupos do SSDF (PO, PS, PW, RV) rendem sete vezes mais.

A segunda é o padrão que decide o assunto. 6 dos 9 itens errados discutem a mesma coisa: onde a segurança mora no ciclo. Ou a atividade foi mudada de fase, ou a segurança foi confinada a um ponto. É essa pergunta que se faz primeiro, e não a de qual sigla está na frase.

A atividade é verdadeira, o endereço é falso — 3 dos 9. Tudo na frase existe, menos a fase. A modelagem de ameaças “é realizada na fase de requisitos”, quando é ela que define a fase de design. A fase de design que prevê a estrutura geral do software “e a realização de revisões de código” — primeira metade certa, segunda deslocada, porque revisar código pressupõe código escrito. E a implementação que contemplaria testes de segurança “sem o uso de soluções para análise de código”, que é exatamente a atividade que caracteriza essa fase. Defesa: leia a atividade, decida sozinho de que fase ela é, e só então confira a fase que o item escreveu. Repare também no formato dos dois primeiros: duas atividades ligadas por “e”, uma certa e uma deslocada — julgue cada metade separadamente.

Confinar a segurança a um ponto, ou declarar uma camada dispensável — 3 dos 9, e são a negação direta da tese do tópico. “Nem todas as fases do processo de desenvolvimento de software são afetadas pela implementação de um SSDLC”; revisões e testes de segurança “focados apenas nos testes finais”; o framework de validação que “dispensa a adoção de simuladores e de testes automatizados e manuais”. Defesa: o SSDLC é definido por alcançar todas as fases, e o ciclo seguro é soma de camadas — nenhum controle isolado substitui outro. Os verbos a marcar são dispensar, apenas e nem todas.

A produtividade como fundamento de uma prática de segurança — 2 dos 9, e atravessa os dois blocos acima. O framework que dispensa testes o faz “conferindo ao processo maior produtividade”; e o SSDF que “incentiva o reúso de credenciais de autenticação entre diferentes ambientes de desenvolvimento” o faria “para facilitar o acesso dos desenvolvedores e agilizar o processo de integração contínua” — a norma manda o oposto, separar ambientes e credenciais, justamente para que o elo mais fraco não entregue a produção. Defesa: em texto de norma de segurança, comodidade e agilidade não são justificativa de nada. Quando a oração final oferece ganho de tempo, desconfie da oração inteira.

O absoluto do elaborador, e o absoluto que é da norma — 1 dos 9, mas o par que ele forma vale mais que a contagem. É Errado o mecanismo que “em quaisquer circunstâncias, rejeit[e] a entrada de dados que contenham caracteres considerados potencialmente perigosos”: não existe conjunto universal de caractere perigoso, a validação depende do contexto, e um apóstrofo é legítimo num sobrenome. É Certo, no mesmo assunto, que “todos os componentes dos ambientes de desenvolvimento de software sejam fortemente protegidos contra ameaças internas e externas” — porque esse absoluto é do SSDF, não do elaborador. E note o terceiro caso, que inverte a intuição: “nem todas as fases” é Errado justamente por não ser absoluto o bastante. Não pergunte se há um absoluto na frase; pergunte de quem ele é.

O número deslocado de uma metodologia para a vizinha — 1 dos 9. “STRIDE é uma metodologia […] baseada em um processo de sete etapas”: são seis categorias, e sete etapas é o PASTA. O item erra duas coisas de uma vez — a contagem e a natureza, porque STRIDE não é processo, é taxonomia. Defesa: recite a sua contagem antes de aceitar a do item. As contagens do DREAD, do PASTA e do CLASP não foram cobradas em nenhum item deste corpus e ficam na tabela de números por serem a origem do número que a banca empresta — foi de lá que veio o sete.

Erros clássicos

Achar que modelagem de ameaças é teste. Ela não executa nada e não precisa de código: é análise de projeto, feita sobre diagramas e fronteiras de confiança, na fase de design, para escolher quais controles construir. Quem executa e ataca é o teste dinâmico, lá na verificação.

Confundir STRIDE com DREAD. STRIDE identifica e classifica a ameaça por tipo; DREAD pontua o risco de uma ameaça já identificada. Um responde “que tipo de ataque é este”, o outro “quão grave é”.

Achar que o ambiente de desenvolvimento não é alvo. O grupo PO do SSDF existe em boa parte por causa disso: repositório, estação do desenvolvedor, servidor de integração e ferramentas são caminho de comprometimento da cadeia de fornecimento e precisam ser protegidos contra ameaça interna e externa.

Tratar segredo como configuração. Credencial em arquivo de configuração versionado, reaproveitada entre ambientes e sem rotação é vulnerabilidade, não conveniência. Cofre, escopo mínimo, rotação e multifator são a resposta esperada.

Esperar que um controle dispense os outros. Nem framework de validação, nem análise estática, nem WAF eliminam a necessidade de teste — o ciclo seguro é defesa em profundidade e camadas somadas.

Confundir SDL com SSDLC genérico. SDL é o ciclo específico da Microsoft, com nome próprio e fases nomeadas; SSDLC é o conceito de embutir segurança em qualquer ciclo de desenvolvimento. O que vale para um vale, em espírito, para o outro — mas quando o item nomeia “SDL”, a fase esperada é a do modelo da Microsoft.