Segurança Aplicada no Desenvolvimento de Software

Prévia do material em texto

Indaial – 2021
Segurança aplicada 
no deSenvolvimento 
de Software
Prof. Nader Ghoddosi
2a Edição
Copyright © UNIASSELVI 2020
Elaboração:
Prof. Nader Ghoddosi
Revisão, Diagramação e Produção:
Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri 
UNIASSELVI – Indaial.
Impresso por:
G427s
 Ghoddosi, Nader
 Segurança aplicada no desenvolvimento de software. / Nader 
Ghoddosi. – Indaial: UNIASSELVI, 2021.
 220 p.; il.
 ISBN 978-65-5663-419-7
 ISBN Digital 978-65-5663-420-3
 1. Segurança da informação. - Brasil. II. Centro Universitário 
Leonardo da Vinci.
 
CDD 004
apreSentação
Caro acadêmico! Estamos iniciando o estudo da disciplina Segurança 
Aplicada no Desenvolvimento do Software. Este livro é um dos instrumentos 
que contribuirá para a sua aprendizagem. A abordagem do livro é sobre a 
importância da segurança ao longo do desenvolvimento do software. Para 
isso, serão apresentados os principais conceitos de segurança da informação 
que interferem diretamente sobre o processo de desenvolvimento. 
 
Durante o desenvolvimento de um software, os desenvolvedores 
buscam garantir a entrega de um produto minimizando as falhas e 
vulnerabilidades, porém, durante o desenvolvimento, não são raros os casos 
que os profissionais ignoram as boas práticas de segurança. Desse modo, 
é essencial que certas rotinas sejam tomadas ao longo de processo, ainda 
que os modelos tradicionais de criação de softwares não sejam focados 
no desenvolvimento do software seguro. Para isso, este livro abordará 
essa importância da segurança como uma vantagem competitiva para as 
organizações. 
Na Unidade 1, nós abordaremos os principais conceitos de segurança 
no desenvolvimento do software e as normas de segurança mais usuais que 
auxiliam o processo de desenvolvimento seguro. 
Na Unidade 2 serão elencados os principais passos para o 
desenvolvimento seguro considerando as aplicações WEB. Além disso, você 
estudará como fazer uma análise de vulnerabilidade e garantir a segurança 
dos arquivos do sistema. 
Na Unidade 3, nós abordaremos questões vinculadas à auditoria do 
desenvolvimento de sistemas, bem como a avaliação do software. Para isso, 
você irá compreender a relação entre o treinamento da equipe e a garantia da 
segurança no processo de desenvolvimento seguro. 
Aproveitamos a oportunidade para destacar a importância de 
desenvolver as autoatividades, lembrando que essas atividades não são 
opcionais. Elas objetivam a fixação dos conceitos apresentados. Em caso 
de dúvida, durante a realização das atividades, sugerimos que você entre 
em contato com seu tutor externo ou com a tutoria da UNIASSELVI, não 
prosseguindo as atividades sem ter sanado todas as dúvidas que irão 
surgindo. 
Bons estudos!
Nader Ghoddosi
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para 
você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novi-
dades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é 
o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um 
formato mais prático, que cabe na bolsa e facilita a leitura. 
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagra-
mação no texto, aproveitando ao máximo o espaço da página, o que também contribui 
para diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, 
apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilida-
de de estudá-lo com versatilidade nas telas do celular, tablet ou computador. 
 
Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para 
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assun-
to em questão. 
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas 
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa 
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de 
Desempenho de Estudantes – ENADE. 
 
Bons estudos!
NOTA
Olá, acadêmico! Iniciamos agora mais uma disciplina e com ela 
um novo conhecimento. 
Com o objetivo de enriquecer seu conhecimento, construímos, além do livro 
que está em suas mãos, uma rica trilha de aprendizagem, por meio dela você 
terá contato com o vídeo da disciplina, o objeto de aprendizagem, materiais complemen-
tares, entre outros, todos pensados e construídos na intenção de auxiliar seu crescimento.
Acesse o QR Code, que levará ao AVA, e veja as novidades que preparamos para seu estudo.
Conte conosco, estaremos juntos nesta caminhada!
LEMBRETE
Sumário
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO ............................................ 1
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE .................................................................. 3
1 INTRODUÇÃO .................................................................................................................................... 3
2 SOFTWARE ........................................................................................................................................... 4
3 MODELOS DE PROCESSO DE SOFTWARE ............................................................................... 5
4 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE .......................................................... 6
5 CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE SEGURO .............................. 9
6 ANÁLISE ESTÁTICA DE CÓDIGO ............................................................................................. 13
7 O PROBLEMA DA SEGURANÇA NO SOFTWARE .................................................................. 14
8 BENEFÍCIOS DO DESENVOLVIMENTO SEGURO ................................................................ 15
RESUMO DO TÓPICO 1..................................................................................................................... 19
AUTOATIVIDADE .............................................................................................................................. 21
TÓPICO 2 — SEGURANÇA DE DADOS ....................................................................................... 23
1 INTRODUÇÃO .................................................................................................................................. 23
2 CONCEITOS DA SEGURANÇA DA INFORMAÇÃO ............................................................. 23
3 PRINCÍPIOS DO SOFTWARE SEGURO ..................................................................................... 27
4 SETE PONTOS DE SEGURANÇA DO SOFTWARE SEGURO ............................................... 28
5 REQUISITOS DE SEGURANÇA DE SOFTWARE .................................................................... 29
6 FERRAMENTAS E TÉCNICAS DE AVALIAÇÃO DOS RISCOS ........................................... 30
6.1 CATEGORIZAÇÃO DE RISCOS ................................................................................................ 31
6.2 GERENCIAMENTO DE RISCOS EM PROJETOS ................................................................... 32
6.3 MATRIZ DE RISCO ...................................................................................................................... 34
7 PADRÕES DE SEGURANÇA.......................................................................................................... 36
RESUMO DO TÓPICO 2..................................................................................................................... 40
AUTOATIVIDADE .............................................................................................................................. 42
TÓPICO 3 — NORMASE MODELOS DE SEGURANÇA .......................................................... 45
1 INTRODUÇÃO ................................................................................................................................. 45
2 MODELO SSE-CMM ....................................................................................................................... 45
3 NORMA ISO/IEC 17799 E ISO/IEC 27001 .................................................................................... 47
3.1 ISO/IEC 27001:2018 ....................................................................................................................... 47
4 ISO/IEC 15408 .................................................................................................................................... 52
LEITURA COMPLEMENTAR ............................................................................................................ 54
RESUMO DO TÓPICO 3..................................................................................................................... 60
AUTOATIVIDADE .............................................................................................................................. 62
REFERÊNCIAS ...................................................................................................................................... 64
UNIDADE 2 — SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB ................ 67
TÓPICO 1 — PRIMEIROS PASSOS PARA O DESENVOLVIMENTO
 SEGURO DE APLICAÇÕES WEB ........................................................................... 69
1 INTRODUÇÃO ................................................................................................................................. 69
2 FALHAS DURANTE O DESENVOLVIMENTO DO PROJETO ............................................. 70
3 TAXONOMIA DE ATAQUES WEB .............................................................................................. 75
4 TESTES DE SEGURANÇA NAS APLICAÇÕES ESSENCIAIS .............................................. 79
5 CUIDADOS A SEREM TOMADOS NA IMPLANTAÇÃO ..................................................... 82
6 MANUTENÇÃO DO PROJETO .................................................................................................... 87
6.1 DOCUMENTAÇÃO .................................................................................................................... 89
6.2 ARTEFATOS ................................................................................................................................. 91
RESUMO DO TÓPICO 1..................................................................................................................... 94
AUTOATIVIDADE .............................................................................................................................. 96
TÓPICO 2 — ANÁLISE DE VULNERABILIDADE ....................................................................... 99
1 INTRODUÇÃO .................................................................................................................................. 99
2 A SEGURANÇA DE APLICAÇÕES NA GESTÃO DA
 SEGURANÇA DA INFORMAÇÃO ............................................................................................... 99
3 REPOSITÓRIOS E PADRÕES ..................................................................................................... 104
4 CLASSIFICAÇÃO DAS TÉCNICAS DE VARREDURAS DE VULNERABILIDADE ..... 107
5 PROCESSO DE ANÁLISE DE VULNERABILIDADE ............................................................ 109
6 PROCEDIMENTOS PARA A GESTÃO DE VULNERABILIDADE...................................... 112
7 TESTE DE PENETRAÇÃO ............................................................................................................ 113
RESUMO DO TÓPICO 2................................................................................................................... 118
AUTOATIVIDADE ............................................................................................................................ 120
TÓPICO 3 — SEGURANÇA DOS ARQUIVOS DO SISTEMA ................................................ 123
1 INTRODUÇÃO ................................................................................................................................ 123
2 CONTROLE DE ACESSO AO CÓDIGO-FONTE DO PROGRAMA ................................... 123
2.1 CODIFICAÇÃO SEGURA ......................................................................................................... 125
2.2 CODIFICAÇÃO SEGURA NO CERT ...................................................................................... 128
2.3 CODIFICAÇÃO SEGURA NO PROJETO ABERTO DE SEGURANÇA EM APLICAÇÕES 
WEB (OWASP) ............................................................................................................................. 128
2.4 CODIFICAÇÃO SEGURA NA MICROSOFT ......................................................................... 130
2.5 PRINCÍPIOS DA ARQUITETURA SEGURA ........................................................................ 131
LEITURA COMPLEMENTAR .......................................................................................................... 133
RESUMO DO TÓPICO 3................................................................................................................... 141
AUTOATIVIDADE ............................................................................................................................ 143
REFERÊNCIAS .................................................................................................................................... 145
UNIDADE 3 — SEGURANÇA E AUDITORIA NO DESENVOLVIMENTO
 DO SOFTWARE ..................................................................................................... 152
TÓPICO 1 — AUDITORIA DO DESENVOLVIMENTO DE SISTEMAS .............................. 154
1 INTRODUÇÃO ................................................................................................................................ 154
2 CONCEITOS DE SISTEMAS ........................................................................................................ 154
3 CONCEITOS DE AUDITORIA DE SISTEMAS ....................................................................... 157
4 ABORDAGEM DE AUDITORIA DE SISTEMAS ................................................................... 160
4.1 ABORDAGEM AO REDOR DO COMPUTADOR ................................................................. 163
4.2 ABORDAGEM ATRAVÉS DO COMPUTADOR .................................................................... 164
4.3 ABORDAGEM COM O COMPUTADOR ............................................................................... 164
5 ATIVIDADES DO MÉTODO DE AUDITORIA PARA DESENVOLVIMENTO DE 
SOFTWARE ......................................................................................................................................... 165
RESUMO DO TÓPICO 1................................................................................................................... 170
AUTOATIVIDADE ............................................................................................................................ 172
TÓPICO 2 — AVALIAÇÃO DO SOFTWARE DE AUDITORIA DE SISTEMAS .................. 176
1 INTRODUÇÃO ................................................................................................................................ 176
2 METODOLOGIAS DE SELEÇÃO .............................................................................................. 176
2.1 COBIT .......................................................................................................................................... 177
2.2 CMMI ............................................................................................................................................ 181
2.3 MELHORIA DO PROCESSO DOSOFTWARE BRASILEIRO (MPS.BR) .......................... 184
2.4 ISO/IEC 12207 .............................................................................................................................. 187
3 ASPECTOS FUNCIONAIS ............................................................................................................ 188
4 ASPECTOS DA GESTÃO .............................................................................................................. 189
5 ASPECTOS RELACIONADOS À TECNOLOGIA ................................................................... 190
RESUMO DO TÓPICO 2................................................................................................................... 193
AUTOATIVIDADE ............................................................................................................................ 195
TÓPICO 3 — TREINAMENTO DE SEGURANÇA ..................................................................... 198
1 INTRODUÇÃO ................................................................................................................................ 198
2 IMPACTOS ...................................................................................................................................... 198
3 ORGANIZAÇÃO DO TRABALHO DE AUDITORIA ............................................................ 203
3.1 PLANEJAMENTO ...................................................................................................................... 204
3.2 ESCOLHA DA EQUIPE ............................................................................................................. 204
3.3 PROGRAMAÇÃO DA EQUIPE ............................................................................................... 205
3.3.1 Papéis e responsabilidades ............................................................................................... 207
3.4 EXECUÇÃO DE TRABALHOS E SUPERVISÃO ................................................................... 207
3.5 REVISÃO DOS PAPÉIS DE TRABALHOS ............................................................................. 208
3.6 ATUALIZAÇÃO DO CONHECIMENTO PERMANENTE ................................................. 208
3.7 AVALIAÇÃO DA EQUIPE ........................................................................................................ 209
3.8 DOCUMENTAÇÃO DOS PAPÉIS DE TRABALHO ............................................................. 209
4 CONTROLES ORGANIZACIONAIS E OPERACIONAIS..................................................... 209
5 O PAPEL DO USUÁRIO ............................................................................................................... 210
LEITURA COMPLEMENTAR .......................................................................................................... 212
RESUMO DO TÓPICO 3................................................................................................................... 215
AUTOATIVIDADE ............................................................................................................................ 217
REFERÊNCIAS .................................................................................................................................... 219
1
UNIDADE 1 — 
DESENVOLVIMENTO DE SOFTWARE 
SEGURO
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
 A partir do estudo desta unidade, você deverá ser capaz de:
• conhecer o ciclo de desenvolvimento do software seguro; 
• compreender os principais conceitos de segurança dos softwares; 
• conhecer as principais normas de segurança; 
• reconhecer as categorias de risco no desenvolvimento do software;
• relacionar segurança com processo de desenvolvimento do software.
 Esta unidade está dividida em três tópicos. No decorrer da unidade, 
você encontrará autoatividades com o objetivo de reforçar o conteúdo 
apresentado.
TÓPICO 1 – DESENVOLVIMENTO DE SOFTWARE
TÓPICO 2 – SEGURANÇA DE DADOS
TÓPICO 3 – NORMAS E MODELOS DE SEGURANÇA
Preparado para ampliar seus conhecimentos? Respire e vamos 
em frente! Procure um ambiente que facilite a concentração, assim absorverá 
melhor as informações.
CHAMADA
2
3
TÓPICO 1 — UNIDADE 1
DESENVOLVIMENTO DE SOFTWARE
1 INTRODUÇÃO
O processo de desenvolvimento de software é algo complexo e, para 
isso, é preciso um conjunto de atividades organizadas e sequências estruturadas 
em passos definidos (SÊMOLA, 2003; ALVES, 2006; FONTES, 2006; 2011). Esse 
conjunto de atividades é definido como um processo de desenvolvimento de 
software, que recebe ajuda da engenharia de software (ALVES, 2006; FONTES, 
2011). 
Uma das etapas que causa grande preocupação nesse processo é a falta 
de segurança nos projetos de desenvolvimento, o que gera vulnerabilidades 
(FERREIRA, 2003; SÊMOLA, 2003; ALVES, 2006). Em função disso, as 
organizações estão em uma busca contínua para adotar medidas mais eficazes 
de proteção alinhadas às metodologias de segurança (FONTES, 2006; WAGNER, 
2011; FERNANDES, 2013; GALITEZI, 2011). 
Essas metodologias são necessárias, já que Kolbe Junior (2020) relata que, 
em 2019, ocorreram 85 bilhões de tentativas de ataques cibernéticos, sendo que, no 
Brasil, ocorreram mais de 24 bilhões de tentativas de ataques. Isso denota a grande 
importância de as empresas adotarem protocolos de segurança para mitigar as 
suas vulnerabilidades durante o processo de desenvolvimento de software. No 
período de Corona Vírus (Covid-19), aumentaram, de modo significativo, os 
ataques de hackers contra empresas, já que as ferramentas que adotam o acesso 
remoto aumentaram 333% no Brasil (KOLBE, 2020). O número de brasileiros 
prejudicados por crimes virtuais é maior do que a média mundial, assim, isso 
coloca o Brasil entre os mais prejudicados por esse tipo de crime (WALTRICK, 
2016).
Em casos recentes, como da maior fabricante de produtos militares do 
mundo, a Lockheed Martin, teve sua rede invadida por hackers que tinham, como alvo, os 
trabalhadores remotos (WALTRICK, 2016).
NOTA
https://www.cliccamaqua.com.br/noticias/2/policia.html
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
4
FIGURA 1 – PREJUÍZO FINANCEIRO CAUSADO PELOS CRIMES VIRTUAIS
FONTE: <http://bit.ly/2WrncLp>. Acesso em: 15 maio 2020.
Desse modo, podemos observar que existe a necessidade de produtos de 
software que, além suportarem os negócios, apresentem melhorias de segurança 
contínua. Neste tópico, entenderemos o processo de desenvolvimento e as suas 
características para permitir a segurança do software. 
2 SOFTWARE
Para iniciar este subtópico, vamos definir o que é software? Conforme 
Pressman e Maxim (2016), o software de computador é um produto que os 
desenvolvedores constroem e o mantêm ao longo do tempo. Sommerville (2011) 
coloca que software não é somente o programa, mas toda a documentação 
associada, além dos dados necessários para executar os programas de modo 
adequado. 
Entretanto, um grande ponto a ser considerado na segurança do 
desenvolvimento de software e que está relacionado com a sua definição é o fato 
de que um determinado software pode ser composto por algumas dezenas de 
linhas de código desenvolvidas por um programador ou pode ser constituído 
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
5
por milhões de linhas de código, dados de configuração, documentação etc. 
(FONTES, 2006; 2011). Portanto, para que o software tenha qualidade e segurança, 
é essencial seja desenvolvido por meio de um processo adequado.
3 MODELOS DE PROCESSO DE SOFTWARE 
O processo de software desenvolvido em uma organização é, geralmente, 
formulado através de padrões previamente descritos, sendo que estes definem 
um conjunto de ações e atividades, necessárias ao desenvolvimento do software 
(FONTES, 2006; SOMMERVILLE, 2011; PRESSMAN; MAXIM, 2016). Portanto, 
um modelo de processo de software pode ser compreendido como um roteiro 
a ser seguido para desenvolver um software de alta qualidade em um tempo 
determinado (PRESSMAN; MAXIM, 2016). Esse modelode processo pode 
ser considerado uma representação abstrata de um processo de software 
(SOMMERVILLE, 2011). Existem inúmeros modelos de processo de software que 
você pode revisar no Livro Didático de Engenharia de Software. 
Os modelos prescritivos prescrevem um conjunto de elementos e 
o modo como esses elementos se inter-relacionam (SOMMERVILLE, 2011; 
PRESSMAN; MAXIM, 2016). Temos um conjunto de quatro modelos prescritivos 
(SOMMERVILLE, 2011; PRESSMAN; MAXIM, 2016): 
• Modelo cascata: atividades de especificação, desenvolvimento, validação 
e evolução, que são fundamentais ao processo, como fases separadas do 
processo, como a especificação de requisitos, o projeto de software, os testes, 
e assim por diante.
• Modelo incremental: combina elementos dos fluxos de processos lineares e 
paralelos. Desse modo, cada uma das sequências lineares gera um incremento 
do software. Esses incrementos são entregáveis e prontos para o cliente, 
portanto, o modelo de processo incremental entrega um produto operacional 
a cada incremento, isso significa um produto sem erros e pronto para o 
usuário usar.
• Modelo evolucionário: caracterizado por ser iterativo e ter características que 
possibilitem o desenvolvimento de versões mais completas do software. O 
software evolui com o tempo e de acordo com as mudanças nas necessidades 
de negócio e de produtos que se modificam frequentemente. Os modelos 
evolucionários se caracterizam por dois modelos comuns: prototipação e 
espiral. A prototipação é usada quando o desenvolvedor não tem certeza 
quanto à eficiência de um algoritmo, ou quanto à adaptabilidade de um 
sistema operacional. Já o modelo espiral garante um grande potencial para 
um desenvolvimento rápido de versões mais completas.
• Modelo baseado em componentes: tem, como base, a existência de um número 
significativo de componentes reutilizáveis. O processo de desenvolvimento 
de software se concentra na integração desses componentes, ao contrário de 
proceder ao desenvolvimento a partir do zero.
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
6
4 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Os softwares são responsáveis pela geração de informações, por isso, 
a segurança do software está atrelada à segurança da informação (SÊMOLA, 
2003; WAGNER, 2011; FERNANDES, 2013; GALITEZI, 2011). Conforme Sêmola 
(2003) e Fontes (2011), a segurança da informação é definida como um conjunto 
de orientações, normas, procedimentos, políticas ou outras ações que protejam o 
recurso à informação.
Outro ponto importante levantado por Fontes (2011) e Fernandes (2013) 
é que o processo de software é definido como um conjunto de atividades e 
resultados que origina um produto. As atividades fundamentais e similares 
a todos os processos de desenvolvimento de software são: especificação, 
desenvolvimento, validação e evolução (FONTES, 2011; SOMMERVILLE, 2011; 
PRESSMAN; MAXIM, 2016). 
No mercado competitivo atual, o processo bem definido e organizado das 
atividades essenciais para o desenvolvimento de um software é uma vantagem 
cada vez maior (GALITEZI, 2011; KOLBE, 2020). Uma empresa que trabalha com 
controle no desenvolvimento, testes, integração de sistemas e, ainda, possui uma 
equipe capacitada para garantir projetos adequados às necessidades dos clientes, 
possui mais chances de sucesso nesse mercado competitivo (KOLBE, 2020).
FIGURA 2 – PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
FONTE: <https://www.softvision.com.br/software.html>. Acesso em: 18 maio 2020.
https://www.softvision.com.br/software.html
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
7
As atividades listadas são organizadas em diferentes processos, com 
níveis diferenciados de detalhamento e, ainda, com prazos diversificados 
(FONTES, 2011; LYRA, 2008). Portanto, o desenvolvimento de um produto pode 
ocorrer por processos distintos, mesmo que esse seja um produto similar ou igual, 
porém, se um processo inadequado for usado, isso gerará o comprometimento 
da qualidade do produto final, que está em desenvolvimento (SÊMOLA, 2003; 
FONTES, 2011). Então, agora, entenderemos melhor as fases dos processos para 
o desenvolvimento seguro de um software.
QUADRO 1 – FASES E ATIVIDADES COMUNS NOS MODELOS DE DESENVOLVIMENTO DE 
SOFTWARES
FONTE: Adaptado de Fontes (2006)
Analisando a descrição das fases, percebemos que as atividades de 
desenvolvimento de um processo de software são afetadas por ações específicas 
para um único objetivo comum, que é o produto de software. Conforme Li e Cui 
(2010) e Fernandes (2013), existe uma combinação de classificações realizadas por 
autores, tendo, em comum, uma lista com as principais atividades de cada fase. 
FASES DESCRIÇÃO
Especificação de 
requisitos
Engloba uma análise dos requisitos, independentemen-
te do modelo de processos selecionado para se desen-
volver um software. Nesta etapa, é necessário conhecer 
quais serão as necessidades e restrições do software.
Projeto de sistema Esta fase abrange o projeto a partir de análises e tradu-ção dos requisitos. Com isso, ocorre a codificação.
Programação 
Desenvolvimento do código-fonte em uma linguagem 
de programação. Isso representa o controle do sistema, 
a lógica e as operações, conforme o que foi descrito e 
levantado na fase de especificação de requisitos.
Verificação e 
validação
Nesta etapa, são efetuados os testes, a verificação do 
sistema checando se o produto ou seus componentes 
estão de acordo com as necessidades do cliente. Ainda, 
é averiguada a satisfação dos clientes com o software, 
visando à qualidade do produto final.
Manutenção e 
evolução
Nesta etapa, ocorrem as mudanças, ajustes, reparos ou 
melhorias que os requisitos venham sofrer após o siste-
ma ser colocado em desenvolvimento.
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
8
QUADRO 2 – PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
FONTE: Adaptado de Fernandes (2013)
O produto final, portanto, está atrelado às atividades de cada fase do 
processo de desenvolvimento, que são especificadas, detalhadas e, ainda, são 
colocadas em uma ordem (FONTES, 2011; FERNANDES, 2013). Esses processos 
auxiliam e orientam modelos diferentes de desenvolvimento de softwares. 
Um dos pontos críticos ligados no processo de desenvolvimento é a 
segurança, além da proteção das informações confidenciais (FERREIRA, 2003). 
Isso porque, atualmente, os clientes consideram as práticas de segurança e 
privacidade como um ponto crucial na decisão de escolher um fornecedor de 
serviços. Assim, a segurança cria novas oportunidades de negócio. De acordo 
ESPECIFICAÇÃO
Engenharia de 
sistema
Estabelecer uma solução comum para 
o problema, envolvendo questões extra 
software.
Análise de 
requisitos
Realizar o levantamento das necessida-
des do software a ser implementado. 
Nesta etapa, o objetivo é desenvolver 
uma especificação de requisitos, que, 
geralmente, é um documento.
Especificação 
de sistema
Uma descrição funcional do sistema, 
podendo incluir um plano de testes 
para verificar a adequação.
PROJETO
Projeto 
arquitetural
Desenvolvimento de um modelo 
conceitual para o sistema, composto de 
módulos mais ou menos independentes.
Projeto de 
interface
Cada módulo possui sua interface de 
comunicação alinhada, definida e com-
preendida. 
Projeto 
detalhado
Definição dos módulos, e tradução 
para pseudocódigo.
IMPLEMENTA-
ÇÃO Codificação
Implementação do sistema em uma lin-
guagem de computador.
VALIDAÇÃO
Teste de 
unidade e 
módulo
Realização de testes para verificação 
dos erros e comportamento adequado 
a nível das funções e módulos básicos 
do sistema.
Integração
Junção dos diferentes módulos em um 
produto de software homogêneo, além 
da verificação da interação entre estes 
quando operando em conjunto.
MANUTENÇÃO 
E EVOLUÇÃO
O software entra em um ciclo interativo que engloba 
todas as fases anteriores.
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
9
com Kolbe (2020), a segurança do software está ligada à resistência e tolerância a 
eventos que ameacem a integridade. Consequentemente,a segurança do software 
corresponde à habilidade do software de evitar, além de suportar eventos que 
ameacem a dependabilidade (WALTRICK, 2016; KOLBE, 2020). Conforme Fontes 
(2006), a segurança do software é o seu desenvolvimento seguro, isso significa 
certificar a sua segurança e capacitar os desenvolvedores, arquitetos e os usuários 
acerca do desenvolvimento de produtos seguros.
5 CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE 
SEGURO
O ciclo de vida de desenvolvimento seguro é essencial para que a 
organização proteja suas informações, mas também as informações dos clientes 
e parceiros (SILVA, 2017). Um ciclo implementado de modo adequado pode 
garantir mais confiabilidade e redução de custos, portanto, o que se percebe é 
que é necessário desenvolver aplicações seguras, visto que os ataques evoluíram 
de modo significativo, além das suas motivações.
QUADRO 3 – MUDANÇAS DAS MOTIVAÇÕES DOS ATAQUES
FONTE: Adaptado de Silva (2017)
Conforme a regra de Myers (2004), o custo de manutenção de uma 
aplicação pode ser até 10 vezes maior a cada ciclo de vida de desenvolvimento. 
Dependabilidade é a propriedade que define a capacidade dos sistemas 
computacionais de prestarem um serviço que se pode justificadamente confiar. Dentre 
os atributos, estão: confiabilidade, segurança, disponibilidade e mantenabilidade (FONTES, 
2011).
NOTA
Passado Presente e futuro
Motivados pelo desafio de in-
vadir os sistemas.
Demonstração de conhecimen-
to técnico.
Ataques focados nas empresas.
Motivação financeira.
Ataques direcionados.
Sequestro de dados pessoais e corporativos.
Ataque a pessoas.
Comprometimento de dispositivos.
Comprometimento de pequenas empresas 
para atacarem grandes empresas.
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
10
Essa regra denota o custo da correção de um defeito, o que pode gerar um aumento 
devido à demora da descoberta do defeito (MYERS, 2004). O que se verifi ca é que 
os defeitos visualizados nas fases iniciais apresentam um menor custo do que 
aqueles encontrados na fase de produção.
FIGURA 3 – REGRA DE MYERS
FONTE: <http://bit.ly/3nwbqeo>. Acesso em: 20 maio 2020.
O desenvolvimento seguro não é somente a codifi cação, engloba a 
infraestrutura para suportar o ambiente da aplicação. Desse modo, é preciso 
investir na proteção de todo o ambiente (HOWARD; LIPNER, 2006). Agora, 
compreenderemos um processo de ciclo de vida de desenvolvimento seguro 
muito utilizado que possui, como base, o Security Development Lifecycle (SDL – 
Ciclo de Vida do Desenvolvimento Seguro). 
O SDL se concentra no desenvolvimento de software introduzindo a 
segurança e a privacidade em todas as fases do desenvolvimento. O SDL concilia 
uma abordagem global com a prática de minimização do número e do grau de 
severidade das vulnerabilidades nos produtos e serviços da Microsoft (HOWARD; 
LIPNER, 2006; SILVA, 2017).
O SDL é compartilhado de modo gratuito pela Microsoft com organizações 
de desenvolvimento de clientes e do setor de software, tendo, como resultado, o 
desenvolvimento de softwares mais seguros (HOWARD; LIPNER, 2006; SILVA, 
2017). 
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
11
QUADRO 4 – DESCRIÇÃO DAS FASES DO PROCESSO SDL
Pré-SDL – 
Treinamento
- Fase fundamental para um processo de desenvolvimento 
seguro de sucesso. 
- Conteúdo direcionado de acordo com o público-alvo. 
- Etapa recorrente e ter o mínimo de colaboradores treinados.
Fase 1 – 
Requisitos
- Identificação de segurança necessária, requisitos mínimos 
de qualquer aplicação. 
- Levantar legislação vigente, políticas internas e externas.
- Privacidade.
- Segurança dos dados. 
- Aprofundamento na avaliação dos riscos de segurança e 
da privacidade.
- Definir os especialistas para o desenvolvimento e de 
segurança da informação.
- Definir quality gates quando avança a próxima etapa, isso 
deve contemplar falhas de segurança.
Fase 2 – Design
- Arquitetar a aplicação com base nos requisitos.
- Classificar o tipo de dado, isso se torna um baseline para 
os próximos projetos.
- Uso e verificação de criptografia para proteger informações 
sensíveis. 
- Definir o algoritmo que será usado.
- Reduzir a superfície de ataque, utilizando proteção em 
camadas, Web Application Firewall, utilização de DMZ, 
banco de dados não exposto para internet etc.
- Atuar com o princípio de menor privilégio.
- Checklist para não esquecer de algum ponto.
Fase 3 – 
Implementação
- Etapa da codificação.
- Banir o uso de APIs inseguras e funções frágeis e 
realizar a devida documentação para que todos tenham 
conhecimento.
- Ferramenta de análise estática realizada pelo próprio 
desenvolver.
- Realizar revisão de código com apoio de ferramentas.
- Realizar teste não estruturado possibilita identificar 
comportamento anômalo.
- Realizar revisão de código manual para identificar se há 
falso positivo e se possível outro desenvolvedor realizar 
essa análise manual.
- Escrever um código limpo para que a manutenção possa 
ser realizada por outro time.
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
12
Fase 4 – 
Verificação
- Fase do teste da aplicação, usando métodos para validar 
se a aplicação está operando conforme o esperado.
- Análise dinâmica, verifica a aplicação, possibilita verificar 
alguns problemas de segurança, comportamento do 
ambiente que suporta a aplicação.
- Revisão dos controles implementados para os riscos 
identificados na análise de ameaça.
- Realizar teste de penetração, com profissionais especiali-
zados, podendo ser internos ou terceiros.
Fase 5 – Release - Requisitos de privacidade.
- Requisitos de segurança da informação.
Pós-SDL – 
Resposta 
- Prática do plano de resposta a incidentes.
- Documentação e atualização são imprescindíveis para o 
sucesso do processo.
FONTE: Adaptado de Silva (2017)
 
A ciência da segurança é a ciência interna do SDL, desenvolvida para 
compreender como os sistemas de computador são invadidos, e, ainda, como 
esses ataques poderiam ser minimizados ou evitados. Desse modo, a ciência da 
segurança elabora e desenvolve técnicas e ferramentas inovadoras que auxiliam a 
dificultar os ataques a softwares (HOWARD; LIPNER, 2006). O SDL é mais eficaz 
devido à ciência da segurança em função de: 
• Auxiliar na localização das vulnerabilidades do software.
• Desenvolver ferramentas e técnicas de mitigação de explorações que serão 
adotadas pelos desenvolvedores.
• Monitorar as tendências de modo contínuo.
• Aperfeiçoar as ferramentas e os processos através dos monitoramentos das 
ameaças.
O monitoramento contínuo é primordial, já que, quando uma nova 
ameaça entra no ecossistema, são ativados os processos de resposta de segurança 
da Microsoft. A Microsoft utiliza o SDL para incluir práticas de segurança 
comprovadas no desenvolvimento de software. O grande ponto a ser considerado 
é que as ameaças aos softwares não são estáticas e, por isso, o SDL sofre um processo 
de aperfeiçoamento ao longo dos anos (HOWARD; LIPNER, 2006). Isso possibilita 
um refinamento e melhoramento da tecnologia, ainda, um compartilhamento, de 
modo agressivo, das práticas recomendadas com desenvolvedores de software 
de terceiros para o auxílio de uma prática em computação segura para todos.
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
13
FIGURA 4 – LINHA DO TEMPO DE APERFEIÇOAMENTO DO PROCESSO SDL
FONTE: O autor
6 ANÁLISE ESTÁTICA DE CÓDIGO 
A análise estática de código é umas das técnicas estáticas de inspeção 
de software no processo de verificação e validação (V&V), sendo uma análise 
automatizada seguida de uma análise profissional dos resultados obtidos 
(ALVES, 2006; LI; BAOJIANG, 2010). A verificação ocorre antes que o software 
seja executado. 
Os verificadores estáticos são considerados ferramentas importantes que 
varrem o código-fonte ou o código-objeto para chamar a atenção do desenvolvedor 
para anomalias do programa, como variáveis utilizadas sem serem iniciadas, variáveis 
não utilizadas ou atribuições com valores fora dos seus limites (LI; CUI, 2010).
As anomaliassão, usualmente, produto de erros de programação ou 
ausência, de maneira que elas sinalizam erros que poderiam prejudicar o software 
quando ele fosse executado (LI; CUI, 2010; CARVALHO, 2017). Entretanto, 
essas anomalias não são, necessariamente, defeitos de programa, por isso, a 
necessidade da análise profissional. Desse modo, o objetivo da análise é destacar 
os problemas, para sua correção com objetividade, tendo, como resultado, mais 
eficiência no processo de desenvolvimento seguro (ALVES, 2006; LI; CUI, 2010). 
A análise estática pode ser agrupada em:
• Verificação por estilo: examina elementos, como endentação, espaços e tabs, 
convenção de nomes, alinhamento na vertical etc. Esses aspectos contribuem 
para que o código seja padronizado, organizado e legível. 
• Verificação por boas práticas: utiliza muitas regras para verificar se as práticas 
corretas estão sendo efetivadas, como: evitar duplicação de código; garantir o 
correto uso de encoding; tamanho de métodos, classes e parâmetros; utilização 
do padrão Singleton etc. O conjunto de regras utilizadas é extenso para 
garantir que o código tenha as melhores práticas. 
• Verificação por bugs: encontrar erros no sistema, permitindo a antecipação de 
problemas no software. A ferramenta mais usada, nesse processo, é o Firebug.
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
14
A verificação das ferramentas PMD e Checkstyle é feita sobre código-fonte 
não compilado (arquivo com extensão .java), porém, a verificação com Firebug analisa 
bytecodes (arquivos compilados do Java, com extensão .class). Desse modo, para análi-
ses envolvendo Firebug, uma compilação prévia é necessária.
NOTA
7 O PROBLEMA DA SEGURANÇA NO SOFTWARE
Ao longo deste tópico, podemos perceber a importância dos softwares 
e dos seus processos ao longo do desenvolvimento. No entanto, quando ocorre 
uma falha, devido a erros de programação, inúmeros problemas são gerados 
decorrentes das vulnerabilidades no software (FONTES, 2008; 2011). 
A codificação é considerada um dos maiores causadores dessas 
vulnerabilidades, já que, muitas vezes, o programador considera, geralmente, 
os cenários positivos, não se preocupando com o caso de ataques (BASU, 2015; 
TORRES; TORRES, 2016; FERREIRA, 2019).
Os imprevistos causados pela exploração dessas vulnerabilidades estão 
vinculados com a perda da integridade da informação ou a divulgação indevida 
(PINHEIRO, 2007; FONTES, 2008; FONTES, 2011; WAGNER, 2011). A Microsoft 
(2010 apud FERREIRA, 2019) utiliza o acrônimo STRIDE para classificar os efeitos 
provocados pelas falhas de segurança.
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
15
FONTE: O autor
Esses efeitos podem causar impactos de baixo a alto valor que irão 
depender do sistema computacional no qual o software está sendo executado. 
Conforme Fontes (2011), os incidentes podem ser simples, como a reinstalação 
de um aplicativo em uma máquina, ou impactos sérios, que afetam a vida 
humana, como a perda de controle de um sistema de transmissão de energia 
elétrica, ou de sistemas de comunicação, por exemplo. Fernandes (2013) destaca 
que o uso contínuo da internet aumenta as possibilidades de ataques, por isso, o 
desenvolvimento de software tem sofrido uma evolução constante para incorporar 
a segurança da informação durante todas as fases de desenvolvimento.
8 BENEFÍCIOS DO DESENVOLVIMENTO SEGURO 
Geralmente, as empresas iniciam os programas de desenvolvimento 
de software se concentrando na funcionalidade, e os testes segurança são 
acrescentados no fim do processo de desenvolvimento (ALVES, 2006; FONTES, 
2011; KOLBE JUNIOR, 2020). Entretanto, essa abordagem possui desvantagens em 
relação a um processo que engloba a segurança durante todo o desenvolvimento. 
FIGURA 5 – ACRÔNIMO STRIDE PROPOSTO PELA MICROSOFT
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
16
FIGURA 6 – CHARGE SOBRE SEGURANÇA DE SOFTWARE
FONTE: <http://bit.ly/2WvMnw6>. Acesso em: 19 jun. 2020.
Conforme o National Institute of Standards and Technology (NIST), 
as correções de código, que são executadas após o lançamento, geram, 
aproximadamente, um custo 30 vezes maior do que das correções efetuadas 
durante a fase inicial (GALITEZI, 2011; KOLBE JUNIOR, 2020). As empresas que 
adotam um processo estruturado apresentam maior probabilidade de localizarem 
e corrigirem as vulnerabilidades no início do ciclo de desenvolvimento (GALITEZI, 
2011). 
O que precisamos considerar é que a prática de segurança no 
desenvolvimento de softwares não é utilizada por todos, mas por aqueles 
desenvolvedores, que usam uma abordagem preventiva coordenada, que 
obtêm um retorno aproximadamente quatro vezes maior do que o investimento 
anual (GALITEZI, 2011; WAGNER, 2011). Então, os principais benefícios de um 
desenvolvimento seguro, conforme Wagner (2011), são:
• Economia: a definição de requisitos de segurança e a manutenção de equipes 
que compreendam os conceitos fundamentais de segurança permitem que 
as informações utilizadas ao longo do desenvolvimento do software sejam 
usadas quando estritamente necessárias. Um código seguro é a efetivação 
de um projeto de sucesso, já que evita as vulnerabilidades e os defeitos. O 
TÓPICO 1 — DESENVOLVIMENTO DE SOFTWARE
17
resultado será economia no tempo e nos recursos, tendo um projeto rentável 
e eficiente para a empresa. 
• Produtividade: os profissionais assimilaram o sistema e, com isso, 
estabeleceram um modelo de trabalho compartilhado. No entanto, as 
informações são partilhadas de maneira ágil e incorporadas, garantindo a 
segurança do desenvolvimento do software. Isso permite mais produtividade 
dos profissionais envolvidos. 
• Foco: uma organização que investe em segurança faz com que os 
desenvolvedores se entendam e foquem o seu tempo nos processos, ou seja, 
compreendam as estratégias de mercado e apliquem no desenvolvimento do 
software. 
 
O que podemos observar é que, atualmente, muito se fala da segurança, 
mas é na segurança de software que tudo começa, já que um processo seguro 
de desenvolvimento envolve proteção física, tecnológica, conscientização dos 
profissionais envolvidos, e cada um tem suas ameaças, vulnerabilidades e riscos, 
o que gera desafios constantes. O que podemos verificar, ao longo deste tópico, é 
que a proteção é um desafio de grande importância na organização e precisa ser 
considerado em todas as etapas do desenvolvimento do software para que sua 
segurança seja garantida. 
Para finalizar este tópico, vamos entender a diferença entre qualidade do 
processo de software versus qualidade do produto de software. 
Conforme Bartie (2002) e Basu (2015), a qualidade se refere a algo operacional que precisa 
estar em conformidade com as especificações que foram definidas, porém, a qualidade do 
produto é definida como as características do produto. 
NOTA
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
18
FONTE: Adaptado de <http://bit.ly/3h2s3fp>. Acesso em: 18 jun. 2020.
QUALIDADE DO PROCESSO DE SOFTWARE VERSUS QUALIDADE DO PRODUTO DE 
SOFTWARE
19
Neste tópico, você aprendeu que:
• O processo de desenvolvimento de softwares é algo complexo e, para isso, é 
preciso um conjunto de atividades organizadas e sequências estruturadas em 
passos definidos.
• Um grande ponto a ser considerado na segurança do desenvolvimento de 
software, e que está relacionado com a sua definição, é o fato de que um 
determinado software pode ser composto por algumas dezenas de linhas 
de código desenvolvidas por um programador, ou pode ser constituído por 
milhões de linhas de código, dados de configuração, documentação etc.
• O processo de software desenvolvido em uma organização é, geralmente, 
formulado através de padrões previamente descritos. 
• A segurança da informação é definida como um conjunto de orientações, 
normas, procedimentos, políticas ou outras ações que proteja o recurso à 
informação.
• Um ponto crítico ligado ao processo de desenvolvimento é a segurança, além 
da proteção das informações confidenciais. Consequentemente,a segurança 
do software corresponde à habilidade do software de evitar, além de suportar 
eventos que ameacem a dependabilidade.
• O desenvolvimento seguro não é somente a codificação, engloba a 
infraestrutura, para suportar o ambiente da aplicação. Desse modo, é preciso 
investir na proteção de todo o ambiente.
• O SDL se concentra no desenvolvimento do software, introduzindo a 
segurança e a privacidade em todas as fases do desenvolvimento. O SDL 
concilia uma abordagem global com a prática de minimização do número 
e do grau de severidade das vulnerabilidades nos produtos e serviços da 
Microsoft.
• O monitoramento contínuo é primordial, já que, quando uma nova ameaça 
entra no ecossistema, são ativados os processos de resposta de segurança da 
Microsoft. 
• A análise estática de código é umas das técnicas estáticas de inspeção de 
software no processo de Verificação e Validação (V&V), sendo uma análise 
automatizada seguida de uma análise profissional dos resultados obtidos.
RESUMO DO TÓPICO 1
20
• As anomalias são, usualmente, produto de erros de programação ou ausência, 
de maneira que elas sinalizam erros que poderiam prejudicar o software 
quando ele fosse executado.
• A codificação é considerada como um dos maiores causadores dessas 
vulnerabilidades, já que, muitas vezes, o programador considera, geralmente, 
os cenários positivos, não se preocupando com o caso de ataques.
• A prática de segurança no desenvolvimento de softwares não é utilizada 
por todos, mas por aqueles desenvolvedores que usam uma abordagem 
preventiva coordenada, que obtêm um retorno aproximadamente quatro 
vezes maior do que o investimento anual.
21
1 O desenvolvimento de um produto pode ocorrer por processos distintos, 
mesmo que seja um produto similar ou igual, porém, se um processo 
inadequado for usado, isso gerará o comprometimento da qualidade do 
produto final que está em desenvolvimento (SÊMOLA, 2003; FONTES, 
2011). Considerando essa afirmação, descreva as fases de processos para o 
desenvolvimento seguro de um software.
2 O desenvolvimento seguro não é somente a codificação, engloba a 
infraestrutura para suportar o ambiente da aplicação. Desse modo, é preciso 
investir na proteção de todo o ambiente (HOWARD; LIPNER, 2006). Agora, 
assinale a alternativa INCORRETA:
a) ( ) O SDL se concentra no desenvolvimento de software, introduzindo a 
segurança e a privacidade em todas as fases do desenvolvimento.
b) ( ) O SDL concilia uma abordagem global com a prática de minimização 
do número e do grau de severidade das vulnerabilidades nos produtos 
e serviços da Microsoft.
c) ( ) A ciência interna do SDL foi desenvolvida para compreender como os 
sistemas de computador são seguros e com planos de contingência.
d) ( ) O SDL é compartilhado de modo gratuito pela Microsoft com organi-
zações de desenvolvimento de clientes e do setor de software, tendo, 
como resultado, o desenvolvimento de softwares mais seguros.
3 O que precisamos considerar é que a prática de segurança no desenvolvimento 
de softwares não é utilizada por todos, mas aqueles desenvolvedores 
que usam uma abordagem preventiva coordenada obtêm um retorno 
aproximadamente quatro vezes maior do que o investimento anual 
(GALITEZI, 2011; WAGNER, 2011). Sobre o exposto, classifique V para as 
sentenças verdadeiras e F para as sentenças falsas:
( ) Um código seguro é a efetivação de um projeto de sucesso, já que evita as 
vulnerabilidades e os defeitos.
( ) Uma organização que investe em segurança faz com que os desenvolve-
dores se entendam e foquem o seu tempo nos processos.
( ) Um processo seguro de desenvolvimento envolve apenas proteção física 
em um grau de implementação do sistema.
( ) As empresas que adotam um processo estruturado apresentam maior 
probabilidade de localizarem e corrigirem as vulnerabilidades no início 
do ciclo de desenvolvimento.
Assinale a alternativa que apresenta a sequência CORRETA:
a) ( ) V – V – V – V.
b) ( ) V – F – V – V.
c) ( ) F – F – V – V.
d) ( ) V – V – F – V.
AUTOATIVIDADE
22
4 O processo de desenvolvimento de softwares é algo complexo e, para isso, 
é preciso um conjunto de atividades organizadas e sequências estruturadas 
em passos definidos (SÊMOLA, 2003; ALVES, 2006; FONTES, 2011). Esse 
conjunto de atividades é definido como um processo de desenvolvimento 
de software, que recebe ajuda da engenharia de software (ALVES, 2006; 
FONTES, 2011). Assinale a alternativa CORRETA:
a) ( ) Uma das etapas que causa grande preocupação neste processo é a falta 
de definição de uma política na implementação do software.
b) ( ) As vulnerabilidades nos projetos podem gerar a quebra de sigilo e a 
aquisição de novas informações.
c) ( ) As organizações estão em uma busca contínua para adotar medidas 
alinhadas às metodologias de desenvolvimento.
d) ( ) Existe a necessidade de produtos de software que, além suportarem os 
negócios, apresentem melhorias de segurança contínua.
5 O processo de software desenvolvido em uma organização é, geralmente, 
formulado através de padrões previamente descritos, sendo que estes 
definem um conjunto de ações e atividades, necessárias ao desenvolvimento 
do software (SOMMERVILLE, 2011). Considerando essa afirmação, assinale 
a alternativa INCORRETA:
a) ( ) Um modelo de processo de software pode ser compreendido como um 
roteiro a ser seguido para desenvolver um software de alta qualidade 
em um tempo determinado.
b) ( ) Modelo de processo pode ser considerado uma representação abstrata 
de um processo de software.
c) ( ) Os softwares são responsáveis pela geração de informações, por isso, a 
segurança do software está atrelada à segurança da informação.
d) ( ) Um dos pontos críticos ligados ao processo de desenvolvimento é o 
acesso contínuo às informações confidenciais.
23
TÓPICO 2 — UNIDADE 1
SEGURANÇA DE DADOS
1 INTRODUÇÃO
A gestão de segurança é considerada um processo que padroniza as 
melhores práticas de segurança com uma variedade de produtos. A falta de gestão 
de segurança gera problemas e a falta de respostas necessárias para resolver os 
problemas de ameaças e vulnerabilidades (FERREIRA, 2003; FERREIRA, 2019; 
GALITEZI, 2011).
Conforme Carvalho (2017), a segurança no desenvolvimento do software 
precisa considerar muitos fatores, não sendo um problema de solução única. A 
abordagem engloba:
• profissionais tecnicamente capacitados na linguagem; 
• planejamento criterioso no levantamento de requisitos;
• equipamentos com poder computacional suficiente;
• equipe de monitoramento proativa para criar e sustentar aplicações com certo 
nível de segurança.
Portanto, sem um padrão de segurança estabelecido, os clientes não 
terão garantia de que o software será seguro (GOMES et al., 2014; FERREIRA, 
2019). Sem uma gestão, não existe igualdade de segurança do produto em toda 
a organização. Ainda, sem um processo padrão estabelecido, algumas equipes 
de produto ignoram a segurança (FONTES, 2008; FONTES, 2011). Então, neste 
tópico, compreenderemos os principais conceitos de segurança que envolvem o 
desenvolvimento do software.
2 CONCEITOS DA SEGURANÇA DA INFORMAÇÃO
Conforme Fontes (2008) e Fontes (2011), a segurança da informação é uma 
área do conhecimento que protege a informação através de ações e normas que 
precisam ser cumpridas. Desse modo, Fontes (2008, p. 11) define: 
A segurança da informação é definida como um conjunto de 
orientações, normas, procedimentos, políticas e demais ações que tem, 
por objetivo, proteger o recurso, a informação, possibilitando que o 
negócio da organização e a sua missão sejam alcançados. A segurança 
existe para minimizar os riscos do negócio em relação à dependência do 
uso dos recursos de informação para o funcionamento da organização. 
Sem a informação ou com uma incorreta, o negócio pode ter perdas 
que comprometam o seu funcionamento e o retorno de investimento 
dos acionistas. 
24
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
Agora, é preciso analisarum item importante do processo de segurança do 
software, que é a implantação de uma política de segurança. Conforme Ferreira 
(2019), um processo adequado de implantação de uma política organizacional 
envolve: 
• Desenvolvimento da política: responsável pela definição dos requisitos 
corporativos da política de segurança da informação, além do estabelecimento 
de padrões para documentação. 
• Aprovação da política: responsável pelo gerenciamento da fase de identificação 
das necessidades da política até a autorização da política final.
• Implementação da política: responsável pela solicitação e pelo recebimento do 
apoio executivo. Nesta etapa, é elaborado um programa de conscientização 
de segurança corporativa.
• Conformidade com a política: avaliação da conformidade e da efetividade 
da política implementada, além de elaborar ações corretivas para a não 
conformidade. 
• Manutenção da política: realizar revisões formais da política e fundamentar 
um processo de gestão de mudanças.
Portanto, é essencial que seja abordada a hierarquia de documentos dentro 
de uma organização, considerando, principalmente, a segurança da informação 
(GOMES et al., 2014; CARVALHO, 2017; FERREIRA, 2019). A hierarquia possibilita, 
à organização, a apresentação dos documentos de segurança implementados ou 
aqueles que estão na fase de planejamento.
A hierarquia é considerada uma ferramenta importante de comunicação 
para os tomadores de decisões, gerentes de negócio, desenvolvedores, auditores 
e outros, para explicar quais documentos estão disponíveis e quais são aplicáveis 
em cada caso (GOMES et al., 2014; CARVALHO, 2017; FERREIRA, 2019). 
FIGURA 7 – EXEMPLIFICAÇÃO DE HIERARQUIA DE DOCUMENTOS
FONTE: Carvalho (2017, p. 20)
TÓPICO 2 — SEGURANÇA DE DADOS
25
Agora, vamos compreender os principais conceitos que estão inclusivos 
na formulação de uma política organizacional e em todo o processo de desenvol-
vimento de softwares. Podemos, conforme Fontes (2008), considerar os seguintes 
conceitos da segurança para garantir a proteção da informação: 
• Confiabilidade: a informação dever ser acessada e usada somente por aqueles 
que precisam dela para efetuar suas atividades na organização, por isso, deve 
existir uma prévia autorização.
• Integridade: a informação deve ser correta, verdadeira e não pode estar cor-
rompida.
• Disponibilidade da informação: a informação deve ser acessível para garantir o 
funcionamento do negócio e para que sejam atingidos os objetivos propostos. 
• Legalidade: o uso da informação precisa estar de acordo com as leis aplicáveis, 
licenças e contratos.
• Auditabilidade: o acesso e o uso da informação precisam ser registrados para 
identificar quem fez o acesso e o que foi realizado com a informação.
Portanto, para que as informações sejam protegidas, é essencial que estejam 
claros os pilares da segurança, que são primordiais para a proteção dos dados, pos-
sibilitando um bom funcionamento das infraestruturas. 
FIGURA 8 – PILARES DA SEGURANÇA
FONTE: <http://bit.ly/38rL6fh>. Acesso em: 28 jun. 2020.
Um processador de texto não tem, como principal preocupação, a 
confiabilidade, então, é necessário o bom senso do usuário em tomar algumas medidas de 
precaução, como salvar o trabalho frequentemente, para que não tenha maiores problemas 
(ALVES, 2006).
NOTA
26
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
Desse modo, os padrões de segurança mostram as soluções adequadas 
para problemas recorrentes, além de servirem de modelo (CARVALHO, 2017; 
TANENBAUM; WOODHULL, 2009; FERREIRA, 2019).
O uso de padrões de segurança é uma estratégia que pode ser aplicada aos 
processos de desenvolvimento de software, com o objetivo de torná-los confiáveis 
através da inserção de atividades que implementem a segurança, de acordo com 
a solução descrita no padrão (SÊMOLA, 2003; ALVES, 2006; FONTES, 2011). 
A seguir, estarão relacionados outros conceitos fundamentais para o 
desenvolvimento de um software seguro.
QUADRO 5 – CONCEITOS DE SEGURANÇA
FONTE: Adaptado de Fontes (2011), Fernandes (2013) e Ferreira (2019)
CONCEITO DEFINIÇÃO
Ameaça
causa potencial de um incidente indesejado, gerando 
dano para um sistema ou organização. Pode ser, ainda, 
um agente externo ao ativo de informação se aproveitan-
do das vulnerabilidades para romper a confidencialida-
de, integridade ou disponibilidade da informação.
Vulnerabilidade fragilidade de um ativo, ou, ainda, de um determinado grupo de ativos que pode ser explorada por ameaças.
Impactos de 
incidentes
potenciais prejuízos provocados ao negócio por 
fragilidades na segurança. Os prejuízos geram perdas de 
recursos financeiros e profissionais, além da deterioração 
da imagem da organização no mercado. 
Privacidade
proteção das informações e a sua utilização de modo ade-
quado através da autorização do cliente. Desse modo, 
uma grande quantidade de informações armazenadas 
gera maior investimento para garantir a segurança, por-
tanto, muitas informações armazenadas podem gerar um 
alto custo para a organização em detrimento dos bene-
fícios do armazenamento. É essencial verificar a relação 
custo x benefício, sendo necessário uma análise de quais 
informações trazem vantagem competitiva. 
Identificação
identificar o usuário dentro do sistema, ou seja, um usu-
ário para uma pessoa. Essa prática possibilita a identifi-
cação do responsável por uma ação efetuada dentro da 
aplicação por meio da trilha de auditoria.
Autenticação
prova que o usuário é ele mesmo, pois ele possui a identi-
dade de acesso na aplicação. O processo pode sofrer me-
lhorias, utilizando a autenticação multifator.
Autorização garantir que o usuário possua autorização concedida pelo cliente da aplicação a acesso das informações. 
Responsabilização garante que a ação executada possa ser atribuída a uma determinada pessoa ou sistema.
Assurance Garante que os controles de segurança foram implemen-tados, avaliados e testados.
TÓPICO 2 — SEGURANÇA DE DADOS
27
3 PRINCÍPIOS DO SOFTWARE SEGURO
A segurança deve ser uma preocupação em todo o processo de 
desenvolvimento, para que problemas com erros, vulnerabilidades e ameaças 
não aconteçam no produto final. Assim, quando se propõe uma solução para 
a resolução de problemas, é preciso considerar os princípios fundamentais do 
software seguro, descritos por Viega e McGraw (2006 apud FERREIRA, 2019).
QUADRO 6 – PRINCÍPIOS DO SOFTWARE SEGURO
FONTE: Adaptado de Carvalho (2017) e Ferreira (2019)
PRINCÍPIOS DESCRIÇÃO
Proteger o elo mais 
fraco
A segurança defensiva do sistema precisa ser como 
uma corrente interligada. Os ataques ocorrerão nas 
brechas do elo mais frágil dessa cadeia.
Defender em 
profundidade
Gerir o risco de modo defensivo em todas as camadas 
e componentes, para que, se um deles falhar, o outro 
consiga funcionar de maneira adequada.
Falhar com 
segurança
Enfrentar as falhas e erros com segurança, pois o 
manuseio inadequado de falhas é, geralmente, a causa 
de quebras de segurança.
Minimizar o 
privilégio
Executar o software com a minimização de privilégios 
para reduzir o possível impacto de um ataque.
Compartimentar 
acessos e áreas
Limitar o máximo possível os danos de ataques, 
compartimentando as áreas, usando VPNs, contentores, 
firewalls.
Manter a 
simplicidade (Keep 
It Simple- KISS)
A maior complexibilidade de um sistema gera mais 
dificuldade de manutenção e, consequentemente, 
muitos problemas à segurança.
Promover a 
privacidade
A proteção de dados pessoais e do sistema é essencial. 
A causa de muitos ataques é a exposição inadequada 
de informação sensível.
Esconder segredos é 
difícil
Até mesmo os melhores algoritmos de segurança 
podem ser quebrados e a confiança no “secreto” é a 
origem das falhas de segurança.
Confiar 
desconfiando
A segurança tem, por premissa, a confiança de uma 
fonte, mas nunca se pode confiar plenamente. Por isso, 
é necessário sempre tomar as devidas contramedidas 
para manutenção do software seguro.
Usar os recursos da 
comunidadeSe algo está bem concebido e já foi escrutinado pela 
comunidade, provavelmente, é uma boa fonte de 
segurança.
28
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
4 SETE PONTOS DE SEGURANÇA DO SOFTWARE SEGURO
Os sete pontos foram definidos por McGraw (2005 apud FERREIRA, 2019) 
e foram organizados pela eficácia e quantidade de erros e falhas que podem 
verificar e mitigar nas diferentes fases de desenvolvimento de um software: 
• Análise estática e revisão de código-fonte para verificar bugs e vulnerabilidades.
• Análise de risco para evidenciar tipos e padrões de ataque.
• Testes de penetração para testar as aplicações em ambiente simulado e em 
ambiente real.
• Os testes de qualidade precisam abranger os testes de funcionalidade padrão 
e os testes de segurança baseados em padrões de ataque.
• Construção de casos de abuso que identifiquem maus usos do sistema, além 
das respostas deste.
• Especificação de requisitos de segurança delineados, permitindo as respostas 
do sistema.
• Monitoramento do software contra padrões de ataque de modo a ter sistemas 
mais seguros. 
Esses pontos de contato possuem tarefas específicas que estão relacionadas 
com diferentes fases de um processo, não sendo, portanto, uma sequência linear. 
A detecção de algum problema leva a revisitar e a atualizar as especificações de 
cada etapa para que o resultado alcançado seja o mais seguro.
TÓPICO 2 — SEGURANÇA DE DADOS
29
5 REQUISITOS DE SEGURANÇA DE SOFTWARE 
Ferreira (2019) define requisitos de segurança como as necessidades 
do software para atender às políticas regulatórias e institucionais de uma 
organização. Desse modo, a definição dos requisitos de segurança é realizada 
pelos engenheiros de sistemas com os usuários. A norma ISO/IEC 27001 (20093) 
salienta que os requisitos de segurança são identificados por meio de uma análise 
sistemática dos riscos de segurança da informação. 
Os requisitos de segurança de software precisam englobar as necessidades 
de segurança da organização definidas nas políticas organizacionais. O que se 
percebe como ponto fundamental no delineamento dos requisitos de segurança 
é o reconhecimento das ameaças. Para isso, consideram-se as políticas de alto 
nível da organização para determinar a relevância de cada uma das ameaças 
(TANENBAUM; WOODHULL, 2009; CARVALHO, 2017; FERREIRA, 2019). 
Analise o exposto a seguir para complementar a sua compreensão acerca 
da importância da segurança no desenvolvimento dos softwares. 
VULNERABILIDADES DO SOFTWARE
FONTE: Adaptado de <https://bit.ly/3auhz78>. Acesso em: 26 jun. 2020.
UNI
https://ynternix.com/saiba-a-diferenca-de-virus-e-malwares-o-que-sao-trojans-spyware-adwares/
30
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
Os requisitos podem ser alinhados conforme as fontes, ou seja, um conjunto 
particular de princípios, objetivos e os requisitos do negócio para o processamento 
da informação, tendo os seguintes tipos, de acordo com Ferreira (2019): 
• Fonte da análise/avaliação de riscos: considera os objetivos e as estratégias 
globais do negócio da organização. Por meio da análise e da avaliação de 
riscos, são indicadas as ameaças aos ativos, além das vulnerabilidades. Após 
esta etapa, é efetuada uma estimativa da probabilidade de ocorrência das 
ameaças, além do potencial do impacto causado ao negócio.
• Fonte legal: considera a legislação vigente, regulamentação, estatutos e 
cláusulas contratuais que a organização, parceiros comerciais, contratados e 
provedores de serviços possuem. 
6 FERRAMENTAS E TÉCNICAS DE AVALIAÇÃO DOS RISCOS
O risco é considerado como algo que pode ou não acontecer, mas se 
acontecer, terá impactos negativos ao projeto em relação aos custos, prazos, 
qualidade, tempo ou satisfação do usuário (FERNANDES, 2013; GOMES et al., 
2014; CARVALHO, 2017). Um risco pode ter uma causa definida ou várias causas 
e, se acontecer, pode gerar um ou vários impactos (FONTES, 2011). O risco, de 
acordo com Ferreira (2019), possui duas dimensões, no caso da sua ocorrência: 
• Probabilidade da sua ocorrência: está ligada à causa-raiz. As ações direcionadas 
à causa do risco afetam a probabilidade de o risco não acontecer.
• Impacto sobre o projeto: está associado ao efeito. As ações sobre o efeito do 
risco afetam o impacto. 
A identificação de riscos gera uma seleção de ocorrências que pode 
ameaçar ou oferecer vantagens em relação aos objetivos do projeto. A causa de um 
risco pode ser um requisito, uma restrição ou uma condição que gere resultados 
negativos ou positivos (GOMES et al., 2014; CARVALHO, 2017). Durante o 
processo de levantamento, surgem os riscos conhecidos, gerando uma resposta. 
Entretanto, alguns riscos não são gerenciados, assim, a equipe precisa elaborar 
um plano de contingência (GOMES et al., 2014; CARVALHO, 2017; FERREIRA, 
2019). A quadro a seguir relaciona as principais estratégias de contingência, 
conforme Lyra (2008). 
TÓPICO 2 — SEGURANÇA DE DADOS
31
QUADRO 7 – ESTRATÉGIAS DE CONTINGÊNCIA
FONTE: Adaptado de Lyra (2008)
O que é importante considerar é que um plano adequado de contingência 
pode ser capaz de sustentar a missão da organização, independentemente de 
quaisquer intempéries.
6.1 CATEGORIZAÇÃO DE RISCOS
O risco, no contexto da área de software, tem, como objetivo, ser 
incremental e direcionado à análise de riscos (LYRA, 2008; FERNANDES, 2013; 
CARVALHO, 2017). A área de riscos na engenharia de software evoluiu, já que 
passou de uma análise dentro dos modelos para uma gerência que está presente 
em todos os processos do ciclo de vida do software (CARVALHO, 2017). Desse 
modo, conforme Ferreira (2019), os riscos precisam ser categorizados. 
ESTRATÉGIA DE 
CONTINGÊNCIA DESCRIÇÃO
Hot-site Responsável para entrar em ação de modo imediato, sendo que o tempo de operacionalização está atrelado 
ao tempo de tolerância à falha do objeto. 
Warm-site
Utilizada em objeto com uma tolerância maior 
à paralisação, sendo que pode ficar sujeita à 
indisponibilidade por mais tempo, até o retorno 
operacional da atividade.
Cold-site Uma alternativa de contingência, considerando um ambiente com mínimos recursos (infraestrutura e 
telecomunicações).
Realocação de 
operação
Desviar a atividade que foi atingida pelo evento que 
causou a quebra da segurança para outro ambiente 
físico, link ou equipamento, pertencente a uma mesma 
organização. 
Bureau de serviços Transferir a processo de operacionalização da atividade atingida para um ambiente terceirizado. 
Essa estratégia é muito interessante.
Contingência significa algo incerto ou eventual, que pode suceder ou não, 
dependendo das circunstâncias.
NOTA
32
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
QUADRO 8 – CATEGORIAS DE RISCOS
FONTE: Adaptado de Ferreira (2019)
6.2 GERENCIAMENTO DE RISCOS EM PROJETOS
Os objetivos principais do gerenciamento dos riscos são o aumento da 
probabilidade, o impacto dos eventos positivos e a redução da ocorrência do 
impacto negativo no projeto (GOMES et al., 2014; CARVALHO, 2017). Desse modo, 
o gerenciamento de riscos representa a identificação das possíveis incertezas para 
tentar controlá-las. 
Ferreira (2019) segmenta a abordagem em três etapas principais, conforme 
o quadro a seguir. Assim, são abordados os riscos técnicos do produto vinculados 
aos requisitos de software, sendo identificados, analisados e controlados. 
QUADRO 9 – GERENCIAMENTO DE RISCOS
FONTE: Adaptado de Ferreira (2019)
 
Para cada atividade do ciclo de vida do processo de teste de software, existe 
um correspondente na gestão de risco, com o objetivo de fornecer o tratamento 
correto para os riscos técnicos identificados (FERREIRA, 2019). 
TIPO DE RISCO DESCRIÇÃO
Riscos de Projeto 
de Software
Define os parâmetros operacionais, organizacionais e 
contratuais de desenvolvimento de software.
Riscos de 
Processo de 
Software
Relacionam-se os problemas técnicos e de gerenciamento. 
Nos procedimentos técnicos, podem se encontrar riscos 
nas atividades de análise de requisitos, projeto, codificaçãoe teste.
Riscos de 
Produto de 
Software
Contém as características intermediárias e finais do 
produto. Esses tipos de riscos têm origem nos requisitos 
de estabilidade do produto, desempenho, complexidade 
de codificação e especificação de testes.
ETAPA DESCRIÇÃO
Lista priorizada de 
riscos
Identificação e análise dos riscos técnicos ligados aos 
requisitos de software.
Testes que 
exploram os riscos
Criação e execução dos casos de testes que verificam a 
existência ou não do risco identificado.
Monitoramento e 
controle dos riscos
Conforme um risco é eliminado, um novo risco pode 
surgir e os esforços de teste devem ser ajustados para 
que foquem nos riscos importantes.
TÓPICO 2 — SEGURANÇA DE DADOS
33
FIGURA 9 – ATIVIDADE NO PROCESSO DE DESENVOLVIMENTO DO SOFTWARE E A RELAÇÃO 
COM A GESTÃO DE RISCO
FONTE: Ferreira (2019, p. 23)
Conforme Ferreira (2019), agora, nós entenderemos os processos 
apontados:
• Estratégia e planejamento: englobam a identificação e avaliação deles, além 
do desenvolvimento de planos de contingência ou da mitigação dos riscos.
• Avaliação dos riscos: determina os efeitos de riscos potenciais. 
• Mitigação de riscos: focada em informações que foram levantadas nas etapas 
anteriores.
• Comunicação: tem, por base, as informações obtidas na identificação, 
planejamento, avaliação e mitigação dos riscos.
• Previsão de risco: resultado das atividades anteriores e representa a 
previsão de risco, envolvendo o conhecimento adquirido acerca dos riscos já 
identificados. 
• Fase execução do teste: monitora a qualidade de cada função individual, 
sendo uma atividade contínua durante toda a fase de teste.
Algumas ferramentas que auxiliam na gestão dos riscos, conforme Wagner 
(2011):
• Brainstorming – Entrevistas estruturadas ou semiestruturadas: um meio de coletar 
um amplo conjunto de ideias e avaliação, classificando-o por uma equipe. O brains-
torming pode ser estimulado através de instruções ou de técnicas de entrevista.
• Delphi: um meio de combinar opiniões de especialistas que possam apoiar a fonte 
e influenciar a estimativa de identificação, probabilidade, consequência e avaliação 
de riscos. É uma técnica colaboradora para a construção do consenso entre os 
especialistas. 
NOTA
34
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
• Structured What If Technique (SWIFT): um sistema para solicitar uma equipe para 
identificar os riscos. Normalmente, é utilizado dentro de um workshop facilitado. 
Normalmente, associado a uma técnica de análise e avaliação de riscos. 
• Análise de cenário: aborda a possibilidade de possíveis cenários futuros. Podem ser 
identificados por meio da imaginação ou extrapolação dos riscos atuais, presumindo 
que cada um desses cenários pode ocorrer.
• Análise de impacto nos negócios: Provê uma análise de como os principais riscos de 
quebra podem afetar as operações de uma organização e identifica e quantifica que 
capacidades que seriam requeridas para o gerenciamento.
6.3 MATRIZ DE RISCO
A ponderação de um risco é avaliada por meio da combinação da 
probabilidade ou frequência de ocorrência e da magnitude das consequências ou 
impacto dessa ocorrência (FERREIRA, 2019). A seguir, apresentaremos a matriz 
de probabilidade e impacto representada no PMBOK, que mostra uma escala de 
probabilidade e impacto de 0 (zero) a 5 (cinco). 
FIGURA 10 – MATRIZ DE PROBABILIDADE E IMPACTO
FONTE: <http://bit.ly/3mLP0F3>. Acesso em: 28 jun. 2020.
A matriz de risco é considerada uma ferramenta muito usada, que 
ajuda o desenvolvedor na classificação e priorização de riscos e, ainda, facilita a 
comunicação visual (FERNANDES, 2013; GOMES et al., 2014; FERREIRA, 2019). 
A representação é por meio de eixos de escalas de probabilidade de ocorrência e 
impacto para um determinado fator de risco.
Após a representação visual da matriz, cada um dos fatores de risco 
precisa ser identificado e avaliado em relação à probabilidade de ocorrência e 
ao impacto (LYRA, 2008; CARVALHO, 2017; FERREIRA, 2019). Os riscos que 
precisam ser tratados de modo prioritário ficam localizados na região vermelha.
TÓPICO 2 — SEGURANÇA DE DADOS
35
Com relação à defi nição dos níveis das dimensões, é necessário se atentar 
para que a quantidade de níveis para probabilidade e impacto seja a mesma, por 
exemplo, se for decidido que a probabilidade será apenas baixa, média e alta (três 
níveis), o impacto pode ser insignifi cante, moderado ou catastrófi co, ou seja, três 
níveis também.
FIGURA 11 – REPRESENTAÇÃO DE UMA MATRIZ DE RISCOS
FONTE: <http://bit.ly/34wDC9J>. Acesso em: 20 jun. 2020.
Observe, a seguir, um exemplo aplicado de uma matriz de impacto. Esse 
modelo irá ajudá-lo a entender como funciona o preenchimento da matriz.
EXEMPLIFICAÇÃO DA MATRIZ DE IMPACTO
FONTE: <http://bit.ly/3mLQAGZ>. Acesso em: 20 jun. 2020.
NOTA
36
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
A análise qualitativa de riscos avalia a prioridade dos riscos identificados, 
usando a probabilidade de eles ocorrerem, o impacto correspondente aos 
objetivos do projeto, se os riscos realmente ocorrerem, além de outros fatores, 
como o prazo e tolerância a risco das restrições de custo, cronograma, escopo e 
qualidade do projeto (ALVES, 2006; SÊMOLA, 2003; LYRA, 2008; FERNANDES, 
2013; CARVALHO, 2017; FERREIRA, 2019).
A análise qualitativa de riscos é, normalmente, uma maneira rápida e 
econômica de estabelecer prioridades para o planejamento de respostas a riscos 
e estabelece a base para a análise quantitativa de riscos (LYRA, 2008; FONTES, 
2011; FERNANDES, 2013).
7 PADRÕES DE SEGURANÇA
Você, ao longo deste tópico, percebeu o quão importante é, que no 
planejamento de um novo software, todos os envolvidos compreendam os 
padrões de segurança em vários níveis. Desse modo, as experiências adquiridas 
em projetos anteriores de software são uma fonte de consulta, além de websites 
e outras publicações especializadas (SÊMOLA, 2003; MOUGOUE, 2016; 
FERREIRA, 2019). Então, para finalizar este tópico, listaremos alguns exemplos 
de boas práticas de planejamento e de desenvolvimento de softwares, conforme 
Alves (2006), Fontes (2011), Fernandes (2013), Carvalho (2017) e Ferreira (2019).
• As configurações do software com informações sensíveis precisam ser 
criptografadas quando em ambiente de produção. Um exemplo é O Net, que 
oferece ferramentas nativas para criptografia de partes do arquivo web.config.
FIGURA 12 – O NET OFERECE FERRAMENTAS NATIVAS PARA CRIPTOGRAFIA
FONTE: <http://www.macoratti.net/Cursos/Cripto/net_cripto4.htm>. Acesso em: 20 jun. 2020.
http://www.macoratti.net/Cursos/Cripto/net_cripto4.htm
TÓPICO 2 — SEGURANÇA DE DADOS
37
• Defi nir modos de evitar SQL Injection, visto que esse tipo de ataque é 
usualmente comum. A consequência é a coleta de informações protegidas ou 
a inutilização do sistema.
FIGURA 13 – EXEMPLO DE SQL INJECTION
FONTE: <http://bit.ly/37BBW0h>. Acesso em: 20 jun. 2020.
• Impedir, passar e receber valores sensíveis de consulta na URL de websites. 
Os parâmetros devem ser transmitidos por meio do método GET do protocolo 
Hypertext Transfer Protocol (HTTP). Entretanto, em situações em que não se 
pode usar criptografi a SSL em decorrência de restrições de negócio, expõem-
se os parâmetros em texto puro (plain text) para o usuário, ou quem venha 
a sniff ar (capturar pacotes) na rede.
FIGURA 14 – EXEMPLO GET DO PROTOCOLO HTTP
FONTE: <https://medium.com/totvsdevelopers/rest-no-protheus-b%C3%A1sico-do-b%C3%A1si-
co-a4b4431a4e3e>. Acesso em: 20 jun. 2020.
38
UNIDADE 1 — DESENVOLVIMENTO DE SOFTWARE SEGURO
• Tratar os dados recebidos via HTTP no backend. Entretanto, em situações 
nas quais não se tenha esse cuidado, uma pequena modificação na Uniform 
Resource Locator (URL) pode executar uma consulta não prevista. Isso pode 
gerar a exposição de informações que não deveriam estar disponíveis ao 
usuário.
FIGURA 15 – EXEMPLIFICAÇÃO DO HTTP NO BACKEND
FONTE: <https://i.stack.imgur.com/ZvEoq.jpg>. Acesso em: 20 jun. 2020.
•