Gest de Seg Software Development Life Cycle

Prévia do material em texto

Capítulo I :GESTÃO DA SEGURANÇA NO SDLC -Security Development 4 
Introdução ao Desenvolvimento Seguro ......................................................... 4 
Segurança em desenvolvimento .................................................................... 6 
Papéis e responsabilidades ............................................................................ 9 
Revisores ..................................................................................................... 9 
Especialistas............................................................................................... 10 
Auditores ................................................................................................... 11 
Facilitadores ............................................................................................... 11 
Conclusão .................................................................................................. 12 
1.1Capítulo II ...................................................................................... 13 
Introdução à modelagem de ameaças ......................................................... 13 
As vulnerabilidades do OWASP Top 10 ......................................................... 16 
Injeção ...................................................................................................... 17 
Quebra de Autenticação e Gerenciamento de Sessão .................................... 18 
Cross-Site Scripting (XSS) ........................................................................... 18 
Referência Insegura e Direta a Objetos........................................................ 18 
Configuração Incorreta de Segurança .......................................................... 19 
Exposição de Dados Sensíveis ..................................................................... 20 
Falta de Função para Controle do Nível de Acesso ........................................ 20 
Cross-Site Request Forgery (CSRF) .............................................................. 21 
Utilização de Componentes Vulneráveis Conhecidos ...................................... 21 
Redirecionamentos e Encaminhamentos Inválidos ........................................ 22 
1.1.................................................................... Erro! Indicador não definido. 
1.2 Capítulo III.................................................................................... 23 
Segurança por Código ................................................................................ 23 
Métricas dos processos ............................................................................... 26 
1.1........................................................................................................ 32 
1.2Capítulo IV ..................................................................................... 32 
Suporte na Revisão e Desenvolvimento........................................................ 32 
Capítulo I :GESTÃO DA SEGURANÇA NO SDLC -Security Development
 ............................................................................................................. 37 
Introdução ao Desenvolvimento Seguro ....................................................... 37 
Segurança em desenvolvimento .................................................................. 39 
Papéis e responsabilidades .......................................................................... 42 
 
 
 
Revisores ................................................................................................... 42 
Especialistas............................................................................................... 43 
Auditores ................................................................................................... 44 
Facilitadores ............................................................................................... 44 
Conclusão .................................................................................................. 45 
1.1Capítulo II ...................................................................................... 46 
Introdução à modelagem de ameaças ......................................................... 46 
As vulnerabilidades do OWASP Top 10 ......................................................... 49 
Injeção ...................................................................................................... 50 
Quebra de Autenticação e Gerenciamento de Sessão .................................... 50 
Cross-Site Scripting (XSS) ........................................................................... 51 
Referência Insegura e Direta a Objetos........................................................ 51 
Configuração Incorreta de Segurança .......................................................... 52 
Exposição de Dados Sensíveis ..................................................................... 52 
Falta de Função para Controle do Nível de Acesso ........................................ 53 
Cross-Site Request Forgery (CSRF) .............................................................. 54 
Utilização de Componentes Vulneráveis Conhecidos ...................................... 54 
Redirecionamentos e Encaminhamentos Inválidos ........................................ 55 
1.1........................................................................................................ 55 
1.2 Capítulo III.................................................................................... 55 
Segurança por Código ................................................................................ 55 
Métricas dos processos ............................................................................... 58 
1.2........................................................................................................ 64 
1.1Capítulo IV ..................................................................................... 64 
Suporte na Revisão e Desenvolvimento........................................................ 64 
 
 
 
Capítulo I :GESTÃO DA SEGURANÇA NO SDLC -Security 
Development 
Introdução ao Desenvolvimento Seguro 
 
O software, além do conceito de uma sequência de instruções que controlam o 
computador, do processamento de dados e informações é tido como uma 
tecnologia evolucionária e, por isso, já não é mais o mesmo, pois não utilizamos 
mais as linguagens de programação de décadas anteriores, e assim podemos 
perceber sua ampla transformação, além dos novos conceitos que surgem a 
cada momento no cenário mundial. Desse modo seu âmbito de aplicação é 
muito abrangente, já que se encontra presente desde o software de sistema, 
para fins de aplicações, pesquisas científicas, embarcados, linhas de produtos, 
aplicações para Web, inteligência artificial, entre outros, os quais são utilizados 
por pessoas, pela indústria ou pelo governo. 
A Engenharia de Software cuida da criação e do suporte dos programas e, 
desse modo, é vista como uma área muito importante, pois estamos cercados 
de sistemas a nossa volta, desde os mais simples até aqueles que se 
caracterizam por sua altíssima complexidade, onde também nos vemos 
marcados por inúmeras tecnologias que tornam sua utilização cada vez mais 
fácil no dia-a-dia. O software está presente em vários tipos de dispositivos 
como computadores, impressoras, celulares, tablets, games, marcapassos, na 
engenharia, eletrodomésticos, em redes sociais além de incontáveis sistemas e 
equipamentos, que passam por vezes despercebidos pelas pessoas. 
Há um tempo, tínhamos que instalar o software no computador pessoal e por 
incontáveis vezes fazer sua manutenção por meio de atualizações que corrigiam 
problemas como bugs e vulnerabilidades, mas hoje com a Internetcada vez 
mais presente no cotidiano, percebe-se que há uma tendência migratória das 
aplicações para servidores on-line, e com isso, temos os avanços percebidos 
pelo cloud computing, onde não se sabe sua localização e a maneira que 
rodam, por isso vemos que a modificação, correção e atualização são feitas de 
 
 
 
forma praticamente imperceptível aos olhos do usuário, marcando sua evolução 
de produto para serviço. 
O software como componente lógico produz, gerencia, adquire, modifica, exibe 
ou transmite informações úteis para gerenciar o processo de tomada de 
decisão, o que vai mais além do tratamento de dados, marcando sua presença 
na vida das pessoas. 
Com as mudanças no hardware e seus aprimoramentos, como uma maior 
capacidade de armazenamento, a ampliação da memória, as alterações 
ocorridas nas arquiteturas dos computadores, a criação de sistemas mais 
sofisticados e robustos, o software tem atingido patamares inimagináveis há 
bem pouco tempo. 
No desenvolvimento de software é comum ocorrer erros, por isso as tarefas de 
manutenção são mais complexas que as de hardware. Para se ter uma ideia de 
valores, um erro de software no início do projeto custa à empresa 
aproximadamente US$140 para ser corrigido, enquanto que um erro detectado 
na fase pós-implantação chega a custar impressionantes US$14.000. 
 
 
 
 
 
 
(http://www.isixsigma.com/industries/software-it/defect-prevention-reducing-
costs-and-enhancing-quality/) 
 
 
 
(https://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf) 
Segurança em desenvolvimento 
 
Com a evolução da Internet, o software hoje oferece funcionalidades imediatas 
(just-in-time), que podem ser acessadas por meio do navegador web e, para 
isso, é importante que seja implantado um processo de gestão de segurança da 
informação confiável, para garantir a manutenção de um nível aceitável de risco 
e operação. 
A reutilização dos componentes do software é uma prática que permite focar 
nas inovações do projeto, podendo-se implementar funções comuns por meio 
de partes repetidas de código, onde as estruturas de dados e detalhes de 
processamento são armazenadas em uma biblioteca de componentes para a 
construção de interfaces futuras. Com isso permite-se ganhar mais tempo nas 
partes importantes da aplicação, em vez de “reinventar a roda”. 
O custo para a correção de vulnerabilidades identificadas aumenta de maneira 
substancial a cada fase do ciclo de desenvolvimento do software (levantamento 
de requisitos, design, implementação, verificação, lançamento e suporte e 
manutenção), portanto, o quanto antes forem identificadas falhas de 
segurança, mais econômico ficará realizar sua manutenção, porque qualquer 
 
 
 
problema posterior acarretará um valor maior, podendo até inviabilizar o 
projeto. 
Por isso, é necessário que o profissional conheça as boas práticas de 
desenvolvimento e de segurança nesse contexto. Investir em segurança traz 
um retorno amplo não só para o projeto, mas também para os usuários. Além 
disso, há um menor investimento no tratamento de bugs, fazendo com que 
sejam reduzidos nesse processo tempo e recursos. 
Uma das propostas da disciplina é quebrar alguns dos paradigmas mais 
engessados, fazendo com que haja uma mudança na cultura dos profissionais 
do software, refletindo inclusive na própria organização, de maneira ampla, 
para que se possa obter qualidade e segurança nos produtos entregues. 
A maior parte das aplicações que estão em produção são vulneráveis a diversos 
tipos de ataques, por isso não se pode falar em um software completamente 
seguro ou blindado, mas pode-se tentar reduzir ao máximo o comprometimento 
das informações e o risco de ataques. Devido a isso, a OWASP (The Open Web 
Application Security Project) apresenta um ranking a partir de uma análise das 
falhas mais comuns em aplicações web, as quais estão presentes em 
praticamente todas as versões não testadas e adequadas do software. 
O processo de segurança denota a importância do software, e por isso deve-se 
visualizar todas as fases componentes do desenvolvimento de software 
(levantamento de requisitos, design, implementação, verificação, lançamento 
da aplicação e suporte e manutenção), para que se possa estudar o 
gerenciamento das principais metodologias utilizadas no mercado e, com isso, 
traçar uma base para as estratégias de uso empregadas pelas organizações, já 
que com as vulnerabilidades, a correção, adaptação e a expansão demandam 
mais pessoas e recursos do que o processo de criação em si. 
Para relembrar as fases do desenvolvimento de uma aplicação temos que na 
fase inicial, no Levantamento de Requisitos, se faz as listagens de recursos 
necessários, especificando as diretrizes de qualidades, além de documentar a 
 
 
 
arquitetura e fazer o agendamento de entrevistas. Na parte de Design da 
aplicação são realizadas as especificações funcionais e o desenho do software. 
A implementação é a fase onde se desenvolve o código, e na Verificação que se 
faz uma busca, além das correções de bugs, mas em ambas podem ser feitos 
testes e avaliações. No lançamento que se faz a assinatura do código e seu 
“encerramento”. Para a fase de suporte e manutenção, são feitas as 
atualizações segurança e correções de vulnerabilidades observadas. 
A arquitetura caracteriza-se por ser uma adaptação do software para atender 
às necessidades de novos ambientes e tecnologias, sendo realizada de maneira 
a trazer um aperfeiçoamento para que se possa implementar novos requisitos 
de um modelo de negócio, e com isso ser responsável pela expansão e 
interoperabilidade. 
Os recursos e funções das aplicações podem ser reutilizados muito facilmente, 
e levando em consideração a importância de projetar, e também de segurança, 
falhas, importância da qualidade, funcionalidade, há uma necessidade em 
poupar tempo e recursos para se concentrar no desenvolvimento da aplicação. 
O desenvolvedor deve levar em conta a tecnologia, os requisitos complexos, e a 
tomada de decisões estratégicas e táticas para proteger a aplicação dos riscos 
de segurança. Por isso é importante que se utilize uma metodologia prática, 
onde haja comunicação, pois é fundamental ouvir as necessidades dos clientes 
e interessados com fins de compreender seus objetivos e aplicá-los de modo 
preciso ao projeto, fazendo o levantamento das necessidades que definirão 
funções e características, além do planejamento (trabalho de engenharia de 
software, com as tarefas, riscos, recursos, produção e o cronograma), análise 
de requisitos, modelagem de projeto (esboço para compreender o problema e 
resolvê-lo, entendendo as necessidades do software através do projeto), 
construção de programa (criação de código e testes para descobrir os erros na 
codificação), até chegar aos testes e suporte. 
 
 
 
 
Papéis e responsabilidades 
 
Os profissionais do desenvolvimento seguro de software são responsáveis em 
apresentar e implantar um conjunto de práticas e metodologias aos 
programadores, o que resulta em melhores aplicações, com um nível muito 
maior de confiabilidade, maturidade, integridade e inviolabilidade. 
Os papéis apresentados se referem às responsabilidades, por isso as atividades 
de cada membro do projeto de desenvolvimento de software são essenciais em 
todas as etapas do planejamento da aplicação, especificando os requerimentos 
básicos para que cada função seja desempenhada da forma mais segura 
possível. 
As responsabilidades da equipe em relação ao Software Development Lifecycle 
são desenvolver, manter e aprimorar a aplicação, definindo aspectos 
obrigatórios do processo, fornecendo o treinamentoadequado aos engenheiros 
e supervisores, além de direcionar as equipes durante todo o processo, 
supervisionando e revisando a segurança por meio de equipes, e de maneira a 
fazer com que os especialistas abordem os aspectos de proteção do software, 
para que os supervisores de segurança possam se informar através de análises 
das respostas, oportunas e precisas, além de revisar a segurança antes que a 
aplicação seja lançada, buscando as vulnerabilidades que podem comprometer 
sua segurança, garantindo assim que as respostas sejam desejadas. 
Revisores 
 
Nesse cenário, os revisores são aqueles que examinam o código do aplicativo e 
sugerem correções ou adições, verificando e atestando sua qualidade, 
garantindo assim um alto nível de qualidade e integridade do software para que 
possa ser considerado robusto e seguro. Dessa forma por meio de sua análise e 
avaliação estão aptos a encontrar discrepâncias entre os procedimentos 
adotados e as metodologias adotadas, para colocá-los em conformidade com as 
 
 
 
necessidades da aplicação, além de participar de forma a verificar o impacto 
que as interferências propostas podem vir a causar. 
Também são responsáveis por diagnosticar através de testes e monitoramento 
simulações de execução do aplicativo no ambiente proposto da aplicação, o que 
pode fazer com que se ateste a existência de bugs e que aprendam com os 
resultados obtidos através dos erros encontrados nas fases de testes, os quais 
podem até ser documentados, para posterior verificação. 
O revisor realiza uma extensa análise da aplicação através do ponto de vista do 
desenvolvedor, testador e do usuário final, onde estuda os cenários possíveis e 
define questões importantes em relação às funções, o ajudando a documentar 
problemas surgidos e estabelecer procedimentos operacionais para elaborar 
estratégias por meio das perspectivas examinadas. 
As atribuições do revisor são: documentar cenários e detalhes, verificar as 
interfaces e interpretar os caos de testes de acordo com suas funcionalidades 
além de conferir os padrões e metodologias de desenvolvimento que são 
estabelecidos pela empresa, de maneira a informar se a aplicação está 
funcionando dentro do que foi proposto e compreendendo o processo de forma 
a aumentar a performance do software em suas verificações, onde irá detectar 
e corrigir os problemas e erros causados pelas inconsistências. 
Especialistas 
 
O especialista é o profissional de TI responsável por determinar se a segurança 
está presente na produção do software, descobrindo falhas por meio de 
análises, realizando atualizações e fazendo o controle de versões, por meio de 
correções das falhas conhecidas, o que deve acontecer o mais rápido possível 
após suas descobertas. 
Um dos papéis do especialista é o de conhecer e avaliar as diversas tecnologias 
disponíveis além de analisar as vantagens e desvantagens de sua aplicação no 
 
 
 
software para as soluções propostas, e na implementação do aplicativo, 
ajudando a aprimorar os requisitos. 
Uma de suas responsabilidades fundamentais é avaliar e preparar a rotina dos 
acontecimentos na fase de testes, devendo observar os comportamentos 
possíveis, prováveis e remotos do usuário relacionados com a aplicação, de 
maneira a realizar um amplo diagnóstico, crítico e preciso com informações 
objetivas sobre eventuais problemas ou erros percebidos para a equipe 
desenvolvedora, assegurando o cumprimento das finalidades planejadas 
através de análises dos resultados observados, buscando prevenir a ocorrência 
de quaisquer vulnerabilidades. 
Auditores 
 
Os auditores são os profissionais que dentre suas responsabilidades se utilizam 
das ferramentas de auditoria para verificar se a aplicação atingiu as metas e 
critérios definidos no planejamento, sendo responsáveis pelo procedimento de 
investigação do processamento, simulação, análise e avaliação dos dados. 
Além disso, o auditor deve compreender o ambiente de desenvolvimento da 
aplicação de forma a realizar uma análise mais ampla, entendendo e 
determinando as situações ocorridas, conferindo o planejamento e os objetivos 
da aplicação, de forma a verificar e elaborar os testes e simulações necessários 
mais adequados ao software, emitindo opiniões e acompanhando propostas de 
melhorias e correção, bem como sua implantação. 
Facilitadores 
 
O facilitador também é conhecido como o coordenador das atividades, ou seja, 
em outras palavras, é o líder do projeto, e por isso uma de suas funções mais 
importantes é garantir que as metodologias de segurança serão aplicadas de 
forma correta ao processo de desenvolvimento do software. 
 
 
 
Uma de suas responsabilidades é trabalhar junto com o gestor, de modo a 
realizar o planejamento da aplicação em todo o ciclo de desenvolvimento, em 
todos os seus aspectos, devendo ter uma visão expandida do software, de seus 
processos, técnicas além de boas práticas, gerenciando a equipe do projeto e 
administrando o relacionamento com o cliente. 
Uma das funções do facilitador é sempre estar próximo aos desenvolvedores e 
ao cliente, esclarecendo as questões primordiais de risco relacionadas à 
aplicação, verificando arduamente a aplicabilidade de métricas, as necessidades 
surgidas e os recursos indispensáveis, além de estar ciente de todos os erros 
descobertos e trabalhar dentro dos padrões de segurança exigidos. 
Conclusão 
 
Portanto, podemos perceber que no ciclo do processo de desenvolvimento da 
aplicação sempre será necessário efetuar correções, onde cada empresa pode 
adotar o modelo que entender mais adequado para suprir suas exigências, por 
isso é ideal que se prepare e administre esse processo de uma maneira a 
aperfeiçoá-lo, realizando adaptações para que se mostre sempre seguro, e para 
isso vislumbra-se necessária a interferência dos profissionais de modo a 
executar análises e testes que objetivam deixá-lo menos vulneráveis, por isso 
seus papéis são de grande importância. 
Nos primórdios da Internet, os sites eram conjuntos de arquivos de hipertexto 
onde as informações usavam textos e gráficos, porém, com o aumento e 
popularização das ferramentas de desenvolvimento voltadas para a Web 
surgiram os sistemas e aplicações baseados na Internet, que posteriormente 
evoluíram para ferramentas computacionais com funções especializadas com 
foco no usuário, e o próximo passo a ser alcançado é o Software como Serviço. 
Falar em desenvolvimento seguro no ciclo de vida do software requer um 
planejamento estruturado forte, pois os WebApps apresentam características 
como o uso intenso da rede, a simultaneidade, carga de usuários não previsível, 
desempenho, disponibilidade, orientação a dados, sensibilidade de conteúdo, 
 
 
 
evolução contínua, imediatismo, segurança e estética, por isso é necessário que 
os profissionais estejam sempre atualizados, porque o risco de ameaças é 
iminente. 
Como estão disponíveis na Internet de forma duradoura, a problemática é 
limitar os acessos pelos usuários finais para que se possa proteger os 
conteúdos sensíveis e oferecer modos seguros de transmissão de dados, sendo 
prioridade a implementação medidas para a proteção na infraestrutura do 
software. 
1.1Capítulo II 
Introdução à modelagem de ameaças 
 
A modelagem de ameaças tem suas origens estabelecidas a partir de um 
conceito militar surgido nos Estados Unidos, sendo que atualmente sua 
estruturação é voltada ao software, por meio de documentações desenvolvidas 
pela Microsoft, onde através de uma ferramenta proprietária são mapeados os 
riscos associados a aplicação aprendendo a tratá-los. 
Para os militares dos Estados Unidos essa conceituaçãoda modelagem de 
ameaças envolve a análise de riscos, sua motivação, a capacidade, sua 
viabilidade e cenários de defesa em face de um possível ataque, que traduzidos 
para a linguagem de segurança da aplicação são realizados estudos a partir da 
compreensão do correto mapeamento de exploits (uma sequência de comandos 
elaborados por hackers que conseguem tirar proveito de um defeito ou 
vulnerabilidade). 
Podemos definir a modelagem de ameaças como um processo estratégico que 
considera a possibilidade de inúmeros cenários de ataque e vulnerabilidades as 
quais podem ocorrem dentro de um ambiente de aplicação, com o propósito de 
identificar os níveis de risco e impacto que podem comprometer a proteção do 
software, para fins de melhorá-lo. 
 
 
 
Com essa visão é primordial que se aprenda a administrar sistematicamente 
quaisquer ameaças e ataques em potencial, por meio de uma abordagem 
estruturada e precisa, que aplique os recursos de segurança de forma 
estratégica, sem causar um desperdício financeiro na busca de ameaças 
improváveis. 
A documentação referente ao tratamento das vulnerabilidades de segurança da 
aplicação deve ser executada a partir da análise e um estudo das ameaças e 
riscos potenciais, onde é classificada por ordem lógica, começando pela 
identificação das mais específicas e prováveis, das que apresentam os maiores 
riscos até as que são vistas como improváveis, mas que podem afetar o 
software. 
O profissional de Tecnologia da Informação que trabalha com segurança de 
software deve ter em mente que desde o momento em que a aplicação foi 
lançada e está disponibilizada na Internet, é considerado um ambiente hostil, 
portanto deve-se perceber os diversos tipos de ameaças que podem ocorrer, e 
por isso é necessário administrar os riscos através de avaliações e análises 
regulares. 
O processo de modelagem de ameaças engloba o desenvolvimento da análise e 
elaboração de técnicas para que se possa identificar e quantificar os riscos 
envolvidos, começando com: a “Identificação dos bens da aplicação” onde 
serão listados todos os recursos que o sistema deve proteger mantendo-os em 
segurança; depois deve-se “criar um panorama de desenho da arquitetura” 
descrevendo como a aplicação funciona; seguido da “decomposição do 
software” em partes e tipos de dados lidos da aplicação e dos usuários, para 
que se possa cobrir qualquer tipo de vulnerabilidade; logo após será necessário 
“identificar a ocorrência de ameaças potenciais” que podem prejudicar o 
sistema e comprometer os recursos; seguido da “documentação das ameaças” 
em um modelo que defina os atributos do software; e por fim deve-se 
“classificar as ameaças” começando pelas mais prováveis e os possíveis danos 
causados em caso de ataque. 
 
 
 
A documentação sobre as ameaças potenciais à segurança da aplicação é 
realizada através de um processo iterativo, ou seja, que se repete 
estrategicamente, de forma contínua, e pode ser utilizado pelos designers, 
desenvolvedores e testadores, pois dessa forma ajuda na tecnologia 
empregada, nas funcionalidades, na redução dos riscos e vulnerabilidades. 
É importante realizar uma análise de riscos de um projeto de desenvolvimento 
de aplicações, onde é necessário visualizar e identificar os recursos disponíveis, 
saber onde estão localizadas as ameaças e vulnerabilidades que podem quebrar 
a segurança do software, para que seja possível tratá-las, evitando os ataques 
e para que se possa assumir um maior controle através da proteção 
implementada. 
Para isso deve-se criar uma arquitetura padronizada, além de estabelecer uma 
documentação em conformidade com as metodologias estipuladas pela equipe, 
sendo de fundamental importância identificar a proposta da aplicação e o que 
ela faz, além de elaborar um diagrama e identificar as tecnologias empregadas, 
porque isso pode ajudar bastante a reduzir os esforços da equipe nas etapas do 
ciclo de vida do desenvolvimento do software. 
Depois de toda essa parte de documentação dos objetivos deve-se decompor o 
software, de maneira onde serão identificados os limites de confiança, além do 
fluxo de dados, os pontos de entrada e também do código privilegiado para que 
se possa documentar o perfil de segurança da aplicação e poder ajustar a 
proteção com base nos tipos de riscos mais prováveis. 
A próxima etapa é a de identificar as ameaças, que podem ser feitas por meio 
de um método, por exemplo, o STRIDE (Spoofing, Tampering, Repudiation, 
Information Disclosure, Denial of Service, Elevation of Privilege), que pode 
conter a verificação das ameaças de redes, de hosts e de aplicação. 
No Spoofing um atacante tenta se passar por alguém que não é para invadir o 
software. Já no Tampering o atacante tenta modificar dados trocados por uma 
aplicação e um usuário autorizado. Quando o atacante consegue penetrar na 
 
 
 
aplicação sem que sua autoria seja reconhecida, é chamado de Repudiation. No 
Information Disclosure o atacante pode ler dados particulares que a aplicação 
transmite ou armazena. Caso o atacante impossibilite o acesso dos usuários a 
aplicação ou o serviço ocorre o Denial of Service. Ao se conseguir privilégios 
não autorizados por um meio não permitido pelo atacante, chama-se Elevation 
of Privilege. 
Enquanto o STRIDE faz uma análise e classificação das ameaças, propondo a 
redução dos riscos, o modelo DREAD (Damage Potential, Reproducibility, 
Exploitability, Affected Users, Discoverability) é utilizado para calcular a 
estimativa do risco total que é associado a uma ameaça de segurança na 
aplicação. 
Para que se aplique o modelo DREAD deve-se verificar o potencial de danos 
causado (Damage), a extensão do dano caso a vulnerabilidade seja explorada 
pelo invasor, depois a facilidade com a qual um ataque é reproduzido 
(Reprodution), e para a capacidade de exploração, a simplicidade quando 
ocorre o lançamento de um ataque (Exploration), os usuários afetados pela 
ameaça (Affected), e por fim a agilidade a qual é descoberta a vulnerabilidade 
(Discovery). 
O profissional do desenvolvimento seguro deve documentar as ameaças, pois é 
a melhor prática, tendo em vista que servirá de apoio a futuras verificações de 
vulnerabilidades na aplicação pela equipe, já que dessa forma é mais fácil 
analisar os riscos e determinar os recursos necessários para suprir qualquer 
brecha que a aplicação possa conter, além de possibilitar que as correções 
sejam feitas com base nessa informação. 
As vulnerabilidades do OWASP Top 10 
 
A OWASP é uma organização sem fins lucrativos, que tem como objetivo 
disseminar a segurança voltada a aplicações web. Seu Top 10 é composto pelas 
vulnerabilidades que mais ocorrem nos WebApps, onde se busca identificar os 
 
 
 
riscos mais graves das aplicações através de informações comuns sobre a 
probabilidade de ocorrência e impacto técnico. 
A Metodologia de Classificação de Riscos da OWASP deriva do tipo de ataque, 
tipo de vulnerabilidade ou do tipo de impacto causado pela invasão, 
demonstrando que os pontos fracos da aplicação podem acontecer por meio de 
Agentes de Ameaça ou Controles de Segurança. 
Os ataques a aplicações podem ocorrer por diferentes maneiras, causando 
danos e representando um risco que pode ser grave e causador de danos, o 
que pode ter consequências graves. Para determinar o impacto do risco é 
necessário avaliar a probabilidade associada a cada agente de ameaça, vetor de 
ataque, vulnerabilidade de segurança e combinar com uma estimativa dos 
impactos técnicos e negociais, onde juntos esses fatores determinam o risco 
total. 
Injeção 
 
As falhas de injeção ocorrem quando dados não confiáveis sãoenviados para 
um interpretador como parte de um comando ou consulta. Nesse cenário os 
dados são manipulados pelo atacante de maneira que podem burlar o 
interpretador para que sejam executados comandos indesejados ou mesmo 
para que se permita o acesso não autorizado. 
Para prevenir que aconteça uma falha de injeção é necessário separar os dados 
não confiáveis dos comandos e consultas, através da utilização de uma API 
segura que não utilize o interpretador inteiramente ou que tenha uma interface 
parametrizada, mas o ideal é realizar a filtragem dos caracteres especiais 
utilizando uma sintaxe para o interpretador e também se recomenda-se uma 
validação de entrada positiva. 
 
 
 
Quebra de Autenticação e Gerenciamento de Sessão 
 
As funções da aplicação estão relacionadas a autenticação e gerenciamento de 
sessão quando são implementadas de maneira errada permitem que os 
atacantes comprometam as senhas, chaves e tokens de sessão ou mesmo para 
explorar alguma falha de implementação assumindo a identidade de outros 
usuários. 
Para evitar essa vulnerabilidade, deve-se disponibilizar aos desenvolvedores um 
conjunto de controles fortes para autenticação e gerenciamento de sessão, que 
se enquadrem em um padrão de verificação de segurança da aplicação, além 
de impedir falhas de XSS que podem roubar os Identificadores de sessão. 
Cross-Site Scripting (XSS) 
 
As falhas de XSS ocorrem quando uma aplicação recebe e envia ao navegador 
dados não confiáveis sem validação ou sem um filtro adequado, permitindo que 
os atacantes executem scripts no navegador da vítima, desfigurar sites, 
podendo inclusive “sequestrar” sessões do usuário ou redirecioná-lo para sites 
maliciosos. 
É necessário separar os dados não confiáveis do conteúdo ativo no navegador, 
por meio de filtro com base no HTML e o contexto o qual serão colocados 
através de técnicas de filtro de dados, uma validação de entrada positiva que 
ajuda na proteção, já que muitas aplicações requerem caracteres especiais na 
entrada, também deve ser considerado o uso de bibliotecas de auto-sanitização 
e a Content Security Policy no site para defesa contra esse tipo de 
vulnerabilidade. 
Referência Insegura e Direta a Objetos 
 
Uma referência insegura e direta a um objeto ocorre quando o programador 
expõe um arquivo, diretório ou registro da base de dados. Quando é feita uma 
referência à implementação interna de um objeto sem a verificação do controle 
 
 
 
de acesso ou outra proteção os atacantes podem inclusive manipular e acessar 
dados não autorizados. 
Para que haja a prevenção à referência insegura e direta a objetos deve haver 
uma abordagem para proteger os objetos acessíveis ao usuário ou sessão, 
impedindo que o atacante acesse recursos não autorizados, e fazendo com que 
a aplicação mapeie as referencias indiretas por cada usuário retornando a 
chave do banco de dados real no servidor, dessa forma recomenda-se a 
utilização de mapas de referencia de acesso sequencial e aleatório para eliminar 
as referências diretas a objetos, e também a verificação do acesso quando se 
utilizar uma origem não confiável, incluindo um controle de acesso que garanta 
que o usuário esteja autorizado em sua requisição. 
Configuração Incorreta de Segurança 
 
Quando se utiliza uma configuração pré-definida de segurança implementada 
na aplicação (frameworks, servidor de aplicação, servidor web, banco de dados 
e plataforma) um risco exponencial pode ocorrer, pois o invasor conhece o 
formato dos padrões facilitando uma possível vulnerabilidade. Dessa maneira o 
mais indicado é que todas as configurações devam ser bem definidas, 
implementadas e mantidas, porque a configuração padrão é insegura por ser 
previsível, sendo outra medida importante a atualização do software. 
O processo de hardening recorrente é de fácil e rápida implantação em um 
ambiente blindado, onde estes devem ser configurados identicamente e de 
forma automatizada, mas respeitando as questões de segurança, de forma de 
se realizar a manutenção de atualizações e correções em tempo hábil para cada 
ambiente. Outra forma é implementar uma arquitetura forte que promova a 
separação segura e eficaz entre os componentes. Realizar auditorias e 
varreduras periódicas para detectar erros de configuração ou correções 
necessárias. 
 
 
 
Exposição de Dados Sensíveis 
 
A não proteção dos dados sensíveis como cartões de crédito, Identificadores 
fiscais e credenciais de autenticação pode expor e comprometer a segurança do 
usuário. Os atacantes podem roubar ou modificar dados desprotegidos com o 
propósito de realizar fraudes, roubos de identidades ou outros crimes. Por isso 
os dados sensíveis merecem proteção como criptografia no armazenamento ou 
tráfego e precauções especiais em relação a sua utilização pelo navegador. 
Para a proteção dos dados sensíveis frente a ameaças deve-se contar com uma 
criptografia inibitória, que tenham algoritmos especializados e chaves fortes, 
além de boas práticas de gerenciamento, onde não é recomendado o 
armazenamento de dados sensíveis desnecessariamente. Outra ajuda é 
desabilitar o cache e o recurso de auto completar em formulários em páginas 
que manipulam dados sensíveis. 
Falta de Função para Controle do Nível de Acesso 
 
A maioria das aplicações web verificam os direitos de acesso em nível de função 
antes de tornar a funcionalidade visível na interface do usuário, e depois 
precisam executar as mesmas verificações de controle de acesso no servidor 
quando a função é invocada. Se as requisições não forem verificadas, os 
atacantes podem forjar as requisições para acessar funcionalidades sem a 
autorização adequada. 
A aplicação deve contar com um módulo de autorização implementado que seja 
de fácil análise e efetue chamadas pelas funções de negócio, por isso, é 
necessário que os processos de gerenciamento de direitos sejam de simples 
atualização e auditoria, onde para a execução de qualquer mecanismo deve ter 
seu acesso negado por padrão, exigindo direitos necessários para que se 
permita o acesso através de uma lógica do controlador ou do negócio. 
 
 
 
 
Cross-Site Request Forgery (CSRF) 
 
O ataque CSRF força a vítima que possui uma sessão ativa em um navegador a 
enviar uma requisição HTTP forjada, incluindo o cookie da sessão da vítima e 
qualquer outra informação e dados de autenticação incluídos na sessão a uma 
aplicação web vulnerável. A falha permite o atacante forçar o navegador da 
vítima a criar requisições que a aplicação vulnerável aceita como legítimas e 
realizadas pela vítima. 
Esse tipo de ataque pode ser facilmente evitado quando se implementa um 
token único imprevisível em cada requisição HTTP, que pode ser incluído em 
um campo oculto e evitando ser enviado na URL, o que pode comprometer a 
segurança por meio de sua exposição direta, pode-se também incluir tokens 
automaticamente com métodos preventivos para as vulnerabilidades ou exigir 
uma nova autenticação do usuário para que prove sua identidade. 
Utilização de Componentes Vulneráveis Conhecidos 
 
A utilização de Componentes como Bibliotecas, Frameworks e outros módulos 
de software quase sempre são executados com privilégios elevados. O 
Componente vulnerável é explorado por meio de um ataque que pode causar 
perdas de dados ou comprometimento do servidor. As aplicações que utilizam 
componentes com vulnerabilidades conhecidas podem minar as suas defesas 
permitindo ataques e impactos. 
Utilizar componentes vulneráveis é um risco crítico, pois podem estar 
desatualizados e sem correções para as vulnerabilidades, por isso no projeto de 
um software é necessárioque todos os componentes sejam identificados, além 
das versões e dependências, para que se possa monitorar a segurança em um 
banco de dados público, mantendo-os sempre atualizados, estabelecer políticas 
de seguranças que definam o uso do componente e exigir práticas no 
desenvolvimento de software que passaram nos testes de segurança e que 
 
 
 
tenham licenças aceitáveis, e também desabilitar funcionalidades não utilizadas 
para proteger falhas ou aspectos vulneráveis dos componentes. 
Redirecionamentos e Encaminhamentos Inválidos 
 
As aplicações web frequentemente redirecionam e encaminham usuários para 
outras páginas e sites, utilizando dados não confiáveis para determinar as 
páginas de destino. Sem uma validação adequada os atacantes podem 
facilmente redirecionar as vítimas para sites de phishing, malware ou usar 
encaminhamentos para acessar páginas não autorizadas. 
Para os redirecionamentos e encaminhamentos, pode-se simplesmente não 
utilizá-los, ou caso usados, evitar envolver parâmetros do usuário para calcular 
o destino, ou caso esses parâmetros não possam ser evitados, deve-se 
assegurar que o valor fornecido é válido e autorizado para o usuário, além de 
recomendar que os parâmetros de destino sejam mapeados e não estejam na 
URL, de maneira que o servidor traduza para seu destino, pois as aplicações 
podem utilizar métodos de redirecionamento seguro, evitando fraudes que 
tentam obter a confiança do usuário. 
Para a Segurança no Ciclo de Vida do Desenvolvimento o OWASP recomenda 
que para a melhoria dos processos nas aplicações se utilize o Modelo de 
Maturidade de Garantia do Software (SAMM), que ajuda a formular e 
implementar estratégias para a segurança do software feita de forma 
personalizada para os riscos específicos enfrentados. 
 
 
 
1.1 
1.2 Capítulo III 
Segurança por Código 
 
Pode-se conceituar a segurança por código como o conjunto de técnicas criadas 
para o tratamento de vulnerabilidades, além dos cuidados necessários que 
devem ser tomados no desenvolvimento seguro de software, já que em toda a 
etapa do ciclo de vida existem erros de programação. 
Dentro desse contexto visualizamos as práticas listadas pela OWASP Top 10 
que ajudam os profissionais a se proteger contra as vulnerabilidades de 
segurança mais comuns nas aplicações Web, fornecendo técnicas para 
aprimorar a salvaguarda do software desenvolvido. 
Na fase de desenvolvimento devem ser elaborados requisitos de processo para 
garantir que as técnicas de segurança utilizadas por código sejam 
implementadas através de boas práticas, Validação de Entradas e Codificação 
de Saída, Autenticação e Gerenciamento de Senhas, Autorização e 
Gerenciamento de Acesso, Gerenciamento de Sessão, Transmissão e 
Armazenamento de Informações Sensíveis, Interação com o Banco de Dados, 
Tratamento adequado de erros e Logging. 
Como práticas adotadas que visam um código seguro, vemos simples exemplos 
como não armazenar senhas diretamente, não utilizar códigos copiados sem 
entender seu funcionamento, não utilizar funções ou recursos desatualizados, 
por isso deve-se buscar sempre a implementação de segurança na etapa de 
validação dos dados. 
A Validação de Entradas e Codificação de Saída é uma técnica onde a validação 
de qualquer interação realizada entre a aplicação e o usuário deve ser feita na 
entrada e na apresentação dos dados recebidos, com as de segurança 
adequadas, sempre realizadas no servidor para evitar riscos, sendo que no 
 
 
 
cliente é opcional, mas sempre de maneira a adotar validação positiva, nunca 
se esquecendo que há possibilidade de um by-pass nessa etapa. 
Para a Autenticação e Gerenciamento de Senhas, deve-se utilizar o HTTP POST 
para fazer uma requisição de autenticação, e o HTTPS para o envio de 
credenciais, sempre pedindo uma nova autenticação em ações críticas, usando 
o hash e o salt para codificar as senhas armazenadas, utilizando um algoritmo 
de hash público e forte, e implementando um grau de complexidade nas 
senhas, além de desaconselhar usuários a utilizar senhas fracas, por meio de 
uma classe ou mecanismo de validação que possa garantir uma política de 
senhas como a do DECEA, desabilitar os lembretes de senha e o recurso de 
auto-completar dados nos navegadores, utilizar mensagens genéricas nas 
tentativas de login ou senhas incorretas, bem como ter um bom planejamento 
dos processos de recuperação de senha, para não expor os dados sensíveis do 
software. 
A Autorização e Gerenciamento de Acesso da aplicação deve ser elaborada por 
meio de restrições de acesso dos perfis em relação aos conteúdos ou 
operações, que devem apresentar uma política de segurança forte e não 
apenas utilizada através de links ocultos, devendo ser feita a validação no 
servidor a cada requisição, garantindo dessa forma que os arquivos e diretórios 
não sejam acessados diretamente, e também que não seja armazenada 
nenhuma informação que comprometa o controle de acesso do usuário, onde é 
prioridade que deva ser realizado um novo login quando houver alguma 
alteração no perfil do usuário, para que não permaneça com o acesso no caso 
de serem retirados privilégios de acesso. 
O Gerenciamento de Sessão e seu controle devem ser feitos pelo servidor, por 
meio de um método de time-out por sessão e que se seja gerado um novo 
identificador após a autenticação, pois não se deve passar identificadores de 
sessão por HTTP GET. Além disso, deve ser implementado um token de sessão 
aleatório a cada nova requisição para evitar ataques CSRF. 
 
 
 
Na Transmissão e Armazenamento de Informações os dados sensíveis devem 
ser transmitidos via HTTPS, pois não se deve armazenar senhas ou dados 
importantes sem uma boa criptografia, bem como não se deve enviar 
informações sensíveis para logs, sendo recomendável que os comentários de 
código não devam conter qualquer tipo de informações que possam 
comprometer a segurança, dessa forma garantindo que a lógica do código não 
crie vulnerabilidades ou exposições pelo lado do usuário, porque os campos 
ocultos não devem armazenar dados sensíveis, devendo utilizar os cabeçalhos 
HTTPS, onde as senhas podem ser revertidas pelo lado do usuário, mas não se 
deve apresentar dados sensíveis com esse recurso. 
A Interação com o Banco de Dados deve adotar Stored Procedures ou Prepared 
Statement, ou então validar todas as interações realizadas com o banco, 
evitando as concatenações para realizar consultas no banco, desabilitar os 
recursos não utilizados, acessar o banco com um usuário com privilégio 
necessário para realizar as operações necessárias, além de não deixar o banco 
ser acessado por outro canal que não a aplicação. 
Para o Tratamento adequado de erros deve-se usar uma estrutura confiável em 
qualquer método onde um erro possa ocorrer, além de utilizar funções como a 
finally para realizar as ações de limpeza corretamente, garantindo assim uma 
redução nas vulnerabilidades do software. 
O Logging como parte da concepção do sistema, deve demonstrar claridade em 
seu uso na aplicação, porque seu objetivo é o de viabilizar auditorias e 
investigações de fraude e casos de abuso em sua implementação errática, 
portanto é altamente recomendável que seja utilizado. 
Mais além dos recursos explicados, a segurança por código envolve muitos 
aspectos de segurança, e segundo o disposto pelo Common Weakness 
Enumeration, que descreve as vulnerabilidades publicamente conhecidas, 
vemos que podem ocorrer: as Falhas na lógica, os Erros numéricos, a 
Conversão de Signed para Unsigned, o Uncontrolled Format String, o 
 
 
 
Information Exposure, os Buffers Overflows, os Races Conditions, o CovertTiming Channel e os Cryptographic Problems. 
Métricas dos processos 
 
No ciclo de vida do software, as métricas são caracterizadas como um conjunto 
de metodologias sistematicamente elaboradas para determinar padrões no 
processo de desenvolvimento seguro, e também servem como um modelo para 
a administração de referências, o qual pode ser utilizado pelos responsáveis 
pelo projeto para suportar um processo de maturidade crescente. 
Dessa maneira, desenvolvimento de aplicações seguras a métrica se caracteriza 
como uma metodologia serve para ajudar os engenheiros de software, desde as 
etapas mais iniciais de visualização do projeto até as posteriores como 
construção do sistema e reparos, sempre visualizando os atributos específicos e 
mensuráveis da aplicação. 
Por isso é fundamental sua utilização, pois ajuda os engenheiros de software a 
controlar a criação de aplicativos com padrões que conferem alta qualidade. Aí 
entra outro fator de sua importância, porque somente a avaliação quantitativa 
mostra-se insuficiente, e nesse escopo é necessário o estabelecimento de 
critérios que possam ser utilizados para a orientação do projetos, sua 
arquitetura, interface e componentes utilizados. 
Na fase de testes existe a orientação quantitativa, que serve para ajudar na 
seleção dos casos, além de apresentar seus objetivos relacionados 
especificamente a aplicação, sendo assim, a métrica possibilita a definição de 
padrões, onde a análise, projeto, codificação e testes possam ser executados 
de forma mais precisa e focada no software. 
Para que se possa implantar o processo de métricas com sucesso, primeiro é 
necessário sua definição, para depois aplicá-las e posteriormente realizar uma 
análise de acordo com as diretrizes preestabelecidas, de acordo com os dados 
avaliados, onde os resultados das análises são estudados e interpretados de 
 
 
 
forma a obter o máximo de informações sobre a qualidade da aplicação, 
podendo levar a alterações no projeto, primando a segurança como fato 
essencial. 
As métricas do software são desenvolvidas por meio de dados coletados dos 
requisitos e modelos de projeto, código-fonte e dos casos de teste, 
estabelecendo os objetivos do projeto antes da coleta de dados, desse modo 
não podem ser ambíguas, e devem ser utilizadas para obter informações sobre 
a qualidade da segurança de um software. 
No desenvolvimento seguro de software mesmo que as métricas da aplicação 
sejam imperfeitas, elas representam uma forma sistemática de avaliar a 
qualidade com base em um conjunto de regras claramente definidas, 
proporcionando uma visão objetiva da segurança, permitindo descobrir e 
corrigir potenciais problemas antes que se tornem falhas e vulnerabilidades. 
As medidas utilizadas para avaliar a qualidade da aplicação são determinantes 
na eficácia dos modelos de requisitos, projeto e código, além dos casos de teste 
e na qualidade geral da aplicação criada, porque enquanto está sendo 
projetada, sempre haverá um processo de avaliação interno do software. 
Entretanto, para que se possa alcançar a melhor qualidade de software em 
relação a segurança da aplicação é necessário estabelecer os requisitos com 
precisão para evitar a ocorrência de falhas, pois quando os objetivos estão mal 
definidos ou há erros no ciclo de vida do software, o risco de acontecerem 
vulnerabilidades aumenta substancialmente. 
Por isso os teste de software se mostram essenciais, porque se revelam como 
um elemento crítico para a garantia de qualidade da aplicação, já que 
representam as revisões de especificação, projeto e codificação, segundo as 
observações analisadas pela equipe de desenvolvimento. 
Ao se aprofundar mais no estudo de métricas, vemos que elas são classificadas 
regularmente como métricas do processo ou métricas do produto, de maneira 
 
 
 
que são criadas e aplicadas durante o processo de desenvolvimento seguro e 
também para a aplicação já desenvolvida. 
As métricas surgiram dentro da engenharia de software e seu objetivo principal 
é garantir a qualidade do software através da definição e normalização de 
processos no desenvolvimento de aplicações. Mesmo que os modelos aplicados 
nas mesmas circunstâncias atuem principalmente no processo, o propósito mais 
importante no estabelecimento de métricas é a garantia de que a criação do 
software corresponda às expectativas e possa suprir as necessidades do cliente, 
dentro do que foi acordado no projeto. 
Dessa maneira tem-se um processo de busca constante pela qualidade, não 
apenas no início ou no final projeto, através da execução de testes, mas sim de 
uma forma que visa abranger toda a engenharia de software, de forma 
permanente e contínua, contando com a colaboração de todos os membros do 
time do projeto. 
Para se falar na melhor qualidade no desenvolvimento de software e seu foco 
em segurança, dentro desse escopo deve haver uma fase de Revisão do 
Produto, constituída por etapas de manutenção, flexibilidade e testabilidade, 
depois uma fase Transição do produto, onde é feita a portabilidade, reutilização 
e interoperabilidade, e logo após na fase de Operação do Produto, que ocorrem 
as análises e verificações, correção, confiabilidade, usabilidade, Integridade e 
eficiência do software. 
Vemos que para a aplicação funcionar da melhor forma, deve apresentar várias 
características operacionais, para que a equipe possa garantir sua qualidade 
com base no projetado, a começar com as matérias mais críticas do ciclo de 
vida do software, como: correção, confiabilidade, eficiência, integridade, 
usabilidade, manutenibilidade, flexibilidade, testabilidade, portabilidade, 
reusabilidade e interoperabilidade. 
Na fase de Operação do Software, a correção determina o quanto um programa 
satisfaz as especificações definidas no projeto e cumpre os objetivos visados 
 
 
 
pelo cliente. Em relação a confiabilidade, é a delimitação de quanto um 
programa executa a função pretendida com a precisão exigida. Já a eficiência é 
uma propriedade essencial que vislumbra a quantidade dos recursos 
computacionais da aplicação e de seu código exigidas para que um programa 
execute suas funções corretamente. Em relação a integridade da aplicação, 
esta se manifesta nas permissões de acesso ao software ou aos dados por 
pessoas não autorizadas, além de seu controle. A usabilidade indica a 
quantidade de esforço necessária para que se possa aprender e preparar a 
entrada e interpretar a saída de um programa. 
Quando se fala na fase de Revisão do Software, a manutenção se mostra como 
necessária para reconhecer a quantidade de esforço que é indispensável para 
localizar e eliminar erros na aplicação. A flexibilidade da aplicação exprime a 
quantidade de esforço necessária para modificar um software. E a 
Testabilidade demonstra o quanto de empenho é necessário para se testar uma 
aplicação garantindo que ela execute suas funções pretendidas. 
A fase de Transição do Software mostra que a portabilidade é o potencial de 
diligência indispensável para transferir o software de uma plataforma para 
outra. O fator da Reusabilidade demonstra o quanto uma aplicação ou sua 
parte podem ser reutilizadas em outros softwares. E por fim, 
a interoperabilidade define o grau de esforço necessário para que se possa 
acoplar uma aplicação a outra. 
Dessa forma, podemos perceber que a aplicação de métodos, padrões, técnicas 
e ferramentas que determinam a qualidade do software, por isso é necessário 
que os desenvolvedores utilizem métodos e ferramentas que os ajudem a obter 
êxito na formulação de métricas de maior qualidade. 
Os padrões estabelecidos podem ser utilizados para determinar modelos aos 
documentos,registro do código e estilo de codificação, mas também podem ser 
estabelecidos pelo cliente, seja por meio de normas internacionais ou mesmo 
pela empresa de desenvolvimento. 
 
 
 
As Métricas do Processo quantificam atributos do ambiente e do processo de 
desenvolvimento do aplicativo com segurança, por isso, são aquelas que 
possuem os recursos, como a experiência do programador e o custo de 
manutenção e criação do software, além daquelas de nível de experiência de 
pessoal, onde é calculado o tempo de experiência de uma equipe em uma 
determinada linguagem de programação, de maneira individual ou coletiva. 
Dentro da disciplina podemos citar inúmeros fatores relacionados diretamente 
ao desenvolvimento e o ciclo de vida do software, como a aplicação das 
técnicas de desenvolvimento, o auxílio na programação, as técnicas de 
supervisão, as quais são de extrema importância no âmbito da equipe. 
Dessa forma entendemos que as métricas do produto são medidas do software, 
e podem não revelar nenhum detalhe sobre como o software foi desenvolvido, 
mas incluem e levam em consideração para sua análise e elaboração o 
tamanho do produto em linhas de código, a complexidade de sua estrutura 
lógica, como os métodos de recursão, o fluxo de controle e a profundidade dos 
laços aninhados, a complexidade da estrutura de dados, as funções. 
Para a segurança do software há métricas explícitas, que podem variar no cicio 
de vida do desenvolvimento da aplicação, desde as vulnerabilidades 
descobertas pela equipe até as existentes na aplicação lançada, por isso é 
importante monitorar sua implementação. 
As métricas dever estar presentes na sua implementação, desde a modelagem 
de ameaças, revisão por código, os testes de segurança e a segurança do 
código, e devem ser gradativamente implantadas, permitindo que as equipes 
acompanhem seu desempenho. 
A metodologia para a construção de métricas deve ser desenvolvida para medir 
o processo de segurança em desenvolvimento e como a administração de 
referências pode ser utilizada pelos responsáveis para suportar um processo de 
maturidade crescente, dessa forma, podemos falar em dos tipos de métricas, 
 
 
 
aquelas utilizadas para o estabelecimento dos processos e as elaboradas para o 
acompanhamento de processos. 
Ao se falar na utilização métricas no ciclo de vida do software, deve-se ter em 
mente a qualidade da segurança da aplicação, por meio de um processo que 
deve ser analisado individualmente, onde seu objetivo é ter um controle da 
situação a partir de uma melhoria contínua. 
Mesmo com as mudanças e a variabilidade causada é necessidade de primeira 
ordem se ter um controle maior sobre a aplicação, definir as métricas dos 
principais processos e os fatores que influenciam na qualidade, pois cuidar da 
segurança é primordial nos dias atuais, e para comprometer a aplicação os 
atacantes se utilizam quaisquer brechas ou vulnerabilidades. 
Os processos de métricas devem ser definidos e documentados, para que 
sejam seguidos de forma correta, lembrando que existem diversas 
metodologias e normas de qualidade presentes na engenharia de software, o 
que ajudara definir e implementar as boas práticas. 
As métricas servem para proporcionar o suporte nos projetos, podem até ser 
reutilizadas, mas com o devido cuidado, pois são feitas para se tomar decisões 
importantes, por isso que demandam qualidade. O processo documentado é 
seguido igualmente por todos e garante que os dados tenham um padrão, 
objetivo, sentido, além de frequência, evidências, validação e rastreabilidade, 
para que se possa verificar uma evolução no objeto medido e os problemas. 
Na engenharia de software reutilizar processos de forma a criar metodologias 
ou boas práticas, auxiliam na diminuição do trabalho repetitivo de criação de 
novos processos, o que influencia diretamente na melhoria da qualidade, por 
isso, há a necessidade de se implementar métricas, as quais por meio de suas 
técnicas, tornam a gestão de aplicações mais eficaz para o controle de 
processos. 
 
 
 
 
1.1 
1.2Capítulo IV 
Suporte na Revisão e Desenvolvimento 
 
O profissional que se utiliza do desenvolvimento seguro do software deve levar 
em consideração que mesmo com as ferramentas mais atualizadas não é 
possível localizar e corrigir todos os erros, e ainda assim são recomendadas as 
revisões manuais de código, até para o aperfeiçoamento da aplicação. 
Para o estudo das Ferramentas de Suporte a Análise, podemos visualizar uma 
sugestão de modelo que a Microsoft divulga, a qual é aplicada aos processos, 
também muito utilizada para o treinamento para segurança em 
desenvolvimento, executada a análise estática, testes e revisão de código, para 
localizar erros na codificação que podem revelar vulnerabilidades de segurança. 
Há uma tendência atualmente orientada a verificação por meio de ferramentas 
de testes difusos, que ao contrário daquelas utilizadas para o código estático, 
são customizadas para a aplicação, fazendo com que se possam localizar erros 
que as demais não são capazes, por sua capacidade de encontrar determinados 
bug que seriam considerados como vulnerabilidades de segurança. 
Ao se falar em desenvolvimento seguro no âmbito de aplicações voltadas para a 
Web, deve haver uma administração efetiva para que haja o cumprimento dos 
requisitos de qualidade estabelecidos, como: Privacidade e Segurança, 
Definição de Especialistas e Revisores e Requisitos Mínimos, para que seja 
possível completar todas as tarefas, encontrar os profissionais capacitados para 
que possam fazer a validação, além do acompanhamento dos requisitos 
requeridos. 
Em relação ao suporte a análise, para o cumprimento de requisitos é altamente 
recomendável nessa fase a utilização de uma ferramenta de bug tracking para 
o acompanhamento de falhas, além de outra, a de quality gates e por fim 
 
 
 
realizar uma Análise de Riscos de Segurança e de privacidade individualmente 
na situação. 
Depois de cumprida essa fase se verificará o design do software, onde é 
necessária uma investigação, que dirá se todos os Requisitos foram 
completados através de um checklist, passando para a Segurança, com a 
revisão de especialistas, e por fim a Privacidade individualmente para depois 
realizar um processo de revisão. 
Essa fase é precedida pela Implementação de Criptografia, além de testes para 
reduzir Superfície de Ataque e implementação de defesas em camadas e 
também privilégios mínimos aos usuários para restringir seu acesso a funções 
não autorizadas. Logo após essa fase, deve ser feita a Modelagem de Ameaças 
e análise de riscos utilizando o STRIDE e o DREAD para identificação de algum 
comprometimento na aplicação ou em sua estrutura. 
O próximo passo é o de implementação voltada para desenvolvimento. Ocorre 
quando está sendo criada a aplicação e os Testes, são executados por meio de 
ferramentas para especificar compiladores, flags e as opções do software, 
seguido de uma validação das APIs e, depois da definição de funções inseguras, 
recomendando-se ao término realizar uma Análise Estática Constante, que é a 
revisão de todo o código desenvolvido por meio de sink e source. 
No âmbito do desenvolvimento seguro é responsabilidade do programador a 
leitura do código através de uma ferramenta de suporte, para que possa ser 
feita uma verificação, por meio de uma Análise Dinâmica que correrá em tempo 
de execução, para inserir e processar informações avaliando o comportamento 
da aplicação, que será precedida pelos Testes Fuzzing, que irão inserir e gerar 
um grande volume de conteúdo malformado, desconhecido e fora do padrão 
injetado no software para verificaçãode seu comportamento, seguido de uma 
Revisão de Ameaças (Time Modelling/Application Security Review) que irá 
validar os módulos contra código completo e depois será executado uma 
Pentest que simulará um comportamento malicioso com a finalidade de 
 
 
 
comprometer a aplicação. Por fim, após passar por todos esses testes será 
lançada a aplicação. 
Após o lançamento da aplicação, será elaborado um Plano de Resposta para 
verificar quando a aplicação dá problema e documentar os procedimentos, 
passando para a Revisão Final dos Aspectos e Requisitos de Segurança onde 
depois é feito o Arquivamento do Release com todos os dados técnicos 
relevantes da documentação para que se possa emitir uma resposta final. 
A revisão do código verificará se os mecanismos de segurança da aplicação 
apresentam um nível suficiente de robustez e também para encontrar 
problemas de complexidade na identificação ao examinar os resultados da 
aplicação. Por isso os testes da aplicação são métodos de extrema importância 
para determinar as falhas e posteriormente atualizar o software, corrigindo-as. 
Nesse âmbito os profissionais envolvidos nas análises são os desenvolvedores e 
especialistas em seguranças, que podem revisar uma aplicação de modo 
eficiente e eficaz, já que há incontáveis problemas e falhas, principalmente na 
área de segurança, que pode comprometer e expor dados de grande 
importância. 
Por isso a revisão de código é importante, porque pode encontrar diversas 
vulnerabilidades, demonstrando que um bom código e com técnicas efetivas os 
risos são evitados caso haja um diagnóstico realizado efetivamente dos 
problemas de segurança. O ideal é seguir as métricas do guia de revisão de 
código, além de documentar os problemas encontrados, pois é considerada 
como uma prática que pode ajudar bastante no Desenvolvimento Seguro no 
Ciclo de Vida, prevenindo contra vulnerabilidades substanciais. 
Revisar o código é uma maneira de complementar os testes e as ferramentas 
utilizadas, ajudando na detecção e remoção de vulnerabilidades de segurança, 
pois são uma etapa indispensável durante o processo de desenvolvimento, com 
a finalidade de se alcançar uma versão final mais estável e protegida, 
permitindo a correção precoce de problemas críticos. 
 
 
 
No desenvolvimento de uma aplicação é necessário que os profissionais 
estejam familiarizados com o processo de manipulação de todas as 
documentações de segurança, para remover vulnerabilidades de segurança 
rapidamente, evitando gastos excessivos, além de fornecer um software mais 
resguardado, por meio de verificações definidas. 
A equipe de segurança deve estar preparada para reiteradas interações no 
desenvolvimento da aplicação, os quais são: o levantamento de requisitos, 
design, implementação, verificação, lançamento e suporte e manutenção, e 
para isso devem ser utilizadas ferramentas para auxiliar o programador a 
desenvolver códigos com mais qualidade e segurança. 
Ainda nesse sentido o Continuous Delivery é uma técnica de Implantação 
Contínua da Aplicação, ou seja, são práticas de entrega do software 
atualizando-o em seu ambiente de produção, de forma previsível, rápida, 
confiável e realizada a qualquer instante. Assim o tempo entre a codificação 
pronta e sua utilização pelos usuários é reduzida por meio dos processos de 
desenvolvimento automatizados. 
Dessa forma há uma rápida entrega do código pronto, que depois é colocado 
produção, através de seu ciclo de vida, estando sempre pronto para o 
ambiente, proporcionando feedback rápido, além de uma maior integração 
entre as equipes de desenvolvimento e operação. 
As principais vantagens são a redução do custo, tempo e risco de entrega do 
software, onde é necessário haver um alto grau de automatização para garantir 
que a aplicação poderá ser implantada sem problemas no ambiente de 
produção a qualquer instante, o que é feito através do desenvolvimento em 
ciclos curtos, possibilitando com isso uma maior qualidade, devido a melhoria 
contínua dos processos. 
Um dos objetivos da técnica é uma exponencial redução do tempo nas fases do 
ciclo de vida até a implantação do aplicativo a ser produzido, de modo a realizar 
a entrega de novas versões continuamente, implantando novas funcionalidades 
 
 
 
ao software, agilizando os negócios, ou seja, é um processo automatizado que 
busca a diminuição do risco de erros a cada instante. 
Isso tudo é possível porque todo o código é imediatamente implantado na 
produção, havendo a necessidade da equipe de estar permanentemente 
preparada para o lançamento de uma nova versão, o que implica na redução de 
riscos com a codificação ajustada em pequenas partes, porque haverá o 
monitoramento de operações e métricas além de mudanças rápidas. 
Os pequenos trechos de código são testados de maneira automatizada e depois 
enviados a um servidor de homologação, onde posteriormente passarão pela 
etapa de integração, testando a infraestrutura e o banco de dados do software, 
pois caso haja algum problema há uma facilidade para que se faça um rollback 
de uma versão. 
Dessa forma a Implantação Contínua, promove os testes de mudanças ainda 
em produção, sendo necessário um monitoramento continuado da experiência 
do usuário em tempo real, o que pode não ser indicado para modelos de 
negócios que tenham uma aplicação com um alto grau de complexidade, 
porque pode haver a criação de gargalos na entrega de mudanças. 
 
 
 
Capítulo I :GESTÃO DA SEGURANÇA NO SDLC -Security 
Development 
Introdução ao Desenvolvimento Seguro 
 
O software, além do conceito de uma sequência de instruções que controlam o 
computador, do processamento de dados e informações é tido como uma 
tecnologia evolucionária e, por isso, já não é mais o mesmo, pois não utilizamos 
mais as linguagens de programação de décadas anteriores, e assim podemos 
perceber sua ampla transformação, além dos novos conceitos que surgem a 
cada momento no cenário mundial. Desse modo seu âmbito de aplicação é 
muito abrangente, já que se encontra presente desde o software de sistema, 
para fins de aplicações, pesquisas científicas, embarcados, linhas de produtos, 
aplicações para Web, inteligência artificial, entre outros, os quais são utilizados 
por pessoas, pela indústria ou pelo governo. 
A Engenharia de Software cuida da criação e do suporte dos programas e, 
desse modo, é vista como uma área muito importante, pois estamos cercados 
de sistemas a nossa volta, desde os mais simples até aqueles que se 
caracterizam por sua altíssima complexidade, onde também nos vemos 
marcados por inúmeras tecnologias que tornam sua utilização cada vez mais 
fácil no dia-a-dia. O software está presente em vários tipos de dispositivos 
como computadores, impressoras, celulares, tablets, games, marcapassos, na 
engenharia, eletrodomésticos, em redes sociais além de incontáveis sistemas e 
equipamentos, que passam por vezes despercebidos pelas pessoas. 
Há um tempo, tínhamos que instalar o software no computador pessoal e por 
incontáveis vezes fazer sua manutenção por meio de atualizações que corrigiam 
problemas como bugs e vulnerabilidades, mas hoje com a Internet cada vez 
mais presente no cotidiano, percebe-se que há uma tendência migratória das 
aplicações para servidores on-line, e com isso, temos os avanços percebidos 
pelo cloud computing, onde não se sabe sua localização e a maneira que 
rodam, por isso vemos que a modificação, correção e atualização são feitas de 
 
 
 
forma praticamente imperceptível aos olhos do usuário, marcando sua evolução 
de produto para serviço. 
O software como componente lógico produz, gerencia, adquire, modifica, exibeou transmite informações úteis para gerenciar o processo de tomada de 
decisão, o que vai mais além do tratamento de dados, marcando sua presença 
na vida das pessoas. 
Com as mudanças no hardware e seus aprimoramentos, como uma maior 
capacidade de armazenamento, a ampliação da memória, as alterações 
ocorridas nas arquiteturas dos computadores, a criação de sistemas mais 
sofisticados e robustos, o software tem atingido patamares inimagináveis há 
bem pouco tempo. 
No desenvolvimento de software é comum ocorrer erros, por isso as tarefas de 
manutenção são mais complexas que as de hardware. Para se ter uma ideia de 
valores, um erro de software no início do projeto custa à empresa 
aproximadamente US$140 para ser corrigido, enquanto que um erro detectado 
na fase pós-implantação chega a custar impressionantes US$14.000. 
 
 
 
 
 
 
(http://www.isixsigma.com/industries/software-it/defect-prevention-reducing-
costs-and-enhancing-quality/) 
 
 
 
 
 
 
 
 
(https://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf) 
 
Segurança em desenvolvimento 
 
Com a evolução da Internet, o software hoje oferece funcionalidades imediatas 
(just-in-time), que podem ser acessadas por meio do navegador web e, para 
isso, é importante que seja implantado um processo de gestão de segurança da 
informação confiável, para garantir a manutenção de um nível aceitável de risco 
e operação. 
A reutilização dos componentes do software é uma prática que permite focar 
nas inovações do projeto, podendo-se implementar funções comuns por meio 
de partes repetidas de código, onde as estruturas de dados e detalhes de 
processamento são armazenadas em uma biblioteca de componentes para a 
construção de interfaces futuras. Com isso permite-se ganhar mais tempo nas 
partes importantes da aplicação, em vez de “reinventar a roda”. 
O custo para a correção de vulnerabilidades identificadas aumenta de maneira 
substancial a cada fase do ciclo de desenvolvimento do software (levantamento 
de requisitos, design, implementação, verificação, lançamento e suporte e 
manutenção), portanto, o quanto antes forem identificadas falhas de 
segurança, mais econômico ficará realizar sua manutenção, porque qualquer 
 
 
 
problema posterior acarretará um valor maior, podendo até inviabilizar o 
projeto. 
Por isso, é necessário que o profissional conheça as boas práticas de 
desenvolvimento e de segurança nesse contexto. Investir em segurança traz 
um retorno amplo não só para o projeto, mas também para os usuários. Além 
disso, há um menor investimento no tratamento de bugs, fazendo com que 
sejam reduzidos nesse processo tempo e recursos. 
Uma das propostas da disciplina é quebrar alguns dos paradigmas mais 
engessados, fazendo com que haja uma mudança na cultura dos profissionais 
do software, refletindo inclusive na própria organização, de maneira ampla, 
para que se possa obter qualidade e segurança nos produtos entregues. 
A maior parte das aplicações que estão em produção são vulneráveis a diversos 
tipos de ataques, por isso não se pode falar em um software completamente 
seguro ou blindado, mas pode-se tentar reduzir ao máximo o comprometimento 
das informações e o risco de ataques. Devido a isso, a OWASP (The Open Web 
Application Security Project) apresenta um ranking a partir de uma análise das 
falhas mais comuns em aplicações web, as quais estão presentes em 
praticamente todas as versões não testadas e adequadas do software. 
O processo de segurança denota a importância do software, e por isso deve-se 
visualizar todas as fases componentes do desenvolvimento de software 
(levantamento de requisitos, design, implementação, verificação, lançamento 
da aplicação e suporte e manutenção), para que se possa estudar o 
gerenciamento das principais metodologias utilizadas no mercado e, com isso, 
traçar uma base para as estratégias de uso empregadas pelas organizações, já 
que com as vulnerabilidades, a correção, adaptação e a expansão demandam 
mais pessoas e recursos do que o processo de criação em si. 
Para relembrar as fases do desenvolvimento de uma aplicação temos que na 
fase inicial, no Levantamento de Requisitos, se faz as listagens de recursos 
necessários, especificando as diretrizes de qualidades, além de documentar a 
 
 
 
arquitetura e fazer o agendamento de entrevistas. Na parte de Design da 
aplicação são realizadas as especificações funcionais e o desenho do software. 
A implementação é a fase onde se desenvolve o código, e na Verificação que se 
faz uma busca, além das correções de bugs, mas em ambas podem ser feitos 
testes e avaliações. No lançamento que se faz a assinatura do código e seu 
“encerramento”. Para a fase de suporte e manutenção, são feitas as 
atualizações segurança e correções de vulnerabilidades observadas. 
A arquitetura caracteriza-se por ser uma adaptação do software para atender 
às necessidades de novos ambientes e tecnologias, sendo realizada de maneira 
a trazer um aperfeiçoamento para que se possa implementar novos requisitos 
de um modelo de negócio, e com isso ser responsável pela expansão e 
interoperabilidade. 
Os recursos e funções das aplicações podem ser reutilizados muito facilmente, 
e levando em consideração a importância de projetar, e também de segurança, 
falhas, importância da qualidade, funcionalidade, há uma necessidade em 
poupar tempo e recursos para se concentrar no desenvolvimento da aplicação. 
O desenvolvedor deve levar em conta a tecnologia, os requisitos complexos, e a 
tomada de decisões estratégicas e táticas para proteger a aplicação dos riscos 
de segurança. Por isso é importante que se utilize uma metodologia prática, 
onde haja comunicação, pois é fundamental ouvir as necessidades dos clientes 
e interessados com fins de compreender seus objetivos e aplicá-los de modo 
preciso ao projeto, fazendo o levantamento das necessidades que definirão 
funções e características, além do planejamento (trabalho de engenharia de 
software, com as tarefas, riscos, recursos, produção e o cronograma), análise 
de requisitos, modelagem de projeto (esboço para compreender o problema e 
resolvê-lo, entendendo as necessidades do software através do projeto), 
construção de programa (criação de código e testes para descobrir os erros na 
codificação), até chegar aos testes e suporte. 
 
 
 
 
Papéis e responsabilidades 
 
Os profissionais do desenvolvimento seguro de software são responsáveis em 
apresentar e implantar um conjunto de práticas e metodologias aos 
programadores, o que resulta em melhores aplicações, com um nível muito 
maior de confiabilidade, maturidade, integridade e inviolabilidade. 
Os papéis apresentados se referem às responsabilidades, por isso as atividades 
de cada membro do projeto de desenvolvimento de software são essenciais em 
todas as etapas do planejamento da aplicação, especificando os requerimentos 
básicos para que cada função seja desempenhada da forma mais segura 
possível. 
As responsabilidades da equipe em relação ao Software Development Lifecycle 
são desenvolver, manter e aprimorar a aplicação, definindo aspectos 
obrigatórios do processo, fornecendo o treinamento adequado aos engenheiros 
e supervisores, além de direcionar as equipes durante todo o processo, 
supervisionando e revisando a segurança por meio de equipes, e de maneira a 
fazer com que os especialistas abordem os aspectos de proteção do software, 
para que os supervisores de segurança possam se informar através de análises 
das respostas, oportunas e precisas, além de revisar a segurança antes que a 
aplicação seja lançada, buscando as vulnerabilidades que podem comprometer