{"subject_id":"3a3cc48d00998128abe7d040f9e17186","topico":"Desenvolvimento seguro: SDL, STRIDE, gestão de segredos","stems":["A respeito do desenvolvimento de software seguro, julgue os itens a seguir.","Em relação a técnicas de desenvolvimento seguro voltadas para o SSDLC (secure software development cycle), julgue os itens a seguir.","A respeito do desenvolvimento seguro de aplicações, frameworks OWASP e testes dinâmicos de aplicações, julgue os itens a seguir.","Julgue os próximos itens, relativos a desenvolvimento seguro.","A respeito de desenvolvimento de software seguro, julgue os itens que se seguem.","Acerca do processo de implementação do CLASP, julgue o próximo item.","A respeito do NIST – secure software development framework, julgue os itens subsecutivos.","A respeito de ciclo de vida de desenvolvimento seguro, julgue os itens que se seguem.","Julgue os próximos itens, relativos a testes de penetração e a modelagem de ameaças.","Com relação ao desenvolvimento de software seguro e à arquitetura de aplicativos, julgue os itens a seguir.","Acerca de segurança de banco de dados e de desenvolvimento de software, julgue os itens subsecutivos.","Julgue os próximos itens, relativos a desenvolvimento e qualidade de software."],"questions":[{"id":"bb7d8141b399","number":116,"stem":0,"statement":"Os princípios da arquitetura e da governança Zero Trust no SDL incluem a presunção de que o sistema já está comprometido, a verificação explícita da confiança e a concessão do menor privilégio necessário para cada conta de usuário, cada identidade de máquina/serviço e cada componente da aplicação.","answer":"C","source":{"slug":"TJ_PA_25_SERVIDOR","ano":2025},"explanation":{"verdict_reason":"Os três princípios citados são exatamente os que definem Zero Trust: presumir violação, verificar explicitamente cada solicitação de acesso e conceder o menor privilégio necessário. O ponto que o item acrescenta e que está igualmente correto é o alcance: o princípio não se aplica só a contas de pessoas, mas também a identidades de máquina e de serviço e a cada componente da aplicação, porque no modelo não existe rede interna confiável.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Zero Trust: presumir violação, verificar explicitamente, menor privilégio","citation":"NIST SP 800-207","trap_note":"Zero Trust se resume a três verbos: presumir comprometido, verificar sempre, privilegiar o mínimo. Item que fale em confiar por estar dentro do perímetro, ou que limite o princípio a usuários humanos, contraria o modelo."}},{"id":"58aadb0d49d3","number":117,"stem":0,"statement":"Na prática “Produzir Software Bem Protegido” do SSDF (secure software development framework), o NIST incentiva o reúso de credenciais de autenticação entre diferentes ambientes de desenvolvimento para facilitar o acesso dos desenvolvedores e agilizar o processo de integração contínua.","answer":"E","source":{"slug":"TJ_PA_25_SERVIDOR","ano":2025},"explanation":{"verdict_reason":"O SSDF recomenda o contrário: cada ambiente de desenvolvimento deve ser separado e protegido, com credenciais próprias, justamente para que o comprometimento do ambiente menos protegido não alcance os demais nem a produção. Essa exigência, aliás, está no grupo de práticas de preparação da organização, que trata da proteção do ambiente. Comodidade do desenvolvedor e agilidade de integração contínua não são justificativa de prática segura em texto de norma.","distortion_type":"inversao","distorted_span":"incentiva o reúso de credenciais de autenticação entre diferentes ambientes de desenvolvimento","corrected_statement":"Na prática “Preparar a Organização” do SSDF (secure software development framework), o NIST recomenda a separação das credenciais de autenticação entre diferentes ambientes de desenvolvimento, de modo que o comprometimento de um ambiente não alcance os demais.","concept":"SSDF: separar e proteger cada ambiente de desenvolvimento","citation":"NIST SP 800-218 (SSDF), prática PO.5","trap_note":"Quando o item oferece facilidade de acesso, agilidade ou produtividade como razão de uma recomendação de segurança, a recomendação costuma estar invertida. Credencial não se reaproveita entre desenvolvimento, homologação e produção."}},{"id":"d10f2161811c","number":118,"stem":0,"statement":"Na estrutura de desenvolvimento de software seguro do NIST, o grupo de prática “Preparar a Organização” inclui a recomendação de que todos os componentes dos ambientes de desenvolvimento de software sejam fortemente protegidos contra ameaças internas e externas, a fim de prevenir comprometimentos.","answer":"C","source":{"slug":"TJ_PA_25_SERVIDOR","ano":2025},"explanation":{"verdict_reason":"Proteger todos os componentes do ambiente de desenvolvimento contra ameaças internas e externas é literalmente uma das práticas do grupo de preparação da organização no SSDF. A razão é de cadeia de fornecimento: repositório, estação de trabalho, servidor de integração e ferramentas são caminho de comprometimento do software antes mesmo de ele existir, e por isso recebem proteção equivalente à de produção.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"SSDF grupo PO: proteger o ambiente de desenvolvimento","citation":"NIST SP 800-218 (SSDF), prática PO.5","trap_note":"Os quatro grupos do SSDF se reconhecem pelo verbo: PO prepara a organização, PS protege o software, PW produz software bem protegido, RV responde a vulnerabilidades. Ambiente e ferramenta caem em PO."}},{"id":"711d8c38a9d5","number":67,"stem":1,"statement":"SSDLC requer a avaliação de riscos como uma etapa do ciclo.","answer":"C","source":{"slug":"MPO_24","ano":2024},"explanation":{"verdict_reason":"Sem avaliação de risco não há critério para escolher controle: é ela que diz quais ativos importam, quais ameaças são plausíveis e quanto vale gastar em cada mitigação. Por isso a avaliação de riscos é etapa do ciclo de desenvolvimento seguro, e não atividade externa a ele.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"SSDLC inclui avaliação de riscos como etapa","citation":null,"trap_note":"Todo modelo do tópico, do SDL ao SSDF, ancora as decisões em risco. Item que descreva o ciclo seguro como lista fixa de controles sem avaliação de risco está incompleto."}},{"id":"419950e8a4f9","number":68,"stem":1,"statement":"Nem todas as fases do processo de desenvolvimento de software são afetadas pela implementação de um SSDLC.","answer":"E","source":{"slug":"MPO_24","ano":2024},"explanation":{"verdict_reason":"O SSDLC é definido exatamente por alcançar todas as fases: treinamento, requisitos, design, implementação, verificação, lançamento e resposta a incidentes, cada uma com a sua atividade de segurança. Restringir o alcance a algumas fases nega a premissa do modelo, que é não existir etapa em que a segurança possa ser adiada.","distortion_type":"inversao","distorted_span":"Nem todas as fases do processo de desenvolvimento de software são afetadas","corrected_statement":"Todas as fases do processo de desenvolvimento de software são afetadas pela implementação de um SSDLC.","concept":"SSDLC afeta todas as fases do ciclo","citation":null,"trap_note":"A tese do tópico é que segurança não é fase, é atributo construído em todas elas. Qualquer item que confine o ciclo seguro a parte do processo contraria essa tese."}},{"id":"acf0e72c798a","number":98,"stem":2,"statement":"Identificação de dados sensíveis, restrições de acesso, autenticação e autorização são exemplos de requisitos de segurança relacionados ao desenvolvimento seguro de aplicações.","answer":"C","source":{"slug":"MPO_24","ano":2024},"explanation":{"verdict_reason":"Requisitos de segurança são os que dizem o que o sistema deve garantir, e não o que ele deve fazer para o usuário: quais dados são sensíveis, quem pode acessar o quê, como a identidade é comprovada e como a permissão é verificada. Os quatro exemplos citados são requisitos desse tipo, levantados junto com os requisitos funcionais no início do ciclo.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Requisitos de segurança: dados sensíveis, acesso, autenticação, autorização","citation":null,"trap_note":"Requisito de segurança é levantado na fase de requisitos, com os demais, e não deduzido depois do sistema pronto. É o que dá critério para a modelagem de ameaças que vem no design."}},{"id":"80b85f266cd2","number":100,"stem":2,"statement":"No desenvolvimento seguro de aplicações, o emprego de frameworks e bibliotecas que realizem validações contra a injeção de código malicioso nas aplicações dispensa a adoção de simuladores e de testes automatizados e manuais, conferindo ao processo maior produtividade.","answer":"E","source":{"slug":"MPO_24","ano":2024},"explanation":{"verdict_reason":"Framework e biblioteca de validação reduzem a chance de injeção, mas não cobrem falha de lógica de negócio, erro de autorização, configuração incorreta nem uso indevido da própria biblioteca, e podem eles mesmos trazer vulnerabilidade. Por isso nenhum controle isolado dispensa teste automatizado ou manual: o ciclo seguro é defesa em camadas somadas, e ganho de produtividade não é fundamento de segurança.","distortion_type":"generalizacao","distorted_span":"dispensa a adoção de simuladores e de testes automatizados e manuais","corrected_statement":"No desenvolvimento seguro de aplicações, o emprego de frameworks e bibliotecas que realizem validações contra a injeção de código malicioso nas aplicações não dispensa a adoção de simuladores e de testes automatizados e manuais.","concept":"Nenhum controle isolado dispensa os demais","citation":null,"trap_note":"O verbo dispensar é o sinal. Em segurança de aplicação, controle nenhum substitui outro: item que prometa eliminar uma etapa inteira em nome da produtividade é falso por construção."}},{"id":"95e245bd88fd","number":113,"stem":3,"statement":"A autenticação multifatorial, um dos controles listados no Microsoft SDL (security development lifecycle), adiciona uma segunda camada crítica de segurança aos logins, a fim de proteger todos os usuários, especialmente os administradores.","answer":"C","source":{"slug":"CPNUJE_24","ano":2024},"explanation":{"verdict_reason":"A autenticação multifator está entre os controles recomendados pelo SDL da Microsoft, e a justificativa do item é a que consta do próprio material: ela acrescenta uma camada adicional ao login e é especialmente crítica para contas administrativas, cujo comprometimento entrega todo o ambiente. Nada na frase amplia o alcance do controle além do que a prática afirma.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"SDL: autenticação multifator como controle recomendado","citation":"Microsoft SDL","trap_note":"Multifator é controle de acesso de identidade, e no ciclo seguro protege sobretudo desenvolvedor e administrador, porque essas contas alcançam o código e o ambiente."}},{"id":"e2305a904d2f","number":116,"stem":4,"statement":"No contexto de Secure Software Development Framework do NIST, a prática de responder a vulnerabilidades (RV) inclui a implementação de processos para identificar, analisar e corrigir vulnerabilidades de segurança em implantação.","answer":"C","source":{"slug":"STJ_24","ano":2024},"explanation":{"verdict_reason":"O grupo RV do SSDF é o que trata do software já entregue: identificar vulnerabilidades continuamente, analisar cada uma para decidir a resposta e corrigi-las, tratando também a causa-raiz para que a mesma classe de falha não retorne. O item descreve esse grupo com o nome certo e no escopo certo.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"SSDF grupo RV: identificar, analisar e corrigir vulnerabilidades implantadas","citation":"NIST SP 800-218 (SSDF), grupo RV","trap_note":"RV é o único grupo do SSDF que atua depois da entrega. Se o item fala de software já implantado, divulgação de vulnerabilidade ou causa-raiz, é RV."}},{"id":"4913c8789a16","number":117,"stem":4,"statement":"No SDL (Security Development Lifecycle), a modelagem de ameaças é uma prática que ajuda a identificar e avaliar possíveis ameaças ao sistema durante a fase de design do software.","answer":"C","source":{"slug":"STJ_24","ano":2024},"explanation":{"verdict_reason":"Modelagem de ameaças é análise de projeto: desenha-se o fluxo de dados, marcam-se as fronteiras de confiança e pergunta-se o que pode dar errado em cada travessia, para escolher os controles antes de existir código. No SDL ela é a atividade que caracteriza a fase de design, e é onde o STRIDE é aplicado.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Modelagem de ameaças é atividade da fase de design","citation":"Microsoft SDL","trap_note":"Guarde o par fase e atividade: design modela ameaças, implementação faz análise estática e revisão de código, verificação faz análise dinâmica e fuzzing. A banca troca a fase, não a atividade."}},{"id":"325df9adc6e9","number":117,"stem":5,"statement":"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.","answer":"C","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"O CLASP organiza as atividades de segurança por papéis, e a identificação da superfície de ataque é atribuída ao designer, porque depende do desenho dos pontos de entrada, das interfaces e das fronteiras de confiança. A definição de superfície de ataque dada no item também está correta: o conjunto das partes expostas do sistema suscetíveis a ataque.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"CLASP: atividades atribuídas a papéis; superfície de ataque é do designer","citation":"OWASP CLASP","trap_note":"CLASP é o modelo em que a pergunta é de quem é a atividade. Especificador de requisitos captura requisitos, designer identifica superfície de ataque, implementador codifica, auditor revisa."}},{"id":"b64c7669107c","number":118,"stem":6,"statement":"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.","answer":"C","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"Componente de terceiro entra no produto com as vulnerabilidades que tiver, e uma CVE publicada amanhã torna vulnerável a biblioteca que hoje está íntegra. Por isso o SSDF trata inventário, monitoramento contínuo e atualização de componentes de terceiros como prática permanente, e não como verificação feita uma única vez na escolha da biblioteca.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"SSDF: monitoramento contínuo de componentes de terceiros","citation":"NIST SP 800-218 (SSDF)","trap_note":"Componente de terceiro exige vigilância contínua porque o risco muda sem que o código mude. Item que trate a verificação de dependências como evento único do início do projeto está errado."}},{"id":"677ff468d137","number":119,"stem":6,"statement":"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.","answer":"C","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"O SSDF recomenda técnicas de proteção da integridade do código e dos dados durante o desenvolvimento, e isolamento de componentes e mecanismos de controle de fluxo são exemplos legítimos: o primeiro limita o dano de um componente comprometido, o segundo impede que a execução seja desviada para caminho não previsto. São medidas de projeto e de compilação, aplicadas antes de qualquer teste.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Integridade de código e dados: isolamento e controle de fluxo","citation":"NIST SP 800-218 (SSDF), grupo PW","trap_note":"Integridade no SSDF não é só assinar o pacote no fim: inclui isolar componentes e endurecer a compilação. O grupo PW é o que trata de como o software é produzido."}},{"id":"81cc65bceb58","number":120,"stem":6,"statement":"É 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","answer":"E","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"A tese do ciclo de desenvolvimento seguro é exatamente a oposta: revisão e teste de segurança se distribuem por todas as fases, porque defeito descoberto no fim já custou o máximo para corrigir e porque teste final não alcança decisão de arquitetura tomada meses antes. Concentrar tudo nos testes finais é o comportamento que o SSDF existe para substituir.","distortion_type":"generalizacao","distorted_span":"focados apenas nos testes finais","corrected_statement":"É recomendado que as organizações realizem revisões e testes de segurança ao longo de todas as fases do desenvolvimento, pois essa conduta permite identificar e mitigar vulnerabilidades antes que o software seja liberado.","concept":"Verificação distribuída por todo o ciclo, não no teste final","citation":"NIST SP 800-218 (SSDF), grupo PW","trap_note":"O advérbio apenas é o marcador de erro neste tópico. Sempre que um item confinar a segurança a uma única fase, confronte com a premissa do deslocamento à esquerda: cada fase tem a sua atividade."}},{"id":"665f0c4e3a10","number":120,"stem":4,"statement":"A programação defensiva inclui a prática de validação e sanitização de entradas para prevenir que dados maliciosos sejam processados pelo sistema.","answer":"C","source":{"slug":"STJ_24","ano":2024},"explanation":{"verdict_reason":"A premissa da programação defensiva é que toda entrada é hostil até prova em contrário, e a consequência direta disso é validar e sanear o que chega antes de processar. É a defesa de fundo contra injeção, e o item a descreve sem exagero: não promete eliminar a classe inteira de ataques, apenas impedir o processamento de dados maliciosos.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Programação defensiva: validação e sanitização de entradas","citation":null,"trap_note":"Validação de entrada é sempre a resposta certa e nunca a resposta suficiente. Item que a descreve como boa prática é verdadeiro; item que a apresenta como garantia de ausência de vulnerabilidade, não."}},{"id":"d5ae148a4591","number":80,"stem":7,"statement":"A modelagem de ameaças pode ser aplicada no componente de um software, para apoiar a seleção de recursos de segurança.","answer":"C","source":{"slug":"DATAPREV_23","ano":2023},"explanation":{"verdict_reason":"A modelagem de ameaças não exige o sistema inteiro como unidade de análise: aplica-se a um componente, a um fluxo ou a uma fronteira de confiança específica. E a sua finalidade é precisamente essa, apoiar a escolha dos recursos de segurança que valem o custo naquele ponto, em vez de espalhar controle sem critério.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Modelagem de ameaças por componente orienta a escolha de controles","citation":null,"trap_note":"A modelagem de ameaças é escalável para baixo. Item que exija sistema completo, ou que a trate como atividade única do projeto inteiro, restringe o que o método permite."}},{"id":"ca5013a53c0e","number":81,"stem":7,"statement":"Durante a fase de implementação, são aplicados padrões de codificação e testes.","answer":"C","source":{"slug":"DATAPREV_23","ano":2023},"explanation":{"verdict_reason":"A fase de implementação é onde o código passa a existir, e com ele os controles que dependem de como se escreve: padrões de codificação, funções inseguras banidas, ferramentas aprovadas, análise estática, revisão de código e testes. O item apenas nomeia duas dessas atividades na fase certa.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Implementação: padrões de codificação, análise estática e testes","citation":"Microsoft SDL","trap_note":"Implementação concentra tudo o que se faz sobre o código escrito. Se a atividade só faz sentido havendo código, ela não é da fase de design."}},{"id":"e67e11da31c4","number":82,"stem":7,"statement":"A fase de implementação contempla a aplicação de testes de segurança sem o uso de soluções para análise de código.","answer":"E","source":{"slug":"DATAPREV_23","ano":2023},"explanation":{"verdict_reason":"É justamente na implementação que entram as soluções de análise de código: análise estática automatizada e revisão de código são as atividades características da fase, executadas a cada alteração enviada ao repositório. A frase nega o que define o momento em que ela se situa.","distortion_type":"inversao","distorted_span":"sem o uso de soluções para análise de código","corrected_statement":"A fase de implementação contempla a aplicação de testes de segurança com o uso de soluções para análise de código.","concept":"Análise estática e revisão de código são da implementação","citation":"Microsoft SDL","trap_note":"Antes de julgar, diga em voz alta qual é a atividade que caracteriza a fase citada. Se o item a exclui, ele está invertido, ainda que o resto da frase seja plausível."}},{"id":"37155eeffd9f","number":83,"stem":7,"statement":"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.","answer":"E","source":{"slug":"DATAPREV_23","ano":2023},"explanation":{"verdict_reason":"A primeira metade está certa: definir a estrutura geral do software relacionada à segurança é atividade de design, ao lado da modelagem de ameaças e da análise da superfície de ataque. Revisão de código, porém, pressupõe código escrito e pertence à fase de implementação. Atividade verdadeira, fase errada.","distortion_type":"atribuicao_errada","distorted_span":"e a realização de revisões de código","corrected_statement":"A fase de design prevê a definição da estrutura geral do software relacionado à segurança e a realização da modelagem de ameaças.","concept":"Revisão de código é da implementação, não do design","citation":"Microsoft SDL","trap_note":"Item com duas atividades ligadas por e costuma trazer uma certa e uma deslocada de fase. Julgue cada metade separadamente antes de decidir."}},{"id":"a0c2cdf247fb","number":91,"stem":8,"statement":"STRIDE é uma metodologia de identificação de ameaças à segurança baseada em um processo de sete etapas para identificar, enumerar e classificar as ameaças.","answer":"E","source":{"slug":"DATAPREV_23","ano":2023},"explanation":{"verdict_reason":"O STRIDE não é um processo de etapas: é uma taxonomia de seis categorias de ameaça, cada uma espelhando uma propriedade de segurança violada. Sete etapas é a contagem de outra metodologia de modelagem de ameaças, o PASTA, centrada em simulação de ataque e risco de negócio.","distortion_type":"numero_errado","distorted_span":"baseada em um processo de sete etapas","corrected_statement":"STRIDE é uma metodologia de identificação de ameaças à segurança baseada em seis categorias de ameaça para identificar, enumerar e classificar as ameaças.","concept":"STRIDE tem seis categorias; sete etapas é PASTA","citation":null,"trap_note":"Recite as contagens antes de julgar: seis categorias no STRIDE, cinco fatores no DREAD, sete etapas no PASTA, quatro grupos no SSDF. A banca desloca o número de uma metodologia para a vizinha."}},{"id":"193c3f4beca6","number":115,"stem":9,"statement":"Systems Security Engineering – Capability Maturity Model (SSE-CMM) é um modelo de processo que pode ser usado para melhorar e avaliar a capacidade de engenharia de segurança de uma organização.","answer":"C","source":{"slug":"DPDF_20_ANALISTA","ano":2020},"explanation":{"verdict_reason":"O SSE-CMM, normalizado como ISO/IEC 21827, é modelo de maturidade: ele não prescreve atividades de desenvolvimento, mede o quanto os processos de engenharia de segurança de uma organização estão institucionalizados e serve tanto para avaliação quanto para melhoria. O item usa os dois verbos corretos, melhorar e avaliar.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"SSE-CMM mede maturidade de engenharia de segurança","citation":"ISO/IEC 21827","trap_note":"Separe os verbos dos modelos: SDL organiza o ciclo, SSDF lista práticas, CLASP distribui papéis, SSE-CMM mede maturidade. Modelo de maturidade avalia capacidade, não dita a atividade."}},{"id":"f05b6587f998","number":54,"stem":10,"statement":"Na metodologia de desenvolvimento seguro de software SDL (Security Development Lifecycle), a modelagem de ameaças é realizada na fase de requisitos.","answer":"E","source":{"slug":"TCE_PA_16","ano":2016},"explanation":{"verdict_reason":"No SDL a modelagem de ameaças é a atividade que caracteriza a fase de design, porque ela opera sobre a arquitetura já esboçada: fluxos de dados, componentes e fronteiras de confiança. Na fase de requisitos definem-se requisitos de segurança e privacidade e as barras de qualidade, não o modelo de ameaças.","distortion_type":"atribuicao_errada","distorted_span":"é realizada na fase de requisitos","corrected_statement":"Na metodologia de desenvolvimento seguro de software SDL (Security Development Lifecycle), a modelagem de ameaças é realizada na fase de design.","concept":"Modelagem de ameaças: design, não requisitos","citation":"Microsoft SDL","trap_note":"Requisitos dizem o que proteger; design decide como. Modelar ameaça exige haver arquitetura sobre a qual modelar, logo nunca é atividade de requisitos."}},{"id":"003550f5c3e9","number":70,"stem":11,"statement":"No que se refere a softwares, uma programação segura deve dispor de mecanismos que, em quaisquer circunstâncias, rejeitem a entrada de dados que contenham caracteres considerados potencialmente perigosos.","answer":"E","source":{"slug":"FUNPRESP_16_JUD","ano":2016},"explanation":{"verdict_reason":"Não existe conjunto universal de caracteres perigosos: o que é perigoso numa consulta SQL não é o que é perigoso em HTML, em nome de arquivo ou em comando de sistema, e caracteres tidos por suspeitos são legítimos em dados reais, como o apóstrofo num sobrenome. A programação segura valida conforme o contexto, prefere lista de permissão e escapa o dado no ponto de uso, em vez de recusar caractere de forma cega e absoluta.","distortion_type":"generalizacao","distorted_span":"em quaisquer circunstâncias, rejeitem a entrada de dados que contenham caracteres considerados potencialmente perigosos","corrected_statement":"No que se refere a softwares, uma programação segura deve dispor de mecanismos que validem a entrada de dados conforme o contexto de uso, tratando adequadamente os caracteres considerados potencialmente perigosos.","concept":"Validação de entrada é dependente de contexto","citation":null,"trap_note":"Em quaisquer circunstâncias, sempre e nunca são marcadores de generalização mesmo quando a frase defende uma boa prática. Segurança de aplicação quase nunca admite regra absoluta sobre conteúdo de dado."}}]}