Logo Passei Direto
Buscar
Material
páginas com resultados encontrados.
páginas com resultados encontrados.
left-side-bubbles-backgroundright-side-bubbles-background

Crie sua conta grátis para liberar esse material. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

left-side-bubbles-backgroundright-side-bubbles-background

Crie sua conta grátis para liberar esse material. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

left-side-bubbles-backgroundright-side-bubbles-background

Crie sua conta grátis para liberar esse material. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

left-side-bubbles-backgroundright-side-bubbles-background

Crie sua conta grátis para liberar esse material. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

left-side-bubbles-backgroundright-side-bubbles-background

Crie sua conta grátis para liberar esse material. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

left-side-bubbles-backgroundright-side-bubbles-background

Crie sua conta grátis para liberar esse material. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

left-side-bubbles-backgroundright-side-bubbles-background

Crie sua conta grátis para liberar esse material. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

left-side-bubbles-backgroundright-side-bubbles-background

Crie sua conta grátis para liberar esse material. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

left-side-bubbles-backgroundright-side-bubbles-background

Crie sua conta grátis para liberar esse material. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

left-side-bubbles-backgroundright-side-bubbles-background

Crie sua conta grátis para liberar esse material. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Prévia do material em texto

Desenvolvimento de Software Seguro 
Marcio Quirino - 1 
 
SUMÁRIO 
Princípios de Software Seguro .............................................................................................................. 5 
Propósito .................................................................................................................................................... 5 
Objetivos .................................................................................................................................................... 5 
Introdução .................................................................................................................................................. 5 
1. Princípios de segurança e o software seguro ......................................................................... 5 
Aspectos essenciais entre princípios de segurança e software seguro ..................................................... 5 
O essencial da confidencialidade ............................................................................................................... 6 
A garantia da integridade ........................................................................................................................... 7 
A importância da disponibilidade ................................................................................................................ 8 
A importância da autenticação e autorização ............................................................................................. 9 
2. Princípios de design seguro de software ................................................................................. 9 
Elementos fundamentais do design de um software seguro ...................................................................... 9 
Fundamentos do privilégio mínimo de um software seguro ..................................................................... 10 
Defesa em profundidade e padrões à prova de falhas ............................................................................. 11 
Defesa em profundidade ...................................................................................................................... 11 
Os padrões à prova de falhas .............................................................................................................. 11 
Separação de funções e Security by Design ............................................................................................ 12 
Economia de mecanismo, design aberto e defesa contra erros ............................................................... 12 
3. Avaliação da cadeia de suprimentos ..................................................................................... 13 
Elementos da cadeia de suprimentos de um software seguro ................................................................. 13 
Vulnerabilidades dos componentes de um software ................................................................................ 14 
Avaliação e gerenciamento dos riscos ..................................................................................................... 14 
Práticas de codificação segura................................................................................................................. 15 
Testes de vulnerabilidades do software ................................................................................................... 16 
4. Conclusão............................................................................................................................... 17 
Considerações finais ................................................................................................................................ 17 
Explore + .................................................................................................................................................. 17 
Referências .............................................................................................................................................. 17 
Questões de Implementação Para Software Seguro .......................................................................... 18 
Propósito .................................................................................................................................................. 18 
Objetivos .................................................................................................................................................. 18 
Introdução ................................................................................................................................................ 18 
1. Validação de entrada ............................................................................................................. 18 
Verificação e validação......................................................................................................................... 19 
Vulnerabilidades na entrada de dados ................................................................................................. 19 
Bibliotecas de validação de entrada ......................................................................................................... 20 
Exemplos de bibliotecas ....................................................................................................................... 20 
Implementação da validação de entrada no servidor ............................................................................... 21 
Etapas para validação no lado do servidor........................................................................................... 21 
Desenvolvimento de Software Seguro 
Marcio Quirino - 2 
 
Limpeza de todas as entradas do usuário ................................................................................................ 22 
Etapas da tarefa de limpeza de dados ................................................................................................. 22 
Teste e revisão do código de validação de entrada ................................................................................. 23 
Etapas dos testes e revisão do código de validação de entrada .......................................................... 23 
2. Processamento de dados com segurança ............................................................................ 24 
Fundamentos do processamento de dados seguros ................................................................................ 24 
Práticas para processamento seguro dos dados ................................................................................. 24 
Controles de acesso ................................................................................................................................. 25 
Criptografia de dados ............................................................................................................................... 26 
Algoritmos de criptografia ..................................................................................................................... 26 
Protocolos de comunicação seguros ........................................................................................................ 27 
Busca por vulnerabilidades e testes ......................................................................................................... 27 
3. Chamadas em software seguro ............................................................................................. 28 
Fundamentos de Chamadas .................................................................................................................... 28 
O uso de funções e medidas preventivas para chamadas seguras ..................................................... 28 
Chamadas de APIs do sistema ................................................................................................................ 29 
Definição de permissões ..........................................................................................................................de comprimento. 
✓ O Django é um framework de código aberto para desenvolvimento web com a linguagem 
Python, baseado no padrão arquitetural model-template-views. 
6. Laravel Validation 
✓ Específica para validar entradas em aplicações web PHP. Ela permite validar a entrada em 
vários formatos, como strings, números e datas e suporta regras de validação personalizadas. 
Portanto, existem diversas bibliotecas de validação de entrada disponíveis para as mais variadas 
programações. Aqui, apresentamos apenas algumas. O mais importante é que você utilize uma biblioteca 
para implementar a validação da entrada para reduzir as vulnerabilidades do software que está 
desenvolvendo e isso certamente vai demandar mais estudo! Porém, tenha certeza de que está investindo 
o seu tempo para adquirir um conhecimento muito valorizado pelo mercado e capaz de lhe auxiliar em termos 
de empregabilidade e destaque profissional. 
A seguir, vamos falar sobre a implementação da validação de entrada do lado do servidor. O 
desenvolvimento de um software seguro, realmente, demanda muito estudo, mas estamos aqui para isso, 
não é mesmo? Então, vamos lá! 
Implementação da validação de entrada no servidor 
Quando falamos sobre validação de entrada de dados, quase sempre estamos nos referindo à 
aplicação do lado do cliente. No entanto, também devemos nos preocupar com a validação de entrada do 
lado do servidor. 
Atualmente, é muito comum utilizarmos aplicações que servem apenas para acessar o servidor e 
visualizar dados. Portanto, é necessário implementar a validação de entrada do lado do servidor, a fim de 
adicionar mais um elemento na criação de software seguro. Isso nos permite evitar vários tipos de 
vulnerabilidades, como ataques de injeção e estouros de buffer. 
Etapas para validação no lado do servidor 
A seguir, apresentamos algumas das etapas que devemos implementar para realizar a validação de 
entrada segura do lado do servidor: 
1. Identificar as entradas 
✓ Desenvolver métodos ou utilizar funções de bibliotecas — o que é a situação ideal - para 
identificar, explicitamente, quaisquer dados enviados. Esses dados podem vir por meio de 
formulários, cabeçalhos HTTP, cookies ou qualquer outra forma de entrada. 
2. Definir regras de validação 
✓ Definir tipos, comprimentos e formatos de dados esperados. 
3. Validar entrada 
✓ Validar as entradas para o servidor para verificar se estão em conformidade com as regras 
definidas. Caso não estejam, jamais devemos apresentar uma mensagem de erro do sistema 
para o usuário, mas sim uma mensagem indicando que o formato é inválido, sem fornecer 
dicas. 
4. Limpar a entrada 
✓ Remover qualquer código ou caracteres maliciosos é imprescindível. Em especial, no caso 
de entradas para consultas ao banco de dados, elas podem conter ataques de injeção de 
SQL. 
5. Realizar verificações de segurança de vulnerabilidades conhecidas 
✓ Conhecer as vulnerabilidades é fundamental para que possamos evitá-las. Existem muitos 
ataques bem documentados, como Cross-Site Scripting (XSS), que permitem a um invasor 
Desenvolvimento de Software Seguro 
Marcio Quirino - 22 
 
injetar código malicioso em uma página da web utilizada por outros usuários; e Cross-Site 
Request Forgery (CSRF), que permite a um invasor executar ações não autorizadas em nome 
de um usuário legítimo. 
6. Manter um log dos erros de validação 
✓ Utilizar mecanismos que registrem todas as ações ocorridas no sistema, de modo a investigar, 
caso seja necessário, os erros de validação que ocorrerem é muito importante para, assim, 
acionarmos os mecanismos legais para punir os invasores. Apesar de existirem muitas formas 
de tratar erros de validação de entrada, também há muitos golpes que se renovam. 
7. Manter as regras de validação atualizadas 
✓ Revisar os processos e garantir que estejam sendo aplicados é igualmente importante. Nesse 
sentido, o uso dos logs é fundamental para entendermos o que realmente está acontecendo 
no sistema e, assim, nos guiar sobre quais são as melhores ações a tomar para melhorarmos 
a validação da entrada do servidor. 
Todas essas etapas nos ajudam a implementar a validação de entrada do lado do servidor e reduzir 
as vulnerabilidades de segurança do nosso software. 
Na sequência, vamos analisar a limpeza dos dados dos usuários, com o objetivo de reduzir 
vulnerabilidades e aumentar a segurança dos nossos sistemas. 
Limpeza de todas as entradas do usuário 
Vamos imaginar a seguinte situação: você desenvolveu um pequeno sistema para a área de 
contabilidade da empresa. O cliente lhe informou que os dados de entrada sempre seriam numéricos e, 
portanto, você focou na implementação das regras de negócio e sem a suposição (ingênua) de que os 
usuários do sistema sempre entrariam com dados numéricos. 
Infelizmente, uma pessoa entrou com uma cadeia de caracteres – string – e o sistema falhou, 
apresentando uma mensagem de erro sem nenhum tipo de tratamento. Esta é uma situação muito comum 
de vulnerabilidade de software. 
Etapas da tarefa de limpeza de dados 
Esse cenário ocorre com muita frequência e serve como alerta sobre a importância de realizarmos 
ações de limpeza dos dados de entradas do usuário, para aumentamos a segurança do nosso servidor de 
software. No entanto, essa tarefa pode implicar a exclusão de dados do usuário. 
Por isso, precisamos de um processo bem definido para realizá-la com segurança. A seguir, 
apresentamos algumas etapas possíveis: 
1. Identificar as entradas do usuário 
✓ Nesta etapa, precisamos saber onde os dados ficam e como deveriam estar armazenados. 
Para isso, precisamos mapear as tabelas de banco de dados, os servidores, os arquivos de 
logs e quaisquer outros meios de armazenamentos de dados. 
2. Determinar as políticas de retenção 
✓ Aqui, nos referimos a quanto tempo os dados devem ser mantidos, quem deve ter acesso a 
eles e como devem ser destruídos quando não forem mais necessários. 
3. Definir um processo para limpar as entradas do usuário 
✓ Esta é uma etapa fundamental, pois precisamos definir um processo que faça verificação da 
identidade do usuário, validação das permissões do usuário para limpar os dados e um 
controle para confirmar a intenção do usuário de realmente excluir os dados e, obviamente, 
registrar essa ação em um arquivo de log. 
4. Usar métodos de exclusão segura 
✓ Nesta etapa aplicamos métodos que, de fato, apaguem os dados, de modo que não possam 
ser recuperados por um invasor. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 23 
 
5. Registrar o processo de exclusão 
✓ Sempre devemos utilizar uma ferramenta ou uma configuração de sistema que permita fazer 
o registro do processo de exclusão, ou seja, devemos ser capazes de responder quem excluiu 
os dados, quando foi realizada a exclusão e qual foi o motivo da exclusão. 
6. Notificar o usuário 
✓ Por fim, o sistema deve avisar explicitamente ao usuário que seus dados foram excluídos 
com segurança. 
Essas etapas auxiliam na limpeza dos dados de entradas do usuário com segurança e garantem que 
estejam protegidos segundo as regras corporativas – no caso, de empresas e demais organizações – ou 
enquanto assim desejarmos – no caso de uso pessoal. 
Teste e revisão do código de validação de entrada 
Por mais eficiente que seja a técnica que apliquemos no nosso sistema, do lado dos invasores vai 
existir um grande esforço para violar a segurança. Em especial, no caso de dados valiosos, isso se torna 
ainda mais crítico. Por isso, precisamos realizar treinamentos e estudar esse assunto continuamente. 
Atenção 
Uma etapa crítica no desenvolvimento de software seguro é fazer testes e revisões rotineiras do código de 
validação de entrada. 
Etapas dos testes e revisão do código de validação de entrada 
Essa é uma forma preventiva de reduzir vulnerabilidades e, caso seja necessário, realizar melhorias 
no código ou no próprio processo de validação de entrada. A seguir,estão listadas algumas etapas que 
podemos realizar para testar e revisar o código de validação de entrada em um software seguro: 
1. Verificar a qualidade das regras de validação 
✓ É essencial estarmos sempre alinhados com as melhores práticas de segurança. Por isso, 
precisamos entrar em sites como a OWASP e outros fóruns para acompanhar novas técnicas 
de validação e discussões sobre o assunto de profissionais que trabalham na área. 
2. Testar entradas inválidas 
✓ É necessário criar diversos cenários que forcem entradas inválidas no sistema. Essa 
abordagem é uma forma muito eficiente de simular ataques, identificar possíveis 
vulnerabilidades e, posteriormente, corrigi-las. 
3. Testar entradas válidas 
✓ É uma boa forma de simularmos o comportamento dos usuários legítimos que farão uso do 
sistema. Vamos avaliar se o sistema vai se comportar conforme o planejado para entradas 
válidas de usuário. 
4. Realizar testes de estresse 
✓ A ideia é forçar situações extremas, com a finalidade de identificar possíveis vulnerabilidades 
na validação de entrada. 
5. Usar técnicas de fuzzing 
✓ É importante para que seja possível automatizar testes que gerem entradas aleatórias ou, 
ainda, entradas que possam acionar determinados tipos de vulnerabilidades. 
6. Revisar o código para vulnerabilidades de segurança 
✓ É necessário revisar o código de validação de entrada e, se for o caso, realizar melhorias 
para nos prevenir de vulnerabilidades, visando reduzir as chances de que os invasores sejam 
bem sucedidos ao aplicar novas técnicas para atacar o sistema. 
7. Usar bibliotecas de validação 
✓ É sempre importante utilizar bibliotecas, pacotes e ferramentas que têm como finalidade 
realizar testes para detectar vulnerabilidades. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 24 
 
2. Processamento de dados com segurança 
Fundamentos do processamento de dados seguros 
Damos muita importância para os dados, o que está correto, pois eles podem ser muito úteis para 
agregação de valor. Entretanto, até chegarmos à etapa de melhorar processos ou criar uma compreensão 
de existirem oportunidades a serem exploradas por meio da análise dos dados, precisamos processá-los. 
Atenção 
Além das preocupações com a implementação das regras de negócio e outros algoritmos que deem essas 
respostas, precisamos garantir que o processamento dos dados não afete a segurança do sistema. 
A segurança de um sistema também precisa levar em consideração o processamento dos dados de 
forma segura. Portanto, precisamos implementar processos e controles capazes de prevenir que os dados 
sejam acessados por pessoas sem o devido acesso. Se a segurança for violada, isso pode levar a roubo, 
modificação indevida ou divulgação não autorizada. Por isso, precisamos usar recursos lógicos e físicos que 
limitem o acesso aos dados. 
Práticas para processamento seguro dos dados 
Listamos, a seguir, algumas práticas que nos ajudam a processar dados com segurança: 
1. Implementar controles de acesso 
✓ São mecanismos de controle responsáveis por garantir que apenas pessoas autorizadas 
tenham acesso aos dados. Exemplos: uso de mecanismos de autenticação que obriguem os 
usuários a utilizarem senhas fortes, autenticação multifator ou de duas fases, e uso de 
biometria para acessar o sistema de processamento de dados. 
2. Criptografar dados 
✓ Caso uma pessoa sem autorização consiga acessar os dados, os mecanismos de criptografia 
vão protegê-los, pois não farão sentido para o atacante. 
✓ Exemplo: os algoritmos simétricos e assimétricos empregados no processo de criptografia, 
como o AES (Advanced Encryption Standard) e RSA (Rivest-Shamir-Adleman). 
3. Implementar práticas de codificação segura 
✓ Utilizar mecanismos e estruturas de codificação conhecidos, capazes de garantir que o código 
seja escrito de maneira segura e, assim, o software poder processar os dados com 
segurança. Exemplos: validação de todas as entradas do usuário, limpeza dos dados, ou seja, 
procurar por conteúdo malicioso e removê-lo, e não executar entrada de dados sem passar 
por métodos que os critiquem. 
4. Usar protocolos de comunicação seguros 
✓ O exemplo mais clássico de protocolo de comunicação segura é o HTTPS, que protege os 
dados em trânsito na rede contra interceptação ou modificação, pois garante que os dados 
sejam criptografados e autenticados durante a transmissão. 
5. Fazer buscas por vulnerabilidade e teste de penetração 
✓ Quanto mais complexo for um sistema, maiores são as chances de que ele tenha 
vulnerabilidades. Por isso, é necessário ter uma rotina para tentar detectá-las e corrigi-las. 
Uma das formas de fazer isso é por meio do teste de penetração que força situações extremas 
e, assim, ajuda na identificação de possíveis vulnerabilidades. 
6. Limitar o tempo de processamento 
✓ Precisamos de uma métrica capaz de ajudar a estimar o tempo provável para que o programa 
processe os dados. Se o tempo consumido for muito diferente da média esperada, então, 
precisamos investigar o que aconteceu, pois é um sinal de alerta, de algo fora do normal. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 25 
 
Controles de acesso 
Uma das melhores formas para o processamento dos dados com segurança é garantir que apenas 
usuários legítimos possam acessá-los. Os controles de acesso são o instrumento responsável por garantir 
que apenas usuários autorizados possam realizar operações no sistema, tais como acessar os dados ou 
executar determinadas funções. 
Listamos alguns dos principais aspectos sobre os controles de acesso: 
1. Criação de perfis 
✓ Os usuários do sistema, por sua vez, serão associados a perfis com papéis de 
responsabilidade e que terão direitos e deveres. Dessa forma, facilitamos o processo de 
gerenciamento do controle de acesso. 
2. Princípio do privilégio mínimo 
✓ Os perfis de usuário devem ter acesso apenas a recursos e funções estritamente essenciais 
para que possa realizar suas funções. Caso o usuário precise de mais privilégios, então é 
necessário rever se ele está no perfil correto, ou, ainda, se devemos ampliar os privilégios do 
perfil em que está. Por meio do controle por perfis e do princípio do privilégio mínimo, 
podemos gerenciar melhor os comportamentos dos usuários do sistema e detectar anomalias 
com mais eficiência. 
3. Separação de funções 
✓ Os poderes que um perfil de usuário pode ter tornam-se menores quanto mais valiosos forem 
os dados que o sistema manipula. Nesse caso, a melhor solução é separar as operações 
sensíveis entre diferentes perfis de usuários, para evitar que um atacante – simulando um 
usuário legítimo – tenha controle total sobre uma função crítica. Obviamente, isso aumenta a 
quantidade de processos para realizar uma tarefa, por isso só deve ser aplicada se, 
realmente, for justificável. 
4. Controle de acesso baseado em perfil 
✓ O monitoramento e aplicação de políticas de controle de acesso baseadas em perfis de 
usuários do que em indivíduos é muito simples. A consequência direta desse tipo de controle 
é, no caso de invasão, mensurar os danos que podem ser causados no sistema e, assim, 
desenvolver contramedidas para prevenir que ocorram, ou, mesmo, para combater invasores. 
5. Autenticação de dois fatores 
✓ O controle semelhante aos usados para autenticar a entrada de dados no sistema também 
pode ser aplicado para verificar a identidade dos usuários que desejam ter acesso aos dados 
ou processá-los. Por exemplo, podemos usar uma estratégia na qual os usuários forneçam 
algo que eles conheçam, como uma senha, junto com algo que eles tenham, como um token 
físico ou um código único enviado para seu dispositivo móvel. 
6. Monitoramento e auditoria 
✓ O processo adotado novamente é semelhante ao que fazemos com o controle seguro de 
dados: geração de arquivos de logs. Por meio desses arquivos, podemos monitorar e, se for 
o caso, auditar o uso do sistema para garantirque tudo esteja funcionando conforme o 
esperado. Se houver alguma tentativa de acesso não autorizado, podemos investigar com 
mais cuidado e tomar medidas legais. 
7. Políticas de senha segura 
✓ O acesso por meio de senhas seguras é básico, mas fundamental. Exemplos dessas políticas 
incluem senhas fortes com combinação de letras minúsculas e maiúsculas e números, 
comprimento mínimo e máximo, uso de símbolos especiais, período de expiração de senha 
e impedimento de reutilização de senhas. 
Todos esses passos são importantes para o controle de acesso, mas dificultam a vida do usuário 
legítimo. Portanto, é importante que a implementação dessas técnicas e processos seja justificável e 
realizada com campanhas de conscientização. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 26 
 
Criptografia de dados 
Por mais cuidadosos que possamos ser, sempre existe a chance de um atacante encontrar formas 
de violar a segurança do sistema e ter acesso não autorizado aos dados. Isso pode ser desastroso, pois os 
dados podem ser modificados e, quando realizarmos o processamento deles, posteriormente, estaremos 
diante de resultados que não refletem a realidade e podem nos conduzir a tomadas de decisões erradas. 
Portanto, precisamos garantir que os dados só tenham valor para os usuários legítimos. Uma das 
técnicas mais eficientes para fazer isso é a criptografia. A criptografia é uma técnica fundamental para 
proteger a confidencialidade, integridade e autenticidade dos dados. 
Ela se baseia em algoritmos de transformação de dados com o uso de chaves. Então, apenas as 
pessoas com acesso a essas chaves conseguem acesso aos dados originais. No caso de um invasor 
acessar os dados criptografados ou tentar modificá-los, isso não trará nenhuma vantagem prática para ele. 
Saiba Mais 
A criptografia é um recurso que aumenta bastante a segurança dos dados de um sistema. Atualmente, é muito 
mais simples utilizá-la na prática, pois muitas ferramentas já a oferecem como recurso para garantir que nossos dados 
estejam protegidos e, assim, seja possível aumentar a resistência a ataques. 
Algoritmos de criptografia 
A seguir, apresentamos algumas questões importantes quando utilizar algoritmos de criptografia para 
aumentar a segurança de um software: 
1. Conhecimento sobre os principais algoritmos de criptografia 
✓ Devemos buscar o melhor algoritmo de criptografia para nossos dados, pois isso vai protegê-
los contra acessos não autorizados. Alguns dos algoritmos de criptografia mais usados 
atualmente são AES (criptografia simétrica), RSA (criptografia assimétrica) e SHA (função 
hash). 
2. Gerenciamento de chaves 
✓ Precisamos de uma política bem definida sobre gerenciamento adequado de chaves que 
envolve geração, armazenamento e proteção das chaves usadas para criptografar e 
decriptografar os dados. O algoritmo de criptografia só é seguro se a chave de criptografia for 
mantida em segurança. 
3. Implementação adequada 
✓ Precisamos garantir que as chaves sejam geradas de modo aleatório, o processo de 
criptografia seja executado corretamente e os dados criptografados sejam armazenados em 
um ambiente seguro, já que, quem vai aplicar a criptografia é um sistema. 
4. Integração com outros sistemas 
✓ Podemos aumentar a eficácia do processo ao utilizar protocolos de segurança como TLS/SSL 
(Transport Layer Security — Camada Segura de Transporte/Secure Sockets Layer - Camada 
de Soquete Seguro), além dos algoritmos de criptografia em si, pois eles garantem que os 
dados sejam criptografados tanto em trânsito como em repouso. 
5. Gerenciamento de certificados 
✓ Devemos criar uma política explícita de gerenciamento para os certificados digitais, pois, 
atualmente, é difícil falar em segurança sem mencioná-los, já que são um recurso lógico 
usado para autenticar a identidade de usuários, servidores e outros dispositivos em uma rede 
e, por este motivo, como outros recursos de segurança, eles também precisam de uma 
política de gerenciamento para garantir que a comunicação seja segura. 
6. Atualizações de segurança 
✓ Precisamos atualizar os algoritmos de criptografia, da mesma forma que precisamos atualizar 
outros recursos de segurança. Para isso, devemos visitar regularmente o fornecedor do 
Desenvolvimento de Software Seguro 
Marcio Quirino - 27 
 
algoritmo que estamos utilizando no sistema e realizar as atualizações sugeridas pela fonte 
oficial 
Protocolos de comunicação seguros 
Os protocolos de comunicação segura são especialmente fundamentais em ambientes cliente X 
servidor, tanto em intranets como na internet. Eles oferecem proteção contra as quebras de 
confidencialidade, integridade e autenticidade dos dados que transmitimos por uma rede. 
Existem algumas questões que precisamos considerar ao utilizar protocolos de comunicação seguros 
em um software: 
1. Escolha do protocolo 
✓ Devemos levar em consideração os requisitos de segurança para o contexto no qual a nossa 
aplicação vai trabalhar. Os protocolos de comunicação segura mais utilizados são o TLS e o 
SSL. 
2. Configuração de parâmetros 
✓ Temos que configurar diversos parâmetros, como o tamanho da chave de criptografia, 
considerando que esta é uma das etapas mais complexas no uso de protocolos seguros e 
uma das principais vulnerabilidades exploradas por invasores. 
3. Gerenciamento de chaves 
✓ Precisamos realizar a geração, armazenamento e proteção adequados das chaves usadas 
para criptografia e decriptografia. 
4. Gerenciamento de certificados digitais 
✓ Precisamos de um plano formal para fazer o gerenciamento, monitoramento, atualização e 
expiração dos certificados digitais para garantir uma comunicação segura, visto que eles são 
importantes para autenticar a identidade de usuários, servidores e outros dispositivos que 
estão na rede. 
5. Monitoramento 
✓ Precisamos monitorar o protocolo de comunicação seguro em qualquer etapa de um software 
seguro. Por exemplo, precisamos analisar possíveis violações ou vulnerabilidades de 
segurança. Fazemos isso por meio do monitoramento de tentativas de acesso não autorizado, 
padrões de tráfego incomuns ou quaisquer outras anomalias. 
6. Atualizações 
✓ Precisamos manter uma rotina de atualização por meio de consultas às fontes oficiais. 
Normalmente, os fornecedores disponibilizam patches de segurança - programas para corrigir 
vulnerabilidades. Desse modo, garantimos que estamos usando a versão mais segura do 
protocolo. 
Sem dúvidas, o uso de protocolos de comunicação segura é uma das questões que devemos levar 
em consideração para realizar o processamento de dados com segurança, pois é uma forma de proteger os 
dados e, assim, reduzir as chances de que nossa aplicação sofra ataques bem-sucedidos. 
Busca por vulnerabilidades e testes 
Para realizar um processamento de dados com segurança, sempre precisamos fazer uma busca por 
vulnerabilidades e realizar testes de segurança. Uma grande vantagem é que já existem passos bem 
conhecidos para tratar esse assunto. 
Listamos os principais: 
1. Varredura de vulnerabilidade 
✓ Precisamos usar ferramentas automatizadas para varrer o código do sistema e identificar 
possíveis vulnerabilidades. Como vimos, a OWASP apresenta diversas vulnerabilidades bem 
comuns, como injeção de SQL, script entre sites (XSS) e estouros de buffer. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 28 
 
2. Teste de penetração 
✓ Devemos realizar testes manuais para identificar pontos fracos de segurança. Esses testes 
conseguem detectar vulnerabilidades que dificilmente seriam pegas por ferramentas 
automatizadas. Fazemos a simulação de ataques para identificar vulnerabilidades e 
determinar qual o impacto delas para segurança do sistema. 
3. Bibliotecas e componentes de fornecedores confiáveis 
✓ Temos, atualmente, acesso a diversas bibliotecas e componentes. Ao utilizarmos esses 
recursos, porém, podemos introduzir vulnerabilidades no nossosistema, pois é inviável 
fazermos testes neles. A forma de reduzir as chances de criarmos um problema é usar fontes 
confiáveis. No entanto, isso não garante que não existam vulnerabilidades nesses recursos. 
4. Teste de conformidade 
✓ Contamos com alguns padrões de testes de conformidade regulatória, como o padrão de 
segurança de dados do setor de cartões de pagamento (PCI DSS) e a lei de portabilidade e 
responsabilidade de seguros de saúde (HIPAA). Ambos os padrões são dos Estados Unidos, 
mas servem como guia para desenvolvermos nossos testes de conformidade de modo 
semelhante. 
5. Teste contínuo 
✓ Devemos lembrar que é importante ter uma rotina de implementação de testes automatizados 
e testes manuais para identificar possíveis vulnerabilidades, pois, assim, teremos a chance 
de aplicar correções antes que possam ser exploradas por invasores. 
6. Avaliação de risco 
✓ Devemos mapear todas as etapas do processamento dos dados e realizar avaliações de 
risco. Desse modo, podemos identificar possíveis riscos de segurança e priorizar 
vulnerabilidades com base no impacto potencial delas. 
7. Documentação 
✓ Precisamos ter em mente que, apesar de não ser bem priorizada, essa etapa é fundamental. 
Sempre que desenvolvermos e realizarmos os testes, devemos documentá-los, assim como 
seus resultados. Além disso, é essencial mantermos o registro das ações que tomamos para 
eliminar as vulnerabilidades e corrigir os erros, pois podem ser úteis para outras pessoas 
envolvidas no projeto. 
Todo o processo relacionado ao processamento de dados com segurança exige muito esforço da 
nossa parte. No entanto, como vimos, existem etapas bem definidas que podemos aplicar para reduzir o 
potencial de danos e detectar e corrigir vulnerabilidades, antes que elas sejam exploradas por invasores. 
3. Chamadas em software seguro 
Fundamentos de Chamadas 
Nossa motivação para construir um software é que ele atenda a uma demanda, ou seja, realize ações 
úteis para seus usuários. Podemos ter softwares utilitários, como os aplicativos de banco, e softwares 
voltados para o entretenimento, como os jogos eletrônicos. Todos esses sistemas têm em comum uma 
arquitetura lógica que realiza comandos a partir da chamada de funções específicas. 
O uso de funções e medidas preventivas para chamadas seguras 
O uso de funções compõe as boas práticas de organizarmos um sistema, pois elas ficam 
responsáveis por partes específicas do processo lógico. No entanto, realizar essas chamadas de funções 
ou, ainda, chamar outros programas de dentro do nosso software, pode ser uma vulnerabilidade para a 
segurança do sistema. Por isso, apesar de essa prática ser muito útil, devemos tomar algumas medidas 
preventivas para evitar riscos de segurança. 
Uma forma bastante comum atualmente de trabalharmos com chamadas de funções é fazer via API 
(sigla para Interface de programação de aplicativos, do inglês Application Programming Interface). Ela 
Desenvolvimento de Software Seguro 
Marcio Quirino - 29 
 
permite que possamos fazer a comunicação entre diferentes componentes de software, de modo que 
possam interagir entre si e, dessa forma, possibilita integrar nossos sistemas e consumir serviços. 
A seguir, apresentamos algumas medidas preventivas que nos ajudam a fazer chamadas seguras: 
1. Validar as entradas do usuário 
✓ Devemos ter certeza de que qualquer entrada do usuário passe por um processo de validação 
antes de ser processada. Uma função deve receber parâmetros, processá-los e retornar um 
resultado, especialmente se queremos evitar ataques de injeção de código. 
2. Usar APIs do sistema 
✓ Podemos nos prevenir de inserir vulnerabilidades no nosso sistema ao utilizarmos APIs e 
bibliotecas do sistema, pois, teoricamente, elas já foram testadas para evitar problemas de 
segurança. 
3. Definir permissões 
✓ Devemos definir as permissões necessárias que um programa deve ter para chamar uma 
determinada função e, assim, acessar os recursos do sistema. Isso é essencial. Para isso, é 
necessário garantir que a função faça uma leitura das credenciais de quem está fazendo a 
chamada, aumentando a complexidade de uma simples chamada. 
4. Limitar privilégios 
✓ Precisamos também limitar os privilégios da função que está sendo chamada, de modo que 
ela tenha acesso apenas aos recursos necessários para executar a tarefa. 
5. Usar funções com as devidas autorizações 
✓ Devemos cadastrar as funções em uma lista, logo após definirmos as permissões e limitar os 
privilégios de acesso aos recursos do sistema, para controlarmos quem pode realizar 
chamadas e executar comandos. 
6. Monitorar as chamadas do sistema 
✓ Precisamos sempre ter um recurso no sistema que gere arquivos de logs, para podermos 
monitorar as chamadas. Esse é o procedimento mais clássico. Por mais eficiente que seja 
nosso processo de segurança preventiva, às vezes, os invasores encontram alguma 
vulnerabilidade e passam a explorá-la. 
7. Usar canais de comunicação seguros 
✓ Precisamos garantir que a comunicação entre as duas máquinas seja criptografada e 
autenticada. Isso é especialmente importante quando o programa que está sendo chamado 
estiver sendo executado em uma máquina diferente. 
Chamadas de APIs do sistema 
Usamos as APIs para definir um conjunto de regras que servem para realizar a solicitação de dados, 
fazer o recebimento de dados, executar operações específicas e acessar determinados recursos de um 
sistema ou serviço de software. 
As APIs podem ser usadas para acessar dados de diversas fontes, como bancos de dados, serviços 
da web e outros aplicativos de software. Portanto, ao utilizá-las, devemos seguir algumas práticas 
recomendadas para garantir que nosso software seja o mais seguro possível. 
Listamos algumas sugestões de como proceder: 
1. Usar chamadas de API bem documentadas e testadas 
✓ Sempre devemos ter uma boa documentação da API e alguma garantia de que ela foi 
submetida a diversos testes, pois vai nos ajudar a garantir que nosso código permaneça 
estável, quando a utilizarmos. 
 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 30 
 
2. Validar a entrada e a saída 
✓ Precisamos validar tanto a entrada como a saída das chamadas da API, com os objetivos de 
evitar receber dados com códigos maliciosos e produzir uma saída maliciosa que comprometa 
a segurança do sistema. 
3. Usar práticas de codificação seguras 
✓ Precisamos considerar que são as mesmas práticas que vimos em outras situações, mas, 
agora, voltadas para o uso de APIs, como validação de entrada, codificação de saída e 
tratamento de erros para evitar vulnerabilidades como estouros de buffer e ataques de 
injeção. 
4. Usar o princípio do privilégio mínimo 
✓ Reduzimos as chances de os invasores obterem acesso a recursos confidenciais quando 
permitirmos que a API tenha acesso apenas aos recursos de que precisa para executar a 
tarefa específica. 
5. Manter o software atualizado 
✓ Devemos sempre utilizar as fontes oficiais para manter as APIs atualizadas, por exemplo, por 
meio de programas, como patches. 
6. Usar ferramentas de segurança 
✓ Devemos nos proteger utilizando ferramentas de segurança como softwares antivírus, 
firewalls e sistemas de detecção de intrusão, o que vai implicar, na prática, a adição de uma 
camada de segurança. 
7. Realizar testes de estresse 
✓ Precisamos compreender que este importante procedimento gera diversos cenários de 
situações que forçam a identificação das possíveis vulnerabilidades de segurança. 
Definição de permissões 
Quanto mais módulos um sistema tiver, maior será a complexidade para estabelecer quais 
permissões devemos conceder aos perfis de usuários. Esse processo, realmente, pode dar muito trabalho. 
Vamos considerar um módulo CRUD (inserir, visualizar, modificar e excluir dados), conforme vemos na 
imagem: 
 
Exemplo de um módulo de CRUD. 
De imediato, precisamos decidir se todos os perfis terão os mesmosacessos e permissões para 
realizar visualizações, cadastros, modificações e exclusões dos dados. Obviamente, essa tarefa vai exigir 
muito da nossa atenção e tem grandes chances de apresentar vulnerabilidades. 
Atenção 
O processo de definir permissões precisa ser realizado antes que o software seja entregue ao cliente, pois o 
papel do desenvolvedor é apenas de criar um ambiente no qual um responsável vai associar as permissões aos perfis 
dos usuários. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 31 
 
Diretrizes para a definição de permissões 
Existem algumas diretrizes que devemos seguir para definir permissões. Vamos conhecê-las! 
1. Usar o princípio do privilégio mínimo 
✓ Cada permissão deve dar acesso a uma ação específica necessária, exclusivamente, para 
realizar uma tarefa. 
2. Restringir as permissões de arquivos e pastas 
✓ Apenas perfis de usuários autorizados podem ter acesso aos arquivos e pastas. No caso de 
sistemas operacionais baseados em Unix, podemos usar o comando chmod para definir 
permissões em arquivos e diretórios. 
3. Usar contas de usuário separadas 
✓ Essa parte pode ser incômoda para o usuário, pois a ideia é que ele utilize uma conta 
separada para usar do servidor da Web e outra conta para acessar o banco de dados. Uma 
alternativa é usar um processo de autenticação baseado em certificado digital que garanta a 
autenticidade do usuário. 
4. Usar senhas fortes 
✓ Essa recomendação é clássica. Por outro lado, precisamos ter cuidado para não dificultar 
excessivamente a vida do usuário, pois, caso contrário, ele pode criar situações que gerem 
vulnerabilidades, por exemplo, anotar a senha e colocar sob o teclado. 
5. Aplicar criptografia 
✓ Para garantir a confidencialidade dos dados, precisamos usar criptografia. Isso vale tanto 
para os dados armazenados, quanto para os que estão em trânsito pela rede. 
6. Verificar as permissões de forma regular 
✓ É natural que haja rotatividade dentro de uma empresa. Às vezes, há mudanças de cargos 
ou profissionais dispensados. Portanto, sempre precisamos manter uma rotina de verificação 
capaz de nos ajudar a identificar possíveis problemas de segurança. 
7. Realizar testes de estresse 
✓ Devemos implementar testes automatizados que verifiquem se as definições de permissões 
estão, realmente, funcionando. O objetivo é criar situações estressantes para o sistema e 
estudar como ele se comporta, antes de enviá-lo para produção. 
Tipos de processamento e vulnerabilidades 
Vimos diversos controles para restringir os privilégios dos perfis dos usuários e de outros aplicativos, 
visando reduzir a possibilidade de um invasor assumir a identidade de um usuário ou aplicativo legítimo e 
causar danos durante o processamento de dados. 
Contudo, há mais algumas questões interessantes e pouco triviais para as quais precisamos ficar 
atentos e que são um diferencial em termos de conhecimento: os tipos de processamento e suas respectivas 
vulnerabilidades. 
A seguir, apresentamos os principais tipos de processamento de dados e analisamos as respectivas 
vulnerabilidades de cada um deles: 
1. Processamento em lote 
✓ Envolve o processamento de uma grande quantidade de dados de uma só vez. As 
vulnerabilidades do processamento em lote incluem a possibilidade de perda ou corrupção 
de dados durante a transferência, armazenamento ou processamento. Além disso, o 
processamento em lote pode ser vulnerável a violações de segurança se os dados não forem 
devidamente criptografados ou protegidos durante o armazenamento ou transmissão. 
2. Processamento em tempo real 
✓ O processamento de dados é realizado à medida que são gerados. Há diversas situações em 
que é muito útil, como controle de condições ambientais e monitoramento de segurança, por 
exemplo. Uma das vulnerabilidades desse tipo de processamento é em relação a problemas 
Desenvolvimento de Software Seguro 
Marcio Quirino - 32 
 
de desempenho e perda de dados. Isso é especialmente crítico quando lidamos com 
aplicações de Big Data. 
3. Processamento de fluxo 
✓ É semelhante ao processamento em tempo real. A principal diferença é ele ser projetado para 
trabalhar com fluxos de dados contínuos, como transmissões de imagens e áudio ao vivo e 
dados de sensores. Assim como ocorre no processamento em tempo real, também é 
vulnerável a problemas de desempenho e isso, certamente, tem impacto na qualidade do 
dado processado. 
4. Processamento em nuvem 
✓ Tecnologia muito utilizada atualmente por diversos motivos, como custos racionais, 
flexibilidade e segurança. Basicamente, o processamento de dados ocorre na nuvem, 
utilizando a arquitetura da internet para realizar processamento em equipamentos de 
empresas especializadas nesse tipo de serviço. Uma das maiores vulnerabilidades ocorre em 
relação à dificuldade de configuração, pois, se não for feita cuidadosamente, pode ter diversos 
tipos de vulnerabilidade, como: violações de segurança, caso os dados não sejam 
criptografados durante o armazenamento ou transmissão; problemas de desempenho, se a 
infraestrutura de nuvem não for projetada adequadamente; e questões relacionadas à própria 
confiança no fornecedor do serviço. Mas, na prática, existem fornecedores muito confiáveis e 
maduros sobre essa tecnologia, como a Amazon, International Business Machines 
Corporation (IBM) e Microsoft. 
Mitigação das vulnerabilidades do processamento de dados 
Existem várias ações que podemos tomar para reduzir as vulnerabilidades associadas aos diferentes 
tipos de processamento de dados, tais como: 
• Usar criptografia; 
• Aplicar protocolos de segurança; 
• Implementar rotinas de backup de dados; 
• Desenvolver e implementar uma política de recuperação de desastres. 
Além disso, no caso de aplicações de Big Data, precisamos usar tecnologias e técnicas que nos 
permitam lidar com grandes volumes de dados e sejam escaláveis para atender às demandas futuras. 
Porém, a ação mais importante de todas é investir na capacitação dos colaboradores e conscientização dos 
usuários. 
Monitoramento das chamadas 
Depois de estudarmos os diversos tipos de controles necessários para ter um processamento seguro 
e como esses processamentos podem ocorrer, precisamos monitorar como as chamadas são feitas. 
A seguir, apresentamos algumas ações que podem auxiliar na viabilização desse processo: 
1. Identificar chamadas de API críticas 
✓ Esse papel está mais associado ao responsável pela arquitetura do software, pois ele pode 
fazer o mapeamento das chamadas de API e estabelecer níveis de criticidade relacionados à 
segurança. Alguns exemplos de critérios que podemos usar para estabelecer o nível de 
criticidade da chamada de uma API é se ela trabalha com dados ou recursos confidenciais. 
2. Implementar registro de chamadas 
✓ Precisamos desenvolver uma forma para registrar informações sobre a chamada que traga 
informações como a hora da chamada, qual usuário fez a chamada e quais os parâmetros 
passados para a chamada. 
3. Monitorar logs 
✓ Sempre devemos ter uma ferramenta que registre as chamadas em arquivos de logs e um 
processo que nos ajude a procurar por padrões que indiquem atividades maliciosas. São 
Desenvolvimento de Software Seguro 
Marcio Quirino - 33 
 
exemplos desse tipo de chamada chamadas repetidas diversas vezes com os mesmos 
parâmetros em intervalos muito curtos e chamadas fora dos padrões de uso normais. 
4. Definir alertas 
✓ Precisamos estabelecer alertas que nos notifiquem sempre que houver uma atividade 
suspeita. Esse é um dos motivos para mantermos arquivos de logs. 
5. Revisar os logs regularmente 
✓ O ideal seria detectarmos uma situação de tentativa de ataque e, rapidamente, atuar para 
evitar que ela fosse bem-sucedida. No entanto, há situações mais complexas que só podem 
ser detectadas depois de muita análise. Por isso, precisamos ter uma política bem definida 
de revisão dos arquivos de logs na qual existamprocedimentos e responsáveis para realizar 
esse tipo de tarefa. 
6. Usar ferramentas automatizadas 
✓ A ideia é acelerar o processo de análise para tentar identificar padrões e detectar atividades 
suspeitas com mais eficiência do que a análise manual. 
7. Realizar testes 
✓ Regularmente, precisamos estressar o sistema por meio da simulação de chamadas 
maliciosas e verificar como ele se comporta. Esse tipo de teste pode nos dar informações 
úteis para que possamos atuar de forma preventiva. 
4. Envio da saída 
Fundamentos da saída 
Todas as etapas são importantes para garantir a segurança. Contudo, a saída merece uma atenção 
especial, pois pode expor dados confidenciais, favorecer potenciais invasores com informações que eles 
podem usar para explorar vulnerabilidades em seu software e, ainda, é possível gerar uma saída que seja 
um problema para outros sistemas, ou prejudicar o suporte à tomada de decisão em vez de ajudar. 
Devemos estar atentos a alguns procedimentos sobre o envio da saída para aumentar as chances 
de que o software seja seguro, tais como: 
1. Usar criptografia 
✓ A saída deve ser criptografada. Dessa forma, se um invasor conseguir interceptá-la, não vai 
conseguir compreendê-la. 
2. Validar a entrada 
✓ Como um invasor pode tentar injetar um código para ser executado por nosso programa, 
precisamos fazer a validação de todas as entradas usadas para gerar a saída. 
3. Limpar a saída 
✓ Precisamos garantir que a saída contenha apenas as informações estritamente essenciais 
para quem vai consumi-la. Portanto, devemos remover qualquer informação confidencial que 
não seja, de fato, essencial. 
4. Usar protocolos de comunicação seguros 
✓ Precisamos trabalhar com protocolos de comunicação seguros, como o HTTPS, para fazer a 
comunicação dos dados. Nesse caso, o envio à saída do nosso sistema, com o objetivo de 
evitar que invasores em potencial interceptem os dados em trânsito. 
5. Limitar a saída para usuários autorizados 
✓ Precisamos usar ferramentas e outros recursos que permitam que apenas usuários com a 
devida autorização consigam ler os dados. Por exemplo, podemos usar uma ferramenta que 
exija a autenticidade do usuário para exibir os dados da saída com o processo inverso da 
criptografia. 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 34 
 
6. Usar registros 
✓ Devemos registrar todas as saídas do sistema e também informações sobre quem as 
acessou. Obviamente, o interesse é identificar qualquer atividade suspeita. 
7. Realizar testes 
✓ Devemos sempre realizar testes para qualquer tratamento de dados, inclusive com a saída. 
Ao simular situações de ataque com ferramentas de teste automatizadas, temos a 
possibilidade de identificar quaisquer problemas antes que eles entrem em produção. 
Uso da criptografia 
O uso de algoritmos de criptografia é essencial para garantimos que os resultados façam sentido 
apenas para os usuários autorizados. Algumas das ações para enviar dados seguros são: 
1. Usar algoritmos de criptografia fortes 
✓ Existem vários algoritmos de criptografia bons, como Advanced Encryption Standard (AES) e 
Triple Data Encryption Standard (Triple DES). 
2. Usar o gerenciamento seguro de chaves 
✓ A criptografia só tem utilidade prática se conseguirmos fazer um gerenciamento eficiente das 
chaves usadas para criptografar e decriptografar os dados. Essas chaves só podem ser 
acessíveis por usuários autorizados e que possam ter suas ações no sistema rastreáveis. 
3. Aplicar protocolos de comunicação seguros 
✓ Especialmente, no caso em que os dados da saída serão transmitidos via rede, é fundamental 
usarmos protocolos de comunicação seguros, como SSL/TLS. 
4. Autenticar o remetente e o destinatário 
✓ Esse mecanismo de autenticação garante que tanto o remetente quanto o destinatário dos 
dados estejam autorizados a acessar os dados. 
5. Verificar os dados de saída 
✓ Antes de criptografar os dados, precisamos garantir que os resultados só contenham 
informações essenciais para quem vai utilizá-las. 
6. Testar a criptografia 
✓ Nesse caso, precisamos de ferramentas específicas para automatizar esse processo. O 
objetivo do teste é garantir que o sistema de criptografia da saída esteja funcionando 
conforme o esperado. 
Protocolos de comunicação seguros 
Protocolos de comunicação segura são especialmente essenciais quando fazemos transmissão de 
dados confidenciais pela internet ou mesmo pela rede interna – raramente sabemos onde está o invasor. 
A seguir, listamos alguns dos principais protocolos de comunicação segura: 
1. Transport Layer Security (TLS)/Secure Sockets Layer (SSL) 
✓ São usados com frequência para proteger o tráfego de dados da web junto com o protocolo 
HTTPS. O objetivo básico é proteger os dados transmitidos pela internet por meio do uso de 
algoritmos de criptografia para garantir que não sejam interceptados ou sofram algum tipo de 
adulteração. 
2. Secure File Transfer Protocol (SFTP) 
✓ É outro protocolo seguro que tem como objetivo proteger dados de arquivos transferidos pela 
internet. Semelhante aos demais protocolos, ele usa criptografia para proteger os dados em 
trânsito. Além disso, utiliza recursos como autenticação de chave pública para garantir acesso 
seguro aos dados. 
3. Internet Protocol Security (IPSec) 
✓ É um conjunto de protocolos que serve para proteger comunicações de protocolo de internet 
(IP) por meio da autenticação e criptografia de cada pacote IP. Especialmente depois da 
Desenvolvimento de Software Seguro 
Marcio Quirino - 35 
 
pandemia de covid-19, em que o trabalho virtual se tornou mais comum, esse protocolo 
ganhou grande popularidade por proteger redes privadas virtuais (VPNs). 
4. Simple Mail Transfer Protocol Secure (SMTPS) 
✓ É uma extensão segura do protocolo Simple Mail Transfer Protocol (SMTP) que é usado para 
enviar e-mail. Ou seja, usa técnicas de criptografia para proteger o e-mail em trânsito e, claro, 
proteger os dados contra a interceptação e adulteração. 
5. Secure Shell (SSH) 
✓ É um protocolo usado para acesso remoto seguro a servidores e outros dispositivos. O SSH 
faz a autenticação e criptografia seguras para acesso remoto. Portanto, o utilizamos para 
impedir o acesso não autorizado a dados confidenciais. 
6. Virtual Private Network (VPN) 
✓ É uma tecnologia usada para criar uma conexão segura e criptografada entre dois dispositivos 
– computadores ou servidores – pela internet. Junto com IPSec, o utilizamos para proteger 
os dados transmitidos entre locais remotos e impedir o acesso não autorizado a dados 
confidenciais. 
Restrição da saída para usuários autorizados 
Há muitos dados circulando pela rede que, se caírem nas mãos erradas, podem gerar enormes 
prejuízos financeiros e de imagem. Portanto, é fundamental utilizarmos mecanismos que restrinjam a saída 
apenas a usuários autorizados, para proteger dados confidenciais da saída do nosso sistema seguro. 
Apresentamos, a seguir, algumas sugestões que auxiliam no processo de restringir a saída apenas 
a usuários autorizados: 
1. Implementar controles de acesso 
✓ Sempre devemos usar mecanismos de controles de acesso para restringir o acesso a dados 
confidenciais apenas a usuários autorizados, como o uso de ferramentas que exijam 
autenticação de usuário e façam o controle de autorização com base no perfil de quem está 
acessando a saída. 
2. Criptografar dados confidenciais 
✓ A criptografia garante que os dados só façam sentido para quem tem acesso à chave de 
criptografia. Isso, obviamente, é feito por meio de ferramentas que precisam de um 
gerenciamento explícito. Utilizar criptografia é muito seguro. Mesmo que um invasor tenha 
acesso aos dados e os modifique, o receptor vai saber que os dados estão corrompidos. Além 
disso, os dados roubados não farão nenhum sentido para o invasor. 
3. Use protocolos de comunicação seguros 
✓ Existem diversos protocolos de comunicação seguros para transmitirdados pela rede - seja 
internet ou intranet - e garantir a sua integridade. 
4. Limpar saída 
✓ As informações geradas por um sistema só devem fazer sentido para usuários com perfis 
autorizados. Portanto, é nossa obrigação ficar atento ao que pode ser exposto para cada perfil 
de usuário. Precisamos fazer isso antes de criptografar os dados, pois a construção lógica do 
que será enviado para saída é de responsabilidade do nosso sistema. 
5. Monitorar a saída 
✓ Semelhante ao que fizemos nas demais etapas do ciclo de vida dos dados de um software 
seguro, também precisamos ter uma rotina de monitoramento bem estabelecida que permita 
analisarmos o uso da saída do sistema e, se for o caso, detectar qualquer atividade suspeita. 
Esse processo precisa do apoio de ferramentas específicas e de responsáveis para fazer o 
acompanhamento de quem está acessando os dados de saída. 
6. Realizar testes de estresse 
✓ O objetivo é encontrar vulnerabilidade nos nossos controles de acesso, além de garantir que 
todo o controle de segurança esteja funcionando conforme o esperado. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 36 
 
Esses controles não têm implementação trivial, mas aumentam nossas chances de construir 
softwares seguros. É muito mais racional investir em ações preventivas do que atuar em medidas corretivas 
para tentar reduzir danos causados por um ataque bem-sucedido. 
Monitoramento da saída e realização de testes 
Estamos, finalmente, na última etapa para a construção de um software seguro! Nosso foco está no 
envio seguro da saída. Assim como temos preocupações em receber dados com códigos maliciosos de 
outros sistemas, também precisamos ter muita atenção para não gerarmos dados que causem danos à 
segurança. Por isso, a segurança de software deve ser vista como um conjunto de partes que se combinam 
para reduzir as chances de ataques bem-sucedidos. 
Uma forma eficiente de complementar as ações para fazer o envio de uma saída segura é por meio 
do monitoramento dos usuários que estão usando o sistema. Obviamente, esse tipo de ação, junto com 
outras que já analisamos, precisa ser justificável. Por exemplo, grandes corporações privadas não têm 
interesse de que outras empresas conheçam suas estratégias de investimento. Da mesma forma, os setores 
de inteligência dos governos também não querem que seus adversários – e, às vezes, até aliados – 
conheçam seus planos militares. 
Portanto, a definição de processos de monitoramento da saída e ações para identificar problemas 
são etapas críticas para garantir a segurança de sistemas. Essa é uma área muito dinâmica, exigindo que 
nos atualizemos constantemente, principalmente, por causa do avanço das técnicas de inteligência artificial, 
que podem ser utilizadas tanto para combater invasões, como para tentar realizá-las. 
Etapas da monitoração da saída 
A seguir, listamos algumas etapas que podemos seguir para monitorar a saída e testar problemas 
de software seguro: 
1. Estabelecer planos de testes de segurança 
✓ Estabelecer um plano de teste de segurança, descrevendo metas, metodologias, 
ferramentas, frequência de teste e responsáveis. 
2. Identificar possíveis ameaças à segurança 
✓ Desenvolver o pensamento de um invasor para podermos criar possíveis cenários de 
ameaças e identificar vulnerabilidades que nosso sistema pode enfrentar. 
3. Desenvolver e executar testes de segurança 
✓ Existem muitos testes que podemos aplicar para verificar, se, de fato, o envio da saída é 
seguro. Por exemplo, podemos usar ferramentas automatizadas para realizar: 
✓ Análise estática: faz a análise do código do sistema. 
✓ Análise dinâmica: realiza testes com o sistema em funcionamento. 
✓ Teste de penetração: estressa o sistema por meio de busca de vulnerabilidades de segurança 
bem conhecidas. 
4. Gerar e monitorar os logs do sistema 
✓ Só podemos analisar dados se eles existirem. Portanto, é essencial utilizarmos recursos que 
permitam gerar arquivos de logs do sistema, ao mesmo tempo que precisamos implementar 
rotinas para detectar atividades suspeitas, como muitas tentativas de login com falha. 
5. Usar técnicas de detecção de anomalias 
✓ Atualmente, temos ferramentas que utilizam algoritmos de aprendizado de máquina para 
detectar padrões incomuns tanto no comportamento do usuário, como nas atividades do 
sistema. 
6. Realizar revisões de código 
✓ Sempre é importante fazer revisões do código para tentar identificar e corrigir vulnerabilidades 
de segurança. 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 37 
 
7. Manter o software atualizado 
✓ Em sistemas complexos, é normal utilizarmos muitos componentes, bibliotecas e outras 
tecnologias fornecidas por terceiros. Por isso, precisamos mapeá-las e, com regularidade, 
visitar os sites dos fornecedores oficiais e realizar as atualizações recomendadas. 
5. Conclusão 
Considerações finais 
Estudamos diversas questões relacionadas à construção de um software seguro. Tratamos sobre 
itens importantes, que vão desde a validação da entrada de dados, como o processamento, chamada de 
outros programas, até o envio da saída de forma segura. Apesar de serem etapas diferentes, o tratamento 
geral que precisamos dar a cada uma delas em muitos momentos se assemelham: controle de acesso, 
monitoramento e aplicação de algoritmos de criptografia. 
Na prática, no entanto, cada uma dessas etapas demanda um tratamento especial. Por exemplo, 
certamente, nossa preocupação da validação de uma entrada é diferente da validação de uma saída, pois, 
nesse último caso, os dados já passaram por todas as fases anteriores de controle. Portanto, é muito mais 
difícil detectarmos uma vulnerabilidade na saída do que na entrada de dados. Isso torna o trabalho ainda 
mais desafiador. Por isso, precisamos estar constantemente nos atualizando e estudando as formas de 
agregar mais segurança aos nossos softwares! 
Explore + 
Para complementar as discussões trazidas neste conteúdo, acesse o site oficial da Microsoft e 
procure por: 
Lei de Portabilidade e Responsabilidade do Seguro de Saúde (HIPAA) & Tecnologia de Informações 
de Saúde para a HiTECH (Economic and Clinical Health Health) Act. Nessa página, você conhecerá melhor 
esses padrões de segurança e, certamente, vai ampliar a sua visão sobre software seguro. 
Usar o PyLint para verificar o código do Python. Lá, você aprende sobre a ferramenta PyLint, que é 
utilizada na prática para fazer análises estáticas de código no Python que, atualmente, é uma das principais 
linguagens de programação. 
Referências 
CHESS, B.; WEST, J. Secure Programming with Static Analysis. Boston: Addison-Wesley, 2007. 
HOWARD, M.; LEBLANC, D. Writing Secure Code. 2. ed. Microsoft Press, 2002. 
MCGRAW, G. Software Security: Building Security In. Nova York: Pearson Education Inc., 2006. 
PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: MacGraw-Hill, 2006. 
SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo: Pearson Addison Wesley, 2005. 
VIEGA, J.; MCGRAW, G. Building Secure Software: How to Avoid Security Problems the Right Way. 
Boston: Addison-Wesley, 2002. 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 38 
 
Modelagem, Implantação e Verificação de Software 
seguro 
Introdução 
A segurança de software é uma área relevante na tecnologia da informação, pois é responsável por 
dar garantias mínimas de proteção de dados e disponibilidade de sistemas contra ameaças de ataques 
cibernéticos. A mentalidade de segurança deve permear o ciclo de vida completo de desenvolvimento de 
software seguro, introduzindo medidas protetivas específicas para cada fase. 
Boas práticas, padronizadas por processos estruturados, devem ser empregadas para gestão de 
risco e modelagem de ameaças. Diversas organizações propõem arcabouços estruturados para cobrir essas 
questões práticas de desenvolvimento de software seguro, sendo excelentes fontes de consulta para todoprofissional envolvido com a área. 
1. Verificação de segurança 
A importância do software seguro 
Você já viu um exploit em ação? Parece mágica a forma como um pedaço de código é executado 
rapidamente e toma o acesso de uma máquina que roda um programa complexo, escrito por uma equipe de 
especialistas e vendido e usado no mundo todo já por alguns anos. 
O processo pode parecer algum tipo de magia computacional, tendo como ingredientes uma grande 
confusão de bits e bytes. Mas quando você der uma olhada no que acontece por debaixo dos panos e 
perceber como, de fato, funciona, certamente, simpatizará com o criador do código, que teve muita 
persistência para testar ações (algumas delas bem inusitadas) até encontrar um caminho capaz de furar o 
uso normal do sistema, ultrapassar os mecanismos de controle e tomar conta da máquina. 
O cenário apresentado aqui é muito factível, por exemplo, em um caso de ataque do tipo buffer 
overflow, que ocorre quando um programa tenta armazenar mais dados em uma área de armazenamento 
temporário na memória (buffer) do que ele pode suportar, o que faz com que o excesso de dados 
“transborde” e seja armazenado em outras áreas da memória. Isso pode permitir que um invasor execute 
um código malicioso ou manipule o programa de maneiras favoráveis a, potencialmente, tomar o controle 
total do sistema. 
Se você conhece um pouco de software, sabe que todos eles possuem bugs. Todo software, em 
algum momento após seu lançamento, vai apresentar uma falha, mau funcionamento diante do inesperado 
(uma ação executada pelo usuário nunca imaginada pelos programadores do sistema) ou até mesmo frente 
ao esperado. As possibilidades de buracos existentes em um sistema complexo são inúmeras! Seja por 
descuido ou desconhecimento, os programadores constroem sistemas com falhas, isso é um fato. Quanto 
maior e mais complexo o software, mais provável a existência de falhas que abram brechas a serem 
exploradas. 
No contexto da segurança de software, alguns conceitos são de extrema importância, como a 
terminologia de base para compreensão de aspectos práticos. Vamos a alguns desses conceitos! 
Vulnerabilidades 
Em termos simples, são os pontos fracos de um sistema, os quais os invasores podem aproveitar a 
seu favor. 
Uma vulnerabilidade é uma falha específica gerada por desconhecimento ou descuido em um 
software, que possibilita que um invasor faça algo mal-intencionado; exponha ou altere informações 
Desenvolvimento de Software Seguro 
Marcio Quirino - 39 
 
confidenciais; interrompa ou destrua o funcionamento do sistema; ou assuma o controle de um sistema ou 
programa de computador. 
Sem dúvida, você deve estar familiarizado com bugs de software. São erros, enganos ou descuidos 
em programas que resultam em comportamento inesperado e tipicamente indesejável. Quase todo usuário 
de computador, em algum momento, já perdeu um trabalho importante por causa de um bug de software. 
Nem todo bug cria vulnerabilidades, ou seja, em geral, as vulnerabilidades de software podem ser 
consideradas um subconjunto do fenômeno maior de bugs de software. Entenda melhor: 
 
Relação entre bugs e vulnerabilidades. 
Vulnerabilidades de segurança são aqueles bugs ou, genericamente, falhas que trazem uma brecha 
para que um usuário mal-intencionado possa se aproveitar para lançar ataques contra o software e os 
sistemas de suporte. 
Todas as vulnerabilidades de segurança advêm de bugs de software, mas apenas alguns bugs de 
software acabam se configurando em vulnerabilidades de segurança. Uma falha deve proporcionar algum 
impacto ou liberar propriedades relevantes à segurança para ser realmente considerada um problema. Em 
outras palavras, a falha deve permitir que os invasores façam algo que, por meio de comportamento 
comumente esperado no uso do sistema, não seriam capazes de fazer. 
Façamos um paralelo com dois termos de mais fácil compreensão: 
• Segurança 
• Confiabilidade 
Tudo aquilo que é sabidamente seguro é automaticamente confiável, mas nem tudo que é confiável 
é necessariamente seguro. Usando isso como uma comparação útil, digamos que um programa confiável é 
aquele que está relativamente livre de bugs. Isso significa que o software raramente falha nas mãos do 
usuário, lidando inclusive com as condições excepcionais normalmente. 
Se o programa foi escrito de forma a ser capaz de lidar com ambientes de execução incertos e 
entradas malformadas, podemos dizer que ele foi construído de maneira “defensiva”, e este deve ser um 
objetivo de todo programador. O programa deve ser capaz de se antecipar a algumas das falhas conhecidas 
e poder repelir um ataque direcionado por intrusos que estejam tentando manipular seu ambiente, 
introduzindo entradas para aproveitar alguma falhar e alcançar algum fim nefasto. 
Confiabilidade e segurança de software não são a mesma coisa, mas compartilham objetivos 
semelhantes, pois ambos exigem estratégias de desenvolvimento que se concentram no extermínio de bugs 
de software. Veja o que diferencia esses dois tipos de software! 
Desenvolvimento de Software Seguro 
Marcio Quirino - 40 
 
A. Software confiável 
✓ É aquele com baixa probabilidade de apresentar mau funcionamento ou falhas inesperadas. 
Isso inclui a garantia de que o software foi desenvolvido de acordo com padrões de qualidade, 
foi testado e validado de forma adequada, e pode ser confiável em termos de desempenho, 
disponibilidade e eficácia acerca dos objetivos para os quais foi projetado e construído. 
B. Software seguro 
✓ É aquele que foi projetado e implementado com o objetivo de proteger o sistema de ataques 
e vulnerabilidades. Isso inclui a aplicação de técnicas de programação seguras, o uso de 
criptografia para proteger dados sensíveis, a implementação de controles de acesso para 
limitar o acesso a informações confidenciais, e outras medidas para reduzir os riscos de 
ataques e comprometimento do sistema. 
Lembrando do caso do ataque de buffer overflow, o programador com mentalidade defensiva, para 
evitar esse tipo de ataque, deve usar técnicas de programação seguras, como verificar o tamanho dos dados 
armazenados em um buffer e garantir que ele esteja adequadamente dimensionado. 
Explorando vulnerabilidades nos softwares 
A exploração de uma vulnerabilidade é realizada na prática por meio de um exploit, que é um software 
no qual o código tem a função de se aproveitar de uma falha existente dentro de um sistema, uma aplicação 
ou um serviço. Esse software, normalmente caracterizado por um pedaço de código, pode ser escrito em 
várias linguagens. Vejamos os tipos de linguagens utilizadas: 
• Python 
• C 
• C++ 
• Assembly 
O exploit carrega uma parte do código conhecida como payload. Em segurança de software, um 
payload (carga útil) refere-se a um código malicioso que é inserido em um sistema vulnerável para executar 
determinada ação. Essa ação pode ser de diversos tipos e depende do objetivo do invasor. Vamos conferir 
os tipos de ações que podem ser executadas! 
1. O roubo de informações. 
2. Os danos ao sistema. 
3. A instalação de outros softwares maliciosos. 
4. O controle remoto do sistema. 
No contexto do uso de exploits, um payload geralmente é usado em conjunto com uma técnica de 
injeção de código para permitir que o atacante execute comandos no sistema comprometido. Isso pode ser 
feito, por exemplo, enviando um arquivo de exploit especialmente criado para o sistema alvo. Quando o 
exploit é executado com sucesso, o payload é então inserido no sistema e executado para realizar a ação 
maliciosa desejada. 
Outro conceito relacionado com a prática da exploração de vulnerabilidades é o Shellcode, um 
conjunto de instruções e comandos criados para serem executados assim que o código é injetado. Deve ser 
encarado como um tipo específico de payload que é projetado para executar um shell (interface de linha de 
comando) no sistema comprometido. É geralmente escritoem linguagem Assembly e executado diretamente 
na memória do sistema comprometido. 
Resumindo 
O objetivo principal do shellcode é permitir que o invasor execute comandos no sistema comprometido, obtendo 
controle total sobre ele. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 41 
 
Relação entre vulnerabilidade, ameaça e risco 
Em termos teóricos, a avaliação de segurança de software é feita tomando por base uma análise de 
risco e o custo e retorno de cada uma das estratégias voltadas para lidar com cada risco. Então, precisamos 
apresentar os conceitos de ameaça e risco, que irão compor a avaliação de segurança. 
Começando pela ameaça, é a situação que expõe o sistema a um evento ou a uma ação que pode 
explorar uma vulnerabilidade existente no software. As ameaças podem ser realizadas por pessoas mal-
intencionadas, como hackers, ou por eventos não intencionais do próprio usuário comum. As ameaças 
podem explorar as vulnerabilidades para causar danos ao sistema, roubar dados ou informações, ou realizar 
outros tipos de ataques advindos de atividades maliciosas, bem como simplesmente expor dados ou travar 
um sistema, no caso de um evento não associado a más intenções. É importante reconhecer que a ameaça 
existe no encontro da vulnerabilidade com a exploração, ou seja, só existe realmente a ameaça quando 
existe uma vulnerabilidade que pode ser explorada. Observe o esquema: 
 
Vulnerabilidade x Ameaça. 
É possível que exista uma vulnerabilidade em um software e que ela não represente uma ameaça 
real. Isso pode ocorrer por vários motivos, como: 
✓ A vulnerabilidade requer acesso a recursos ou privilégios que não estão disponíveis para um 
invasor em potencial, ao menos pelos métodos mapeados na avaliação de segurança. 
✓ A vulnerabilidade é difícil ou impossível de explorar na prática, também na visão dos métodos 
mapeados, que deve considerar o estado da arte das técnicas de exploração. 
Um exemplo prático seria uma vulnerabilidade em um software que requer acesso administrativo ao 
sistema para ser explorada. Nesse caso a ameaça é dependente da existência de ameaça do acesso 
administrativo. Se o sistema estiver configurado corretamente e o acesso administrativo for restrito a 
usuários confiáveis, a vulnerabilidade pode não representar uma ameaça real. 
Resumindo 
Não há ameaça real se as condições necessárias para sua exploração da vulnerabilidade não são atendidas. 
Portanto, é importante avaliar não apenas a existência de vulnerabilidades em um sistema, mas também as condições 
necessárias para sua exploração e o nível de risco associado a elas. 
Enfim chegamos ao conceito de risco, que é a probabilidade de uma ameaça explorar uma 
vulnerabilidade para causar danos ao sistema. O risco deve ser calculado como um produto da probabilidade 
de uma ameaça ocorrer pelo tamanho do impacto que essa ameaça pode causar. Portanto, quanto maior a 
probabilidade de uma ameaça ocorrer e maior o impacto que essa ameaça pode causar, maior será o risco 
associado. Isso pode ser visualizado através de uma ferramenta conhecida como matriz de riscos. Confira: 
Desenvolvimento de Software Seguro 
Marcio Quirino - 42 
 
 
Matriz de riscos. 
Consolidando, vulnerabilidade é uma fraqueza no software, ameaça é a exploração dessa 
vulnerabilidade por uma ação ou evento e risco é a probabilidade de uma ameaça ocorrer e impactar o 
sistema. O gerenciamento de risco é importante na segurança de software para garantir a proteção do 
sistema contra ameaças conhecidas e desconhecidas. 
Framework de avaliação 
A verificação de segurança de software envolve executar ações para avaliar e gerir riscos, sempre 
considerando as possíveis expectativas que os usuários têm, ou seja, respondendo o que seria considerado 
uma violação de segurança. Nem toda falha causa impactos na segurança, que é frequentemente descrita 
com base em três componentes, que podem ser descritos da seguinte forma: 
A. Confidencialidade 
✓ É a capacidade de que a informação se mantenha privada apenas a quem detém direito de 
acessá-la. 
B. Integridade 
✓ É a capacidade de que a informação seja confiável e esteja correta. 
C. Disponibilidade 
✓ É capacidade de que a informação esteja disponível no momento oportuno. 
Considerando os três pilares que suportam as expectativas relacionadas à segurança de um sistema, 
podemos definir a avaliação de risco de segurança conforme as ações de: identificar, avaliar e implementar 
os principais controles de segurança no software, com enfoque também na prevenção de defeitos e 
vulnerabilidades. 
Se a verificação de segurança executa tais ações corretivas e preventivas, perpassando todo o ciclo 
de vida do software, desde o design até o final do suporte, podemos organizar, de forma enxuta, a gestão 
de riscos em quatro etapas, com respectivas demandas de atividade. 
Gestão de risco 
Envolve um processo estruturado para identificar, avaliar e mitigar os riscos em uma organização. 
Vejamos algumas etapas comuns envolvidas no processo de gestão de riscos! 
 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 43 
 
A. Identificação 
✓ Etapa em que se deve levantar todos os ativos críticos da infraestrutura de tecnologia e então 
elencar as informações confidenciais criadas, armazenadas ou transmitidas por esses ativos. 
Para cada ativo, deve ser criado um perfil de risco. 
B. Avaliação 
✓ Etapa em que se deve abordar os riscos de segurança identificados para cada um dos ativos 
críticos, avaliando-os. A avaliação deve analisar as relações entre ativos, cruzando ameaças 
e vulnerabilidades, e estabelecendo controles atenuantes. Após a avaliação, é necessário 
determinar como alocar tempo e recursos de maneira eficaz e eficiente para tratar os riscos. 
C. Tratamento 
✓ Etapa em que é preciso definir uma abordagem de correção ou mitigação, aplicando 
efetivamente os controles de segurança para cada risco encontrado nos respectivos ativos. 
Os riscos que estiverem dentro de níveis aceitáveis podem ser aceitos, o que significa 
simplesmente deixá-los de lado. Outra abordagem é delegar a responsabilidade de terceiros, 
por vezes contratando um serviço, ou se preparar para os impactos apenas fazendo um 
seguro, por exemplo. 
D. Prevenção 
✓ Etapa em que se deve implementar ferramentas e processos para minimizar a ocorrência de 
vulnerabilidades e a consequente existência de ameaças aos ativos. 
A gestão de risco permite que uma organização visualize o portfólio de aplicativos de forma holística 
pelo ponto de vista de um invasor. 
Métodos de verificação de software 
Com foco na verificação de segurança, vamos “explodir” a etapa de avaliação da gestão de risco, 
pois é justamente sobre ela que recai a parte mais “mão na massa”, na qual os bits e bytes são vistos de 
perto, ou como dizemos no jargão da TI, “escovados”, a partir de alguns métodos. Vamos conferi-los! 
Auditoria de software 
É o processo de análise de código (no formato fonte ou binário) para descobrir vulnerabilidades que 
possam ser exploradas por invasores. Com esse processo de análise sendo feita por time amigo, é possível 
identificar e fechar brechas de segurança, que, de outra forma, colocariam dados confidenciais e recursos 
de negócios em risco desnecessário. 
Time amigo 
Refere-se a um grupo de profissionais de segurança da informação, especialistas em auditoria de software, 
que são contratados pela própria empresa ou organização que desenvolveu o software a ser auditado. Esse time é 
considerado “amigo" porque trabalha em colaboração com a equipe de desenvolvimento do software, com o objetivo 
comum de identificar e corrigir quaisquer vulnerabilidades ou brechas de segurança presentes no código. Ao contrário 
de uma auditoria externa, em que um grupo de especialistas externos é contratado para testar a segurança do software, 
a auditoria realizada pelo time amigo permite maior transparência e cooperação entre equipes de segurançae 
desenvolvimento, facilitando a correção imediata das vulnerabilidades descobertas. Dessa forma, o time amigo é visto 
como um aliado no processo de garantir a segurança do software e proteger os dados confidenciais e recursos de 
negócios da empresa ou organização. 
Teste de caixa preta 
É um método de avaliação de um sistema de software manipulando apenas suas interfaces expostas. 
Normalmente, esse processo envolve a geração de entradas especialmente criadas que provavelmente 
farão com que o aplicativo execute algum comportamento inesperado, como falha ou exposição de dados 
confidenciais. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 44 
 
 
Teste da caixa preta. 
O teste de caixa preta é tão somente injetar dados em uma aplicação e esperar que ocorra um 
comportamento inesperado. Não é possível saber exatamente o que o software está fazendo com os dados, 
portanto, podem existir centenas de caminhos de código que não serão explorados porque os dados 
injetados não acionam esses caminhos. Porém, por mais espantoso que possa parecer, muitas 
vulnerabilidades são encontradas por hackers testando o que acontece se lançar dados estranhos ao 
comportamento esperado como entrada. Felizmente, a auditoria de código pode ser combinada com o teste 
de caixa preta para maximizar a descoberta de vulnerabilidades em um período mínimo. 
2. Modelagem de Ameaças 
Definição dos objetivos 
Modelar ameaças é uma forma de usar a identificação de vulnerabilidades para priorizar 
contramedidas. Vejamos uma modelagem de ameaças em cinco etapas: 
 
Modelagem de ameaças. 
Na primeira etapa, definir objetivos, devemos identificar os objetivos de segurança, definindo-os em 
estrito acordo com os requisitos. É uma etapa crítica no processo de modelagem de ameaças de segurança 
de software, pois envolve levantar os ativos que precisam de proteção, elencando as possíveis ameaças 
que podem prejudicá-los, ou seja, qualquer inobservância a algum ativo pode ter efeito dramático para os 
resultados. 
A partir desse mapa, muito similar ao perfil de risco da primeira etapa da gestão de riscos e, tomando 
por base os requisitos de segurança estipulados, definem-se formalmente os objetivos de segurança a 
serem atingidos. De maneira mais específica, descrevemos os aspectos mais importantes dessa etapa. 
Vamos conferir! 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 45 
 
1. Identificar as metas do sistema 
✓ Pode incluir a funcionalidade que o sistema deve fornecer, observando o que o sistema faz e 
para que e quem ele faz. É importante entender a finalidade do sistema e os objetivos de 
seus usuários a fim de identificar possíveis riscos de segurança. 
2. Identificar ativos que precisam de proteção 
✓ Podem ser dados, hardware, software ou pessoal. Isso ajuda a entender o que precisa ser 
protegido de possíveis ameaças. É importante que nenhum ativo relevante fique de fora desse 
levantamento. 
3. Identificar ameaças potenciais que podem prejudicar os ativos 
✓ Pode incluir ameaças externas (como hackers, malware e ataques de phishing) e ameaças 
internas (como erros de funcionários ou pessoas mal-intencionadas). Essa etapa deve 
considerar uma diversidade de perfis de especialistas em segurança, a fim de varrer a maior 
gama possível de ameaças conhecidas. 
4. Entender a conformidade regulamentar 
✓ Pode ser necessário, dependendo do setor e do país onde o sistema será implantado, cumprir 
regulamentos ou padrões específicos. É importante identificar e entender esses regulamentos 
e padrões para garantir que o sistema seja projetado e implementado de acordo. 
No geral, a primeira etapa da modelagem de ameaças é crucial para definir os objetivos de segurança 
do sistema e entender os riscos potenciais que podem afetar o sistema. Essa etapa ajuda a estabelecer 
uma base sólida para o restante do processo de modelagem de ameaças. 
Diagramação dos fluxos de dados 
A etapa de diagramação de fluxos visa criar um diagrama de fluxo de dados (DFD), ou seja, envolve 
a representação visual do sistema e de seus componentes, incluindo como os dados fluem entre eles. 
Vejamos alguns aspectos importantes! 
1. Identificar os componentes do sistema (servidores, bancos de dados e interfaces de 
usuário) 
✓ Inclui o propósito de cada componente e como eles trabalham juntos para atingir os objetivos 
do sistema e construir uma visão clara sobre como o sistema funciona. 
2. Definir fluxo de dados entre os componentes 
✓ Inclui identificar os diferentes tipos de dados, como entrada do usuário ou informações 
confidenciais, e como eles são transmitidos entre os componentes. 
3. Identificar onde os dados são armazenados e como são protegidos 
✓ Inclui armazenamentos de dados internos, como bancos de dados, e externos, como 
armazenamento em nuvem. 
4. Identificar limites de confiança 
✓ Inclui limites de confiança, que definem os limites entre diferentes componentes ou sistemas 
que possuem diferentes níveis de confiança. Por exemplo, um aplicativo da web pode ter um 
limite de confiança entre o navegador do cliente e o servidor da web. 
5. Analisar o fluxo de dados para identificar possíveis falhas de segurança 
✓ Inclui a identificação de áreas onde os dados podem ser vulneráveis ao acesso, à modificação 
ou à exclusão não autorizados. 
Ao criar um diagrama de fluxo de dados, o modelador de ameaças obtém melhor compreensão da 
arquitetura do sistema e de como os dados são transmitidos entre seus componentes. 
Resumindo 
O entendimento do diagrama de fluxo ajuda a identificar possíveis riscos e vulnerabilidades de segurança que 
podem ser tratados nas etapas subsequentes do processo de modelagem de ameaças. É desejável que sejam 
empregadas ferramentas de modelagem com bom resultado gráfico, gerando documentação de qualidade. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 46 
 
Identificação das ameaças 
A etapa de identificação de ameaças envolve o brainstorming de todas as possíveis ameaças ao 
sistema e seus componentes, incluindo ameaças internas e externas. Os diagramas de fluxos de dados 
devem ser utilizados como insumos para o brainstorming, pois trazem visibilidade sobre os possíveis pontos 
de falha observados a partir do acompanhamento do fluxo dos dados pelo sistema. Vejamos alguns aspectos 
importantes! 
1. Identificar agentes (quem ou o que) de ameaça ao sistema 
✓ Inclui ameaças externas, como hackers ou malware, bem como ameaças internas, como 
funcionários com intenções maliciosas. 
2. Identificar vetores de ameaças 
✓ Inclui a identificação de possíveis pontos de entrada, como conexões de rede, interfaces de 
usuário ou componentes de terceiros para identificar como um agente de ameaça pode obter 
acesso ao sistema ou a seus componentes. 
3. Identificar ações de ameaças que um agente pode executar depois de obter acesso ao 
sistema 
✓ Inclui ações como roubo de dados confidenciais, modificação de configurações do sistema 
ou lançamento de ataques de negação de serviço. 
4. Categorizar ameaças 
✓ Inclui priorizar quais ameaças devem ser abordadas primeiro. Uma vez identificadas todas as 
possíveis ameaças, elas devem ser categorizadas com base em sua gravidade e 
probabilidade de ocorrência. 
5. Documentar ameaças identificadas junto com seu impacto potencial no sistema 
✓ Inclui a documentação usada na próxima etapa do processo de modelagem de ameaças para 
desenvolver contramedidas para lidar com as ameaças identificadas. 
Durante os trabalhos de identificação, pode ser interessante utilizar um checklist estruturado de tipos 
de ameaça, incluindo: 
• Falsificação 
• Adulteração 
• Repúdio 
• Divulgação de informações confidenciais 
• Negação de serviço 
• Escalada de privilégio 
Ao identificar todas as possíveis ameaças ao sistema, o modelador de ameaças obtém melhor 
compreensão dos possíveis riscos e vulnerabilidades que precisam ser resolvidos. Esse entendimento ajuda30 
Diretrizes para a definição de permissões............................................................................................ 31 
Tipos de processamento e vulnerabilidades ............................................................................................ 31 
Mitigação das vulnerabilidades do processamento de dados .............................................................. 32 
Monitoramento das chamadas ................................................................................................................. 32 
4. Envio da saída ........................................................................................................................ 33 
Fundamentos da saída ............................................................................................................................. 33 
Uso da criptografia ................................................................................................................................... 34 
Protocolos de comunicação seguros ........................................................................................................ 34 
Restrição da saída para usuários autorizados ......................................................................................... 35 
Monitoramento da saída e realização de testes ....................................................................................... 36 
Etapas da monitoração da saída .......................................................................................................... 36 
5. Conclusão............................................................................................................................... 37 
Considerações finais ................................................................................................................................ 37 
Explore + .................................................................................................................................................. 37 
Referências .............................................................................................................................................. 37 
Modelagem, Implantação e Verificação de Software seguro.............................................................. 38 
Introdução ................................................................................................................................................ 38 
1. Verificação de segurança ...................................................................................................... 38 
A importância do software seguro ............................................................................................................ 38 
Vulnerabilidades ....................................................................................................................................... 38 
Explorando vulnerabilidades nos softwares ............................................................................................. 40 
Relação entre vulnerabilidade, ameaça e risco ........................................................................................ 41 
Framework de avaliação .......................................................................................................................... 42 
Desenvolvimento de Software Seguro 
Marcio Quirino - 3 
 
Gestão de risco .................................................................................................................................... 42 
Métodos de verificação de software ..................................................................................................... 43 
Auditoria de software ............................................................................................................................ 43 
Teste de caixa preta ............................................................................................................................. 43 
2. Modelagem de Ameaças ....................................................................................................... 44 
Definição dos objetivos ............................................................................................................................ 44 
Diagramação dos fluxos de dados ........................................................................................................... 45 
Identificação das ameaças ....................................................................................................................... 46 
Mitigação das ameaças ............................................................................................................................ 46 
Validação do modelo de ameaças ........................................................................................................... 47 
3. Implantação de software seguro ............................................................................................ 48 
Definindo os requisitos de segurança ...................................................................................................... 48 
Projetando software seguro...................................................................................................................... 49 
Desenvolvendo software seguro .............................................................................................................. 50 
Testando o software ................................................................................................................................. 50 
Implantando e fazendo manutenção do software ..................................................................................... 51 
4. Garantias e métodos formais ................................................................................................. 52 
OWASP .................................................................................................................................................... 52 
SAFECode ............................................................................................................................................... 53 
Microsoft SDL ........................................................................................................................................... 54 
Fornecer treinamento ........................................................................................................................... 54 
Definir requisitos de segurança ............................................................................................................ 55 
Definir métricas e relatórios de conformidade ...................................................................................... 55 
Executar modelagem de ameaças ....................................................................................................... 55 
Estabelecer requisitos de projeto ......................................................................................................... 55 
Outras práticas ..................................................................................................................................... 55 
NIST ......................................................................................................................................................... 55 
NIST CSF (Cybersecurity Framework) ................................................................................................. 56 
NIST SP 800-39 ................................................................................................................................... 56 
NIST SP 800-160 ................................................................................................................................. 56 
Outros exemplos .................................................................................................................................. 56 
Normas ISO..............................................................................................................................................a garantir que o sistema seja projetado e implementado com a segurança em mente, reduzindo a 
probabilidade de ataques bem-sucedidos. 
Mitigação das ameaças 
A etapa de mitigação envolve o desenvolvimento de contramedidas para lidar com as ameaças e 
vulnerabilidades identificadas, de forma a corrigir os problemas de segurança do sistema. Acompanhar a 
gestão de bug, considerando as ameaças identificadas, ajuda a configurar o fluxo de trabalho dessa etapa. 
Isso ocorre com ainda mais eficiência se for apoiado no checklist estruturado sugerido na identificação das 
ameaças, pois cria uma padronização da tarefa, garantindo que nada seja esquecido. Vejamos alguns 
aspectos importantes dessa etapa! 
 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 47 
 
A. Priorizar ameaças identificadas 
✓ Inclui o foco primeiro nas ameaças mais críticas que são medidas por meio do seu impacto 
potencial e probabilidade de ocorrência. É comum a utilização de três variáveis de avaliação 
como critério de priorização, a saber: impacto, gravidade e risco. 
B. Avaliar a eficácia de cada contramedida 
✓ Inclui testar a contramedida, garantindo que ela aborde a ameaça identificada em um 
ambiente controlado, além de simular diferentes cenários de ataque. 
C. Implementar contramedidas 
✓ Inclui a avaliação da eficácia de cada uma das contramedidas, para que sejam 
implementadas no sistema. Isto é: integrar as contramedidas no projeto do sistema e garantir 
que não interfiram na funcionalidade do sistema, como os controles de segurança, controles 
de acesso, criptografia ou sistemas de detecção de intrusão. 
✓ As contramedidas podem cobrir um ou mais tipos controles de segurança, dentre eles: 
controles físicos (câmeras de segurança), técnicos (como criptografia) ou administrativos 
(como políticas). Além disso, podem ter uma ou mais funções, como: preventiva, detectiva, 
corretiva, recuperativa e impeditiva. 
D. Documentar contramedidas implementadas 
✓ Ao registrar essas contramedidas, garantimos um registro dos controles de segurança 
implantados no sistema. Dessa forma, podemos manter e atualizar as contramedidas 
conforme necessário. 
Ao desenvolver e implementar contramedidas para abordar as ameaças identificadas, o modelador 
de ameaças reduz a probabilidade de ataques bem-sucedidos e fortalece a segurança geral do sistema. A 
manutenção contínua e as atualizações das contramedidas garantem que o sistema permaneça seguro 
diante das ameaças em evolução. A documentação amplia a consciência situacional e pode contribuir 
também para observação de possíveis lacunas ocasionadas por falta de cobertura das contramedidas. 
Validação do modelo de ameaças 
A etapa de validação envolve revisar e testar o modelo de ameaça para garantir que ele reflita com 
precisão os requisitos de segurança do sistema e seja eficaz na identificação e no tratamento de riscos de 
segurança. Geralmente acontece antes da implantação do sistema para garantir que os requisitos de 
segurança sejam cumpridos, as hipóteses sejam validadas e os controles de segurança sejam avaliados. 
Vejamos algumas ações importantes! 
1. Revisar modelo de ameaça e garantir precisão dos requisitos de segurança 
✓ Inclui revisar o diagrama de fluxo de dados, as ameaças identificadas e as contramedidas 
desenvolvidas para lidar com essas ameaças. 
2. Testar contramedidas desenvolvidas e garantir a eficácia no tratamento das ameaças 
✓ Inclui testar o sistema em um ambiente controlado e simular diferentes cenários de ataque. 
3. Resolver problemas identificados durante revisão e teste, atualizando modelo de ameaça 
e contramedidas 
✓ Inclui a adição de novas contramedidas ou o ajuste das existentes para lidar melhor com as 
ameaças identificadas. 
4. Comunicar às partes interessadas resultados da validação do modelo de ameaça 
✓ Inclui documentar o modelo de ameaça atualizado e as contramedidas e fornecer treinamento 
para administradores de sistema e outro pessoal relevante. 
Ao validar o modelo de ameaça, o modelador de ameaças garante que o sistema seja projetado e 
implementado com a segurança em mente, reduzindo a probabilidade de ataques bem-sucedidos. A 
validação e os testes contínuos ajudam a garantir que o sistema permaneça seguro diante das ameaças em 
evolução. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 48 
 
3. Implantação de software seguro 
Definindo os requisitos de segurança 
Chegou a hora de implementarmos o software, e é neste momento que entra o ciclo de vida de 
desenvolvimento seguro, encontrado na literatura pelas siglas SSDLC (secure software development 
lifecycle) ou SDL (secure development lifecycle). Confira as quatro etapas de teste: 
 
Ciclo de vida de desenvolvimento seguro. 
Na etapa de definição dos requisitos, que envolve capturar o escopo de funcionalidades do produto, 
são definidos objetivos e metas do projeto de software, traduzidos em requisitos funcionais e não funcionais 
que o software deve atender. É uma parte crítica do SDL porque define a base para todo o processo de 
desenvolvimento de software, sendo importante identificar os requisitos de segurança nesse estágio para 
garantir que a segurança seja integrada ao software desde o início. Isso pode ajudar a evitar que 
vulnerabilidades de segurança sejam introduzidas posteriormente no processo de desenvolvimento, quando 
se torna mais difícil e caro para corrigir. 
Comentário 
Os requisitos de segurança são geralmente identificados por meio de uma combinação de análise de risco, 
modelagem de ameaças e padrões e diretrizes de segurança. Os requisitos de segurança devem ser documentados e 
comunicados claramente a todas as partes interessadas, incluindo desenvolvedores, testadores e gerentes de projeto. 
Vamos conhecer alguns exemplos de requisitos de segurança que podem ser identificados durante 
a fase de levantamento de requisitos. Vamos lá! 
looks_one 
1. Requisitos de autenticação e controle de acesso 
✓ Especificam como os usuários são autenticados e autorizados a acessar o software e seus 
recursos. 
2. Requisitos de proteção de dados 
✓ Especificam como os dados confidenciais serão protegidos, por exemplo, usando criptografia 
ou outras medidas de segurança. 
3. Requisitos de registro e auditoria 
✓ Especificam como a atividade do sistema será registrada e auditada para detectar incidentes 
de segurança e rastrear a atividade do usuário. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 49 
 
4. Requisitos de conformidade 
✓ Especificam quaisquer requisitos regulamentares ou legais que o software deve atender, 
como a Lei Geral de Proteção de Dados (LGPD), ou outra norma associada ao negócio no 
qual o sistema irá operar. 
O conceito-chave nesse passo é definir os aspectos de segurança do produto de maneira a incutir 
uma mentalidade de “segurança em primeiro lugar” e promover a conscientização do time de 
desenvolvedores. Ao identificar e documentar os requisitos de segurança, os desenvolvedores de software 
podem garantir que a segurança seja uma preocupação desde o princípio e que o software seja projetado e 
construído para atender aos padrões de segurança exigidos. Isso pode ajudar a reduzir o risco de violações 
de segurança, proteger dados confidenciais e manter a integridade e a disponibilidade do software. 
Projetando software seguro 
A etapa de projeção de software seguro envolve desenhar tecnicamente os requisitos. A arquitetura 
do software é desenhada e as especificações técnicas são formalmente definidas empregando linguagens 
voltadas à modelagem. 
Resumindo 
O objetivo da fase de projeção de software é garantir que este seja projetado de forma a atender aos requisitos 
funcionais e não funcionais identificados na fase de definição dos requisitos, ao mesmo tempo em que integra 
considerações de segurança ao design. 
As considerações de segurança são integradas à arquitetura geral do software e às especificaçõestécnicas, o que inclui analisar possíveis riscos e vulnerabilidades de segurança identificados e projetar o 
software de forma a mitigar esses riscos. Vejamos algumas considerações de segurança que podem ser 
abordadas na fase de design. Confira! 
1. Armazenamento e transmissão segura de dados 
✓ Projeta o software para armazenar e transmitir dados com segurança, como criptografar 
dados em trânsito e em repouso. 
2. Controle de acesso 
✓ Projeta o software para controlar o acesso a recursos ou dados confidenciais, como por meio 
de controle de acesso baseado em função (role-based access control - RBAC) ou outros 
mecanismos de autenticação. 
3. Validação de entrada 
✓ Projeta o software para validar a entrada de usuários e outros sistemas, de modo a evitar a 
exploração de vulnerabilidades de segurança, como injeção de SQL ou script entre sites 
(cross-site scripiting - XSS). 
4. Protocolo de comunicação seguro 
✓ Projeta o software para usar protocolos de comunicação seguros, como hypertext transfer 
protocol secure (HTTPS), para proteger os dados transmitidos pela Internet. 
5. Tratamento de erros 
✓ Projeta o software para lidar com erros e exceções de maneira segura, como registrar erros 
sem revelar informações confidenciais e tentar garantir o retorno ao estado anterior durante 
a detecção do erro. Essa abordagem é chamada de resiliência em software e visa tornar o 
sistema mais confiável. 
Ao integrar considerações de segurança no projeto do software, os desenvolvedores podem criar um 
software menos vulnerável a ataques. Isso pode ajudar a evitar que vulnerabilidades de segurança sejam 
introduzidas posteriormente no processo de desenvolvimento e pode reduzir o risco de violações de 
segurança e perda de dados ou de disponibilidade. A fase de projeto prepara o terreno para a fase de 
desenvolvimento, na qual o software é realmente construído e codificado de acordo com as especificações 
técnicas definidas nessa etapa. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 50 
 
Desenvolvendo software seguro 
A etapa de desenvolvimento envolve escrever o código que implementa o desenho técnico e permite 
que o software seja desenvolvido com base nas especificações técnicas definidas na fase de projeto. O 
objetivo dessa fase é implementar o software de forma que atenda aos requisitos funcionais e não funcionais, 
e integre as considerações de segurança identificadas nas fases anteriores. 
Durante a fase de desenvolvimento, os desenvolvedores escrevem o código, criam a documentação 
e executam tarefas de garantia de qualidade para assegurar que o software funcione conforme pretendido 
e atenda aos requisitos especificados. Práticas de segurança e técnicas de codificação seguras são 
seguidas durante essa fase para garantir que o software seja desenvolvido com a segurança em mente. 
Alguns exemplos de práticas de codificação segura que podem ser seguidas durante a fase de 
desenvolvimento incluem todas as considerações abordadas na fase de projeto e a utilização de bibliotecas 
seguras, em vez de escrever o código do zero. O desenvolvedor pode utilizar bibliotecas seguras já 
existentes que tenham sido testadas e verificadas para evitar vulnerabilidades de segurança que abram 
brechas para ataques ao sistema. 
Vamos relembrar as preocupações levantadas e desenhadas na fase de projeto, uma vez que devem 
ser levadas em consideração durante o desenvolvimento. Confira! 
• Validação de entrada, inclusive com crítica não apenas ao formato, mas também levando em 
consideração a limitação adequada de tamanho, de forma a tentar evitar ataques de buffer 
overflow. 
• Armazenamento e transmissão seguros de dados, considerando mecanismos criptográficos 
para proteção dos dados. 
• Tratamento de erros e exceções de maneira segura que garantam a não exposição de 
informações críticas e confidenciais no caso de uma mensagem de erro. 
• Controle de acesso com mecanismo de autenticação para dados confidenciais e recursos do 
sistema. 
• Protocolos de comunicação seguros para proteger os dados transmitidos pela internet. 
A fase de Desenvolvimento é uma parte crítica do SDL porque é onde o software é realmente 
construído e codificado. Ao seguir práticas e técnicas de codificação seguras durante esta fase, os 
desenvolvedores podem ajudar a fazer um software que atenda aos padrões de segurança, reduza o risco 
de tornando o software mais robusto em sua superfície de ataques, parte exposta a ameaças de hacker. 
Além de escrever código, os desenvolvedores também criam documentação e realizam tarefas de garantia 
de qualidade para assegurar que o software seja desenvolvido de acordo com as especificações técnicas e 
atenda aos requisitos identificados nas fases anteriores. 
Conscientização e mentalidade de segurança é algo que os desenvolvedores de software seguro 
devem possuir. Portanto, oferecer treinamento e educação é algo desejável nas empresas de 
desenvolvimento. A varredura de código por um profissional diferente do que desenvolveu também contribui 
para a segurança do software. Existem ainda scanners que analisam código e podem detectar problemas 
durante a codificação. 
É importante criar um processo operacional repetível. Por exemplo, instruir os desenvolvedores a 
sempre executarem as ferramentas de varredura de segurança antes de enviar seu código, bem como 
realizar reciclagens periódicas de treinamento para melhores práticas de segurança. 
Testando o software 
A etapa de teste de software envolve verificar se as funcionalidades se desenvolvam como esperado 
e dentro dos requisitos de segurança. O software é testado para garantir que funcione conforme o planejado, 
Desenvolvimento de Software Seguro 
Marcio Quirino - 51 
 
atenda aos requisitos funcionais e não funcionais e integre as considerações de segurança identificadas nas 
fases anteriores. 
A fase de teste é essencial porque ajuda a identificar quaisquer problemas ou vulnerabilidades no 
software antes de sua implantação, realizando um apanhado geral sobre a qualidade de todas as atividades 
anteriores voltadas à segurança. Testes devem ser realizados durante todo o processo de desenvolvimento, 
desde testes unitários até testes de integração, finalizando com teste de sistema e teste de aceitação. 
Confira alguns exemplos de testes que podem ser realizados: 
A. Teste funcional 
✓ Testar o software para garantir que ele execute as funções a que se destina. 
B. Teste de segurança 
✓ Testa o software em busca de vulnerabilidades e pontos fracos de segurança, como testes 
de penetração ou verificação de vulnerabilidades. 
C. Teste de desempenho 
✓ Testa o software para garantir que ele funcione adequadamente sob cargas esperadas e 
cenários de uso, assegurando sua disponibilidade mesmo em condições de estresse dentro 
dos requisitos previstos. 
D. Teste de usabilidade 
✓ Testa o software para garantir que seja fácil de usar e atenda às necessidades do usuário e 
que um comportamento inesperado do usuário não comprometa a confidencialidade, 
integridade ou disponibilidade do sistema. 
E. Teste de compatibilidade 
✓ Testa o software para garantir que ele funcione conforme o esperado em diferentes 
plataformas, navegadores e dispositivos. 
O teste deve ser um processo contínuo ao longo do ciclo de desenvolvimento, e os desenvolvedores 
devem usar uma variedade de ferramentas manuais e automatizadas, e técnicas de teste para garantir que 
o software seja utilizado de forma completa e precisa. Os resultados dos testes devem ser documentados e 
comunicados claramente a todas as partes interessadas, incluindo desenvolvedores, testadores e gerentes 
de projeto. 
Comentário 
Um SDL verdadeiramente ágil não segue o padrão de testes de um processo linear. Quando estamos falando 
em produção de software em modelos tradicionais, primeiro é preciso fazer tudo e só depois testar. Esse protocolo não 
pode ser seguido em um SDL ágil, porque novasversões são lançadas de forma rotineira. 
A maioria das equipes hoje constrói algum tipo de pipeline com integração contínua e testes de 
software frequentes. Nesse modelo, há uma série de testes ocorrendo em vários estágios, alguns durante a 
codificação, alguns após cada envio de código, alguns todas as noites e alguns testando o ambiente de 
produção ao vivo, por exemplo. 
Dentro da etapa de requisitos, é importante mapear onde os testes de segurança devem ser 
executados, mas é possível introduzir testes adicionais antes da implantação, dependendo da estratégia de 
lançamento do sistema. 
Implantando e fazendo manutenção do software 
Na etapa de implantação e manutenção, o software é implantado em ambiente de produção e 
mantido ao longo do tempo para garantir que continue atendendo aos requisitos funcionais e de segurança. 
Durante a fase de implantação, o software é liberado para produção, e a infraestrutura necessária é 
implementada para dar suporte ao software em um ambiente de produção. Isso pode envolver a 
configuração de servidores, configuração de bancos de dados e implementação de controles de segurança 
para proteger o software e os dados. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 52 
 
Depois que o software é implantado, manutenção e suporte contínuos são necessários para garantir 
que ele continue atendendo aos requisitos funcionais e de segurança. Isso pode envolver a execução de 
atualizações e patches regulares para solucionar vulnerabilidades de segurança ou correções de bugs, 
monitorar o software quanto a problemas de desempenho ou incidentes de segurança e fornecer suporte 
técnico aos usuários. 
Confira alguns exemplos de atividades que podem ser realizadas durante a fase de implantação e 
manutenção. 
A. Atualizações e patches de segurança 
✓ Envolve atualizar regularmente o software para solucionar quaisquer falhas ou pontos fracos 
que tenham sido descobertos posteriormente. 
B. Monitoramento e resposta a incidentes 
✓ Envolve monitorar o software quanto a incidentes de segurança ou problemas de 
desempenho, e respondê-los de maneira oportuna e eficaz, inclusive interagindo com 
agências específicas da área para publicar os fatos ocorridos, ampliando a abrangência de 
conscientização sobre as falhas para outras organizações que utilizem o mesmo sistema por 
meio de alertas. 
C. Suporte ao usuário 
✓ Envolve o fornecimento de suporte técnico aos usuários para garantir que eles possam usar 
o software de maneira eficaz e segura. 
D. Ajuste de desempenho 
✓ Envolve a otimização do desempenho do software para garantir que ele funcione de maneira 
ideal sob as cargas esperadas e os cenários de uso. 
E. Backups de dados e recuperação de desastres 
✓ Envolve a implementação de backups de dados e medidas de recuperação de desastres para 
garantir que os dados sejam protegidos e possam ser restaurados em caso de perda ou 
interrupção de dados. 
Ao realizar manutenção e suporte contínuos durante a fase de implantação e manutenção, outros 
aspectos da segurança devem ser abordados, incluindo questões da infraestrutura que irá abrigar o sistema 
e os acessos a ela. Para os casos cada vez mais comuns de sistemas que rodam na nuvem, existe toda 
uma disciplina de segurança. Todas as atividades incluídas nessa etapa visam dar garantias mínimas de 
que o software continue atendendo às necessidades dos usuários. 
4. Garantias e métodos formais 
OWASP 
The Open Worldwide Application Security Project (OWASP) é uma fundação sem fins lucrativos que, 
conforme sua missão, trabalha para melhorar a segurança do software. Promove projetos de software de 
código aberto, desenvolvendo lideranças locais nos diversos capítulos espalhados pelo mundo, e promove 
conferências educacionais e de treinamento, servindo de boa fonte para desenvolvedores e tecnólogos 
protegerem a web. A OWASP atua nos mais diversos temas relacionados à segurança das aplicações web. 
O SDL proposto pela OWASP é uma estrutura para a construção de software seguro que consiste 
em uma série de etapas a serem seguidas durante o processo de desenvolvimento de software, desde o 
planejamento até o lançamento. Vamos conferir! 
A. Definição dos requisitos de segurança 
✓ Nesta fase, os requisitos de segurança para o aplicativo são identificados e documentados, o 
que inclui a identificação de possíveis riscos e ameaças à segurança e a definição de 
objetivos de segurança que o aplicativo deve atender. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 53 
 
 
B. Criação de um modelo de ameaças 
✓ Nesta fase, o objetivo é identificar e documentar possíveis ameaças e vulnerabilidades à 
segurança. A modelagem de ameaças envolve a identificação de ameaças potenciais, como 
usuários mal-intencionados, conexões de rede inseguras ou vulnerabilidades no código. 
C. Design seguro 
✓ Nesta fase, o desenho de projeto do aplicativo é revisado e os recursos de segurança são 
adicionados, o que inclui a implementação de controles de segurança, como controles de 
acesso, validação de entrada e criptografia. 
D. Implementação 
✓ Nesta fase, o aplicativo é desenvolvido usando práticas de codificação seguras. Isso inclui 
seguir as diretrizes de codificação segura, que são orientações para que o software esteja 
apto a passar nos testes de segurança. 
E. Verificação 
✓ Nesta fase, o aplicativo é testado quanto a vulnerabilidades de segurança usando várias 
técnicas de teste, como teste de penetração e varredura de vulnerabilidade. 
F. Lançamento do software 
✓ Nesta fase, o aplicativo é liberado para produção. Isso inclui garantir que o aplicativo seja 
seguro e que os controles de segurança estejam em vigor para proteger o aplicativo e seus 
dados. 
G. Pós-lançamento 
✓ Nesta fase, o aplicativo é monitorado quanto a vulnerabilidades e ameaças de segurança, o 
que inclui a realização de avaliações de segurança regulares, resposta a incidentes de 
segurança e atualização do aplicativo com correções (incluindo as correções segurança), 
conforme necessário. 
SAFECode 
Software Assurance Forum for Excellence in Code (SAFECode) é uma organização sem fins 
lucrativos, com atuação global, dedicada a aumentar a confiança em produtos e serviços de tecnologia da 
informação e comunicação por meio do avanço de métodos eficazes de garantia de software. A missão da 
SAFECode é promover as melhores práticas para desenvolver e fornecer software, hardware e serviços 
mais seguros e confiáveis. 
A organização publicou um conjunto de diretrizes denominado “Práticas Fundamentais para o 
Desenvolvimento de Software Seguro”, no qual apresentam elementos essenciais de um programa de ciclo 
de vida de desenvolvimento seguro. O SDL proposto é composto de oito práticas fundamentais. Algumas 
serão descritas com mais detalhes, e outras apenas citadas. Vejamos! 
1. Definição de controles de segurança da aplicação 
✓ O SAFECode usa o termo application security controls (ASC) para se referir aos requisitos de 
segurança. As entradas para o ASC devem incluir: princípios de design seguro; práticas de 
codificação seguras; requisitos legais e do setor com os quais o aplicativo precisa estar em 
conformidade (por exemplo, PCI – no setor de pagamentos, SCADA – na automação 
industrial ou LGPD – para proteção de dados pessoais); políticas e normas internas; 
incidentes e outros comentários; ameaças e riscos. 
2. Projeto 
✓ O software deve incorporar recursos de segurança para cumprir, internamente, as práticas 
de segurança e, externamente, as leis ou os regulamentos. Além disso, o software deve 
resistir a ameaças conhecidas com base no ambiente operacional. A modelagem de 
ameaças, revisões de arquitetura e revisões de design podem ser usadas para identificar e 
corrigir falhas de projeto antes de partir para implementação do código-fonte. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 54 
 
3. Práticas de codificação segura 
✓ Asvulnerabilidades não intencionais são introduzidas no código por erros do programador. 
Esses tipos de erros podem ser evitados e detectados usando padrões de codificação; 
selecionando das linguagens, estruturas e bibliotecas mais apropriadas, incluindo o uso de 
seus recursos de segurança associados; usando ferramentas de análise automatizadas; e 
revisando manualmente o código. 
4. Gestão de risco de segurança inerente ao uso de componentes de terceiros 
✓ Os projetos de software são construídos usando componentes de código aberto e de 
proprietários terceiros. Cada um desses componentes pode ter vulnerabilidades já na adoção 
ou que apareçam depois. Uma organização deve manter um inventário desses componentes, 
usar ferramentas para verificar vulnerabilidades neles e ter um plano para responder quando 
novas vulnerabilidades forem descobertas. 
5. Teste e validação 
✓ A organização deve aplicar testes automatizados estáticos e dinâmicos, além dos famosos 
testes de penetração realizado pelos hackers éticos. Nesse último, um especialista em 
exploração de vulnerabilidades é contratado e liberado legalmente para tentar encontrar e 
explorar vulnerabilidades do sistema, reportando cada uma delas. 
6. Gestão de descobertas de falhas de segurança 
✓ As cinco primeiras práticas produzem artefatos que ajudam nas descobertas relacionadas à 
segurança do produto (ou falta dela). As descobertas devem ser rastreadas e ações devem 
ser tomadas para remediar as vulnerabilidades. Como alternativa, a equipe pode aceitar 
conscientemente o risco e, nesse caso, o risco deve ser rastreado, com uma classificação de 
gravidade; um plano de correção; um prazo de nova revisão. 
7. Divulgação e resposta de vulnerabilidade 
✓ O fato de seguir um SDL formal não faz o produto se tornar perfeitamente seguro devido ao 
cenário de ameaças que muda constantemente. A organização deve desenvolver uma 
resposta de vulnerabilidade e processo de divulgação para ajudar a conduzir a resolução de 
vulnerabilidades descobertas externamente e para manter todas as partes interessadas 
informadas sobre o progresso. 
8. Planejamento da implementação do desenvolvimento seguro 
✓ O SDL saudável e maduro deve incluir, além das sete práticas anteriores, uma integração 
dessas práticas no processo de negócios em toda a organização, incluindo gerenciamento 
de programas, gerenciamento de partes interessadas, planejamento de implantação, métricas 
e indicadores e um plano de melhoria contínua. A cultura, a expertise e o nível de habilidade 
da organização precisam ser considerados ao planejar a implantação de um ciclo de vida de 
software seguro. 
Microsoft SDL 
A Microsoft desenvolveu um SDL próprio, o Microsoft Security Development Lifecycle, para o 
processo de desenvolvimento de seus produtos e, desde 2006, vem disseminando esse conhecimento. Seu 
método contém diversas práticas que serão descritas resumidamente as mais importantes, e as outras 
apenas citaremos, tudo bem? 
Fornecer treinamento 
Toda a organização de desenvolvimento deve conhecer a perspectiva, os objetivos e as técnicas do 
invasor, não apenas as implicações comerciais de não criar produtos seguros, o que chega a ser intuitivo. 
Em muitos casos, profissionais como desenvolvedores, arquitetos de software, engenheiros de serviço, 
gerentes de programa, gerentes de produto e gerentes de projeto não tiveram no seu cabedal de educação 
formal aprendizado sobre segurança cibernética. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 55 
 
Ferramentas de segurança, linguagens de programação seguras e vetores de ataque estão em 
constante evolução, tornando o conhecimento obsoleto com grande velocidade. Portanto, o treinamento 
contínuo em segurança cibernética é essencial para organizações que desenvolvem software. 
Definir requisitos de segurança 
A empresa desenvolveu algumas técnicas para a elaboração sistemática de requisitos de segurança. 
Por exemplo, a engenharia de requisitos de qualidade de segurança (security quality requirements 
engineering - SQUARE), que é um processo de nove etapas que ajuda as organizações a criar segurança 
nos estágios iniciais do ciclo de vida da produção. 
O framework keep all objectives satisfied (KAOS) para linguagem de especificação de requisitos 
baseado em objetivos tem como foco o conceito de antimodelos. Um antimodelo é construído abordando 
obstáculos maliciosos (chamados antiobjetivos) criados por invasores para ameaçar os objetivos de 
segurança de um sistema. Um obstáculo nega os objetivos existentes do sistema! 
O secure i* estende a estrutura de modelagem i* com modelagem e análise de compensações de 
segurança e alinha os requisitos de segurança com outros requisitos. É importante entender que os 
requisitos de segurança devem ser continuamente atualizados para refletir as mudanças na funcionalidade 
necessária, nos padrões e no cenário de ameaças. 
Definir métricas e relatórios de conformidade 
A equipe de gerenciamento deve entender e ser responsabilizada pelos níveis mínimos aceitáveis 
de segurança usando métricas de segurança. Um subconjunto dessas métricas pode ser definido como 
indicadores-chave de desempenho (KPIs) para relatórios gerenciais. 
Executar modelagem de ameaças 
A particularidade da Microsoft é empregar o que chamam de spoofing, tampering, repudiation, 
information disclosure, denial of service, elevation of privilege (STRIDE) como check list estruturado. 
Estabelecer requisitos de projeto 
O design de recursos seguros envolve o cumprimento dos princípios de segurança atemporais, ou 
seja, conceitos praticamente imutáveis: simplicidade; controle de acesso baseado em permissão em vez de 
exclusão; segurança não baseada na obscuridade; princípio do privilégio mínimo; defesa em profundidade; 
entre outros princípios que norteiam os requisitos de projeto. 
Outras práticas 
As outras práticas que completam a estrutura de SDL da Microsoft são: 
• Definição de uso de padrões de criptografia. 
• Gerenciamento de riscos de segurança usando componentes de terceiros. 
• Emprego apenas de ferramentas homologadas. 
• Execução de teste estático de código, conhecido como static analysis security testing (SAST). 
• Execução de teste dinâmico de código, conhecido como dynamic analysis security testing 
(DAST). 
• Teste de penetração, o pen test. 
• Estabelecimento de processo-padrão de resposta a incidentes. 
NIST 
O National Institute of Standards and Technology (NIST) oferece uma série de publicações que 
podem ser usadas como suporte formal aos esforços de desenvolvimento seguro. Vamos citar algumas, 
mas dentro de um universo gigantesco de informações disponíveis. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 56 
 
NIST CSF (Cybersecurity Framework) 
O arcabouço de segurança cibernética fornece orientação às organizações para entender, gerenciar, 
reduzir e comunicar melhor os riscos de segurança cibernética. O framework propõe uma classificação de 
maturidade para as organizações subdividida em níveis. 
Os níveis CSF funcionam como uma forma de fazer as organizações enxergarem e compreenderem 
o patamar que sua abordagem de segurança cibernética e processos em vigor para gerenciar esse risco 
está. Os níveis têm gradação crescente de rigor e sofisticação na descrição geral das práticas de gestão do 
risco de segurança cibernética. 
NIST SP 800-39 
O objetivo da Publicação Especial 800-39 é gerenciar riscos de segurança da informação nas 
operações organizacionais, ou seja, missão, funções, imagem e reputação, ativos organizacionais, 
indivíduos, dentre outros. Fornece uma abordagem estruturada, mas flexível, para gerenciar o risco de 
segurança da informação, considerando detalhes de avaliação, resposta e monitoramento contínuo do risco. 
O texto põe foco na gestão de riscos técnicos de sistemas de TI com abordagem prescritiva e 
sugestiva. Inclui ameaças, vulnerabilidades, probabilidade e impacto, juntocom monitoramento de controle 
e verificação de conformidade. 
NIST SP 800-160 
A publicação concentra-se na engenharia de resiliência cibernética, uma disciplina relativamente 
nova de engenharia de sistemas especializada em desenvolver sistemas seguros confiáveis e com 
capacidade de sobrevivência. Observada do ponto de vista da gestão de risco, a resiliência cibernética tenta 
reduzir o risco de dependência da empresa dos recursos cibernéticos. 
A norma NIST SP 800-160 define a engenharia de resiliência cibernética e tem como objetivo 
construir e manter sistemas confiáveis com a habilidade de prever, resistir, recuperar-se e adaptar-se a 
situações desfavoráveis, estresses, ataques ou comprometimentos que envolvam ou sejam ativados por 
recursos cibernéticos. 
NIST SP 800-53 
É uma publicação bastante interessante em termos práticos para mitigação de risco, no âmbito da 
gestão de riscos e implementação de contramedidas no âmbito da avaliação de software seguro. Fornece 
um catálogo de controles de segurança e privacidade para sistemas de informação e organizações para 
proteger operações e ativos organizacionais e indivíduos de um conjunto diversificado de ameaças e riscos, 
incluindo ataques hostis, erros humanos, desastres naturais, falhas estruturais, entidades de inteligência 
estrangeiras e riscos de privacidade. 
Os controles propostos são flexíveis e customizáveis e abordam diversos requisitos derivados de 
leis, regulamentos, políticas, padrões e diretrizes. O catálogo de controle aborda a segurança e a privacidade 
pela perspectiva da funcionalidade e de garantia. Abordar funcionalidade e garantia ajuda a garantir que os 
produtos de tecnologia da informação e os sistemas que dependem desses produtos sejam suficientemente 
confiáveis. 
Outros exemplos 
Vejamos outras publicações e ferramentas relacionadas que merecem ser citadas: 
1. NIST SP 800-61 
✓ Guia para tratamento de incidentes de segurança de computadores. 
2. NIST SP 800-122 
✓ Guia para proteção de confidencialidade de informações de identificação pessoal. 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 57 
 
3. NIST SP 800-218 
✓ Mitigando o risco de vulnerabilidades de softwares pela adoção de um Framework de 
Desenvolvimento de Software Seguro. 
O NIST também conta com diversas publicações relacionadas à criptografia, como técnicas de 
cifragem de blocos, algoritmos de função resumo (hash function) e os próprios algoritmos de criptografia em 
si, tanto de simétricos como assimétricos. O NIST já foi responsável por um concurso mundial para seleção 
do padrão de criptografia a ser adotado pelos EUA por ocasião da substituição do então algoritmo padrão, 
o data encryption standard (DES). Existem publicações que versam inclusive sobre criptografia pós-
quântica, ou seja, o que acontecerá com a criptografia quando o computador quântico for efetivamente 
inventado e fabricado em escala. O NIST preocupa-se em estar sempre na fronteira do conhecimento, 
sendo, portanto, importante fonte de informação de qualidade. 
Normas ISO 
International Organization for Standardization (ISO) é uma entidade não governamental que 
desenvolve e publica padrões internacionais. A atuação do órgão é extremamente abrangente, passando 
por diversas áreas do conhecimento. Relacionado à gestão da segurança da informação, podemos 
relacionar toda a família de normas 27000. Com respeito ao sistemas de software, daremos um destaque 
especial para: ISO 15288, ISSO 16085, ISO 20004 e ISO 23643. 
Família ISO 27000 
É um conjunto de padrões internacionais que fornece diretrizes para sistemas de gerenciamento de 
segurança da informação (SGSI). Vejamos a família de normas ISO 27000! 
1. ISO/IEC 27001 - Tecnologia da Informação – Técnicas de segurança – Sistemas de gestão 
de segurança da informação - Requisitos 
✓ Especifica os requisitos para um SGSI e fornece uma abordagem sistemática para gerenciar 
informações confidenciais da empresa para garantir sua confidencialidade, integridade e 
disponibilidade. 
2. ISO/IEC 27002 - Tecnologia da Informação – Técnicas de segurança – Código de prática 
para controles de segurança da informação 
✓ Fornece um código de práticas para gerenciamento de segurança da informação e abrange 
uma ampla gama de controles de segurança, incluindo segurança física, segurança de rede, 
controles de acesso e gerenciamento de incidentes. 
3. ISO/IEC 27003 - Tecnologia da informação — Técnicas de segurança — Sistemas de gestão 
da segurança da informação — Orientações 
✓ Fornece diretrizes para a implementação de um SGSI e inclui informações sobre as fases de 
planejamento, projeto e implementação. 
4. ISO/IEC 27004 - Tecnologia da informação — Técnicas de segurança — Sistemas de gestão 
da segurança da informação — Monitoramento, medição, análise e avaliação 
✓ Fornece orientações sobre a medição e avaliação da eficácia de um SGSI, incluindo o uso de 
métricas e indicadores de desempenho. 
5. ISO/IEC 27005 - Tecnologia da informação — Técnicas de segurança — Gestão de riscos 
de segurança da informação 
✓ Fornece diretrizes para gerenciamento de riscos relacionados à segurança da informação, 
incluindo avaliação, tratamento e comunicação de riscos. 
6. ISO/IEC 27006 - Information technology – Security techniques – Requirements for bodies 
providing audit and certification of information security management systems 
✓ Apresenta diretrizes ao credenciamento de organizações que fornecem serviços de 
certificação para SGSI, garantindo que os organismos de certificação operem de forma eficaz 
e imparcial. No entanto, é uma norma ainda não traduzida/adaptada para o português. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 58 
 
A família de padrões ISO 27000 é essencial para organizações que lidam com informações 
confidenciais, incluindo dados financeiros, informações pessoais e propriedade intelectual. Ao implementar 
um SGSI com base nesses padrões, as organizações podem reduzir o risco de violações de segurança e 
garantir a confidencialidade, integridade e disponibilidade de suas informações. 
Existe uma certificação ISO 27001 que é reconhecida globalmente e proporciona às organizações 
uma vantagem competitiva, aumentando sua credibilidade e reputação. 
ISO/IEC 15288 
É uma norma antiga (2009), mas que ainda não foi substituída e possui tradução/adaptação para o 
português. Descreve o ciclo de vida de sistemas a partir de processos que apoiam definição, controle e 
melhoria dos procedimentos associados ao ciclo de vida utilizados em uma organização ou em um projeto. 
A ISO/IEC 15288 aborda o desenvolvimento de sistemas e configurações de hardware, software, 
dados, pessoas, processos, procedimentos, instalações, materiais e entidades envolvidas. Aplica-se a 
organizações que desempenham papéis tanto de comprador como de fornecedor, engloba todo o ciclo de 
vida de sistemas, incluindo concepção, desenvolvimento, produção, utilização, suporte e desativação de 
sistemas, e para a aquisição e fornecimento de sistemas, independentemente de ser realizado interna ou 
externamente à organização. Além disso, fornece um modelo de referência de processo definido por 
propósito e resultados esperados de processo, que decorrem da execução bem-sucedida das tarefas. 
ISO/IEC 16085 
É uma norma que fornece um padrão para profissionais responsáveis pelo gerenciamento de riscos 
associados a sistemas e software ao longo de todo seu ciclo de vida. Essa norma foi revisada recentemente 
para se alinhar com as atualizações de outros padrões relacionados, bem como para incluir novos conteúdos 
relacionados aos desafios de gerenciamento de riscos inerentes a grandes programas e projetos de 
engenharia de sistemas complexos. 
ISO/IEC 20004 
É uma norma que toma por base outras duas, realizando um refinamento de atividades definidas na 
ISO/IEC 18045. Fornece orientações mais específicas sobre a identificação, seleção e avaliação devulnerabilidades para proporcionar uma avaliação (baseada na ISO/IEC 15408) de um sistema-alvo. A 
norma tomou como base a biblioteca ITIL (Information Technology Infrastructure Library), que é um conjunto 
de práticas e processos para gerenciamento de serviços de TI, o qual fez relativo sucesso no início dos anos 
2000 com sua versão 2. 
ISO/IEC 23643 
É uma norma recente (2020), que especifica os requisitos para os fornecedores de software e fornece 
diretrizes para usuários e desenvolvedores de software seguro e ferramentas de verificação de segurança. 
Os usuários de tais ferramentas são desenvolvedores de software que precisam estar cientes das 
necessidades de segurança de software. 
É interessante, pois apresenta casos de uso para segurança de software e ferramentas de verificação 
de segurança. Apresenta também categorias de ferramentas para segurança de software e fornece 
orientação e requisitos específicos de cada categoria para fornecedores e desenvolvedores de ferramentas. 
A ISO é uma importante fonte de consulta para profissionais das mais diversas áreas, tendo algumas 
de suas normas obrigatoriedade de uso em um grande espectro de setores e indústrias. 
Considerações finais 
A verificação de software é um processo crucial que tem como objetivo garantir que o software atenda 
aos requisitos de segurança, confiabilidade, desempenho e qualidade. A respeito especificamente da 
segurança, a modelagem de ameaças é uma técnica utilizada para identificar e avaliar as possíveis ameaças 
e vulnerabilidades que podem comprometer o software. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 59 
 
O gerenciamento de risco é outra atividade importante no processo de verificação de segurança de 
software. Engloba a identificação de ativos, avaliação e tratamento dos riscos associados a medidas de 
prevenção. 
O SDL é um processo de desenvolvimento de software que incorpora a segurança desde o início do 
ciclo de vida do desenvolvimento. A segurança incorporada tira proveito de ferramentas estruturadas, por 
exemplo, a modelagem de ameaças, composta das seguintes etapas: definição de objetivos; diagramação 
de fluxos de dados; identificação de ameaças; mitigação; e validação. 
Em conjunto, a modelagem de ameaças, o gerenciamento de risco e o SDL formam uma abordagem 
abrangente para a verificação de software, ajudando o software a reduzir o número de falhas que se 
configurem como vulnerabilidades exploradas. 
Explore + 
Confira as indicações que separamos especialmente para você! 
Pesquise: 
A base de dados de exploits e conheça os exploits já prontos orientados para determinadas 
plataformas e tipos de ataque, com o respectivo autor do código. Vale conferir! 
Em seus próprios portais eletrônicos, OWASP, SAFECode e Microsoft SDL. São excelentes 
caminhos para aprofundar o seu estudo! 
Referências 
KHAN, S. A.; KUMAR, R.; KHAN, R. Software security: concepts & practices. Boca Raton, FL: 
Chapman & Hall/CRC Press, 2023. 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 60 
 
Emprego DevSecOps no Ciclo de Vida do Software 
Introdução 
Com o DevSecOps, você dá um passo importante na jornada de desenvolver aplicativos mais 
modernos e, acima de tudo, mais seguros. Essa prática de engenharia de software está se tornando cada 
vez mais popular, especialmente em relação à transformação digital e à segurança da informação. A prática 
consiste na integração de segurança no ciclo de vida do desenvolvimento de software, desde o início do 
projeto até a implantação e manutenção do software em produção. Ou seja, DevSecOps garante que a 
disciplina de segurança seja trabalhada desde a concepção do software a ser desenvolvido, durante sua 
implementação, até sua manutenção em produção. 
Diferente do modelo tradicional de desenvolvimento de software, em que a segurança é considerada 
apenas na fase final de testes, DevSecOps prega pela integração contínua de requisitos de segurança 
durante o processo de desenvolvimento, com o objetivo de antecipar, minimizar e até mesmo evitar 
vulnerabilidades e ameaças à segurança do software em desenvolvimento. 
Enquanto DevOps tem como objetivo principal acelerar o processo de desenvolvimento de software 
por meio de práticas de engenharia de software, automação de processos de desenvolvimento, automação 
de builds e integração frequente e contínua de pequenos artefatos de software entre outros conceitos, 
DevSecOps alinha as práticas de desenvolvimento ágil com a segurança da informação, garantindo que a 
segurança seja parte integrante do processo de desenvolvimento. 
1. Segurança no ciclo de vida do software 
Segurança: Modelo tradicional x DevOps 
Ciclo de vida de software 
Quando falamos de desenvolvimento de software, a primeira coisa que precisamos considerar é seu 
ciclo de vida, que normalmente é composto por diversas fases que juntas permitem o desenvolvimento de 
um produto de software. Não existe um padrão único e que contemple todas as fases possíveis para um 
ciclo de vida efetivo no desenvolvimento de software, mas podemos destacar fases importantes que devem 
ser contempladas em qualquer ciclo de vida de desenvolvimento de software. Vamos conferi-las! 
A. Ideação 
✓ Fase em que o problema a ser resolvido com um produto de software é explorado e entendido. 
Nessa fase, os requisitos de negócio que devem ser endereçados pelo produto de software 
emergem e são adicionados a um backlog de produto. 
B. Design 
✓ Fase em que a solução de software para resolver os problemas e requisitos de negócio 
identificados na fase de ideação é desenhada. Contempla-se arquitetura, definição de 
componentes e integração entre diferentes serviços (inclusive de terceiros), bem como outras 
características que devem ser endereçadas pela solução, ou seja, é a fase em que a solução 
é definida. 
C. Implementação 
✓ Fase em que a solução definida na fase de design é implementada, ou seja, construída. 
D. Teste 
✓ Fase em que o produto de software desenvolvido é testado quanto a sua aderência de 
resolução do problema identificado na fase de ideação. 
E. Implantação 
✓ Fase em que o produto de software desenvolvido e testado é posto em produção para seu 
efetivo uso por parte dos usuários. 
F. Evolução 
Desenvolvimento de Software Seguro 
Marcio Quirino - 61 
 
✓ Fase em que o produto de software é evoluído, baseado no feedback de seus usuários. 
A descrição das fases não deixa claro em que momento a disciplina de segurança deve ser 
contemplada. Na maioria das vezes, a subjetividade levava à negligência dessa disciplina importante por 
parte das equipes de desenvolvimento de software, que só se preocupavam com segurança quando algum 
problema era relatado pelos usuários. 
Com o advento de DevSecOps, a segurança passa a ser uma disciplina pensada e tratada em todas 
as fases do ciclo de vida de desenvolvimento, desde a ideação até a sua evolução, sendo parte integrante 
do dia a dia das pessoas envolvidas em seu desenvolvimento. 
Segurança no modelo tradicional de desenvolvimento de software 
No modelo de desenvolvimento de software tradicional, a disciplina de segurança é normalmente 
endereçada como um aspecto isolado do processo de desenvolvimento, sendo muita das vezes uma fase 
adicional ao ciclo de vida, ou até mesmo uma atividade na fase de testes desses ciclos tradicionais. Isso 
porque a disciplina de segurança é identificada como um requisito adicional aos requisitos funcionais das 
soluções de software, permitindo que os times de implementação enxerguem segurança como uma fase 
posterior ao desenvolvimento das funcionalidades de negócio. 
Os times focam na implementação de artefatos de software que resolvem os problemas de 
negócio, e só depois se preocupam em testar esses artefatos quanto aos aspectos de segurança 
necessários. 
Muitas vezes os testes de segurança somente são realizados na fase diretamente anterior a sua 
implantação. Normalmenteos testes são realizados por uma equipe especializada em segurança que utiliza 
ferramentas de terceiros para realizar diversos tipos de testes, como testes de penetração, com o objetivo 
de identificar falhas e vulnerabilidades no sistema desenvolvido. 
O problema é que essa abordagem é insuficiente e ineficiente, pois as vulnerabilidades somente 
serão descobertas tardiamente no processo de desenvolvimento, gerando um conjunto de bugs críticos de 
segurança que devem ser endereçados prioritariamente sobre novas funcionalidades, o que pode levar a 
atrasos no lançamento do software e a possíveis violações de segurança. 
Além disso, a disciplina de segurança não é considerada uma responsabilidade compartilhada de 
todos os envolvidos no processo de desenvolvimento, levando a uma falta de conscientização e 
compreensão sobre a importância da segurança por todos os envolvidos no desenvolvimento do produto de 
software. 
Segurança no modelo DevSecOps de desenvolvimento de software 
No modelo de desenvolvimento DevSecOps existe uma abordagem completamente diferente da 
disciplina segurança. Com DevSecOps a disciplina segurança é considerada parte integrante do processo 
de desenvolvimento do software e permeia por todas as fases de seu ciclo de desenvolvimento, desde a 
ideação até sua operação e evolução. 
Essa mudança de paradigma coloca a disciplina de segurança como um dos pilares centrais do 
desenvolvimento do produto de software, fazendo com que os aspectos de segurança sejam considerados 
em todos os momentos. 
Uma das principais maneiras pelas quais o DevSecOps aborda a segurança é por meio da utilização 
de técnicas e ferramentas de automação. Ferramentas de automação são usadas como base para que 
continuamente possamos avaliar a segurança do código que está sendo desenvolvido. 
Essas ferramentas também servem para detectar e corrigir vulnerabilidades de segurança à medida 
que são encontradas. Elas incluem: 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 62 
 
A. Análise estática de código 
B. Testes de penetração automatizados 
C. Monitoramento de vulnerabilidades em tempo real 
Outra maneira pela qual o DevSecOps endereça a segurança é por meio do envolvimento de equipes 
de segurança em todo o processo de desenvolvimento. Isso significa que os especialistas em segurança 
são incorporados às equipes de desenvolvimento e operações desde o início, em vez de serem chamados 
apenas no final do processo para realizar uma revisão de segurança. Essa abordagem colaborativa ajuda a 
identificar e resolver problemas de segurança mais cedo no processo de desenvolvimento, reduzindo o 
tempo e o custo associados à correção de problemas de segurança no final do ciclo de vida do software. 
Além disso, a abordagem DevSecOps promove a cultura de segurança em toda a organização, 
permitindo que todos os membros da equipe sejam responsáveis pela segurança do software, não apenas 
os especialistas em segurança. Isso é alcançado a partir da conscientização e do treinamento de segurança 
para todos os membros da equipe, bem como por meio da implementação de políticas e práticas de 
segurança consistentes em toda a organização. 
Resumindo 
O DevSecOps aborda a segurança de forma mais integrada e colaborativa do que os modelos tradicionais de 
desenvolvimento de software. A segurança é incorporada em todas as fases do ciclo de vida do software, é 
automatizada sempre que possível e é abordada como uma responsabilidade de toda a equipe. Essa abordagem ajuda 
a garantir que o software desenvolvido seja mais seguro e confiável, reduzindo o risco de violações de segurança e 
minimizando os custos associados à correção de problemas de segurança no final do processo de desenvolvimento. 
Propósito e benefícios do DevSecOps 
Propósito de DevSecOps 
O propósito é garantir que a disciplina de segurança seja integrada ao longo de todo o ciclo de vida 
de desenvolvimento do software, desde sua concepção até a sua operação e evolução. Mas não se restringe 
apenas aos aspectos técnicos utilizados no desenvolvimento dos produtos de software, DevSecOps vai 
além, criando uma cultura em que a segurança seja integrada em todos os aspectos e atividades das 
empresas. Assim, não se restringe ao aspecto técnico e se torna uma preocupação de todas as áreas e 
pessoas dentro das empresas. 
O DevSecOps também ajuda a promover a cultura de segurança dentro das organizações de 
desenvolvimento de software, tornando a segurança uma responsabilidade compartilhada por todos os 
membros da equipe. Isso pode levar a uma maior conscientização e responsabilidade em relação à 
segurança do software e dos dados do usuário. 
Benefícios de DevSecOps 
É notório que quando adotamos um modelo de desenvolvimento de produtos de software baseado 
em uma cultura e técnicas de DevSecOps vamos colher diversos benefícios. Vamos destacar alguns! 
1. Redução de custos: Ao se tentar antecipar e minimizar possíveis vulnerabilidades e ameaças à 
segurança do software, a prática de DevSecOps tende a reduzir custos com ações corretivas e 
de reparação de danos, que muitas das vezes podem ser intangíveis. 
2. Melhoria da qualidade do software: Pensar e integrar segurança desde o início do processo de 
desenvolvimento e mantendo durante todo o ciclo de vida de um software, garante a melhor 
qualidade do software possível, fazendo com que o software atenda aos requisitos de segurança, 
performance e disponibilidade. 
3. Maior eficiência do processo: A automação de testes e a integração contínua permitem uma 
entrega mais rápida e confiável de novas funcionalidades e correções de segurança. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 63 
 
4. Maior transparência: A integração contínua de segurança no processo de desenvolvimento 
pode aumentar a transparência do projeto, permitindo que os desenvolvedores entendam melhor 
os riscos de segurança e tomem medidas preventivas. 
5. Maior conformidade regulatória: O DevSecOps incorpora a conformidade com padrões e 
regulamentos de segurança, ajudando as organizações a cumprir os requisitos de conformidade 
e a evitar penalidades e multas. 
6. Melhor resiliência: A adoção de práticas DevSecOps pode melhorar a resiliência do sistema, 
permitindo que a organização se recupere mais rapidamente de possíveis violações de 
segurança ou interrupções no sistema. 
7. Maior visibilidade e transparência: A integração contínua de segurança no processo de 
desenvolvimento pode aumentar a transparência do projeto, permitindo que os desenvolvedores 
entendam melhor os riscos de segurança e tomem medidas preventivas. 
8. Aceleração da entrega de software: Ao integrar segurança no processo de desenvolvimento, 
as equipes podem antecipar e resolver problemas de segurança mais rapidamente, o que pode 
acelerar a entrega de software. 
9. Melhor gerenciamento de riscos: O DevSecOps permite uma abordagem proativa na gestão 
de riscos de segurança, ajudando as organizações a identificar e gerenciar melhor possíveis 
ameaças. 
10. Maior agilidade: A incorporação de práticas DevSecOps pode melhorar a agilidade das 
organizações, permitindo que elas respondam rapidamente às mudanças no ambiente de 
segurança e às demandas do mercado. 
11. Melhor reputação e confiança: Uma abordagem proativa em relação à segurança do software 
pode ajudar a construir uma reputação positiva e a confiança do cliente, aumentando a lealdade 
e a fidelidade do cliente. 
Em resumo, DevSecOps é uma prática que visa integrar segurança no ciclo de vida do 
desenvolvimento de software, com o objetivo de antecipar e minimizar possíveis vulnerabilidades e ameaças 
à segurança do software. A prática de integrar segurança desde o início do processo de desenvolvimento 
pode ajudar a reduzir custos, melhorar a qualidade do software, aumentar a transparência e acelerar a 
entrega do software. 
2. Automação e orquestração 
Processo de automação e orquestraçãoA importância dos conceitos de automação e orquestração 
Tanto DevOps quanto DevSecOps têm como um de seus pilares a aplicação dos conceitos de 
automação e orquestração das atividades necessárias no desenvolvimento das soluções de software. O 
objetivo principal da aplicação desses conceitos é garantir que atividades rotineiras, que muitas das vezes 
seriam executadas por pessoas, sejam executadas pelos computadores. 
Exemplo 
Imagine que, há alguns anos, toda vez que uma nova versão de um software fosse lançada, os profissionais 
precisassem testar manualmente todas as funcionalidades, tanto as novas quanto as antigas. Isso era necessário para 
garantir que o novo desenvolvimento não afetasse as funcionalidades existentes. Nesse cenário, as empresas 
costumavam ter áreas com muitas pessoas responsáveis por realizar esses testes repetitivos. Esse processo era 
demorado, propenso a erros - afinal, dependia do trabalho humano - e extremamente ineficiente. 
A indústria de desenvolvimento de produtos de software precisava encontrar alternativas para 
melhorar esse cenário, tornando-o mais seguro, rápido e eficiente. E a solução para isso foram os conceitos 
de automação e orquestração. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 64 
 
Automação 
É fundamental para DevSecOps porque permite que tarefas repetitivas sejam efetuadas de maneira 
automatizada, como: realização de testes funcionais e de segurança, compilação de código, publicação de 
artefatos em ambientes, verificação de vulnerabilidades, provisionamento de recursos etc. A automação é 
importante, pois aumenta a eficiência economizando tempo e recursos, além de reduzir erros humanos. 
Justamente por automatizar tarefas repetitivas e garantir que sejam executadas de maneira muito 
mais rápida e segura, a automação permite que novas versões de uma solução de software sejam entregues 
de maneira mais rápida e contínua, o que é essencial para acompanhar as demandas do mercado. 
Orquestração 
É o conceito que se refere à capacidade de coordenar diferentes ferramentas e processos de 
automação para criar uma cadeia de eventos contínua. 
A orquestração é responsável por executar as tarefas programadas na sequência correta, definir 
dependências e gerenciar a execução em vários ambientes, garantindo que todo o processo de entrega de 
artefatos de software esteja integrado e funcionando de maneira contínua e eficiente. 
DevSecOps tem a orquestração como um de seus principais pilares, pois garante que as etapas 
necessárias para se garantir os critérios de segurança de um artefato de software serão executadas de 
maneira adequada e que o processo de análise seguirá um caminho predeterminado de acordo com o 
resultado das tarefas executadas. 
Benefícios 
Como principais benefícios da automação e orquestração, podemos destacar: 
A. Eficiência 
✓ Ao aplicar técnicas e ferramentas de automação e orquestração, diversas tarefas repetitivas 
podem ser executadas de maneira muito mais rápida e com menor propensão a erros 
humanos, garantindo maior eficiência no processo de desenvolvimento de produtos de 
software. Além de permitir que os profissionais se concentrem em outras atividades que 
permitam a aceleração do desenvolvimento das entregas de funcionalidades e novos 
recursos. 
B. Mitigação de erros 
✓ Por se tratar de processos automatizados e orquestrados, removendo o fator humano das 
atividades repetitivas, mitiga-se a possibilidade de erros eventuais causados pela má 
execução de uma pessoa. 
C. Visibilidade 
✓ A orquestração fornece uma visão geral de todo o processo de desenvolvimento do produto 
de software, permitindo que as equipes identifiquem rapidamente possíveis problemas e 
tomem as ações de correção de maneira mais acelerada, garantindo assim o monitoramento 
de todo o pipeline do ciclo de entrega dos artefatos de software. 
D. Redução de custos 
✓ A automação e a orquestração ajudam a reduzir os custos de desenvolvimento dos produtos 
de software, permitindo que as equipes realizem tarefas de maneira mais eficiente. 
E. Confiabilidade 
✓ Aumento da confiabilidade do pipeline de entrega, garantindo que todas as etapas estejam 
completas antes que a próxima seja iniciada. 
F. Segurança 
✓ A automação e a orquestração ajudam a aumentar a segurança do processo de entrega, 
detectando e corrigindo vulnerabilidades mais rapidamente. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 65 
 
CI/CD e DevSecOps 
Continuous integration (integração contínua) e continuous delivery (entrega contínua) são práticas 
de engenharia de software oriundas dos conceitos de automação e orquestração, que são pilares 
fundamentais para as abordagens DevOps e DevSecOps. As práticas e técnicas são tão essenciais que 
pode-se dizer que sem elas, DevOps e DevSecOps não seriam viáveis, devido aos benefícios que elas 
proporcionam como suporte para essas abordagens. 
Continuous integration (CI) 
É uma prática de engenharia de software que tem como objetivos: 
1. Automatizar o processo de compilação, teste e implantação de código-fonte, de maneira mais 
rápida, eficiente e frequente possível. Essa prática foi popularizada por Martin Fowler e Kent Beck 
em seu livro Continuous Integration: Improving Software Quality and Reducing Risk. 
2. Detectar erros o mais cedo possível no ciclo de vida do desenvolvimento de software, a partir da 
frequente integração da base de código-fonte pelos desenvolvedores, antes que se tornem 
problemas maiores e mais difíceis de corrigir. Isso é feito por meio da execução automatizada de 
diversas fases, desde a análise estática de código e de testes em busca de violações de estilo e 
outras anomalias. 
A CI também ajuda a facilitar a colaboração entre os membros da equipe de desenvolvimento, 
garantindo que o código-fonte seja frequentemente integrado ao repositório principal, permitindo que todos 
os desenvolvedores trabalhem a partir de uma base atualizada frequentemente. 
Para implementar a CI, é necessário o uso de ferramentas que permitam a automação do processo 
de compilação e teste do código-fonte, como: 
A. Jenkins, GitLab CI/CD 
B. Azure DevOps entre outras 
Além disso, é necessário que a equipe de desenvolvimento adote uma cultura de colaboração e 
comunicação constante para que a prática de integração contínua seja bem-sucedida, preferencialmente 
alinhada a uma cultura ágil. 
Continuous delivery (CD) 
É uma prática de engenharia de software que visa entregar alterações de código de forma frequente, 
segura e confiável. O objetivo da CD é alcançado por meio da automação do processo de entrega dos 
artefatos de software, incluindo testes e implantação automatizada. 
A CD ligeiramente difere da CI, pois se concentra na entrega confiável e automatizada de software 
em um ambiente de produção. No entanto, a CI é um componente fundamental da CD, já que permite aos 
desenvolvedores integrar suas alterações de código com frequência e detectar erros mais rapidamente, 
sendo assim duas práticas complementares. 
CI/CD e DevSecOps 
DevSecOps acrescenta uma dimensão de segurança à prática de CI/CD. Enquanto a integração 
contínua e a entrega contínua se concentram principalmente em automatizar e agilizar o processo de 
desenvolvimento e entrega de software, DevSecOps enfatiza a importância de incorporar práticas de 
segurança em todas as etapas do ciclo de vida do desenvolvimento de software. 
Assim, o DevSecOps adiciona controles de segurança automatizados em todas as etapas dos 
pipelines de CI/CD. Confira tais práticas de segurança! 
A. Análise estática de código-fonte 
B. Verificação de vulnerabilidades 
C. Análise de configuração de segurança 
Desenvolvimento de Software Seguro 
Marcio Quirino - 66 
 
D. Testes de penetração automatizados 
Essas práticas de segurança ajudam a identificar e corrigir vulnerabilidades em um estágio inicial do 
desenvolvimento, garantindo que as ameaças sejam mitigadas antes dechegarem à produção. 
Além disso, o DevSecOps incentiva a colaboração entre equipes de segurança, desenvolvimento e 
operações, para garantir que os requisitos de segurança sejam considerados desde o início do processo de 
desenvolvimento de software. 
A abordagem DevSecOps também promove a implementação de controles de segurança de forma 
contínua e o monitoramento em tempo real de ameaças e vulnerabilidades, permitindo que as organizações 
respondam rapidamente a incidentes de segurança e reduzam o risco geral de segurança de seus sistemas 
de software. 
Scripts e estruturas de testes 
Scripts e estruturas de teste são fundamentais para o DevSecOps, pois são as ferramentas usadas 
na integração e entrega contínua para avaliar os parâmetros de segurança. Eles desempenham um papel 
crucial na garantia da qualidade e segurança do software em desenvolvimento. Vamos conhecê-las! 
Scripts 
São arquivos que contêm uma sequência de comandos e instruções que podem ser interpretados e 
executados por um programa ou sistema operacional. Esses comandos e instruções são escritos em uma 
linguagem de script, que é uma linguagem de programação projetada para ser facilmente legível por 
humanos e executável por computadores. 
Os scripts são usados para automatizar tarefas e processos repetitivos em sistemas de computador, 
como instalação de software, configuração do sistema, gerenciamento de arquivos e pastas, entre outros. 
No contexto de DevSecOps, os scripts são comumente usados para realizar testes de segurança 
automatizados e para integrar as ferramentas de segurança ao pipeline de entrega contínua. 
Scripts são importantes no contexto de DevSecOps porque permitem automatizar tarefas repetitivas 
e complexas, melhorando a eficiência do processo de desenvolvimento e segurança do produto de software. 
Com o aumento da complexidade dos sistemas de software, há uma crescente necessidade de testes 
automatizados para garantir que os sistemas estejam em conformidade com os requisitos de segurança. 
Dentre as funções que os scripts de teste desempenham, podemos enumerar: 
1. Permitir que os testes sejam executados de forma repetitiva e consistente, garantindo que as 
vulnerabilidades de segurança sejam identificadas e corrigidas com mais eficiência. 
2. Facilitar a integração contínua e na entrega contínua, permitindo que os testes sejam executados 
automaticamente sempre que houver uma nova atualização no software. Isso é essencial para 
garantir que as mudanças feitas no código não introduzam novas vulnerabilidades e que o 
software continue seguro. 
3. Automatizar tarefas de segurança, como a análise estática de código e a verificação de 
configuração de segurança, garantindo que o software seja desenvolvido de acordo com as 
práticas recomendadas de segurança. Isso ajuda a reduzir o tempo gasto em tarefas manuais e 
aumenta a eficiência geral do processo de segurança. 
Em resumo, os scripts são importantes no contexto de DevSecOps porque permitem a automação 
de tarefas de segurança e testes, melhorando a eficiência e a eficácia do processo de desenvolvimento e 
segurança de software. 
Estrutura de testes 
São conjuntos de ferramentas, bibliotecas e convenções que fornecem uma estrutura padronizada 
para criar e executar testes automatizados de software. As estruturas de teste fornecem um ambiente 
Desenvolvimento de Software Seguro 
Marcio Quirino - 67 
 
consistente para testes, permitindo que desenvolvedores e testadores criem e executem testes de maneira 
mais simples e rápida. 
As estruturas de teste são uma parte fundamental do processo de desenvolvimento de software, 
especialmente em um ambiente DevSecOps, em que a automação e a orquestração de testes são 
essenciais para garantir a segurança e qualidade do software. As estruturas de teste podem ser usadas para 
testar desde pequenos módulos de código até sistemas inteiros, garantindo que o software seja testado em 
todas as etapas do processo de desenvolvimento. 
Existem várias estruturas de teste disponíveis para diferentes linguagens de programação e 
tecnologias. Conheça agora as estruturas de teste mais populares! 
A. JUnit para Java 
B. NUnit para .NET 
C. PyTest para Python 
D. Jasmine para JavaScript 
O uso de estruturas de teste ajuda a garantir que o software seja testado de maneira consistente e 
confiável, o que pode aumentar a eficiência do processo de desenvolvimento e melhorar a qualidade do 
software final. 
Existem diversas estruturas de testes que são importantes para a implementação de DevSecOps. 
Vejamos algumas das mais relevantes! 
A. Testes de unidade 
✓ Verificam se cada componente do software está funcionando corretamente de forma isolada, 
ou seja, testam unidades individuais de código. 
B. Testes de integração 
✓ Garantem que diferentes módulos ou componentes do software trabalhem juntos 
corretamente, integrando as diferentes partes do sistema. 
C. Testes de aceitação 
✓ Validam se o software atende aos requisitos do usuário e se funciona conforme o esperado. 
D. Testes de performance 
✓ Medem o desempenho do software em relação a tempos de resposta, uso de recursos, 
capacidade de carga, entre outros aspectos. 
E. Testes de segurança 
✓ Verificam a existência de vulnerabilidades no software, como falhas de autenticação, injeção 
de código, cross-site scripting, entre outras. 
F. Testes de conformidade 
✓ Avaliam se o software está em conformidade com leis, normas e regulamentos aplicáveis, 
como a Lei Geral de Proteção de Dados (LGPD), PCI-DSS, HIPAA, entre outros. 
É importante destacar que a escolha das estruturas de testes depende das necessidades específicas 
de cada projeto e das características do software em questão. 
3. Modelagem de Ameaças, Controles e Resposta a 
Incidentes 
Conceitos de modelagem de ameaças 
Modelagem de ameaças 
É uma técnica utilizada em DevSecOps para identificação e avaliação de possíveis ameaças à 
segurança em um sistema ou aplicação. A técnica busca a criação de um modelo que represente todos os 
Desenvolvimento de Software Seguro 
Marcio Quirino - 68 
 
componentes e processos do sistema e permita avaliar as possíveis ameaças que podem surgir em cada 
etapa. 
A modelagem de ameaças é essencial no DevSecOps, pois ajuda a identificar antecipadamente 
possíveis vulnerabilidades e ameaças de segurança. Isso ajuda a reduzir o risco de serem explorados por 
pessoas mal-intencionadas. Ao aplicar essa técnica, é possível descobrir e compreender melhor os pontos 
fracos do sistema, permitindo tomar medidas para corrigir ou reduzir essas vulnerabilidades. 
A modelagem de ameaças pode e deve ser realizada nas diversas etapas do ciclo de vida do 
desenvolvimento de software, desde a concepção até a entrega em produção da solução. 
Além disso, essa técnica pode ser integrada com outras práticas de segurança, como testes de 
penetração e análise de estática de código-fonte, fornecendo assim uma visão ainda mais abrangente das 
possíveis ameaças à segurança. 
Existem diversas ameaças que um sistema pode sofrer. Vamos entendê-las! 
1. Spoofing 
✓ É o tipo de ataque em que uma pessoa ou um sistema assume a identidade de outra pessoa 
ou organização por meio da falsificação de dados para enganar uma vítima e assim ganhar 
sua confiança para ter acesso e realizar ações maliciosas. Um exemplo de spoofing é o 
ataque phishing, em que o atacante envia um e-mail fingindo ser uma empresa ou indivíduo, 
a fim de obter informações sensíveis de sua vítima. 
2. Tampering 
✓ É a ameaça com o objetivo de alterar dados, códigos ou configurações de um sistema criando 
assim uma vulnerabilidade para que o atacante explore e atinja seu objetivo que pode ser o 
roubo de dados ou até mesmo prejudicar o funcionamento do sistema. 
3. Repudiation 
✓ É uma ameaça à integridade dos dados dos sistemas. Ocorre normalmente quando um 
usuário ou sistema nega ter executado uma ação ou transação específica, e o sistemaafetado 
não possui mecanismos que garantam a rastreabilidade das ações dos usuários para garantir 
a autenticidade das transações realizadas. 
4. Exploitability 
✓ É a ameaça em que o atacante explora uma vulnerabilidade do sistema por meio da injeção 
de códigos que possam comprometer a integridade do sistema, permitindo assim acesso 
indevido, utilizando técnicas como SQL Injection, Buffer Overflow etc. 
Para tentar prever, monitorar e impedir que ameaças sejam exploradas existem diversas 
metodologias e ferramentas disponíveis para a modelagem de ameaças, vejamos! 
A. Dread 
✓ (Damage, reproducibility, exploitability, affected users and discoverability): Tem como objetivo 
a análise de risco qualitativa para priorizar as ameaças com base em cinco critérios que 
compõem a sua sigla, sendo muito utilizada para avaliar a gravidade das ameaças. As 
ameaças são então categorizadas em uma escala entre 5 e 15 e, com base na nota que o 
item tiver, ele pode ser considerado de alto, médio ou baixo risco. 
B. Stride 
✓ (Spoofing, tampering, repudiation, information disclosure, denial of service e elevation of 
privilege): Tem como objetivo identificar ameaças em cada um dos seis tipos de ataques que 
compõem a sua sigla, sendo uma metodologia amplamente utilizada em grandes corporações 
provedoras de soluções em tecnologia, como a Microsoft. 
C. Pasta 
✓ (Process for attack simulation and threat analysis): Tem como objetivo ter amplitude na 
análise das ameaças através de um contexto mais amplo que a Dread e a Strike, 
Desenvolvimento de Software Seguro 
Marcio Quirino - 69 
 
considerando fatores como os atores das ameaças, ativos, vulnerabilidades e impacto 
potencial caso uma vulnerabilidade seja explorada. 
D. Trike 
✓ (Threats, risks, identities, knowledge and environment): É um processo de modelagem de 
ameaças de código aberto e tem como objetivo analisar ameaças baseada no processo de 
auditoria de segurança cibernética. 
Cada metodologia tem sua própria abordagem e técnica, mas todas compartilham o objetivo comum 
de identificar e mitigar ameaças à segurança em sistemas e aplicações. 
Controles de segurança e resposta a incidentes 
Controles de seguranças 
São medidas que devem ser implementadas para mitigar riscos e proteger sistemas contra possíveis 
ameaças e vulnerabilidades. Os principais controles de segurança conhecidos são regidos por normas 
internacionais. São elas: 
1. ISO/IEC 27001:2013 
✓ Trata do tema de sistema de gestão de segurança da informação. 
2. SO/IEC 27002/2022 
✓ Trata do tema segurança da informação, cibersegurança e proteção de privacidade – 
Controles de segurança da informação. 
3. ISO/IEC 27005/2018 
✓ Trata do tema gestão de risco de segurança da informação. 
4. ISO/IEC 27017/2015 
✓ Trata do tema código de prática para segurança da informação em nuvem. 
Outras normas também são amplamente difundidas e implementadas pelas empresas com o objetivo 
de desenvolver e implementar camadas adicionais de segurança aos sistemas, podendo destacar a norma 
Nist SP 800-53, que determina uma estrutura de controle de segurança desenvolvida pelo Instituto Nacional 
de Padrões e Tecnologia (NIST) dos Estados Unidos e a CIS Controls, que á uma lista com 20 controles de 
segurança desenvolvida pelo Center for Internet Security (CIS). 
Observe alguns exemplos de controles de segurança! 
A. Controle de acesso 
✓ Todo sistema que gerencia dados sensíveis deve ter mecanismos de autenticação, 
autorização e criptografia, limitando o acesso ao sistema e seus dados apenas a pessoas 
autorizadas. Isso é mandatório. 
B. Monitoramento 
✓ Todo sistema deve ter implementado mecanismos de armazenamento de log para seu 
monitoramento, permitindo assim sua análise e detecção de eventos suspeitos de exploração 
de possíveis vulnerabilidades. 
C. Backup e recuperação 
✓ Mecanismos de backup e recuperação devem ser implementados para garantir 
disponibilidade e integridade das informações críticas dos sistemas. 
D. Controle de segurança de infraestrutura 
✓ Todo sistema deve utilizar firewalls e mecanismos de detecção de intrusões de rede, proteção 
contra malwares e ameaças externas. 
Planejamento de resposta a incidentes 
Parte fundamental da gestão de segurança da informação, o planejamento de resposta a incidentes 
apresenta o plano de ação para tratar incidentes de segurança, caso ocorram. Tem como objetivo minimizar 
os danos causados pelo incidente, restaurar o pleno funcionamento dos sistemas afetados o mais rápido 
Desenvolvimento de Software Seguro 
Marcio Quirino - 70 
 
possível, além de investigar a causa raiz que permitiu que o incidente ocorresse, identificando solução e 
melhorias nos processos afetados para garantir que o incidente não ocorra novamente no futuro. 
As principais normas que regem o tema de resposta a incidentes incluem: 
1. ISSO/IEC 279035 
✓ Information Technology – Security Techniques – Information Security Incident Management 
2. NIST SP 800-61r2 
✓ Computer Security Incident Handling Guide 
3. SANS Institute 
✓ Incident handling Step-by-Step Guide 
Todas as normas determinam um conjunto de técnicas e planos para o a gestão efetiva de incidentes 
para as empresas. Mas todas têm em comum um conjunto de ações que devem ser contempladas em seus 
planos. Confira! 
A. Notificação e comunicação 
✓ Procedimento para determinar quais pessoas e áreas devem ser notificadas e comunicadas 
na ocorrência de um incidente, e como essa comunicação deve ser realizada para as partes 
interessadas (funcionários, clientes, reguladores etc.). 
B. Identificação e isolamento 
✓ Procedimento para que seja realizada a identificação dos sistemas afetados pelo incidente e 
o pleno isolamento destes para que outros sistemas não sejam afetados, com o objetivo de 
limitar o impacto do incidente. 
C. Recuperação de desastres 
✓ Procedimento para restaurar as operações normais do negócio alinhado a procedimento 
coleta, análise e preservação de evidências do incidente para ações de prevenção futura. 
4. Conformidade e governança 
Práticas em segurança da informação 
Conceitos de conformidade e governança 
Conheça agora os conceitos fundamentais de segurança da informação! 
A. Conformidade 
✓ Refere-se ao cumprimento das leis, regulamentos e padrões estabelecidos com o objetivo de 
garantir a segurança dos dados e informações. 
B. Governança 
✓ Trata do conjunto de processos, políticas, normas e diretrizes que devem ser utilizados para 
gerenciar e controlar a segurança da informação de uma organização. 
Esses conceitos são complementares, e para sua adequada implementação são necessários: 
• Estabelecimento de processos claros e bem definidos 
• Definição de papéis e responsabilidades 
• Plena comunicação dentro da organização 
Conformidade e governança possuem normas que indicam quais são os mecanismos e como deve 
ser feita a implementação nas empresas, tendo como referência a norma ISO/IEC 27001 – Sistema de 
gestão de segurança da informação e a ISO/IEC 27002 – Segurança da informação, cibersegurança e 
proteção de privacidade – Controles de segurança da informação, COBIT (Control Objectives for Information 
and Related Technology), ISO 38500 – Governança de TI e ITIL (Information Technology Infrastructure 
Library). Adicionalmente temos a Lei Geral de Proteção de Dados brasileira, que deve ser observada e 
atendida em sua plenitude. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 71 
 
A análise e os métodos de conformidade aplicáveis em cada empresa devem levar em consideração 
o contexto de negócio que ela está inserida. Uma empresa que atua no mercado financeiro terá um conjunto 
de regulação a ser atendido, diferente de uma empresa que atua na indústria de óleo e gás, que terá outro 
conjunto de regulação. Algumas regras serão comuns a todos os contextos de negócio e certos mecanismos 
serão comuns a todos. Observe alguns exemplos de mecanismos de conformidade!57 
Família ISO 27000 ............................................................................................................................... 57 
ISO/IEC 15288 ..................................................................................................................................... 58 
ISO/IEC 16085 ..................................................................................................................................... 58 
ISO/IEC 20004 ..................................................................................................................................... 58 
ISO/IEC 23643 ..................................................................................................................................... 58 
Considerações finais ................................................................................................................................ 58 
Explore + .................................................................................................................................................. 59 
Referências .............................................................................................................................................. 59 
Desenvolvimento de Software Seguro 
Marcio Quirino - 4 
 
Emprego DevSecOps no Ciclo de Vida do Software .......................................................................... 60 
Introdução ................................................................................................................................................ 60 
1. Segurança no ciclo de vida do software ................................................................................ 60 
Segurança: Modelo tradicional x DevOps ................................................................................................ 60 
Ciclo de vida de software ..................................................................................................................... 60 
Segurança no modelo tradicional de desenvolvimento de software ..................................................... 61 
Propósito e benefícios do DevSecOps ..................................................................................................... 62 
Propósito de DevSecOps ..................................................................................................................... 62 
Benefícios de DevSecOps.................................................................................................................... 62 
2. Automação e orquestração .................................................................................................... 63 
Processo de automação e orquestração .................................................................................................. 63 
A importância dos conceitos de automação e orquestração ................................................................ 63 
Automação............................................................................................................................. 64 
Orquestração ......................................................................................................................... 64 
Benefícios .............................................................................................................................. 64 
CI/CD e DevSecOps ................................................................................................................................ 65 
Continuous integration (CI)................................................................................................................... 65 
Continuous delivery (CD) ..................................................................................................................... 65 
CI/CD e DevSecOps............................................................................................................................. 65 
Scripts e estruturas de testes ................................................................................................................... 66 
Scripts .................................................................................................................................................. 66 
Estrutura de testes ............................................................................................................................... 66 
3. Modelagem de Ameaças, Controles e Resposta a Incidentes ............................................. 67 
Conceitos de modelagem de ameaças .................................................................................................... 67 
Modelagem de ameaças ...................................................................................................................... 67 
Controles de segurança e resposta a incidentes...................................................................................... 69 
Controles de seguranças...................................................................................................................... 69 
Planejamento de resposta a incidentes ................................................................................................ 69 
4. Conformidade e governança .................................................................................................. 70 
Práticas em segurança da informação ..................................................................................................... 70 
Conceitos de conformidade e governança ........................................................................................... 70 
Normas e diretrizes para segurança da informação ................................................................................. 71 
Regulamentos e padrões de segurança ............................................................................................... 71 
Auditoria de segurança: monitorando a proteção dos sistemas ............................................................... 73 
Conceitos de auditoria e monitoramento .............................................................................................. 73 
Considerações finais ................................................................................................................................ 73 
Explore + .................................................................................................................................................. 74 
Referências .............................................................................................................................................. 74 
Desenvolvimento de Software Seguro 
Marcio Quirino - 5 
 
Desenvolvimento de Software Seguro 
Princípios de Software Seguro 
Propósito 
Com a popularidade de áreas como a ciência de dados, aprendizado de máquina, Big Data e 
inteligência de negócios, houve um aumento significativo de garantir a segurança dos dados, afinal de 
contas, eles são a matéria-prima para essas áreas. Nesse sentido, é importante conhecer os vários aspectos 
que devem estar presentes em um software seguro, pois é um assunto extremamente atual e muito 
valorizado no mercado de trabalho. 
Objetivos 
1. Reconhecer a relação entre os princípios de segurança e o software seguro. 
2. Identificar os princípios de design seguro de software. 
3. Reconhecer os elementos da cadeia de suprimentos. 
Introdução 
Cada vez mais, geramos e consumimos dados. O simples ato de fazer uma compra, podendo ser 
on-line ou em uma loja, já produz uma grande quantidade de dados que podem revelar informações sobre 
nossas preferências e que podem ser explorados por profissionais de vendas para incentivar o aumento do 
consumo personalizado. Em outras situações, os dados podem trazer informações importantes sobre a 
situação de empresas que podem beneficiar algumas pessoas que tenham acesso a eles e prejudicar muitas 
outras. 
Então, não há dúvidas de1. PCI DSS 
✓ Padrão de segurança de dados do setor de cartões de pagamento. É um padrão que se aplica 
a empresas que vão ter algum processo de negócio de pagamento por cartões de crédito 
e/ou débito. Ele define os requisitos de segurança que as empresas devem seguir ao 
processar, armazenar ou transmitir dados de cartão de pagamento. 
2. SOC 2 
✓ Service Organization Control 2 é um padrão de segurança que define as práticas 
recomendadas de segurança da informação para empresas que proveem serviços de 
computação em nuvem para outras empresas. 
A governança apresenta também diversos mecanismos que devem ser considerados para sua 
implementação com o objetivo de garantir efetividade, eficiência e segurança das operações. Vejamos 
alguns dos principais mecanismos de governança! 
1. Gerenciamento de risco 
✓ Identificação, avaliação e tratamento dos riscos que podem afetar a empresa, levando-se em 
consideração fatores, como: probabilidade, impacto, vulnerabilidade e ameaças. 
2. Controles internos 
✓ Implementação de controles internos para garantir a integridade das operações, prevenção 
de fraudes e erros, proteção de ativos e cumprimento de regulamentações. 
3. Compliance 
✓ Adoção de um programa de compliance que permita a empresa cumprir com as leis, 
regulamentações e políticas internas. 
4. Responsabilidade corporativa 
✓ Promoção de uma cultura de responsabilidade corporativa, que envolve o comprometimento 
com a ética, integridade e transparência nos negócios. 
Normas e diretrizes para segurança da informação 
Regulamentos e padrões de segurança 
Durante todo o desenvolvimento do conteúdo, citamos diversos regulamentos e padrões que ajudam 
empresas a se prepararem para lidar com riscos e ameaças de segurança. 
Regulamentos e padrões de segurança são documentos estabelecidos por governos e organizações 
com o objetivo de definir requisitos e diretrizes de segurança que as empresas devem seguir, fornecendo 
um conjunto de regras, normas técnicas e práticas recomendadas para garantir que as empresas 
implementem medidas de segurança adequadas para proteger operações, sistemas e dados. 
É essencial lembrar que diferentes contextos de negócio em uma empresa estão sujeitos a 
regulamentos e padrões específicos. Por esse motivo, é crucial ter processos de negócio claramente 
definidos. A partir dessa definição, é possível construir ações para mitigar riscos de segurança da 
informação. 
A vantagem de se aplicar os padrões de segurança é que as empresas podem implementar 
um conjunto de práticas e técnicas que são amplamente difundidas e reconhecidas pela indústria 
como eficazes nos temas que abordam. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 72 
 
Além disso, implementando metodologias, mecanismos e práticas determinadas nos padrões de 
segurança garante-se que os processos de negócio e sistemas da empresa estão aderentes à prática de 
mercado, o que gera maior segurança e confiabilidade das empresas com seus clientes. 
Confira aqui um breve resumo das principais normas e regulações que são amplamente conhecidas 
pelo mercado: 
1. ISO 27001: 
✓ Norma que define os requisitos para estabelecer, implementar, manter e melhorar continuamente um 
sistema de gestão de segurança da informação (SGSI). 
2. NIST SP 800-53: 
✓ Norma, publicada pelo National Institute of Standards and Technology (NIST), que fornece um conjunto 
abrangente de controles de segurança da informação para as organizações dos EUA. 
3. GDPR: 
✓ Regulamento Geral de Proteção de Dados da União Europeia, o qual define as regras para a proteção 
de dados pessoais dos cidadãos da UE. 
4. LGPD: 
✓ Lei Geral de Proteção de Dados, lei brasileira que estabelece as regras para coleta, armazenamento, 
tratamento e compartilhamento dos dados pessoais de indivíduos. 
5. PCI DSS: 
✓ Padrão de Segurança de Dados do Setor de Pagamento, que é um conjunto de requisitos de segurança 
para empresas que processam transações com cartões de crédito. 
6. HIPAA: 
✓ Lei de Portabilidade e Responsabilidade do Seguro Saúde, que é um conjunto de normas de segurança 
da informação para a proteção de dados de saúde nos Estados Unidos. 
7. SOX: 
✓ Lei Sarbanes-Oxley, lei federal dos EUA que estabelece requisitos para a contabilidade e a divulgação 
de informações financeiras. 
8. COBIT: 
✓ Controle de Objetivos para Informação e Tecnologia Relacionada, que é um modelo de governança de 
TI usado para ajudar as empresas a gerenciar e proteger seus recursos de informação. 
9. ITIL: 
✓ Biblioteca de Infraestrutura de Tecnologia da Informação (ITIL) é um conjunto de práticas 
recomendadas para a gestão de serviços de TI. 
10. ISO 22301: 
✓ Norma que define os requisitos para um Sistema de Gestão de Continuidade de Negócios (SGCN) 
para ajudar as empresas a se prepararem para lidar com interrupções e manter as operações em caso 
de desastres. 
11. ISO 27002: 
✓ Estabelece um conjunto de controles de segurança da informação que podem ser implementados por 
organizações de qualquer porte ou setor. 
12. ISO 27017: 
✓ Fornece diretrizes específicas para a segurança da informação em nuvem. 
13. ISO 27018: 
✓ Estabelece um conjunto de diretrizes para proteção de informações pessoais em ambientes de 
computação em nuvem pública. 
14. ISO 27701: 
✓ Trata dos requisitos e orientações para um sistema de gestão de privacidade da informação (SGPI). 
15. ISO 22301: 
✓ Estabelece requisitos para um sistema de gestão de continuidade de negócios (SGCN). 
Desenvolvimento de Software Seguro 
Marcio Quirino - 73 
 
16. ISO 20000: 
✓ Estabelece requisitos para um sistema de gestão de serviços de TI (SGSTI). 
17. ISA/IEC 62443: 
✓ Norma que é usada para proteger sistemas de controle industrial contra ameaças cibernéticas. 
Auditoria de segurança: monitorando a proteção dos sistemas 
Conceitos de auditoria e monitoramento 
Acompanhe a definição desses conceitos! 
A. Auditoria 
✓ É um processo de avaliação das atividades e processos de uma organização ou sistema para 
garantir a conformidade com normas e procedimentos estabelecidos, bem como identificar 
pontos de melhoria e riscos potenciais. 
B. Monitoramento 
✓ É uma atividade contínua e sistemática que tem como objetivo avaliar o desempenho da 
empresa em relação a suas metas e objetivos, bem como verificar se políticas, processos e 
controles estão implementados e operando de maneira adequada. 
Tanto auditoria quanto o monitoramento podem ser realizados de forma interna ou externa, sendo 
executadas por profissionais especializados capazes de fazer uma avaliação independente e imparcial da 
eficácia e eficiência dos controles e procedimentos internos da empresa. Em ambos os casos os resultados 
são documentos e relatórios que devem apontar os pontos de aderência e os pontos de falha de adoção de 
normas e procedimentos a serem utilizados para melhorar a conformidade, a governança e a gestão de 
riscos das empresas. 
Existem diferentes modelos de auditoria e monitoramento que as empresas podem adotar, como: 
1. Auditoria interna: Realizada por uma equipe interna da empresa para avaliar o cumprimento de 
políticas, normas e procedimentos de segurança. 
2. Auditoria externa: Realizada por uma empresa terceirizada ou por um auditor independente 
para avaliar a eficácia dos controles de segurança da empresa. 
3. Monitoramento de eventos de segurança: Consiste na coleta e análise de informações de logs 
de sistemas, redes e aplicativos para identificar atividades suspeitas e possíveis violações de 
segurança. 
4. Monitoramento de rede: Consiste no monitoramento constante de tráfego de rede para 
identificar possíveis ameaças à segurança. 
5. Testes de penetração: Consiste na simulação de ataques cibernéticos para avaliar a segurança 
da infraestrutura de TI da empresa. 
6. Avaliação de conformidade: Consiste na avaliação regular da conformidade da empresa com 
padrões e normas de segurança, como PCI-DSS,ISO 27001, entre outros. 
7. Auditoria de privacidade: Consiste na avaliação da conformidade da empresa com leis e 
regulamentos de privacidade, como GDPR e LGPD. 
Considerações finais 
Chegando aqui, certamente, você teve uma boa base para determinar o que é DevSecOps e 
entender o porquê de essa prática de engenharia de software ser tão importante para acelerar a entrega de 
um software cada vez mais seguro. 
Além disso, compreendeu que riscos e ameaças não são apenas do ponto de vista técnico, mas 
também do ponto de vista pessoal. Entendeu que existem diversas normas e padrões a serem adotados 
para garantir que os riscos de ameaças e vulnerabilidades sejam mitigados, diminuindo assim o dano 
potencial desses riscos. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 74 
 
Neste conteúdo, foi possível conferir a importância de se ter os processos de negócio que sua 
empresa atua bem mapeados, a fim de determinar de maneira clara quais regulações, normas e padrões 
devem ser implementados, juntamente com processos e governança claros para garantir que essas normas 
sejam devidamente atendidas. 
Lembre-se ainda que auditoria e monitoramento são benéficos ao negócio, pois evidenciam de 
maneira proativa possíveis pontos de vulnerabilidade e melhoria. 
Agora, você é mais do que capaz de identificar como o DevSecOps pode potencializar a segurança 
dos seus produtos de software e entender como ter uma cultura com foco em segurança pode ajudar a 
alavancar ainda mais o potencial do seu negócio. Esperamos que tenha tido um bom proveito na aplicação 
desse conhecimento! 
Explore + 
Confira as indicações de leitura que separamos especialmente para você! 
DevSecOps: A Comprehensive Guide, artigo disponível no portal Owasp. Vale conferir! 
DevSecOps: Shifting Security Left with Automation, artigo disponível no portal Red Hat. Imperdível! 
Referências 
ADKINS, H. et al. Building Secure and Reliable Systems: Best Practices for Designing, Implementing, 
and Maintaining Systems. 1. ed. Sebastopol: O'Reilly Media, 2020. 
BRASIL. Lei nº 13.709, de 14 de agosto de 2018. Lei Geral de Proteção de Dados Pessoais (LGPD). 
Brasília, 2018. 
CRISPIN, L.; GREGORY, J. Agile Testing: A Practical Guide for Testers and Agile Teams. 1. ed. 
Boston: Addison-Wesley Professional, 2009. 
HUMBLE, J.; FARLEY, D. Continuous Delivery: Reliable Software Releases through Build, Test, and 
Deployment Automation. 1. ed. Boston: Addison-Wesley Professional, 2011. 
ISO. ISO/IEC 27001: Information security management. Consultado na internet em: 25 maio 2023. 
ISO. ISO/IEC 27002: Information Technology - Security Techniques - Code of Practice for Information 
Security Controls. Consultado na internet em: 25 maio 2023. 
KIM, G. et al. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in 
Technology Organizations. 1. ed. Portland: IT Revolution Press, 2016. 
MICROSOFT. Microsoft Security Development Lifecycle (SDL). Consultado na internet em: 25 maio 
2023. 
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST. Cybersecurity Framework. 
Gaithersburg: NIST, 2018. 
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST. Special Publication 800-53: 
Security and Privacy Controls for Information Systems and Organizations. Gaithersburg: NIST, 2020. 
OPEN WEB APPLICATION SECURITY PROJECT. OWASP. Dread. Consultado na internet em: 25 
maio 2023. 
PAYMENT CARD INDUSTRY DATA SECURITY STANDARD. PCI DSS. PCI Security Standards 
Council. Consultado na internet em: 25 maio 2023. 
SHOSTACK, A. Threat Modeling: Designing for Security. 1. ed. Indianapolis: Wiley Publishing, 2014.que os dados são valiosos. E o que fazemos com coisas valiosas? 
Protegemos para que sejam utilizadas apenas quando for necessário e para alcançarmos objetivos 
específicos. Nesse sentido, a segurança da informação tem um papel crucial. Mas aí vem outra questão: 
quem é que, de fato, torna operacional o gerenciamento da segurança dos dados? A resposta é: os diversos 
aplicativos de softwares. 
Então, fica bastante claro que precisamos garantir que um software tenha elementos de segurança 
que possam ser verificados, para que possa ser chamado de seguro. É exatamente esse assunto que vamos 
abordar neste estudo. Aqui, teremos a oportunidade de conhecer os diversos aspectos que relacionam 
segurança ao desenvolvimento, operação e monitoramento de software. Sem dúvidas, é uma das áreas 
mais “quentes” do momento e que exige muito estudo da nossa parte, mas que é muito valorizada no 
mercado. 
1. Princípios de segurança e o software seguro 
Aspectos essenciais entre princípios de segurança e software 
seguro 
Facilmente, reconhecemos a noção de uma situação segura ou não. Por exemplo, você deixaria um 
objeto pessoal de valor de forma que qualquer um pudesse ter fácil acesso? Obviamente, não. Então, por 
que você deixaria os dados do sistema que você opera para qualquer um ter acesso? 
Provavelmente, você tem cuidado com os dados, mas, certamente, deve conhecer muitas pessoas 
que ainda não têm cuidados básicos. É aqui que entramos com os aspectos essenciais de segurança e 
como eles se relacionam com um software seguro. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 6 
 
Basicamente, os princípios de segurança são aspectos fundamentais bem conhecidos (trataremos 
um pouco mais adiante) que são usados para projetar e implementar sistemas seguros. Portanto, um 
software seguro é um elemento lógico – normalmente, chamado de sistema – que foi projetado e 
desenvolvido para garantir proteção contra ameaças e ataques. 
Nesse sentido, precisamos entender a relação entre princípios de segurança e software seguro como 
a relação entre um projeto de arquitetura de um prédio e sua materialização que, no nosso caso, é o 
desenvolvimento de software seguro. 
Os princípios de segurança são a base estrutural para identificar possíveis ameaças e 
vulnerabilidades e projetar recursos para reduzir a exposição aos riscos. De forma resumida, o software 
seguro deve ser construído sobre os princípios de segurança. 
Os princípios de segurança fundamentais para o desenvolvimento de software seguro são: 
A. Confidencialidade 
✓ Significa que apenas pessoas autorizadas podem ter acesso aos dados. 
B. Integridade 
✓ Garante que os dados não sejam modificados ou adulterados de maneira não autorizada. 
C. Disponibilidade 
✓ Garante que os sistemas e dados estejam acessíveis a usuários autorizados sempre que 
precisam utilizá-los. 
D. Autenticação 
✓ Garante a identificação dos usuários de um sistema antes de conceder acesso a dados. 
E. Autorização 
✓ Garante que os usuários tenham as permissões necessárias para acessar dados ou sistemas 
específicos. 
Ou seja, a palavra mais repetida nos princípios de segurança foi “garantia”. E a ideia é exatamente 
esta: oferecer garantias sobre identificação, acesso e manipulação dos dados. Neste tópico, vimos a relação 
entre os princípios de segurança e um software seguro. Nos próximos, vamos explorar cada um desses 
elementos com o objetivo de criar softwares mais seguros e, portanto, menos vulneráveis a ataques. 
O essencial da confidencialidade 
Se a pessoa não tem autorização para acessar ou manipular um dado ou sistema, então deve existir 
um recurso que dê essa garantia. O nome desse recurso é confidencialidade. Ela é um dos elementos 
básicos de um software seguro, pois auxilia na proteção de dados importantes. Muitas vezes, os dados são 
classificados de duas formas: 
A. Sensíveis 
✓ Podem incluir informações pessoais como nomes, endereços, números de identidade ou 
CPF, números de cartão de crédito e registros médicos. 
B. Confidenciais 
✓ Referem-se a qualquer dado que deva ter acesso restrito. Normalmente, são associados a 
segredos comerciais, informações financeiras ou projetos de empresas e governos. 
No contexto de software seguro, conseguimos garantir a confidencialidade de medidas de segurança, 
tais como: 
1. Criptografia 
✓ Utiliza algoritmos específicos para transformar os dados em um formato ilegível que só pode 
ser decifrado usando uma chave de criptografia. 
 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 7 
 
2. Controle de acesso 
✓ Faz a limitação do acesso aos dados utilizando o princípio do menor privilégio, ou seja, o 
comportamento padrão é que os perfis dos usuários tenham acesso mínimo aos dados. 
3. Mascaramento de dados 
✓ São técnicas que trocam dados importantes por falsos. 
Se um software não consegue garantir a confidencialidade, ele está colocando todos os dados do 
sistema em risco. Isso é uma seríssima vulnerabilidade e pode trazer terríveis consequências, como roubo 
de identidade, violação de dados, perdas financeiras e usar uma identidade legítima para cometer crimes. 
A garantia da integridade 
Quando você escuta a palavra íntegro, lembra de quê? Provavelmente, de algo que não foi violado, 
ou de uma pessoa que não é corrupta. A mesma coisa se aplica para a integridade do software seguro. Ela 
é traduzida, na prática, como um conjunto de recursos capazes de evitar que os dados sofram alterações 
ou modificações sem a devida autorização. Em outras palavras, a integridade vai proteger os dados de 
qualquer modificação indevida. 
Essas modificações, quando ocorrem, são feitas através de programas mal-intencionados ou de 
ataques direcionados. Infelizmente, há situações em que o responsável pelo software facilita a vida dos 
atacantes, pois não utilizam nenhum recurso que limite o acesso aos dados, nem mesmo tem uma política 
de backup. Mas aí vem a pergunta: como garantir a integridade dos dados? 
Existem algumas ações que podemos fazer para garantir a integridade do software. Alguns exemplos 
concretos são: 
1. Assinaturas digitais 
✓ É uma técnica que valida a autenticidade e a integridade de um documento, mensagem ou 
software. Uma boa comparação é com uma assinatura manuscrita com reconhecimento em 
cartório, só que muito mais segura. 
2. Assinatura de código 
✓ É um método que utiliza uma assinatura digital em um programa, arquivo, atualização de 
software ou executável com o objetivo de garantir sua autenticidade e integridade durante a 
instalação e execução. 
3. Controle de versão 
✓ Fazem o controle das alterações de código do software no local onde eles ficam hospedados. 
Um exemplo de um repositório muito conhecido com essa finalidade é o GitHub. Esses 
repositórios possuem recursos para que os desenvolvedores identifiquem quaisquer 
modificações ou alterações. 
4. Práticas de codificação segura 
✓ Existem várias questões que devem ser tratadas em um software. Por exemplo: validação de 
entrada; tratamento de explícito de exceções; verificação de limites de memória para evitar 
ataques de estouro de buffer; controle contra ataques de injeção de SQL e controles de 
injeção de código de um modo geral. 
Tanto as assinaturas digitais como a assinatura de código nos ajudam a garantir que o software seja 
íntegro. No caso das assinaturas digitais, elas utilizam mecanismos de criptografia para verificar a identidade 
do desenvolvedor de software. Já a assinatura de código usa os certificados digitais para vincular uma 
assinatura digital a um código específico. Interessante, não é? 
Atualmente, está cada vez mais comum utilizarmos esses recursos. Isso nos ajuda a ganhar tempo, 
economizar recursos financeiros e, principalmente, aumentar a integridade dos dados e do software. No 
nosso próximo tópico, vamos abordar o aspecto de disponibilidade. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 8A importância da disponibilidade 
Você já ouviu falar na expressão 24 por 7? Ela significa trabalhar 24 horas por dia durante os sete 
dias da semana. Mas, isso realmente funciona na prática? Bem, todo software precisa ter um plano de 
manutenção planejada, caso contrário, vai estar exposto a uma manutenção corretiva que é uma situação 
muito mais complicada. Por isso mesmo, precisamos estabelecer diretrizes que reduzam as chances de que 
situações desastrosas ocorram, como, por exemplo, as regras para acessar dados. 
As regras para acessar os dados de um software seguro precisam ser bem estabelecidas. Vamos 
ver algumas dessas regras. 
1. Quais os dados que o software dá acesso. 
2. Quais são os perfis que podem acessar os dados. 
3. Quais são as ações associadas a cada perfil. 
4. Quais são os horários que os dados podem ser acessados. 
5. Quais são os horários que os dados podem ser modificados. 
6. Qual a política de backup para garantir que – na eventualidade de um desastre – os dados 
estejam disponíveis novamente. 
É um fato muito importante ter consciência de que a indisponibilidade de um software pode causar 
sérios danos financeiros, de reputação, queda de produtividade e, em alguns casos, a exposição do risco 
da vida das pessoas. 
Exemplo 
Imagine os problemas causados quando os sistemas de controle de trânsito falham. Agora – no caso de uma 
situação mais extrema ainda –, quais são as consequências quando um sistema que leva oxigênio para mineradores 
de regiões subterrâneas falha? Ou seja, são situações que exigem cuidados extremos. 
Agora, vamos pensar um pouco sobre as causas que podem levar um sistema à indisponibilidade. 
Entre elas estão: 
• Falhas de hardware; 
• Problemas de conectividade de rede; 
• Bugs de software; 
• Ataques de negação de serviço (DoS). 
Em especial, o ataque DoS é bastante sofisticado e pode ser usado em dois níveis. No primeiro nível, 
os invasores sobrecarregam o sistema com um excesso de solicitações, tornando-o inacessível para 
usuários legítimos. Enquanto os técnicos ficam focados tentando corrigir esse problema, os invasores 
utilizam outros tipos de ataques para roubar ou adulterar dados. Então, nesse momento, já deve estar bem 
claro para nós a importância de garantir a disponibilidade de um software. Mas, o que podemos fazer para 
garantir essa disponibilidade? 
Para garantir a disponibilidade do software, as pessoas e organizações de um modo geral – sejam 
públicas ou privadas – devem implementar medidas, tais como: 
1. Redundância de dados. 
2. Versões mínimas de um software para garantir o funcionamento das atividades mais 
importantes. 
3. Planos de recuperação de desastres. 
4. Balanceamento de carga para evitar pontos únicos de falha. 
5. Realizar testes regulares. 
6. Fazer o monitoramento da operação do sistema por meio da análise dos dados de log. 
7. Ter um plano de manutenção de sistemas bem definido. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 9 
 
8. Realizar manutenções de software com regularidade. 
Portanto, existem caminhos que podemos tomar para garantir a disponibilidade de um software. A 
questão é realizarmos um equilíbrio entre benefícios e custos. Se a disponibilidade do software é 
fundamental, então, devemos investir nos métodos que deem essa garantia. 
A seguir, vamos estudar mais dois aspectos importantes para ter um software seguro: autenticação 
e autorização. 
A importância da autenticação e autorização 
Os conceitos de autenticação e autorização são diferentes, mas estão fortemente relacionados. A 
autenticação é usada para determinar a identidade do usuário. Ou seja, ela trata do processo de verificação 
de um usuário ou sistema que tenta acessar um recurso ou um conjunto de dados. Existem diversas técnicas 
para isso. Algumas delas são: 
• Uma combinação de nome de usuário (login) e senha. 
• Autenticação biométrica que pode usar a digital, por exemplo. 
• Métodos de autenticação multifator: essas são mais elaboradas. Por exemplo, o usuário entra 
com login e senha para acessar o e-mail, mas precisa passar por uma etapa de validação de 
um número de celular pré-cadastrado para verificar se, de fato, a identidade é dele mesmo. 
Portanto, o objetivo da autenticação é bem simples: garantir que apenas usuários legítimos possam 
acessar o sistema e seus recursos. 
No caso da autorização, o objetivo é determinar quais são os recursos ou funções que um usuário 
legítimo pode acessar dentro de um sistema. 
Um software seguro utiliza a autorização associada ao perfil do cliente ao invés do indivíduo 
em si, pois é mais fácil gerenciar direitos e impor limites. 
Essas duas características – autenticação e autorização – são dois elementos que devem compor 
um sistema de software seguro, pois restringem o acesso de quem pode utilizar o sistema e trabalhar com 
os dados, além de restringirem o que o usuário pode realizar dentro do sistema. 
Dessa forma, vimos que os princípios de segurança são fundamentais para garantir que um software 
seja seguro. No próximo módulo, nós vamos estudar sobre os princípios de design seguro, ou seja, dos 
aspectos que devem fazer parte da arquitetura do software. Antes de avançar, faça os exercícios para fixar 
o conhecimento e, se for necessário, retorne para o texto para entender melhor algum conceito. 
2. Princípios de design seguro de software 
Elementos fundamentais do design de um software seguro 
Os usuários de aplicativos utilizam programas prontos para atender às suas necessidades. No 
entanto, para chegar até esses usuários, os programadores precisam garantir que as funcionalidades 
estejam funcionando corretamente e que o sistema não tenha vulnerabilidades. Essa segunda parte, em 
especial, é muito mais desafiante do que parece! 
Uma vulnerabilidade nem sempre se trata de um erro de software. Pode ser, inclusive, que ela nunca 
se manifeste. No entanto, é um risco enorme deixá-la dentro de um sistema, seja de forma proposital – que 
é uma situação muito estranha! – ou por falta de planejamento de testes. É aí que entram os elementos 
fundamentais do design de um software seguro. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 10 
 
Quando falamos sobre design de software seguro, nos referimos ao conjunto de diretrizes que os 
desenvolvedores usam para projetar e desenvolver um sistema para reduzir as vulnerabilidades. Os 
principais princípios de design de software seguro são: 
A. Privilégio mínimo 
▪ Significa que os usuários ou, ainda, os perfis dos usuários devam ter apenas os privilégios 
essenciais para realizar suas tarefas. 
B. Defesa em profundidade 
▪ Utiliza várias camadas de segurança para proteger contra diferentes tipos de ataques. Essas 
camadas incluem gerenciamento de acesso, acesso condicional, autenticação por multifator, 
gerenciamento dos privilégios pela identidade e proteção de identidade. 
C. Padrões à prova de falhas 
▪ Utiliza configurações padrões seguras que não dependem do usuário. 
D. Separação de funções 
▪ É essencial fazer a segmentação de um sistema em camadas. Sendo que cada camada tem 
um conjunto de funções. Um dos modelos mais conhecidos de arquitetura de software é o 
MVC. Mais à frente, vamos abordá-lo com mais profundidade. 
E. Security by Design 
▪ É a aplicação de boas práticas de segurança em todas as fases do ciclo de vida do 
desenvolvimento de software. 
F. Economia de mecanismo 
▪ Simplificar a configuração da arquitetura do software para reduzir o potencial de erros e 
vulnerabilidades difíceis de serem detectadas. 
G. Design aberto 
▪ Significa que a arquitetura do sistema possa ser revisada por outras pessoas do projeto. É 
uma péssima prática deixar a responsabilidade do projeto da arquitetura de um sistema para 
apenas um indivíduo. 
H. Tratamento de erros 
▪ É responsabilidade dos desenvolvedores criarem mecanismos para detectar exceções e 
tratá-las explicitamente. Os erros “raízes” – errosda execução do programa – nunca devem 
ser expostos para o usuário final, pois podem ser usados para explorar vulnerabilidades. 
Os princípios de design de software seguro são excelentes direcionadores, para que os 
desenvolvedores possam criar softwares mais confiáveis e menos vulneráveis a ataques. Nos próximos 
tópicos, vamos explorar com mais detalhes esses princípios. 
Fundamentos do privilégio mínimo de um software seguro 
Como podemos desenvolver um software capaz de reduzir os danos que um invasor pode causar ao 
se passar por um usuário legítimo? Bem, uma das formas de conseguir esse resultado é conceder privilégios 
mínimos para cada perfil. 
O princípio do privilégio mínimo nos orienta a fornecer apenas o nível essencial para que o usuário 
realize o trabalho dele. O objetivo aqui é reduzir o risco de danos que um invasor – ser humano ou sistema 
– possa causar. Mas há outro benefício também no caso de o sistema ser comprometido: ser capaz de medir 
os danos. 
O ideal é sempre agir com proatividade, mas nem sempre isso é possível. Às vezes, só 
conseguimos atuar de forma reativa, mas, até mesmo para isso, é importante ter um caminho a 
seguir. Como sabemos de antemão quais são os privilégios de um determinado perfil, podemos criar 
mecanismos que bloqueiem a execução das atividades. 
O privilégio mínimo é importante para segmentar as atividades e, assim, impor restrições. Um 
exemplo disso ocorre com um processo de servidor da web que pode apenas fazer leitura de arquivos, ou 
Desenvolvimento de Software Seguro 
Marcio Quirino - 11 
 
seja, não tem acesso de gravação. Na prática, isso minimiza o risco de modificações não autorizadas. Mas, 
como podemos implementar o privilégio mínimo em um sistema? 
Para implementarmos o privilégio mínimo em um sistema, precisamos ter um mapa com todas as 
funções e responsabilidades associadas a cada perfil de usuário. Ou seja, precisamos saber: 
• Quais são os processos envolvidos? 
• Quais os recursos e funções utilizados nesses processos? 
A ideia é atender à necessidade do usuário por meio de um perfil e, a partir disso, traçar os possíveis 
caminhos que ele pode seguir. Assim, podemos fazer um monitoramento da operação do sistema e observar 
se há comportamentos inadequados ou privilégios que não condizem com um determinado perfil. 
Resumindo 
O princípio do privilégio mínimo é mais um aspecto de design de software seguro, pois nos auxilia a reduzir 
riscos de danos e, no caso de uma invasão, nos orienta a como agir para interromper o ataque. No próximo tópico, 
vamos conhecer um pouco mais sobre dois princípios de design de software seguro: defesa em profundidade e padrões 
à prova de falhas. 
Defesa em profundidade e padrões à prova de falhas 
Esses dois princípios de projeto aumentam a segurança de um software. A ideia básica é 
trabalharmos com camadas semelhantes à criação de trincheiras para dificultar o avanço de um invasor. A 
seguir, apresentamos os dois princípios com mais detalhes. 
Defesa em profundidade 
É uma estratégia de segurança que implementa várias camadas de controles de segurança e 
também contramedidas para reduzir danos. Essas camadas podem incluir uma visão mais externa do 
sistema – a infraestrutura de rede – como também o servidor, a aplicação em si e os dados que são 
acessados pelo sistema. Abaixo, apresentamos uma figura que nos dá uma ideia da defesa em 
profundidade. 
 
Defesa em profundidade. 
Os padrões à prova de falhas 
Tratam das diversas formas para prevenir ou, pelo menos, reduzir o impacto de possíveis falhas ou 
erros. Entre essas técnicas, estão: 
• Mecanismos para detecção de erros. 
• Mecanismos para correção de erros. 
• Sistemas de backup e recuperação de dados. 
• Redundância de sistemas. 
• Técnicas de tolerância a falhas. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 12 
 
Juntos, os dois princípios dificultam a vida dos possíveis invasores. Por outro lado, precisamos ter 
cuidado para não inserir vulnerabilidades no sistema, pois, agora, ele está ficando mais complexo. 
Separação de funções e Security by Design 
Novamente, voltamos para a segmentação de funções. Agora, no entanto, utilizamos os princípios 
de separação de funções e segurança por design. Vamos ver cada um deles com mais detalhes. 
1. Separação de funções 
✓ Trata da divisão das principais tarefas e responsabilidades entre diferentes indivíduos ou 
equipes para reduzir as chances de que um invasor possa usar a identidade de um usuário 
legítimo e ter controle ou acesso a informações confidenciais. Portanto, a ideia é diminuir o 
poder dos perfis do usuário dentro do sistema. 
2. Security by Design 
✓ Significa aplicar as boas práticas de segurança no sistema ao longo de todo o ciclo de 
desenvolvimento. 
É importante notarmos que esses princípios não fazem parte do processo “natural” de 
desenvolvimento. Os desenvolvedores precisam ser orientados a trabalhar dessa forma desde o começo do 
projeto e ser conscientizados sobre a importância desses aspectos de segurança. Por isso mesmo, é 
importante investir tanto na formação técnica como na explicação para os gestores sobre as implicações de 
negócio associados a um sistema seguro. 
Economia de mecanismo, design aberto e defesa contra erros 
Não há dúvidas de que a segurança é um aspecto essencial para um software. O problema disso é 
que o efeito colateral de implementarmos esses princípios no software é aumentarmos as possibilidades de 
que existam vulnerabilidades. Parece contraditório, não é mesmo? Mas basta pensarmos que estamos 
acrescentando elementos que terão de se comunicar por meio de protocolos e que ninguém terá 
conhecimento total do sistema. Por isso, precisamos fazer um bom planejamento antes de iniciar uma 
implementação. 
Agora, vamos analisar três princípios que auxiliam a manter o software mais seguro, ao mesmo 
tempo que tentam reduzir as vulnerabilidades devido à complexidade: 
1. Economia de mecanismo 
▪ São práticas de implementação que desencorajam ataques ou acessos não autorizados. Por 
exemplo, quando fazemos a implementação de controles de acesso, mecanismos de 
auditoria e monitoramento e criptografia, estamos aumentando as dificuldades de um invasor. 
2. O design aberto 
▪ O objetivo aqui é oferecer transparência do código-fonte e, claro, da documentação para 
outros desenvolvedores. Em especial, para os que têm perfil de desenvolvimento de 
segurança com o objetivo de revisar e identificar possíveis vulnerabilidades no sistema. 
3. A defesa contra erros 
▪ Trata-se de mapear o funcionamento do sistema e identificar possíveis falhas. Depois disso, 
precisamos tratar essas exceções explicitamente e jamais exibir uma mensagem de erro do 
sistema para o usuário final. Também faz parte desse princípio a utilização de sistemas de 
backup e recuperação, redundância e princípios de projeto tolerantes a falhas. 
Todos os princípios que vimos auxiliam a desenvolver sistemas mais seguros, pois fazem parte da 
arquitetura do software, ou seja, estão ligados ao projeto e, por isso mesmo, precisam ser bem 
documentados e testados, pois serão a base para a implementação de outros programas. 
No nosso próximo módulo, vamos estudar sobre a cadeia de suprimentos de um software. Ou seja, 
vamos estudar sobre o impacto dos componentes de terceiros para a implementação de um software seguro. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 13 
 
3. Avaliação da cadeia de suprimentos 
Elementos da cadeia de suprimentos de um software seguro 
A expressão “cadeia de suprimentos” é bastante utilizada em problemas de logística. Normalmente, 
ela está associada aos diversos processos que vão desde a extração da matéria-prima até a entrega de um 
produto para o consumidor final. Mas, o que isso tem a ver com software seguro? 
Bem, no contexto de software seguro, a ideia é parecida. Precisamos lembrar que um software é 
composto por bibliotecas e componentes,além de usar ferramentas de desenvolvimento que são fornecidas 
por terceiros, ou seja, é uma cadeia de suprimentos tecnológica. Cada elemento dessa cadeia pode 
influenciar em relação a alguma vulnerabilidade de um sistema. É por isso que precisamos ter políticas de 
segurança que nos auxiliem a fazer avaliação desses itens que, também, incluem componentes de 
hardware. 
Existem vários casos conhecidos de componentes com seríssimas vulnerabilidades. Alguns 
exemplos são: 
1. Heartbleed 
✓ Trata-se de uma vulnerabilidade na biblioteca de criptografia OpenSSL. Ela facilitava a vida 
dos invasores de modo que pudessem ter acesso a dados confidenciais da memória de um 
servidor da web. 
2. Spectre e Meltdown 
✓ São vulnerabilidades que tiveram grande impacto na maioria dos processadores modernos. 
Elas, simplesmente, possibilitavam que um invasor acessasse dados confidenciais da 
memória de um sistema. 
3. Violação de dados da Equifax 
✓ Essa vulnerabilidade, em 2017, causou um prejuízo de, aproximadamente, um bilhão e meio 
de dólares para a empresa Equifax. A empresa sofreu uma violação de dados que possibilitou 
que os invasores fizessem a exposição de informações pessoais de milhões de clientes. E 
qual foi a causa desse problema? Devido a uma vulnerabilidade na estrutura do aplicativo 
web Apache Struts. 
4. Spyware Pegasus 
✓ É um malware desenvolvido pela empresa israelense NSO Group. Ele age de várias formas, 
mas, essencialmente, o objetivo é explorar vulnerabilidades em vários aplicativos de software 
para obter acesso ao dispositivo de um alvo e roubar dados confidenciais. 
Esses são apenas alguns exemplos das muitas vulnerabilidades de softwares, mas, infelizmente, é 
claro que existem muitos outros componentes e recursos de terceiros que podem tornar um software 
inseguro. 
Então, o que devo fazer para proteger um sistema de vulnerabilidades, de um modo geral? 
Investir em treinamento e estudo direcionado. 
Um exemplo concreto de treinamento e estudo direcionado é visitar os seguintes portais: 
A. OWASP Top Ten 
✓ Contém as dez principais vulnerabilidades de aplicações web. Além disso, ele apresenta 
exemplo de como essas vulnerabilidades se manifestam na prática e o que devemos fazer 
para combatê-las. 
B. National Vulnerability Database 
✓ Apresenta uma base muito extensa de vulnerabilidades de software conhecidas e o como nos 
proteger em relação a elas. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 14 
 
É importante ressaltar que, no mundo corporativo, esse tipo de estudo deve fazer parte de uma 
política de segurança formal. Nessa política, deve haver a descrição de procedimentos de estudos, 
monitoramento e testes que nos auxiliem a tratar com quaisquer riscos a que um sistema esteja exposto. 
Vulnerabilidades dos componentes de um software 
Podemos encontrar diversos tipos de vulnerabilidades nos componentes de um software. Como 
muitas dessas vulnerabilidades são bem conhecidas e documentadas, se elas não forem tratadas 
rapidamente, podem ser exploradas por atacantes para roubar dados e violar a segurança dos sistemas. A 
seguir, apresentamos algumas das vulnerabilidades mais comuns. 
A. Componentes desatualizados 
✓ É bastante comum que os fabricantes descubram vulnerabilidades nos componentes deles e 
disponibilizem correções. No entanto, é obrigação do usuário fazer a atualização. Aqui, cabe, 
ainda, uma ressalva: sempre faça atualizações apenas de fontes oficiais, pois um atacante 
pode tentar enganar um usuário com uma versão atualizada falsa. 
B. Configuração inadequada 
✓ Sistemas mal configurados ou usados com configuração padrão podem facilitar ataques de 
modo que um invasor obtenha acesso não autorizado. 
C. Injeção de código 
✓ Trata-se de um ataque no qual o invasor insere um trecho de código malicioso para ser 
executado por um programa legítimo. A vulnerabilidade mais conhecida desse tipo é a injeção 
de SQL que pode permitir que um ataque acesse informações ou assuma o controle do 
sistema. 
D. Falhas de autenticação 
✓ Se a autenticação de um componente aceitar senhas fracas ou criar alternativas de 
autenticação, novamente essa vulnerabilidade pode ser explorada para permitir que um 
atacante tenha acesso não autorizado. 
E. Quebra de autorização 
✓ Se o componente de software não validar as permissões de acesso de um usuário, isso pode 
ser explorado para permitir que um atacante cause danos no sistema ou nos dados. 
F. Fragilidade de criptografia 
✓ Ocorre quando um componente não faz a criptografia dos dados. Nesse caso, se um atacante 
tiver acesso a eles, poderá manipulá-los com facilidade. 
G. Não tratar a entrada de dados 
✓ Se os componentes não criticarem os dados de entrada, então o sistema estará exposto a 
diversos tipos de ataques, como a injeção de código SQL e de outros tipos de dados que 
podem gerar interrupções do funcionamento do sistema. 
As maneiras que temos para reduzir as ocorrências dessas vulnerabilidades são: 
• Implementar práticas de segurança durante todo o processo de desenvolvimento do software. 
• Realizar testes de segurança com regularidade. 
• Fazer atualizações de fontes seguras. 
• Realizar configurações seguras. 
Além disso, manter-se atualizado sobre notícias relacionadas à segurança nos fóruns na internet. 
Avaliação e gerenciamento dos riscos 
Como vimos, as vulnerabilidades podem ser a porta de entrada para ataques muito sérios. Por isso 
mesmo, precisamos ter um bom conhecimento sobre elas para identificá-las e, sempre que possível, eliminá-
las. Mas, nem sempre temos a possibilidade de agir da forma ideal. Então, é fundamental que tenhamos um 
Desenvolvimento de Software Seguro 
Marcio Quirino - 15 
 
plano que nos permita fazer a avaliação e o gerenciamento de riscos relacionados aos programas que 
utilizamos. 
Para conseguirmos uma identificação e redução de riscos efetivos, precisamos estabelecer 
processos que devem estar devidamente contextualizados. Por exemplo: 
1. Software desenvolvido pela própria empresa 
▪ Então é necessário aplicar as práticas seguras que envolvem, inclusive, um plano de testes. 
2. Software vem de outro fornecedor 
▪ Então precisamos conhecer quais são os planos de manutenção, correção e atualização. 
Nos dois casos, precisamos de um processo formal que envolve treinamento, muito estudo e 
realização de simulações e testes de estresse. Ou seja, tudo isso tem o objetivo de identificar riscos 
potenciais, avaliar a probabilidade da ocorrência de um problema e quais são os impactos deles. 
Em linhas gerais, podemos formalizar uma política de avaliação e gerenciamento de riscos de 
software por meio das seguintes etapas: 
1. Identificação de riscos 
✓ Devemos listar explicitamente quais são os riscos potenciais que podem afetar o software. 
Dependendo do contexto, podemos tratar de riscos associados ao desenvolvimento, 
implantação e operação de software. 
2. Análise de risco 
✓ Consiste em medirmos as probabilidades reais de um risco se tornar um problema e quais 
os impactos que esse problema pode trazer para nós, seja no contexto pessoal ou 
corporativo. 
3. Priorização de riscos 
✓ Na sequência, precisamos estabelecer uma prioridade em relação aos riscos, apesar de 
que o ideal é eliminarmos a ocorrência por meio da aplicação de técnicas seguras, sempre 
que for possível. 
4. Mitigação de riscos 
✓ Aqui é que entra a implementação de medidas para reduzir ou eliminar os riscos 
identificados. Entre as ações que podemos tomar, estão: 
o A implementação de controles de acesso. 
o Formalizar contramedidas para evitar que o risco ocorra ou minimizar seu impacto. 
5. Monitoramento e revisão de riscos 
✓ Agora, precisamos fazer uma análise periódica do sistema em operação, para estudar o 
comportamento dele e, quando for necessário, atuarmos para combater ataques. 
Em resumo, é fundamental termos processos formais da avaliação e do gerenciamento de riscosde 
software. Além disso, é muito importante atribuir níveis de responsabilidades para os indivíduos, pois, assim, 
não haverá dúvidas sobre quem deve tomar qual ação sempre que houver a necessidade de atuar para 
garantir a confiabilidade do software. 
Práticas de codificação segura 
Estamos preocupados em entender as melhores práticas que devemos implementar ou verificar para 
garantir que um software seja seguro. Para garantir a segurança, precisamos reduzir a ocorrência de 
vulnerabilidades e ter planos formais de como agir, caso ocorra algum problema. Aqui, podemos ver algumas 
das principais práticas de codificação segura: 
A. Validação de entrada 
✓ Como já vimos, os invasores podem tentar explorar as entradas de um sistema. É por isso 
que precisamos realizar a validação da entrada antes do sistema executar os procedimentos 
dele. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 16 
 
B. Tratamento de erros 
✓ Muitas linguagens de programação oferecem recursos explícitos para o tratamento de 
exceções. O objetivo é garantir que o sistema permaneça seguro e estável, caso ocorra um 
erro. Além disso, ao tratarmos os erros de forma explícita, evitamos de fornecer informações 
sobre o software que possam ser usadas para explorar alguma vulnerabilidade. 
C. Autenticação segura 
✓ Trata-se da utilização de técnicas que garantam políticas de senha fortes, autenticação 
multifator e armazenamento seguro de credenciais de autenticação. 
D. Controle de acesso 
✓ São mecanismos associados a configurações de privilégios relacionados a perfis de usuário. 
E. Comunicação segura 
✓ Aqui, usamos algoritmos de criptografia para garantir a segurança de qualquer comunicação 
entre o cliente. 
F. Armazenamento seguro 
✓ Aqui, também precisamos criptografar os dados para impedir o acesso não autorizado, no 
entanto, o contexto é servidor de banco de dados. 
G. Uso de funções especializadas em codificação segura 
✓ Qualquer funcionalidade de um sistema deve ter como base um componente confiável, ou 
seja, precisamos ter acesso a uma documentação de boa qualidade e ter um local oficial para 
realizarmos atualizações e informações. 
H. Atualizações regulares 
✓ Como já vimos, essa prática envolve atualizar o software regularmente apenas com fontes 
oficiais para evitar vulnerabilidades e corrigir erros no sistema. 
Em resumo, ao seguir essas práticas de codificação segura, estamos reduzindo as probabilidades 
de exposição ao risco. 
Testes de vulnerabilidades do software 
O teste de vulnerabilidade de software é um processo de identificação de pontos fracos ou 
vulnerabilidades em software que podem ser explorados por invasores. Existem vários tipos de teste de 
vulnerabilidade que podem ser usados para identificar vulnerabilidades no software. Aqui estão alguns dos 
principais: 
A. Teste estático de segurança de software 
✓ É um tipo teste que analisa o código-fonte – por isso é estático – para identificar possíveis 
vulnerabilidades de segurança. Basicamente, ele verifica o código em busca de padrões 
conhecidos de vulnerabilidades que podem ser explorados por invasores. 
B. Teste dinâmico de segurança de software 
✓ É um tipo de teste que utiliza a execução do software para analisar o comportamento dele e 
tentar identificar possíveis vulnerabilidades. Aqui, precisamos enviar uma série de requisições 
ao software e analisar as respostas. Dessa forma, podemos analisar questões como tempo 
de resposta médio para a execução de uma tarefa. 
C. Teste interativo de segurança de software 
✓ É um tipo de teste que combina os testes estáticos e dinâmicos para tentar identificar 
possíveis vulnerabilidades. 
D. Teste de penetração 
✓ Nesse tipo de teste, fazemos a simulação de um ataque ao software para identificar possíveis 
vulnerabilidades. Como já estudamos, existem muitas vulnerabilidades conhecidas e são elas 
que esse tipo de teste tenta explorar para analisar o quão seguro é o software. 
E. Teste Fuzzing 
✓ Ele gera dados de entrada aleatórios em grandes quantidades e os envia para o software 
para identificar possíveis vulnerabilidades, tais como estouros de buffer e ataques de injeção. 
Desenvolvimento de Software Seguro 
Marcio Quirino - 17 
 
Por meio desses testes, podemos minimizar os riscos de ficarmos expostos a vulnerabilidades. Mas, 
obviamente, é necessário fazermos atualizações constantes, pois os invasores são criativos para explorar 
vulnerabilidades. Tão importante quanto todas as práticas, testes e técnicas que estudamos é a 
conscientização de gestores, usuários e desenvolvedores sobre a importância de desenvolver e usar um 
software seguro. 
4. Conclusão 
Considerações finais 
Estudamos sobres os princípios de software seguro. Aprendemos que esses princípios devem estar 
presentes desde a concepção do projeto do software até o monitoramento da operação dele. 
Vimos ainda que existem fontes oficiais que disponibilizam conteúdo sobre vulnerabilidades bem conhecidas 
que nos ajudam a aprofundar o nosso conhecimento técnico para identificá-las e utilizar recursos técnicos 
que vão do uso de ferramentas específicas à definição de processos para eliminá-las, quando possível, ou, 
pelo menos, reduzir os danos que elas podem causar. 
Sabemos bem que a ciência e a tecnologia têm avançado a uma velocidade gigantesca. Hoje, temos acesso 
a diversas ferramentas e pacotes que podem ser usados para produzir coisas excelentes, como também 
podem ser utilizados para cometer crimes, pois, afinal de contas, são apenas ferramentas e técnicas. No 
centro de tudo isso sempre estará o ser humano. Por isso mesmo, é muito importante formar profissionais 
com forte base de conhecimento, estimular a proatividade e conscientizar sobre aspectos éticos. Dessa 
forma, além de alcançarmos nossos objetivos profissionais, também contribuímos para o bem-estar da 
sociedade e reduzimos os danos que podem ser causados por pessoas mal-intencionadas. 
Explore + 
Acesse o site oficial da Microsoft e procure por Visão geral do desenvolvimento e das operações de 
segurança. Lá, você aprenderá como uma das principais empresas de software do planeta trabalha para 
desenvolver softwares seguros. 
Acesse o site oficial do OWASP. Essa é uma leitura obrigatória para um profissional que trabalha ou deseja 
trabalhar com desenvolvimento de software seguro. Procure pelo termo OWASP Top Ten. 
Acesse o site oficial do Banco de Dados Nacional de Vulnerabilidades do governo dos Estados Unidos – em 
inglês: National Vulnerability Database. Essa é uma leitura muito útil para um profissional que trabalha ou 
deseja trabalhar com desenvolvimento de software seguro. Procure pelo termo Vulnerabilities. 
Referências 
CHESS, B.; WEST, J. Secure Programming with Static Analysis. Boston: Addison-Wesley, 2007. 
HOWARD, M.; LEBLANC, D. Writing Secure Code. 2. ed. Microsoft Press, 2002. 
MCGRAW, G. Software Security: Building Security In. Irving, TX: Pearson Education Inc., 2006. 
PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: McGraw Hill, 2006. 
SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo: Pearson Addison Wesley, 2005. 
VIEGA, J.; MCGRAW, G. Building Secure Software: How to Avoid Security Problems the Right Way. Boston: 
Addison-Wesley, 2002. 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 18 
 
Questões de Implementação Para Software Seguro 
Propósito 
O conhecimento das diversas técnicas, ferramentas, procedimentos e protocolos de implementação 
para um software seguro é importante para garantir a segurança dos dados, sendo esta uma das áreas com 
grande demanda no mercado, em especial, de empresas que usam dados estratégicos para realizar a 
tomada de decisão. 
Objetivos 
• Reconhecer a importância da validação de entrada. 
• Analisar o processamento de dados com segurança. 
• Identificar o processo de chamada de outros programas. 
• Analisar o envio da saída. 
Introdução 
Se você utilizaum sistema bancário para gerenciar suas finanças, certamente não gostaria que 
outras pessoas tivessem acesso aos seus dados, pois isso poderia gerar grandes transtornos. Temos 
diversas outras situações nas quais precisamos de garantias de segurança. As aplicações que oferecem 
essa característica são chamadas de software seguro. No entanto, não é uma tarefa tão simples construir 
sistemas seguros. 
Uma das grandes dificuldades para construir um sistema seguro é ter um conhecimento 
multidisciplinar. Ou seja, além de dominar uma linguagem de programação em si, é preciso também aplicar 
algoritmos de criptografia, protocolos de segurança e mecanismos de controle. Temos ainda que 
acompanhar os avanços na área de segurança e as atualizações feitas pelos fornecedores oficiais, sempre 
que estes detectam alguma vulnerabilidade nos sistemas ou fazem melhorias, para reduzir os riscos de 
invasões bem-sucedidas. 
Um sistema, basicamente, tem quatro fases de tratamento dos dados: entrada, processamento, 
chamada a outros sistemas e geração da saída. Para cada uma dessas etapas, precisamos aplicar um tipo 
de tratamento que, novamente, envolve diversas ações. Além de esse assunto ser extremamente 
interessante, também vem sendo muito requisitado no mercado e gera alta empregabilidade. Em especial, 
com as novas tecnologias se popularizando e as técnicas de inteligência artificial se tornando mais presente 
nas nossas vidas, o conhecimento sobre software seguro é um grande diferencial para o profissional da 
área. 
1. Validação de entrada 
A parte mais básica de qualquer software é o processo de entrada. Nos casos mais simples, 
precisamos realizar duas ações: 
1. Entrar com o login de usuário válido. 
2. Digitar a senha. 
Depois de validar as credenciais do usuário, muitos sistemas fazem testes para verificar se é uma 
pessoa e não um robô (programa) que está tentando invadir o sistema. Vejamos um exemplo! 
Desenvolvimento de Software Seguro 
Marcio Quirino - 19 
 
 
Protótipo do aspecto geral da etapa de entrada no sistema. 
Além disso, alguns sistemas exibem diversas imagens para garantir que é um ser humano que está 
entrando no sistema. E ainda há casos mais elaborados! A validação segura de entrada de software é um 
aspecto crítico do desenvolvimento de aplicativos de software seguros. 
Verificação e validação 
Alguns autores distinguem verificação e validação. Observe! 
A. Verificação 
✓ Processo de avaliação de um software para determinar se ele atende aos requisitos 
especificados e se foi implementado corretamente. 
B. Validação 
✓ Processo de avaliação de um sistema para garantir que ele atenda às necessidades de seus 
usuários e às partes envolvidas. 
Apesar de haver semelhanças entre os conceitos, ambos se diferenciam de uma forma muito 
simples: Aquele conceito que responde à pergunta “Fizemos o que foi solicitado pelo cliente do sistema?” é 
o de verificação. Mas, se a pergunta é “Desenvolvemos o software com a aplicação das melhores práticas?”, 
significa que estamos preocupados com eficácia e eficiência, ou seja, com o processo de validação. 
Vulnerabilidades na entrada de dados 
Até agora, falamos apenas da entrada no sistema, ou seja, do processo de autenticação. Depois que 
entramos, há vários pontos a serem tratados e observados – neste caso, nosso papel é o de desenvolvedor 
–, de modo a garantir que o usuário utilize o sistema de forma correta. 
Várias situações comuns podem ser testadas logo na entrada dos dados, como: Os formatos dos 
dados estão de acordo com o que o sistema está preparado para aceitar? Os intervalos de dados – tamanho 
da entrada – estão em conformidade com o que foi especificado? 
Existem muitas outras vulnerabilidades associadas a entrada de dados. A mais conhecida delas é a 
injeção de código malicioso, destacando-se o caso de injeção de código SQL. 
Nesse caso, o ataque funciona da seguinte maneira: o invasor entra com comandos na entrada, que 
traz informações sobre como é feito o processo de autenticação. A partir da leitura de um erro gerado pelo 
programa, o atacante entra com um comando SQL que dá acesso ao sistema e, a partir disso, consegue se 
passar por um usuário autêntico e, obviamente, não fará nenhuma ação positiva. 
A injeção de código SQL é apenas um exemplo entre muitos outros ataques bem documentados, 
que exploram vulnerabilidades na entrada do sistema. No entanto, existem práticas que podemos 
implementar para realizar uma validação segura de entrada de software, como: 
Desenvolvimento de Software Seguro 
Marcio Quirino - 20 
 
1. Validar todas as entradas do usuário 
✓ Devemos realizar essa validação tanto no cliente quanto no servidor para evitar a entrada de 
conteúdo ou código mal-intencionado. Exemplos concretos incluem validação de formatos de 
dados e controle de comprimentos de dados. 
2. Usar bibliotecas de validação de entrada 
✓ Atualmente, temos diversas bibliotecas para as principais linguagens de programação 
disponíveis que nos ajudam a fazer esse controle de validação de forma eficiente. Um 
exemplo concreto é o Pylit para a linguagem Python. 
3. Implementar validação de entrada do lado do servidor 
✓ Existe um tipo de ataque que ocorre no lado do cliente que tem como alvo o servidor. Um dos 
mais conhecidos é um ataque de script entre sites, normalmente, referenciado, pela sigla XSS 
(cross site scripting). 
4. Criticar todas as entradas do usuário 
✓ Antes de entrar no sistema, é necessário termos mecanismos para remover quaisquer 
caracteres ou conteúdo que possam ser usados para explorar vulnerabilidades de softwares. 
Um exemplo concreto é a remoção de tags HTML e código JavaScript. 
5. Garantir a aplicação de melhores práticas para o código de validação de entrada 
✓ Existem excelentes fontes de informação que explicam detalhadamente como muitos ataques 
funcionam e como combatê-los. Portanto, é responsabilidade do desenvolvedor aplicar essas 
boas práticas. No caso de corporações, é fundamental investir na capacitação de seus 
colaboradores. Uma excelente fonte de informação é o site do OWASP, o qual vamos explorar 
mais adiante. 
A seguir, vamos estudar as bibliotecas de validação de entrada. 
Bibliotecas de validação de entrada 
A validação ajuda a evitar vários tipos de vulnerabilidades de segurança. Porém, fazer esse trabalho 
sem uso de ferramentas específicas dá bastante trabalho e pode demandar muitos recursos financeiros, 
profissionais especializados e, ainda assim, gerar outras vulnerabilidades. Atualmente, temos a vantagem 
de contar com muitas bibliotecas (algumas ferramentas usam a expressão “pacotes”) que fornecem a 
funcionalidade de validação de entrada. 
Exemplos de bibliotecas 
Vejamos alguns exemplos de ferramentas para validação de entrada: 
1. OWASP ESAPI 
✓ A sigla ESAPI se refere ao termo Enterprise Security API (API de Segurança Corporativa). 
Basicamente, é um conjunto de bibliotecas que, entre outras funcionalidades, implementa 
recursos de segurança, como validação de entrada. 
2. InputSanitizer 
✓ Como o nome sugere, faz a sanitização para validação de entrada. Ela pode ser utilizada em 
diversas linguagens de programação, sendo mais comum no caso do PHP. 
3. Validator.js 
✓ Validação de entrada em aplicativos JavaScript. Ela oferece suporte para regras de validação 
de e-mail, URL e comprimento. 
4. Apache Commons Validator 
✓ Validação de entrada em aplicativos Java. Entre as funções de validação de entrada que ele 
fornece estão entradas em vários formatos, como strings, datas e números e suporte a regras 
de validação personalizadas. 
 
 
Desenvolvimento de Software Seguro 
Marcio Quirino - 21 
 
5. Django Forms 
✓ Validação de entradas em aplicações para os programadores de Python que trabalham com 
o framework Django. Entre as validações oferecidas, estão: validar a entrada e manipular os 
dados do formulário, campos obrigatórios, validação de e-mail e validação

Mais conteúdos dessa disciplina