Title: Desenvolvimento de Software / Desenvolvimento Seguro (SDLC)
Tags: Desenvolvimento_de_Software Resumo
On every note of this deck, unless a note says otherwise:
tldr: - SDLC é o ciclo de vida (iterativo) de desenvolvimento de software: requisitos → projeto/planejamento → desenvolvimento → testes → deploy.
- O aumento constante de ameaças levou ao S-SDLC (Secure SDLC): não substitui o SDLC, aprimora o processo com atividades de segurança em todas as fases.
- No S-SDLC, entram práticas adicionais como:
- definição de requisitos/recursos de segurança já na elicitação;
- revisão de cenários de ameaça (threat modeling) no design;
- SAST + secure coding durante a codificação;
- code review + pentest para elevar a robustez;
- pré-produção com DAST e validações antes do deploy.
- Desenvolvimento seguro pode ser visto como:
- técnicas (independentes de linguagem/plataforma) e
- ferramentas (comuns em DevOps/DevSecOps, integrando segurança continuamente).
- Modelagem de ameaças: processo estruturado para identificar requisitos de segurança, ameaças e vulnerabilidades, priorizar criticidade e definir respostas.
- Conceitos importantes (ISO 27005): ameaça, vulnerabilidade, risco, evento e incidente; e respostas típicas: mitigar/tratar, aceitar, transferir ou mudar o projeto, além de plano de contingência.
- Segurança no código (secure coding) envolve práticas como: documentação/onboarding/treinamento, clean code, ofuscação, tratamento de erros, APIs confiáveis, versionamento, atualização de dependências, revisões e testes.
- Revisão de código pode ocorrer via: pair programming, over-the-shoulder, refatoração, revisões automatizadas (ex.: linters/quality gates) e auditorias.
- Testes seguem o padrão AAA (Arrange–Act–Assert) e incluem:
- testes de componentes (unitário, integração, sistema, validação, E2E);
- testes de segurança: SAST (estático), DAST (dinâmico), IAST (híbrido), RASP (proteção em runtime/produção) e pentest (simulação ofensiva).
- Em disponibilidade/estabilidade, destacam-se métricas e testes: MTBF/MTTR, desempenho, carga, stress e recuperação.
- No deploy, prioriza-se ambiente seguro, monitoramento, resposta a incidentes e estratégias de entrega como blue/green e canary (liberação gradual).
- Pós-implementação: monitoramento contínuo via logs centralizados e ferramentas como Prometheus (métricas/consulta), Grafana e Kibana (visualização/análise).
- Abordagens específicas:
- CLASP (OWASP): processo leve, baseado em papéis/atividades e focado em análises estáticas; organiza-se em visões, recursos e casos de uso de vulnerabilidades.
- Microsoft SDL: modelo mais amplo com fases (requisitos, projeto, implementação, verificação, release) + suporte (treinamento, resposta), incluindo varreduras (segredos, criptografia, binário), fuzzing, governança de componentes e liberação em anéis (SDP).
- CLASP x SDL: ambos são proativos e cobrem o ciclo; o CLASP tende a ser mais simples e prescritivo e mais focado em estático, enquanto o SDL é mais abrangente/complexo, cobrindo testes estáticos/dinâmicos/interativos e práticas pós-release.
link: https://documentacao.online/estudos/3dym.html

front: (IDECAN/IF CE/2021) No que diz respeito à tolerância a falhas em sistemas, existem medidas de confiabilidade, sendo que os fabricantes devem fornecer essas medidas para os seus produtos, tanto para os componentes eletrônicos, como para os sistemas de computação mais complexos. São medidas determinadas estatisticamente, observando o comportamento dos componentes e dispositivos fabricados e que fazem referência aos seguintes parâmetros:
I. Tempo esperado até a primeira ocorrência de defeito.
II. Tempo médio para reparo do sistema.
III. Tempo médio entre as falhas do sistema.
Os temos descritos em I, II e III são conhecidos, respectivamente, pelas siglas
a) MTTF, MTBF e MTTR
b) MTBF, MTTF e MTTR
c) MTTF, MTTR e MTBF
d) MTTR, MTBF e MTTF
response: Alternativa C
comment: Vamos comentar cada um dos itens. I. Tempo esperado até a primeira ocorrência de defeito. O tempo esperado até a ocorrência de um defeito recebe o nome de Mean Time To Failure (MTTF), ou Tempo Médio Até a Falha II. Tempo médio para reparo do sistema. O tempo médio para reparo do sistema é chamado de Mean Time To Repare (MTTR) III. Tempo médio entre as falhas do sistema. Para o tempo médio entre as falhas, usamos o termo Mean Time Between Failures (MTBF) Portanto, temos MTTF, MTTR e MTBF - correta a letra C. (Gabarito: Letra C)
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Alternativa C - Vamos comentar cada um dos itens. I. Tempo esperado até a primeira ocorrência de defeito. O tempo esperado até a ocorrência de um defeito recebe o nome de Mean Time To Failure (MTTF), ou Tempo Médio Até a Falha II. Tempo médio para reparo do sistema. O tempo médio para reparo do sistema é chamado de Mean Time To Repare (MTTR) III. Tempo médio entre as falhas do sistema. Para o tempo médio entre as falhas, usamos o termo Mean Time Between Failures (MTBF) Portanto, temos MTTF, MTTR e MTBF - correta a letra C. (Gabarito: Letra C)

front: (CEBRASPE/SERPRO/2023) Quanto ao OWASP Top 10, julgue o item seguinte. Quando os desenvolvedores de software não testam a compatibilidade de bibliotecas atualizadas ou corrigidas, isso caracteriza um problema de segurança que o OWASP nomeia como componentes vulneráveis e desatualizados.
response: Correto
comment: Perfeito! A questão aborda o problema de vulnerabilidade A6:2021 - Componente Desatualizado e Vulnerável. Usualmente, quando estamos desenvolvendo aplicativos, usamos bibliotecas de componentes prontas ou pré-prontas, para evitar dispêndio de mão de obra com trabalhos que já foram feitos por outras pessoas e possam ser aplicados ao problema que queremos solucionar. O problema é que, ao ser descoberta uma vulnerabilidade em um componente, todos que o utilizam estão sujeitos a essa vulnerabilidade. Portanto, é importante que seja feito um controle de atualizações e patches de componentes, para que a entidade não se sujeite a problemas. Vou dar um exemplo recente, do final de janeiro de 2024. Um programa de automação de implementações de software muito utilizado é o Jenkins, que apontou uma vulnerabilidade crítica, permitindo a execução de códigos remotos que levavam ao vazamento de chaves criptográficas e elementos confidenciais. Para solucionar, a empresa por trás do Jenkins realizou a correção do problema, sendo necessário um patch por parte dos usuários para corrigir o problema. (Gabarito: Correto)
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Correto - Perfeito! A questão aborda o problema de vulnerabilidade A6:2021 - Componente Desatualizado e Vulnerável. Usualmente, quando estamos desenvolvendo aplicativos, usamos bibliotecas de componentes prontas ou pré-prontas, para evitar dispêndio de mão de obra com trabalhos que já foram feitos por outras pessoas e possam ser aplicados ao problema que queremos solucionar. O problema é que, ao ser descoberta uma vulnerabilidade em um componente, todos que o utilizam estão sujeitos a essa vulnerabilidade. Portanto, é importante que seja feito um controle de atualizações e patches de componentes, para que a entidade não se sujeite a problemas. Vou dar um exemplo recente, do final de janeiro de 2024. Um programa de automação de implementações de software muito utilizado é o Jenkins, que apontou uma vulnerabilidade crítica, permitindo a execução de códigos remotos que levavam ao vazamento de chaves criptográficas e elementos confidenciais. Para solucionar, a empresa por trás do Jenkins realizou a correção do problema, sendo necessário um patch por parte dos usuários para corrigir o problema. (Gabarito: Correto)

front: (CEBRASPE/DATAPREV/2023) No que se refere a OWASP Top 10, julgue o item a seguir. Insecure design recomenda o uso de LIMIT e outros controles SQL para prevenir a divulgação em massa de registros em caso de injeção de SQL.
response: Errado
comment: Ótima questão da Cebraspe. Podemos fugir da decoreba analisando a questão. A cláusula LIMIT, em SQL, limita a quantidade de resultados retornados em um comando. Então, ao sofrermos um ataque de injeção, se limitarmos a quantidade de resultados retornados, teremos uma quantidade menor de dados vazados. É uma ótima abordagem para mitigação de danos. Porém, a afirmativa incorre em um erro. Não é a vulnerabilidade insecure design que faz essa recomendação, é a injection. Corrigindo a alternativa: Insecure design injection (A03:2021) recomenda o uso de LIMIT e outros controles SQL para prevenir a divulgação em massa de registros em caso de injeção de SQL. (Gabarito: Errado)
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Errado - Ótima questão da Cebraspe. Podemos fugir da decoreba analisando a questão. A cláusula LIMIT, em SQL, limita a quantidade de resultados retornados em um comando. Então, ao sofrermos um ataque de injeção, se limitarmos a quantidade de resultados retornados, teremos uma quantidade menor de dados vazados. É uma ótima abordagem para mitigação de danos. Porém, a afirmativa incorre em um erro. Não é a vulnerabilidade insecure design que faz essa recomendação, é a injection. Corrigindo a alternativa: Insecure design injection (A03:2021) recomenda o uso de LIMIT e outros controles SQL para prevenir a divulgação em massa de registros em caso de injeção de SQL. (Gabarito: Errado)

front: (CEBRASPE/DATAPREV/2023) A respeito de ciclo de vida de desenvolvimento seguro, julgue os item a seguir. A fase de design prevê a definição da estrutura geral do software relacionado à segurança e a realização de revisões de código.
response: Errado
comment: De fato, na fase de design, ou de projeto (num bom português), temos a definição da estrutura geral do software, com requisitos de segurança e orientações gerais do programa. Entretanto, a realização de revisão de códigos ocorre somente em etapa posterior, afinal como vamos revisar o código se nem o elaboramos? Faça um paralelo com a construção de casas. No projeto, definimos o que vamos construir, tentando abordar todos os eventuais problemas e soluções. Ainda não temos a casa, que vai ser feita na construção - que, em desenvolvimento de sistemas, é um paralelo para a codificação, oucoding. (Gabarito: Errado)
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Errado - De fato, na fase de design, ou de projeto (num bom português), temos a definição da estrutura geral do software, com requisitos de segurança e orientações gerais do programa. Entretanto, a realização de revisão de códigos ocorre somente em etapa posterior, afinal como vamos revisar o código se nem o elaboramos? Faça um paralelo com a construção de casas. No projeto, definimos o que vamos construir, tentando abordar todos os eventuais problemas e soluções. Ainda não temos a casa, que vai ser feita na construção - que, em desenvolvimento de sistemas, é um paralelo para a codificação, oucoding. (Gabarito: Errado)

front: (CEBRASPE/CNMP/2023) Em relação a qualidade de software e análise estática de código-fonte, julgue o item subsequente. De acordo com o princípio de clean code, o uso de polimorfismo deve ser evitado, uma vez que esse método dificulta o entendimento e, consequentemente, a manutenção do código.
response: Errado
comment: Como acabamos de ver, o uso do polimorfismo é fortemente indicado, ao contrário do que a afirmativa aponta. Seu uso aumenta o entendimento e a escalabilidade da aplicação. (Gabarito: Errado)
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Errado - Como acabamos de ver, o uso do polimorfismo é fortemente indicado, ao contrário do que a afirmativa aponta. Seu uso aumenta o entendimento e a escalabilidade da aplicação. (Gabarito: Errado)

front: (FCC/TRT 4/2022) Sobre as etapas de teste unitário do padrão Triple A, considere:
I. Verifica-se se a operação realizada na etapa anterior surtiu o resultado esperado. Se o teste passa ou falha.
II. Configura-se tudo o que é necessário para que o teste possa rodar, ou seja, inicializa-se variáveis, cria-se alguns test doubles como Mocks, dentre outras coisas.
III. Processa-se de fato o teste. Onde se chama alguma função ou método que se quer colocar à prova.
As etapas constantes dos itens I, II e III referem-se, correta e respectivamente, a:
a) Arrange – Align – Act
b) Act – Assert – Analyze
c) Analyze – Arrange – Align
d) Assert – Arrange – Act
e) Assert – Align – Analyze
response: Alternativa D
comment: Vamos a que etapa do padrão Triple A corresponde cada item. Testes I. Quando verificamos se a etapa anterior surtiu o resultado esperado, estamos na etapa assert. II. A configuração é feita na etapa de arrange. III. Por fim, temos a etapa act, que é onde realizamos de fato o testo. Sendo assim, temos assert - arrange - act. (Gabarito: Letra D)
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Alternativa D - Vamos a que etapa do padrão Triple A corresponde cada item. Testes I. Quando verificamos se a etapa anterior surtiu o resultado esperado, estamos na etapa assert. II. A configuração é feita na etapa de arrange. III. Por fim, temos a etapa act, que é onde realizamos de fato o testo. Sendo assim, temos assert - arrange - act. (Gabarito: Letra D)

front: (FGV/SEMSA MANAUS/2022) No que se refere aos testes de software, um dos níveis de teste, conhecido como Unit Testing, tem por objetivo
a) testar a adequação do sistema no ambiente de negócios, e avaliar a conveniência de sua liberação.
b) testar a compatibilidade com dados de sistemas herdados.
c) testar a integração de seções ou partes, explorando as falhas de interação entre partes.
d) testar se a conformidade do sistema à luz dos requisitos estabelecidos.
e) testar seções ou partes separadamente, usualmente com teste funcionais.
response: Alternativa E
comment: Os testes unitários, ou Unit Testing, testam componentes unitários, isolados, do nosso código, como, por exemplo, um método específico aplicado em uma classe. A afirmativa que melhor se coaduna ao conceito de testes unitários é a letra E. (Gabarito: Letra E)
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Alternativa E - Os testes unitários, ou Unit Testing, testam componentes unitários, isolados, do nosso código, como, por exemplo, um método específico aplicado em uma classe. A afirmativa que melhor se coaduna ao conceito de testes unitários é a letra E. (Gabarito: Letra E)

front: (FGV/CGE SC/2023) O tipo de teste de software que serve para garantir que todas ou algumas partes de um sistema estão dialogando e funcionando corretamente em conjunto é o teste
a) de regressão.
b) de aceitação.
c) de integração.
d) de validação.
e) unitário.
response: Alternativa C
comment: Quando estamos focando em “diálogos entre partes”, entre componentes, e que essas partes estão funcionando corretamente em conjunto, estamos falando dos testes de integração. (Gabarito: Letra C)
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Alternativa C - Quando estamos focando em “diálogos entre partes”, entre componentes, e que essas partes estão funcionando corretamente em conjunto, estamos falando dos testes de integração. (Gabarito: Letra C)

front: (FGV/TRT/2022) Sobre a ferramenta de monitoramento Prometheus, analise as afirmativas a seguir.
I. Armazena fundamentalmente todos os dados como séries temporais.
II. Possui uma linguagem para consulta das métricas armazenadas denominada PromQL.
III. Coleta métricas através do protocolo HTTP.
Está correto o que se afirma em
a) I, apenas.
b) II, apenas.
c) III, apenas.
d) I e II, apenas.
e) I, II e III.
response: Alternativa E
comment: Vamos ver cada afirmativa. I. Correto. Os dados do Prometheus são, em seu core, séries temporais – por isso ele é conhecido como um TSDB (Time Series DataBase). II. Correto. PromQL é, de fato, a linguagem de consulta das métricas. III. Correto. A coleta realmente é feita através do protocolo HTTP. (Gabarito: Letra E)
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Alternativa E - Vamos ver cada afirmativa. I. Correto. Os dados do Prometheus são, em seu core, séries temporais – por isso ele é conhecido como um TSDB (Time Series DataBase). II. Correto. PromQL é, de fato, a linguagem de consulta das métricas. III. Correto. A coleta realmente é feita através do protocolo HTTP. (Gabarito: Letra E)

front: (CEBRASPE/PF - PERITO CRIMINAL/2013) No que se refere a processos de desenvolvimento seguro de aplicações, julgue o item subsecutivo. O CLASP (Comprehensive, Lightweight Application Security Process) fornece uma taxonomia de vulnerabilidades que podem ocorrer no código-fonte e que podem ser verificadas com o uso de ferramentas automatizadas para análise estática de código.
response: Correto
comment: De fato, o CLASP fornece uma abordagem de taxonomia, que classifica as vulnerabilidades de acordo com uma abordagem de classificação de alto nível. Essa taxonomia é dividida em várias categorias, dentre ela os tipos de problema. além disso, como vimos, o CLASP é, de fato, orientado para análises estáticas de código. (Gabarito: Correto)
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Correto - De fato, o CLASP fornece uma abordagem de taxonomia, que classifica as vulnerabilidades de acordo com uma abordagem de classificação de alto nível. Essa taxonomia é dividida em várias categorias, dentre ela os tipos de problema. além disso, como vimos, o CLASP é, de fato, orientado para análises estáticas de código. (Gabarito: Correto)

front: (CEBRASPE/CNJ/2013) Acerca de conceitos relacionados ao desenvolvimento de software seguro e segurança para web services, julgue o item subsecutivo. O SDL é um processo de desenvolvimento de software seguro, que envolve a adição de produtos e atividades, como o desenvolvimento de modelos de ameaças
response: Correto
comment: Perfeito! O SDL envolve a aplicação de diversas práticas de segurança no desenvolvimento de softwares. Dentre elas está, corretamente, o desenvolvimento de modelos de ameaças (ou modelagem de ameaças). Lembrem que a modelagem de ameaças faz parte da etapa de projeto! (Gabarito: Correto)
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Correto - Perfeito! O SDL envolve a aplicação de diversas práticas de segurança no desenvolvimento de softwares. Dentre elas está, corretamente, o desenvolvimento de modelos de ameaças (ou modelagem de ameaças). Lembrem que a modelagem de ameaças faz parte da etapa de projeto! (Gabarito: Correto)

front: CESPE / CEBRASPE - 2025 - TRF - 6ª REGIÃO - Analista Judiciário – Área: Apoio Especializado – Especialidade: Tecnologia da Informação O designer é responsável por identificar a superfície de ataque de uma aplicação, a qual abrange todas as partes expostas do sistema que sejam suscetíveis a ataques.
response: Certo
comment: O responsável pelo desenho do sistema deve mapear toda a área exposta a possíveis investidas, identificando portas e interfaces vulneráveis para reduzir o risco de incidentes..
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Certo - O responsável pelo desenho do sistema deve mapear toda a área exposta a possíveis investidas, identificando portas e interfaces vulneráveis para reduzir o risco de incidentes..

front: CESPE / CEBRASPE - 2025 - TRF - 6ª REGIÃO - Analista Judiciário – Área: Apoio Especializado – Especialidade: Tecnologia da Informação É recomendado que as organizações realizem revisões e testes de segurança focados apenas nos testes finais, pois essa conduta permite identificar e mitigar vulnerabilidades antes que o software seja lançado, aumentando a segurança do produto final.
response: Errado
comment: A abordagem recomendada não é focar apenas nos testes finais, mas realizar testes de segurança durante todo o ciclo de vida.
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Errado - A abordagem recomendada não é focar apenas nos testes finais, mas realizar testes de segurança durante todo o ciclo de vida.

front: CESPE / CEBRASPE - 2025 - TRF - 6ª REGIÃO - Analista Judiciário – Área: Apoio Especializado – Especialidade: Tecnologia da Informação Na implementação desse framework, é recomendado utilizar técnicas avançadas para assegurar a integridade do código e dos dados durante o desenvolvimento de software seguro, como o isolamento de componentes e o uso de mecanismos de controle de fluxo.
response: Certo
comment: O uso de técnicas avançadas para garantir a integridade do código, como isolamento e controle de fluxo, fortalece a proteção contra falhas de segurança desde o início do processo de desenvolvimento. O isolamento de componentes é uma técnica que separa os módulos de um sistema, garantindo que cada um opere de forma independente. Essa abordagem reduz o impacto de falhas, pois problemas em um componente não afetam diretamente os demais. Já os mecanismos de controle de fluxo regulam o movimento de dados dentro do sistema, permitindo apenas acessos e interações autorizadas. Isso impede fluxos inadequados ou excessivos que podem comprometer a segurança ou o desempenho. Juntos, esses métodos reforçam a confiabilidade e proteção do software.
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Certo - O uso de técnicas avançadas para garantir a integridade do código, como isolamento e controle de fluxo, fortalece a proteção contra falhas de segurança desde o início do processo de desenvolvimento. O isolamento de componentes é uma técnica que separa os módulos de um sistema, garantindo que cada um opere de forma independente. Essa abordagem reduz o impacto de falhas, pois problemas em um componente não afetam diretamente os demais. Já os mecanismos de controle de fluxo regulam o movimento de dados dentro do sistema, permitindo apenas acessos e interações autorizadas. Isso impede fluxos inadequados ou excessivos que podem comprometer a segurança ou o desempenho. Juntos, esses métodos reforçam a confiabilidade e proteção do software.

front: CESPE / CEBRASPE - 2025 - TRF - 6ª REGIÃO - Analista Judiciário – Área: Apoio Especializado – Especialidade: Tecnologia da Informação Enfatiza-se a importância crítica de se estabelecer mecanismos robustos de monitoramento contínuo e de atualização rigorosa de bibliotecas e componentes de terceiros.
response: Certo
comment: A manutenção de monitoramento contínuo e a atualização regular de dependências são cruciais para evitar falhas existentes, garantindo que componentes externos sejam corrigidos ou substituídos quando necessário.
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Certo - A manutenção de monitoramento contínuo e a atualização regular de dependências são cruciais para evitar falhas existentes, garantindo que componentes externos sejam corrigidos ou substituídos quando necessário.

front: CESPE / CEBRASPE - 2024 - TSE - Analista Judiciário – Área: Apoio Especializado – Especialidade: Tecnologia da Informação Conforme o OWASP SAMM (software assurance maturity model), o processo formal de gerenciamento de incidentes em vigor deve seguir uma sequência estabelecida e bem documentada para detecção de incidentes, com ênfase na avaliação automatizada de logs.
response: Certo
comment: Não adianta apagar o fogo sem saber como começou! O OWASP SAMM exige um processo formal e bem documentado para detectar incidentes, priorizando a avaliação automatizada de logs. Isso garante respostas rápidas e reduz danos causados por ataques.
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Certo - Não adianta apagar o fogo sem saber como começou! O OWASP SAMM exige um processo formal e bem documentado para detectar incidentes, priorizando a avaliação automatizada de logs. Isso garante respostas rápidas e reduz danos causados por ataques.

front: (CESPE – CNJ/Técnico Judiciário – Programação de Sistemas/2013) Para aumentar a segurança de um programa, deve-se evitar o uso de senhas consideradas frágeis, como o próprio nome e identificador de usuário, sendo recomendada a criação de senhas consideradas fortes, ou seja, aquelas que incluem, em sua composição, letras (maiúsculas e minúsculas), números e símbolos embaralhados, totalizando, preferencialmente, mais de seis caracteres.
response: Certo
comment: Conforme vimos, a segurança e controle dos formatos de senhas permitidas pelos usuários faz parte de um processo seguro de uma aplicação. Mencionamos ainda que na prática, utiliza-se oito caracteres como uma quantidade segura, entretanto, algumas aplicações e examinadores consideram seis como uma quantidade suficiente.
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Certo - Conforme vimos, a segurança e controle dos formatos de senhas permitidas pelos usuários faz parte de um processo seguro de uma aplicação. Mencionamos ainda que na prática, utiliza-se oito caracteres como uma quantidade segura, entretanto, algumas aplicações e examinadores consideram seis como uma quantidade suficiente.

front: (CESPE – TCE-PA/Auditor de Controle Externo – Informática/2016) Na metodologia de desenvolvimento seguro de software SDL (Security Development Lifecycle), a modelagem de ameaças é realizada na fase de requisitos.
response: Errado
comment: A modelagem de ameaças se dá na fase de DESIGN. Lembremos os principais aspectos considerados nessa fase: • Definir as diretivas de design e arquitetura de segurança; • Documentar os elementos da superfície de ataque do software; • Realizar a modelagem de ameaças; • Definir critérios de fornecimento complementar.
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Errado - A modelagem de ameaças se dá na fase de DESIGN. Lembremos os principais aspectos considerados nessa fase: • Definir as diretivas de design e arquitetura de segurança; • Documentar os elementos da superfície de ataque do software; • Realizar a modelagem de ameaças; • Definir critérios de fornecimento complementar.

front: (CESPE – CNJ/Analista Judiciário – Análise de Sistemas/2013) O SDL é um processo de desenvolvimento de software seguro, que envolve a adição de produtos e atividades, como o desenvolvimento de modelos de ameaças.
response: Certo
comment: Essa é a definição básica do processo contemplado pelo SDL.
title: Desenvolvimento Seguro (SDLC)
Other fields (not shown on cards):
back: Certo - Essa é a definição básica do processo contemplado pelo SDL.