Title: Engenharia de Software / Controles e Testes de Segurança
Tags: Engenharia_de_Software Resumo

front: (CESPE / FUB – 2022) A metodologia empregada nos testes de caixa branca tem como base a geração de casos de teste por meio do conhecimento da estrutura interna do programa.
response: Correto
comment: Os testes de caixa branca, também conhecidos como testes estruturais, focam na análise interna do software, explorando a lógica e a estrutura do código-fonte para criar casos de teste. Este método permite identificar problemas específicos, como loops infinitos, falhas em condições de contorno, e questões de segurança, como vulnerabilidades que poderiam ser exploradas por ataques. Ao contrário dos testes de caixa preta, que não requerem conhecimento sobre a estrutura interna do software, os testes de caixa branca são essenciais para garantir a qualidade e a segurança do código desde as fases iniciais de desenvolvimento.
tldr: - Teste (OWASP): comparar o estado do sistema/aplicação com critérios definidos para avaliar qualidade, desempenho e confiabilidade (não “arte obscura” baseada só em intuição).
- Objetivo do OWASP: padronizar e tornar acessível o teste de segurança, permitindo que pessoas sem grande expertise consigam testar melhor.
- Principais técnicas de teste:
- Inspeções/revisões manuais: avaliar pessoas, processos, políticas e decisões técnicas (“confie, mas verifique”).
- Modelagem de ameaças (Threat Modeling): identificar ativos, ameaças e vulnerabilidades cedo; priorizar mitigação e recursos.
- Revisão de código: detectar falhas complexas (concorrência, lógica de negócio, acesso, criptografia) e até código malicioso.
- Teste de penetração: simular ataques (caixa preta); útil, mas não suficiente sozinho (cobre só uma amostra de possíveis falhas).
- Princípios-chave:
- Não há bala de prata: segurança é processo contínuo, não um produto/ferramenta isolada.
- Pensar estrategicamente: evitar “corrigir e esquecer”; buscar causa raiz e integrar segurança ao SDLC.
- “SDLC é rei” + testar cedo e sempre: incorporar segurança em todas as fases reduz custo e retrabalho; treinar dev/QA para pensar como atacante.
- Automação em CI/CD: usar SAST, DAST e SCA para achar vulnerabilidades recorrentes e “low hanging fruit”.
- Definir escopo e requisitos: classificar ativos e alinhar conformidade legal/regulatória.
- Detalhismo e validação: eliminar falsos positivos, revisar profundamente e reportar riscos e correções de forma clara.
- Usar código-fonte quando possível e criar métricas para acompanhar evolução da segurança.
- Documentar resultados: relatórios reproduzíveis, auditáveis e orientados ao risco do negócio.
- Como testes de segurança entram no SDLC:
- Na implementação, devs usam análise estática (código) e testes dinâmicos/“unitários de segurança”.
- Antes de integrar, resultados são revisados/validados (frequentemente por dev sênior/lead).
- Em integração e sistema, testes avaliam o aplicativo completo (caixa branca, preta e cinza).
- Em validação pré-produção, times de QA cuidam de funcionalidade; engenheiros de segurança/hackers éticos executam testes de segurança; achados alimentam gestão de riscos, e falhas críticas normalmente precisam ser corrigidas (ou formalmente aceitas) antes do deploy.
link: https://documentacao.online/estudos/ve4r.html
title: Controles e Testes de Segurança
Other fields (not shown on cards):
back: Correto - Os testes de caixa branca, também conhecidos como testes estruturais, focam na análise interna do software, explorando a lógica e a estrutura do código-fonte para criar casos de teste. Este método permite identificar problemas específicos, como loops infinitos, falhas em condições de contorno, e questões de segurança, como vulnerabilidades que poderiam ser exploradas por ataques. Ao contrário dos testes de caixa preta, que não requerem conhecimento sobre a estrutura interna do software, os testes de caixa branca são essenciais para garantir a qualidade e a segurança do código desde as fases iniciais de desenvolvimento.

front: (FGV / MPE-AL – 2018) Controles e Testes de Segurança são objeto de atenção do desenvolvedor de sistemas, sempre que estiver codificando para o ambiente Web. Nesse contexto, a Open Web Application Security Project (OWASP), comunidade dedicada à segurança na Web, organizou, em seu site institucional, um guia de boas práticas de programação, assim como um guia de testes de segurança para aplicações web (OWASP Testing Guide), atualmente na versão 4.0. Assinale a opção que contém um princípio dos testes, de acordo com o OWASP Testing Guide 4.0.
a) Pense estrategicamente e taticamente (Think Strategically and Tactically).
b) Teste tardia e frequentemente (Test Late and Test Often).
c) Entenda o assunto em questão (Understand the Subject).
d) Desenvolva testes de caixa preta (Develop black box Tests).
e) Documente o resultado das métricas (Document Metric Results).
response: Letra C
comment: (a) Errado, o princípio correto seria Pensar Estrategicamente, Não Taticamente; (b) Errado, o princípio correto seria Testar Cedo e Testar Sempre; (c) Correto, o princípio correto é realmente Entender o Assunto; (d) Errado, o princípio correto seria Desenvolver a Mentalidade Certa; (e) Errado, o princípio correto seria Documentar o Resultado do Teste. Princípios DESCRIÇÃO Pensar estrategicamente, não taticamente Abandonar o modelo de "corrigir e penetrar" que foca apenas na correção superficial de bugs sem investigar a causa raiz. É essencial incorporar a segurança ao Ciclo de Vida do Desenvolvimento de Software (SDLC) desde o início e usar técnicas como modelagem de ameaças para alocar recursos a partes do sistema mais vulneráveis. Testar Cedo e Testar Sempre Detectar e corrigir bugs de segurança cedo no SDLC reduz custos e tempo. É importante educar as equipes de desenvolvimento e QA sobre questões de segurança e formas de detectá-las e preveni-las. A educação em testes de segurança também ajuda os desenvolvedores a adquirirem a mentalidade adequada para testar uma aplicação do ponto de vista de um atacante. Desenvolver a Mentalidade Certa Testar aplicativos em busca de vulnerabilidades requer pensar "fora da caixa" e considerar casos de uso não previstos. Os testadores de segurança devem pensar como atacantes para descobrir falhas de segurança potenciais, questionar suposições dos desenvolvedores e encontrar maneiras de subvertê-las. Entender o Assunto Documentar detalhadamente a arquitetura e os casos de uso do aplicativo e estabelecer uma infraestrutura de segurança que permita a monitorização e deteção de ataques. Documentar os Resultados do Teste Produzir um relatório formal das ações de teste realizadas, incluindo detalhes das descobertas, quem as executou e quando. O relatório deve identificar claramente os riscos para os proprietários do negócio e fornecer instruções claras para os desenvolvedores resolverem as vulnerabilidades. Ele também deve ser compreensível para auditores e outras partes interessadas e permitir que outros testadores reproduzam os resultados.
tldr: - Teste (OWASP): comparar o estado do sistema/aplicação com critérios definidos para avaliar qualidade, desempenho e confiabilidade (não “arte obscura” baseada só em intuição).
- Objetivo do OWASP: padronizar e tornar acessível o teste de segurança, permitindo que pessoas sem grande expertise consigam testar melhor.
- Principais técnicas de teste:
- Inspeções/revisões manuais: avaliar pessoas, processos, políticas e decisões técnicas (“confie, mas verifique”).
- Modelagem de ameaças (Threat Modeling): identificar ativos, ameaças e vulnerabilidades cedo; priorizar mitigação e recursos.
- Revisão de código: detectar falhas complexas (concorrência, lógica de negócio, acesso, criptografia) e até código malicioso.
- Teste de penetração: simular ataques (caixa preta); útil, mas não suficiente sozinho (cobre só uma amostra de possíveis falhas).
- Princípios-chave:
- Não há bala de prata: segurança é processo contínuo, não um produto/ferramenta isolada.
- Pensar estrategicamente: evitar “corrigir e esquecer”; buscar causa raiz e integrar segurança ao SDLC.
- “SDLC é rei” + testar cedo e sempre: incorporar segurança em todas as fases reduz custo e retrabalho; treinar dev/QA para pensar como atacante.
- Automação em CI/CD: usar SAST, DAST e SCA para achar vulnerabilidades recorrentes e “low hanging fruit”.
- Definir escopo e requisitos: classificar ativos e alinhar conformidade legal/regulatória.
- Detalhismo e validação: eliminar falsos positivos, revisar profundamente e reportar riscos e correções de forma clara.
- Usar código-fonte quando possível e criar métricas para acompanhar evolução da segurança.
- Documentar resultados: relatórios reproduzíveis, auditáveis e orientados ao risco do negócio.
- Como testes de segurança entram no SDLC:
- Na implementação, devs usam análise estática (código) e testes dinâmicos/“unitários de segurança”.
- Antes de integrar, resultados são revisados/validados (frequentemente por dev sênior/lead).
- Em integração e sistema, testes avaliam o aplicativo completo (caixa branca, preta e cinza).
- Em validação pré-produção, times de QA cuidam de funcionalidade; engenheiros de segurança/hackers éticos executam testes de segurança; achados alimentam gestão de riscos, e falhas críticas normalmente precisam ser corrigidas (ou formalmente aceitas) antes do deploy.
link: https://documentacao.online/estudos/ve4r.html
title: Controles e Testes de Segurança
Other fields (not shown on cards):
back: Letra C - (a) Errado, o princípio correto seria Pensar Estrategicamente, Não Taticamente; (b) Errado, o princípio correto seria Testar Cedo e Testar Sempre; (c) Correto, o princípio correto é realmente Entender o Assunto; (d) Errado, o princípio correto seria Desenvolver a Mentalidade Certa; (e) Errado, o princípio correto seria Documentar o Resultado do Teste. Princípios DESCRIÇÃO Pensar estrategicamente, não taticamente Abandonar o modelo de "corrigir e penetrar" que foca apenas na correção superficial de bugs sem investigar a causa raiz. É essencial incorporar a segurança ao Ciclo de Vida do Desenvolvimento de Software (SDLC) desde o início e usar técnicas como modelagem de ameaças para alocar recursos a partes do sistema mais vulneráveis. Testar Cedo e Testar Sempre Detectar e corrigir bugs de segurança cedo no SDLC reduz custos e tempo. É importante educar as equipes de desenvolvimento e QA sobre questões de segurança e formas de detectá-las e preveni-las. A educação em testes de segurança também ajuda os desenvolvedores a adquirirem a mentalidade adequada para testar uma aplicação do ponto de vista de um atacante. Desenvolver a Mentalidade Certa Testar aplicativos em busca de vulnerabilidades requer pensar "fora da caixa" e considerar casos de uso não previstos. Os testadores de segurança devem pensar como atacantes para descobrir falhas de segurança potenciais, questionar suposições dos desenvolvedores e encontrar maneiras de subvertê-las. Entender o Assunto Documentar detalhadamente a arquitetura e os casos de uso do aplicativo e estabelecer uma infraestrutura de segurança que permita a monitorização e deteção de ataques. Documentar os Resultados do Teste Produzir um relatório formal das ações de teste realizadas, incluindo detalhes das descobertas, quem as executou e quando. O relatório deve identificar claramente os riscos para os proprietários do negócio e fornecer instruções claras para os desenvolvedores resolverem as vulnerabilidades. Ele também deve ser compreensível para auditores e outras partes interessadas e permitir que outros testadores reproduzam os resultados.