2

EXPLICANDO, APPLICATION
SECURITY
Segurança de software é uma jornada, e este livro será seu guia

Cássio Batista Pereira

PARTE UM

NOVEMBRO DE 2022

3
 Explicando, Application Security
Segurança de software é uma jornada, e este livro é o seu guia

Cássio Batista Pereira

TODOS OS DIREITOS RESERVADOS

Nenhuma permissão é dada para que qualquer parte deste livro seja reproduzida, transmitida de
qualquer forma ou meio; eletrônicos ou mecânicos, armazenados em um sistema de recuperação,
fotocopiados, gravados, digitalizados ou de outra forma. Qualquer uma dessas ações requer a
devida permissão por escrito do autor.

Publicação independente

Contato:

Cássio Batista Pereira

cassio@[Link]

4
 ÍNDICE
Prefácio 10
Sugestão de como ler este livro 12
Autor 14
Você não precisa de “shift-left” 16
Guia 🗺️ 17
Introdução 📌 17
O erro 17
A matéria prima do software 18
Exemplo de Requisito funcional 18
Ataques de força bruta 19
Criptografia 20
Engenharia Social 20
Logs e Monitoramento 20
Outros 21
Automação 🤖 21
KPIs 📊 23
Ferramentas 🛠️ 23
Conclusão ✅ 24
Preparando o seu software 25
Guia 🗺️ 26
Introdução 📌 26
Arquitetura 26
Threat Modeling 27
Automação 🤖 28
KPIs 📊 28
Ferramentas 🛠️ 28
Conclusão ✅ 28
Cuidados com o código enquanto nasce 30
Guia 🗺️ 31
Introdução 📌 31
O código 31
Onde nasce a vulnerabilidade 32
Bônus 33

5
Aumentando seu poder de proteção 33
Code review 33
Pair programming 34
Políticas de repositório 34
SAST - Static Application Security Testing 35
Presente 35
Introdução, curtinha 35
Integrações 36
IDE 36
Repositório 37
Repo actions 37
Pipeline 38
CLI e API 38
A análise 38
Conclusão 39
SCA - Software Composition Analysis 39
Introdução 39
Integrações 40
A análise 40
IaC - Infrastructure as code 40
Introdução 40
Integrações 41
A análise 41
Automação 🤖 41
Dica 💡 42
Code Review 42
Políticas de repositório 44
SAST 44
IDE 44
Repositório 45
Dica 💡 45
Repo Actions 45
Dica 💡 46
Pipeline 46
Dica 💡 46
API 48
Dica 💡 48
SCA 48

6
 IaC 49
KPIs 📊 49
Abaixo alguns exemplos para te incentivar, mas não acostuma que não
terá em todo capítulo: 50
Ferramentas 🛠️ 55
Conclusão ✅ 56
Curiosidade 🧠 56
E os meus segredos? 57
Guia 🗺️ 58
Introdução 📌 58
Como 58
Cuidados 59
Automação 🤖 59
Dica 💡 59
KPIs 📊 60
Ferramentas 🛠️ 60
Conclusão ✅ 60
Segredos em todo lugar 60
CI / CD com segurança, mas ainda não é DevSecOps 62
Guia 🗺️ 63
Introdução 📌 63
Build 64
Test 64
CI/CD 64
Manual 65
IAST 65
Pentest 65
Release 65
Antimalware 66
Assinatura digital 66
Automação 🤖 67
KPIs 📊 68
Ferramentas 🛠️ 68
Conclusão ✅ 69
Fiz deploy, e agora? 70
Guia 🗺️ 71
Introdução 📌 71

7
 Como 72
KPIs 📊 72
Automação 🤖 73
Ferramentas 🛠️ 73
Dica 💡 73
Conclusão ✅ 73
Conheça o comportamento da sua aplicação 74
Guia 🗺️ 75
Introdução 📌 75
Como 76
KPIs 📊 77
Automação 🤖 78
Ferramentas 🛠️ 78
Conclusão ✅ 79
Não basta encontrar problemas, tem que resolvê los 80
Guia 🗺️ 81
Introdução 📌 81
Então o que fazer? 82
KPIs 📊 82
Automação 🤖 83
Ferramentas 🛠️ 83
Conclusão ✅ 84
KPIs, para onde vou? O que faço? 85
Guia 🗺️ 86
Introdução 📌 86
KPIs 📊 86
Automação 🤖 87
Ferramentas 🛠️ 87
Conclusão ✅ 88
DevSecOps, agora sim! 89
Guia 🗺️ 90
Introdução 📌 90
KPIs 📊 91
Automação 🤖 91
Ferramentas 🛠️ 91
Conclusão ✅ 92

8
Fim 93

9
10
 Prefácio

Por muitos anos a segurança da informação foi ignorada durante o ciclo de

desenvolvimento de aplicações, e controles de segurança eram apenas adicionados após
a aplicação ter sido finalizada, e pior, apenas após uma brecha de segurança ter sido
explorada. Essa falta de integração entre os desenvolvedores e os princípios de
segurança levou o mercado a cometer os mesmos erros quando o desenvolvimento de
aplicações para dispositivos móveis iniciou, ou seja, segurança não foi considerada como
parte do projeto inicial, apenas um pensamento pós desenvolvimento.

O desenvolvimento de aplicações usando recursos nativos da nuvem também

alavancou a necessidade de priorizar segurança de aplicações. De acordo com um
estudo conduzido pela Synk, 60% das empresas entrevistadas aumentaram a
preocupação com segurança desde a adoção de tecnologias nativas da nuvem. Essa
tendência está fazendo com que as empresas comecem a priorizar o investimento em
segurança de aplicações. De acordo com um estudo conduzido pelo instituto Forrester,
segurança de aplicação é um mercado que vai crescer para 12.9 bilhões de dólares até
2025. Com o crescimento deste mercado torna-se crucial que os desenvolvedores passem
a utilizar as melhores práticas de desenvolvimento de software seguro e entendam os
vetores de ataque de uma aplicação. Sem esse conhecimento fundamental, torna-se
quase impossível de embutir segurança no código desde a concepção do projeto.

Ao passo que estas tendências que empurram o mercado para ficar mais atento
com segurança de aplicação é importante, é preciso treinar os desenvolvedores para este
novo modelo. Infelizmente, faculdades de Ciência da Computação, não preparam os
desenvolvedores para desenvolver código seguro, na realidade, a segurança da
informação quase não é coberta em um curso de Bacharel em Ciência da Computação.

Por esse motivo, você leitor que está buscando o conhecimento necessário para
adequar-se a essa demanda do mercado está lendo o livro correto. Neste livro, o autor
Cássio Pereira traz, em uma linguagem amigável e compreensível todos os princípios
fundamentais de desenvolvimento seguro. Você vai aprender os conceitos necessários
para iniciar seu projeto e fazer uso de tecnologias que vão habilitar a criação e
distribuição da sua aplicação de forma segura.

Boa leitura!
Yuri Diogenes
Mestre em Segurança Cibernética
Autor de mais de 30 livros na área de segurança
Professor na EC-Council University
Cursando PhD em Liderança de Segurança Cibernética
Para maiores informações ver [Link]
Para maiores informações ver [Link]

11
 Cássio B. Pereira
Cyber Security Engineer

12
 Sugestão de como ler este livro

Imagine uma pipeline, onde as coisas acontecem de forma orquestrada e bem

definidas em etapas (tasks) uma após a outra, cada etapa pode informar valores
(parâmetros) para a próxima, assim como cada etapa tem autonomia de execução. Podem
acontecer em paralelo, assim como uma pode depender da outra, mas no final o objetivo
(normalmente) é, ter o software funcionando, compilado, com todas as dependências,
testado, integrado, preparado em um pacote (dll, exe, jar, container etc), muitas vezes
também implantado (deploy) em um ambiente funcional (dev, teste, QA, produção etc).

Tentarei seguir uma mesma estrutura para cada tópico, assim facilita sua leitura e
entendimento do conteúdo, tentarei manter a seguinte estrutura para cada capítulo:

● Guia
○ Aqui você terá um “GPS” de onde estamos no desenho do DevSecOps, caso
se aplique.

● Introdução
○ Obviamente uma introdução sobre o tópico.

● Dissertação
○ Aqui irei descrever o tópico em si, trazendo problemas, casos de uso,
soluções, referências, exemplos etc.
● Automação
○ Dicas de como automatizar o assunto do tópico.
● KPIs
○ Sugestões de indicadores sobre o tópico para enriquecer ainda mais seu
projeto de AppSec.
● Ferramentas
○ Uma lista com algumas ferramentas acerca do tópico.
● Conclusão
○ Obviamente uma conclusão sobre o tópico.

Cada capítulo deste livro é como se fosse uma task de uma pipeline, alguns você
pode ler em paralelo, outros dependem de um capítulo anterior, alguns passam
informação para o próximo, outros complementam a leitura do anterior portanto, não
pule, não burle o processo, sua pipeline vai falhar no final, especialmente o capítulo 1,
como o nome já diz, você vai entender a importância do real shift-left e por quê não se
deve “pular etapas” em segurança.

13
 A famosa figura do DevSecOps, é um bom guia para nós e talvez possa ajudar
nesse fluxo, considerando que um projeto começa no planejamento e depois entra num
ciclo praticamente infinito, veja:

Cássio B. Pereira
Cyber Security Engineer

14
 Autor

Muito prazer, eu sou Cássio Batista Pereira, a.k.a. @cassiodeveloper, sou

Desenvolvedor e Arquiteto de Software por formação. Atuo como Application Security
Engineer e assim ajudo empresas e profissionais a construírem soluções mais seguras.
Possuo 20 anos de experiência no mercado de desenvolvimento nos mais variados
segmentos de negócio, onde obtive conhecimento para trabalhar com diferentes
tecnologias, linguagens, frameworks e processos. Sou evangelista da cultura de
Desenvolvimento Seguro e compartilho conhecimento sobre AppSec, DevSecOps e SDLC,
mais detalhes aqui.

15
Explicando, Application Security

16
 Capítulo 1

Você não precisa de “shift-left”

“Segurança é responsabilidade de todos”

—Cássio B. Pereira

17
Guia
Seguindo nosso guia, considere que estamos na fase de Planejamento ou PLAN.

Introdução

O erro

Eu poderia começar este livro diretamente pela conclusão, você iria ler, talvez
entender e seguir sua vida. Mas faltaria algo, claro… como se conclui algo que não
começou de fato? Pois é, então eu teria de indicar os capítulos anteriores que levaram a
tal conclusão, daí sim faria muito mais sentido aquela conclusão, pois houve um caminho
percorrido até ali.

Perceba que, após a conclusão você teve de voltar (shift left) para os capítulos
anteriores. Mas não faz sentido, o fluxo natural das coisas até mesmo a forma como
escrevemos e lemos é, da esquerda para a direita. Pois então, por que em segurança de
software precisamos fazer o shift-left? Porque começamos pela “conclusão”, começamos
fazendo SAST, SCA e DAST (veremos em detalhes sobre esses termos mais adiante neste
livro), encontramos um monte de vulnerabilidades e não sabemos o que fazer com elas.
Continuamos a executar ferramentas durante o nosso ciclo de desenvolvimento para
encontrar problemas que sequer sabemos como parar de criá-los. Ou seja, entramos num
ciclo infinito de criar vulnerabilidades, fazer scan para encontrá-las (quando

18
encontramos), corrigir (quando corrigimos) e entregar o software (possivelmente cheio de
vulnerabilidades).

Ou ainda o bom e velho pentest, muita empresa faz, custa caro e normalmente traz
um relatório cheio de problemas catastróficos que você morre de medo. Todo o time de
dev, infra e outros são mobilizados para corrigir o quanto antes, afinal estamos em risco.
Legal, corrigimos boa parte (muitos problemas são, falso positivo de acordo com o time)
estamos seguros, até o próximo relatório daqui 1 ano mais ou menos, onde o ciclo se
repete.

Veja, você precisa de shift-left quando você faz errado, quando você mete o pé
pelas mãos, quando você começa ler da direita para a esquerda. Mas ainda neste capítulo
vou te ensinar como fazer o que apelidei de “from left to right, the natural flow”.

A matéria prima do software

Já se perguntou, qual é a matéria prima do software? Talvez a resposta que venha
a mente seja código, mas o código é o software em si, e ele é produzido com base nos
requisitos funcionais, que são fruto da ideia ou necessidade de um software e
normalmente são escritos pelo analista de sistemas / usuário (área de negócio) e até
mesmo pelo dev. Que vai entender a necessidade do software e o que ele precisa fazer, e
então “traduzir” no formato de requisitos funcionais (lembre-se que temos requisitos,
funcionais, requisitos não funcionais, requisitos de segurança entre outros). Então com a
lista de requisitos funcionais em mãos, o código começa ser escrito para “dar vida” aos
requisitos, portanto a matéria prima do software é o requisito funcional propriamente
dito. Veja abaixo um exemplo de requisito funcional (se é que me lembro bem das aulas
de engenharia de software):

Exemplo de Requisito funcional

RF1 - Login

A página de login deve ser a primeira página que os usuários veem ao acessar o aplicativo.
Ela deve apresentar dois campos de texto - um para inserir um nome de login e outro para inserir
uma senha, que deve ser mascarada no formato bolinhas. Além disso, deve ter um botão de comando
que inicie a ação de verificação de senha, por exemplo “Entrar”. Se um dos campos de texto for
deixado em branco, um erro deve ser relatado ao usuário informando qual campo está em branco.
Se ambos os campos estiverem preenchidos, mas não houver registro do nome de usuário ou a senha
estiver incorreta, isso também deve ser informado ao usuário. Caso o usuário e senha correspondam
a um registro na base de dados, o login é considerado sucesso e o usuário deve ser redirecionado
para a tela principal do aplicativo.

19
 Claro e simples, o requisito acima descreve uma tela de login de um site ou
aplicativo qualquer. Este pequeno texto, foi traduzido para o formato de requisito
funcional de uma conversa mais ou menos assim:

- Cliente (usuário / área de negócio) Oi, então eu preciso de um sistema para controlar os
meus clientes, quero poder gerenciar isso de qualquer lugar, ou do escritório ou de casa e
até mesmo na rua.
- Anal. de Sistemas Claro, e qualquer pessoa poderá acessar estes dados ou apenas você?
- Cliente (usuário / área de negócio) Eu e alguns funcionários, mas eu quero poder fazer
tudo os funcionários não podem apagar nada….
- Anal. de Sistemas Ótimo, então teremos uma tela de login para controlar quem acessa o
seus dados, e as permissões de cada pessoa.
- Cliente (usuário / área de negócio) Exato, igual a tela para entrar no Facebook né?
- Anal. de Sistemas Exatamente.

Veja que, tudo que é necessário para iniciar o processo de desenvolvimento dessa
funcionalidade nós já temos. Claro que questões visuais e de performance devem ser
discutidas, mas são requisitos não funcionais. Ainda mais no mundo “ágil” (e ainda
menos seguro), as coisas são muito dinâmicas e a qualquer nova “sprint” isso poderá ser
adicionado. No mundo real, este requisito vira código, que por sua vez é testado (as
vezes?), feito deploy e voilá, temos uma nova funcionalidade, funcionando (de vez em
quando), um bug aqui outro ali, mas temos um login funcional.

Se você é um profissional de segurança, com certeza sentiu falta de algumas coisas

no exemplo de requisito acima, não? (Se não, considere estudar mais e aqui vai uma dica,
este livro vai te ajudar.) Mas se você não é um profissional de segurança, muito
provavelmente você deve pensar, o requisito está ok, bem definido e claro quanto ao que
é esperado. Mas do ponto de vista de segurança da informação, mais especificamente
segurança de aplicações, alguns pontos muito importantes podem ter ficado de fora da
descrição do requisito funcional, como por exemplo:

● Ataques de força bruta

● Criptografia
● Engenharia social
● Logs e monitoramento
● Outros

Ataques de força bruta

Não cabe aqui explicar o que é um ataque de força bruta em detalhes, mas a grosso
modo é o famoso “água mole em pedra dura, tanto bate até que fura”, o atacante fica
“batendo” na tela de login (API, etc) com usuários e senhas randômicos (ou de dados

20
vazados), até conseguir uma combinação que funcione (e ele consegue rapidinho usando
o John the Ripper por exemplo).

E se o nosso requisito considerasse esse tipo de ataque na sua descrição, algo como:
deve haver uma proteção contra bots e ou usuários mal intencionados, um desafio (ex.
captcha) deve ser solicitado ao usuário a cada tentativa de login. Ou ainda algo como,
após a terceira tentativa de login mal sucedida (login inválido), deve ser acrescentado um
tempo de espera para cada nova tentativa (aguarde 3 minutos antes de tentar novamente,
5 minutos, 10 minutos etc). Ou o famoso, após três tentativas de login sem sucesso, a conta
deve ser bloqueada, este não gosto muito pois permite ao atacante gerar um DoS, se ele
tiver todas as contas vazadas por exemplo, ele bloqueia todas!

Mas perceba que, esse ataque é muito comum e poderiam estar descritas algumas
proteções diretamente no requisito funcional, por quê não?

Criptografia

É óbvio que login (e-mail) e senha são informações sensíveis e devem ser tratadas
como tal, pode até variar de classificação em algum cenário muito específico mas ainda,
um dado que deve ser tratado com mais segurança. Então, nosso requisito poderia incluir
algo como: tanto o campo login quanto o campo senha são informações críticas e devem
ser criptografadas (mascaradas) durante o seu processamento (em trânsito ou em
descanso) utilizando um algoritmo seguro (padrão de mercado). Você deve estar
pensando, Cássio só quem é de segurança escreveria um requisito assim… ai eu te
pergunto, será? (Conclusão logo mais adiante)

Engenharia Social

É jovem, a engenharia social ainda é (e sempre será) muito utilizada pelos

atacantes. E a sua aplicação pode fornecer informações valiosas para eles. Imagine que sua
tela de login apresente a seguinte mensagem quando um login é inválido:

“Tentativa de login inválida, a senha informada está incorreta.”

A mensagem parece inocente, aliás ela é mesmo, o usuário vai ler e pensar, puxa realmente
errei minha senha, vai digitar novamente e seguir sua vida feliz e saltitante. Mas o atacante
que está tentando o acesso indevido, vai ler e pensar, ótimo o login é válido (existe o
usuário na base de dados), só preciso agora descobrir a senha. Percebe que a mensagem é
a informação que o atacante precisa para conduzir o ataque? Nosso requisito poderia
simplesmente mencionar que, caso o login ou a senha sejam inválidos, o sistema deverá
exibir uma mensagem genérica do tipo “Login ou senha incorreta, tente novamente!”.

21
Logs e Monitoramento

Se você não sabe o que acontece no seu sistema, sinto muito. Quando sofrer um
ataque saberá menos ainda e digo (escrevo) mais, o atacante sabe mais do que você sobre
o seu próprio sistema. Portanto é fundamental gerir logs, sim gerir, do verbo gerenciar
(não só gerar logs), mas gerar, processar, centralizar, analisar, aprimorar… tudo
utilizando a stack ELK, por exemplo, você já entendeu. Sem logs você está navegando às
cegas, e isso é tão perigoso quanto correr e mascar chiclete ao mesmo tempo (tenta!).
Nosso requisito poderia contemplar isso mais ou menos assim, para cada tentativa de
login deve ser gerado um registro de controle (log), contendo a data e hora da tentativa, o
status (sucesso ou falha), o usuário que tentou, o IP de origem da requisição, etc etc. Nem
mencionei para criptografar esse usuário no log (deveria) para não complicar tanto.

Outros

Para este requisito em particular eu pensei nestes pontos de segurança, para cada
requisito em um software outros pontos de segurança devem ser levantados obviamente.
Eu por exemplo não mencionei a questão de complexidade de senha se for o caso, ou ainda
que a página de login só poderia ser acessada através de uma rede específica (VPN) ou
ainda de um IP específico, etc. Diversos aspectos de segurança devem ser considerados
durante o SDL, muitas das mitigações aplicadas são identificados durante o processo de
Threat Modeling (veremos mais detalhes adiante neste livro), que só é praticado em times
com razoável maturidade tanto no processo de desenvolvimento quanto em segurança de
aplicação. Podemos usar esta mesma prática como insumo para os nossos requisitos
funcionais, podemos enriquecê-los com os outputs de uma modelagem de ameaças mais
alto nível, ou macro como preferir, ou ainda um bom e velho brainstorming, mas o pulo
do gato é fazer o máximo possível para alimentar o requisito funcional com os aspectos
de segurança pois como disse anteriormente, o requisito é a matéria prima do software, e
se a matéria prima de QUALQUER produto é de má qualidade, o que esperar do produto
final?

Vale destacar ainda que, não podemos também criar requisitos infinitos do ponto
de vista de implementação. Um "livro" como requisito funcional simplesmente nunca
será implementado, a complexidade do requisito em si deve ser mantida na sua natureza
de negócio e não adicionada por um ou outro controle de segurança, por exemplo, no
requisito login que vimos não seria legal inserir controles específicos para SQLi, XSS, ou
qualquer outra vulnerabilidade comum ou mesmo não comum, seria praticamente
impossível descrever ou prever tudo, alguns controles como validação de dados por
exemplo, se aplicam a qualquer ou a maioria dos requisitos, logo não precisa ser descrito
ou repetido mais de uma vez, evitando assim floodar um simples requisito com um
monte de controle que, pode até ser relevante mas que pode ser tratado de forma mais
genérica, queremos facilitar a implementação de segurança e não dificultar.

22
Automação
Aqui é fácil, não tem automação. Mas falando sério, todo o tema engenharia de
requisitos em si trata da abordagem da escrita das necessidades (funcionalidades)
traduzidas em requisito, é um trabalho empírico por definição e não há automação
possível aqui, considerando o SSDL.

O que talvez pode ser feito é, utilizando algum framework BDD você consiga
escrever os requisitos diretamente no código (ou em formato de código que pode ser
interpretado pelo computador) e daí automatizar alguns testes de segurança, validações
etc, na verdade pensei nisto aqui enquanto escrevia, irei pesquisar mais sobre.

Outro ponto pensando em uma automação de processos aqui, é como documentar

esses requisitos, talvez uma listagem simples (a parte a documentação completa) no Jira
ou Azure Boards no formato de Work Items ou qualquer outra ferramenta similar possa
facilitar a geração / coleta de indicadores posteriormente, fazer automação do fluxo de
trabalho como trigger de testes por exemplo, imagine um requisito “login do usuário”,
você quer garantir que não há vulnerabilidades SQLi ou OWASP Top 10 por exemplo,
quando o Work Item do requisito for marcado como “DONE”, pode triggar um scan SAST
por exemplo, ou DAST… com as regras específicas habilitadas (OWASP Top 10 no caso),
o resultado do scan volta direto para o Work Item e você pode ser notificado pelo Teams
ou Slack.

23
 Este modelo não é comum, veremos mais adiante outras formas de automação
mais populares e até “padrões” aceitos pelo mercado, mas porquê não linkar o item do
backlog diretamente nos testes? Ainda mais requisito funcional, fazer mais shift left que
isso só como descrito na conclusão mais adiante.

KPIs
Indicadores são sempre importantes para nos manter na direção correta (ou pelo
menos saber para onde estamos indo), falando em requisitos e fazendo o link com o tópico
anterior Automação alguns indicadores que podemos considerar aqui:

● Quantidade de requisitos (considerando que eles já possuem segurança embutida)

○ Por status (To do, doing, done…).
○ Por pessoa (time, squad…)
○ Por projeto (produto)
● Quantidade de requisitos com teste integrado
○ *AST (Application Security Testing)

Como agrupar ou filtrar vai depender muito do seu fluxo de trabalho, ferramenta
que você utiliza mas minimamente você deveria considerar estes dados mencionados mas
não limite-se à estes. O Jira e o próprio Azure Boards possuem diversas funções de
dashboards para criar visualizações bem interessantes destes dados, use e abuse dessas
funções para obter ainda mais valor das informações que você já tem, por exemplo, alguns
dados funcionam melhor se apresentados num gráfico de pizza, outros num gráfico de
barras, outros em gráfico nenhum mas numa listagem simples, brinque, teste, implemente
e veja o que funciona para você.

Ferramentas
Ahhh o tão esperado capítulo que todo mundo gosta, ferramentas, me dá
ferramenta! Qual ferramenta você usa? É free? Tem pra linux? Roda em docker?
Pouhaaaaa, é ferramenta que você quer? Então toma (ferramentas citadas no capítulo e
outras):

● John the Ripper

● Captcha
● ELK
● Jira
● Azure Boards
● Teams
● Slack
● Enterprise Architect

24
 ● Markdown

Conclusão
A mensagem aqui é a seguinte: as questões de segurança (nem todas, mas boa
parte) podem e ao meu ver, devem ser levantadas / apontadas já no requisito funcional
por mais complicado que isso seja, a ideia é evitar o futuro bypass de processos. Se os
requisitos forem definidos (separados) como normalmente são: requisitos funcionais,
requisitos não funcionais, requisitos de sistema e requisitos de segurança dentre outros, a
chance de todos os requisitos que não funcionais serem deixados de lado ou para depois
(backlog infinito) é muito grande. Quando o projeto estiver atrasado, quando a demanda
aumentar, quando o escopo mudar, quando os devs da equipe mudarem de emprego etc
etc, todo o impacto é sentido diretamente no desenvolvimento do software, pois tudo que
pode "a princípio" ser deixado para depois será e questões de qualidade e segurança são
as primeiras a entrarem na lista do (na v2 a gente implementa). A medida que o requisito
funcional já descreve TUDO o que é necessário para o software (funcionar) do ponto de
vista de negócio, logo este será implementado, então se os requisitos de segurança forem
incorporados no requisito funcional, logo não poderão ser deixados de lado, afinal
ninguém desmembra o requisito em si, não é? (desmembraram, mas é bem menos
comum).

Em resumo, você não precisa de “shift left” se você começar direitinho já no “left”.

25
 Capítulo especial

Preparando o seu software

"Dá para encontrar os problemas, antes do software existir.”

—Cássio B. Pereira

26
Guia
Seguindo nosso guia, considere que estamos na fase de Planejamento ou PLAN.

Introdução

Arquitetura

Fase crucial durante o ciclo de desenvolvimento de software, é a fase de Design. É

onde todo o alicerce e estrutura da aplicação vai se estabelecer e sustentar o restante do
desenvolvimento / software como um todo.

Nessa fase normalmente os arquitetos da aplicação se reúnem para definir a

estrutura do software, definir frameworks e bibliotecas que serão utilizados, estabelecer
alguns padrões a serem seguidos etc. Mesmo que um time ou empresa não tenha a figura
do arquiteto, essa discussão e etapa acontece entre os desenvolvedores ou responsáveis
técnicos do projeto, mesmo que separada em sprints, uma em uma única fase, essa
discussão está lá, de forma clara e definida ou de forma integrada ao “dia a dia” sem de
fato ser nomeada como fase de Design. Portanto, não se engane quando uma empresa não
tem um time ou um arquiteto, todo software tem arquitetura ainda que esta seja
estabelecida pelo desenvolvedor.

Este momento é crítico quando se trata de segurança, pois é aqui que são definidos
muitos padrões de segurança como por exemplo:

27
 ● Audit logs
● Algoritmo de criptografia
● Autenticação e autorização

Apenas alguns exemplos que são cruciais para a segurança da aplicação e precisam
de uma definição e estruturação prévia, que caso não aconteçam, irão impactar
diretamente a saúde do projeto bem como aumentar exponencialmente seu risco. Isso sem
mencionar o famoso “pouts, isso vai quebrar um monte de coisa agora, deveria ter sido
visto lá atrás ... vai demorar meses para implementar”.

Threat Modeling

Vale lembrar ainda que é neste momento que a Modelagem de Ameaças ganha
vida real, pois na definição de arquitetura, já temos detalhes de requisitos funcionais e
técnicos suficientes para diagramar a aplicação e extrair ameaças que nos auxiliarão a
definir requisitos de segurança.

A modelagem de ameaças ou Threat Modeling, é uma atividade crucial para o

desenvolvimento seguro, ela visa identificar ameaças a um sistema, mesmo que este
sistema ainda não exista (ainda estamos na fase de Design, certo?), e a partir dessas
ameaças, criarmos controles de segurança para eliminar o risco da ameaça, ou mitigá-lo.

A modelagem é feita de forma simples aplicando algum framework que

independe de ferramenta ou tecnologia, você só precisa escolher um deles:

● STRIDE
● DREAD
● PASTA
● Trike
● VAST
● OCTAVE
● NIST
● Security Cards
● Attack Tree

Dentre estes e outros, o mais popular e comum é o STRIDE. Mas, eu sugiro que você leia
este guia da OWASP sobre um processo de Threat Modeling em geral e veja se faz sentido
para seu time / equipe / empresa. O que importa aqui é, utilizar um modelo o mais
simples possível para se tornar um processo para você, eu sugiro que, para cada sprint
plan, uma modelagem seja feita considerando as features que serão desenvolvidas, e cada
dev diariamente revise e atualize o modelo conforme sua feature evolui, além de uma
revisão final na sprint review. Assim, fica fácil começar, manter e escalar a modelagem de
ameaças. No modelo “tradicional”, a modelagem é feita uma vez no início do projeto, e

28
nunca mais é vista… diagramas gigantes, lista de requisitos infinitos e no fim, segurança
zero pois ninguém vai implementar ou até mesmo dar atenção para isso.

Automação
É complicado falar de automação em um contexto onde o trabalho em si é
empírico. Mas se podemos considerar algo é que a fase de Design é para estruturar a
aplicação, então parte dessa estrutura e definição pode ser documentada de forma
estruturada a ponto de facilitar etapas posteriores como testes e validação por exemplo.
Então imagine, na sua arquitetura você definiu que toda autenticação entre serviços irá
confiar na troca de tokens, ok. Você pode documentar este requisito utilizando os padrões
que você já segue, como um ticket no Jira, ou qualquer outro sistema, por sua vez definir
critérios de aceite para testes, como um caso de teste mesmo, para que possa ser validado
posteriormente, inclusive integrando com ferramentas de testes ou scans.

KPIs
Uma vez que você tenha definido a sua estratégia de como irá implementar
segurança na fase de Design, essa estratégia deve permitir ser mensurada, por exemplo,
concordamos em para cada requisito criar um item no Jira, ok. Para esses itens, podemos
extrair informações do tipo:

● Quantos itens de Design são registrados vs quantos são implementados

● Quantos itens de Design são obrigatórios (compliance)
● Quantos itens de Design são opcionais
● SLA para implementação de cada item

Ferramentas
Aqui existe um mundo de possibilidades, mas uma ferramenta que gosto bastante
é o Security Compass, ele praticamente automatiza o processo de Threat Modeling e testes
de segurança com base em requisitos, integrando com seu ticket system etc.

● Security Compass

Conclusão
Para fecharmos este capítulo quero que você imagine o seguinte cenário, imagine
construir uma casa ou prédio, muitas coisas são definidas ANTES, no projeto, no DESIGN,
pois a fundação precisa ser de acordo com o tamanho (altura, peso etc) da construção. Não
é possível mudar isso depois do projeto, a menos que você destrua tudo, e faça novamente

29
do zero o que normalmente não irá acontecer. Em software é igual, este momento é crucial
para segurança do software, pois boa parte da FUNDAÇÃO é definida aqui, para ser
executada durante o desenvolvimento, caso não seja definida aqui, será descartada, ou
muitas vezes não será mesmo possível implementar algo. Nesta palestra aqui eu falo sobre
o The Real Shift-left, e como podemos nos beneficiar da modelagem de ameaças ainda
mais, mesmo antes da fase de Design, vale a leitura.

30
 Capítulo 2

Cuidados com o código enquanto nasce

“Quem cria as vulnerabilidades, é você dev.”

—Cássio B. Pereira

31
Guia
Seguindo nosso guia, considere que estamos na fase de codificação ou CODE.

Introdução

O código

Ótimo, chegamos a parte que todo mundo gosta, o código. A real mesmo, é que
queremos abrir nossa IDE favorita (Visual Studio no meu caso) e sentar os dedos no
teclado até ver compilar (rodar), sem mesmo nem ter lido / compreendido o requisito por
completo, gostamos é de "codar". Seja Java, JavaScript, C# (minha linguagem favorita),
PHP, Python não importa a linguagem, ou ainda o tipo do software (Web, Desktop,
Mobile etc) todo software está exposto a algum risco de segurança de algum modo, uns
mais outros menos.

O código pode ser considerado o cérebro de um software, dentre tantos outros

componentes de infraestrutura e computação, o código em si carrega o DNA (lógica) de
sua própria existência, assim como as instruções de execução para qual foi escrito. O
código em si compõe boa parte do ciclo de desenvolvimento, ele está em constante
mudança, evolução (ou depreciação), dependendo do projeto mais ou menos
desenvolvedores estão "mexendo" nele cada um com sua lógica e jeito próprio de
programar(mesmo diante de tantas boas práticas) enfim, está claro o quão fundamental é
o código para um software certo?

32
 Cuidar do código não é fácil, tanto do ponto de vista de qualidade e de sua própria
estrutura (arquitetura / design) quanto do ponto de vista de segurança, estima-se que 92%
das falhas de segurança estão em software, então cuidar do código no que se refere a
segurança é fator crítico de sucesso para um projeto de AppSec de sucesso. Nem vou
gastar seu tempo explicando sobre commits, pull requests e merges da vida, além de todo
o fluxo de code review (quando aplicado) ou simplesmente técnicas de testes como TDD,
o meu ponto aqui é o seguinte, o código precisa de atenção O TEMPO TODO, a cada
novo caractere digitado, classe criada, método definido, função criada, parâmetro inserido
etc uma nova vulnerabilidade (bug) pode surgir, e o quanto antes for resolvido
(descoberto inclusive) melhor, vai por mim, afinal é como diz o ditado né, cortar o mal
pela raiz.

Onde nasce a vulnerabilidade

Mas é bem na sua cara senhor dev, developer, programador, desenvolvedor como
queira (desconsidere essa parte caso não seja dev ). A vulnerabilidade, o bug nasce na
sua cara bem abaixo do seu nariz e o senhor não vê . Tudo bem eu entendo, é muita
pressão, muita coisa para fazer, o requisito é enorme, o projeto está atrasado, a arquitetura
do software está confusa, você não gosta da linguagem, a lua está minguante apontando
ao norte de júpiter… pois é, inúmeras são as desculpas (dificuldades) que muito
desenvolvedor dá quando se fala em encontrar / corrigir vulnerabilidades. Mas a
verdade é que, são eles que as criam (creio eu que na maioria das vezes, de forma não
proposital), portanto por quê “não gostam” quando alguém aponta defeitos no seu
código? Seja o time de Q&A, o time de segurança e até mesmo os usuários nos testes
funcionais, gente, se tem um problema no software (funcional), seja um bug, uma
vulnerabilidade ou mesmo não atende o requisito, a responsabilidade é 99,9% do
desenvolvedor, não adianta brigar com isso. Então vale afirmar que, a vulnerabilidade
nasce na sua IDE, no seu teclado, assim que você finaliza sua codificação (método, classe,
função etc) pronto, uma nova vulnerabilidade PODE estar ali.

Então não é nenhum problema considerar uma pequena ajuda neste momento tão
crítico não acham? Por exemplo, os famosos lints (Wikipedia, 13/11/2022), ferramentas
(plugins, extentions tanto faz) que vão auxiliar durante a escrita do código sugerindo
melhorias, apontando falhas etc. Eu sei, pode ser meio chato, atrapalhar um pouco mas, o
benefício é muito grande. Imagine que você finalize a escrita de um método por exemplo,
e o lint já te avisa, olha aqui pode ter uma vulnerabilidade de SQLi, que tal corrigir o
parâmetro X e fazer um tratamento antes de acessar seu valor. Um lint de segurança bem
famoso é o SonarLint (Sonarsource, 13/11/2022), que te ajuda a identificar problemas de
segurança enquanto escreve o seu código.

33
Bônus
E se todo desenvolvedor soubesse como as vulnerabilidades são exploradas? Logo
ele também saberia como corrigí-las e até mesmo como NÃO CRIÁ-LAS. Isso é possível
através da educação, sim, educação acerca do que eu gosto de chamar de “programação
defensiva”. Através de muita prática, o desenvolvedor aprende a criar código mais
performático, código mais limpo etc, por quê não código mais seguro? Ferramentas como
as da lista abaixo, auxiliam o desenvolvedor a entender a exploração de uma
vulnerabilidade num nível de detalhe impressionante, dando a ele a capacidade de
corrigir uma falha similar quando encontrar, e principalmente evitar codificar de tal forma
(evitando que vulnerabilidades sejam criadas):

● Checkmax Codebashing
● Kontra
● Veracode Security Labs

Aumentando seu poder de proteção

Segurança é sempre uma questão de “double check”, sempre pode (e vai) passar
algo que o desenvolvedor não consegue verificar de fato. Algumas ferramentas de SAST
(veremos mais detalhes sobre este tema adiante) fornecem plugins para a IDE que
permitem o desenvolvedor visualizar os resultados de uma análise (e executar a análise
também) e já trabalhar nas correções das vulnerabilidades encontradas, um bom exemplo
disto é o Checkmarx Visual Studio Plugin (Checkmarx, 13/11/2022), que permite essa
capacidade de integrar sua IDE (Visual Studio por exemplo), diretamente ao servidor do
SAST. Importante ressaltar que, SAST é uma análise muito mais avançada que a análise
de um lint, portanto elas se complementam.

Outras práticas mais comuns podem e devem ser utilizadas para aumentar ainda
mais sua capacidade de detecção de vulnerabilidades o quanto antes, por exemplo:

● Code review
● Pair programing
● Políticas de repositório

Code review

Code review é um processo de revisão de código, onde uma segunda / terceira

pessoa irá revisar o que foi alterado / adicionado / removido do código em questão. Um
dos objetivos do code review é garantir que erros que possam ter passado despercebidos
pelo desenvolvedor sejam “pegos” por outros membros da equipe, garantindo assim uma

34
maior qualidade na entrega deste trecho de código, e consequentemente no produto final
como um todo.

Um code review acontece após a atividade de commit / push de um

desenvolvedor quando finaliza determinado raciocínio, as ferramentas de SCM por sua
vez irão notificar os responsáveis pelo review que há uma nova atividade para que eles
atuem na revisão (aprovação / rejeição).

A fim de aumentar nosso poder de proteção, que tal os code reviews incluírem
também uma espécie de checklist de segurança? Os code reviews focam em performance,
estilo do código, guidelines, nomenclatura etc mas normalmente deixam de lado questões
de segurança em específico como:

● Buscar por potenciais vulnerabilidades

● Verificar se os erros são tratados corretamente
● Observar falhas simples como:
○ Credenciais fixadas no código
○ Vazamento de dados sensíveis
○ Comentários com informações indevidas
● Verificar se o código já foi analisado por alguma ferramenta SAST por exemplo

São diversas as possibilidades, listei algumas como incentivo para que você possa finalizar
este parágrafo e já aplicar algo no seu dia a dia hoje mesmo.

Pair programming

A programação em par (ao meu ver) ajuda muito a elevar a qualidade do código
se bem executada (pode atrapalhar um pouco em pessoas menos experientes na prática),
introduzir conceitos de segurança nesta prática, aumenta ainda mais a qualidade do
código como um todo.
Basicamente uma programação em par é feita, adivinha? tic tac… tic tac… por
duas pessoas normalmente o piloto e o co-piloto (enquanto um programa de fato o
outro faz a sombra), normalmente o co-piloto é quem cuida da parte de qualidade e dá
dicas e “pitacos” acerca das melhorias. Legal seria, se este co-piloto fizesse observações
sobre segurança, cuidados com vulnerabilidades etc como descrito no code-review
anteriormente (e usando as técnicas aprendidas aqui).

Políticas de repositório

Aqui o apoio da sua ferramenta de SCM (Source code management) é crucial, você
pode definir algumas políticas para evitar que o código seja submetido fora de alguns
padrões, como por exemplo você pode definir que:

35
 ● Não será aceito código sem ao menos a aprovação de X pessoas
● Não será aceito código sem comentários / documentação
● Se não tiver um scan associado (integração com outras ferramentas)
● Se o mesmo usuário possui histórico de reprovação, maiores “checks” podem ser
requisitados
● Não é aceito código submetido fora de um determinado horário
● Etc

Essas políticas ajudam bastante a evitar que o código avance com problemas e venha
compor o produto final algumas sprints à frente.

Notou que essas técnicas praticamente não dependem de ferramentas? Ou, as que
dependem são ferramentas que você já usa como o SCM por exemplo ou ainda um simples
plugin, nada demais. E o poder que elas te dão na defesa contra a criação de
vulnerabilidades é muito grande, praticamente a custo zero você só tem a ganhar, certo?
Errado, sempre haverá um ruído por parte dos devs (e outras figuras envolvidas) e
falaremos disso num capítulo mais adiante.

SAST - Static Application Security Testing

Presente

Antes de começarmos este trecho, quero te dar um presente já que chegou até aqui.
Se você clicou direto no índice ou fez scroll, volte e leia até aqui. É sério, volte e leia até
aqui pacientemente, não vale “hackear”. Mano… é sério volta lá vai… lê direitinho e com
calma, ai o presente será justo!

Beleza, leu né? Então aqui está um cupom de desconto exclusivo para o meu curso
Explicando, SAST, só usar o cupom EULIOLIVRO para ter desconto especial

Introdução, curtinha

Este não é um livro de SAST, portanto serei breve na introdução. Análise SAST ou
análise estática do código, é basicamente um software que analisa o código fonte (ou
binário) em busca de “padrões pré definidos” (queries / regras) que podem corresponder
a uma vulnerabilidade. Cada ferramenta de SAST trabalha de uma forma diferente com
relação a isso, mas todas tem sua “base de regras” que basicamente ela usa para dar
“match” no seu código. Em resumo, uma ferramenta que faz um “raio-x” do seu código e
te mostra se “têm ou não uma fratura”, gostou da analogia?

Já para matar sua curiosidade, ansiedade e afobação, eu sei que você está se
perguntando “Qual ferramenta SAST favorita do Cássio?” ou “Qual a melhor ferramenta

36
SAST do mercado?” ou ainda “Quanto custa uma ferramenta SAST?” vou te responder
com apenas dois links:

● Checkmarx
● Nova8

Integrações

Pronto, agora sim vamos falar sobre SAST no dia a dia. Em resumo, tenha um
SAST, não é opcional hoje em dia em meio a tantas vulnerabilidades em software que você
não faça scan do seu código com uma ferramenta dessas. O SAST pode ser integrado de
várias formas ao seu SDL, o mais comum / popular é na esteira, ou seja, para cada build
disparado na sua esteira, será disparado também um scan no SAST, essa é a forma
literalmente mais comum que vi ao longo dos meus 20 anos de estrada em T.I. e InfoSec /
AppSec. Mas as tecnologias avançam muito rápido, hoje em dia as formas de integração
são as mais variadas, vou listar algumas mais adiante e você decide qual é a melhor para
o seu time / modelo de trabalho, tenha em mente que o quanto antes você encontrar os
problemas melhor, e vale lembrar também que dependendo da ferramenta SAST que você
escolher uma ou outra opção pode não estar DISPONÍVEL (dica, o Checkmarx têm todas):

● IDE
● Repositório
● Repo actions
● Pipeline
● CLI
● API

Agora vamos entender em detalhes esses pontos e ver as possibilidades, vantagens e

desvantagens de cada um deles a seguir.

IDE
A integração na IDE ajuda muito na detecção de vulnerabilidades o quanto antes,
algumas ferramentas possuem a possibilidade de fazer scan direto da IDE, mesmo que o
scan seja executado num servidor e não na máquina local. Mas o principal ponto desta
integração é a possibilidade de visualizar os resultados de um scan, já navegar pelo código
e executar a correção necessária, isso é praticamente como fazer exames todos os dias em
busca de uma doença, perceba que não evita a doença, mas irá encontrar ela rapidamente
permitindo assim agir rápido na cura, o que aumenta muita suas chances de
sobrevivência.

A maior vantagem dessa integração é o desenvolvedor poder fazer um scan (ainda

automatizar isso) a qualquer momento, o que praticamente elimina o retrabalho em

37
estágios futuros no ciclo de desenvolvimento, por exemplo, quando o time de segurança
for fazer alguns testes, ou ainda no SAST da esteira que falaremos adiante.

A maior desvantagem dessa integração é que todo SAST possui limitação de

processamento, normalmente na licença ou na infra-estrutura (hardware). Se você possui
muitos desenvolvedores, e todos fazem scans constantemente, sua fila de scans pode ficar
grande, consequentemente o tempo de scan ser maior, logo, mais ruído, menos
engajamento aí alguém vai falar “tira!”, pronto acabou a segurança neste ponto, então
cuidado, uma boa estratégia é limitar quem (time, squad etc) pode fazer este tipo de
integração.

Repositório
Qualquer SAST que preste (não é brincadeira) no mínimo tem que integrar com
seu repositório (Git, SVN, Bitbucket etc), afinal é uma ferramenta de análise de código, e
onde TODO MUNDO “guarda” o código? No SCM, ou repositório no popular, logo essa
integração é muito útil. Basicamente no SAST, você aponta o seu repositório, branch,
autenticação caso necessário etc, pronto… o SAST “faz o checkout” do código e faz o scan.

A grande vantagem dessa integração, se dá pelo fato de você não precisar de

nenhuma outra ferramenta ou etapa no meio, uma vez que o SAST tem acesso ao seu
código, ele faz o scan sem maiores problemas. Inclusive sugiro que você faça um
agendamento (maioria dos SASTs faz) de scans, por exemplo, diariamente a noite faz
checkout da branch master e faz análise, todo dia pela manhã você terá um relatório
fresquinho (para já corrigir se for o caso).

A desvantagem é que você não vai usar essa integração se você tem um CI/CD
por exemplo, você será tentado a fazer um job no seu CI, e não utilizar essa integração,
tudo bem, nada de errado. Outro ponto também é que, talvez o SCM que você usa pode
não possuir suporte pelo SAST, logo não conseguirá integrar (isso só se você usa algo
muito fora dos padrões, tipo Source Safe ).

Repo actions
Essa é a nova onda do momento, utilizar ações no seu repositório para disparar
outras ações, por exemplo, a cada commit e push no seu repositório, na branch dev, você
quer que uma análise seja executada no SAST. Essa é uma das integrações que mais
crescem nos últimos anos, cada vez mais o foco é no repositório que é o dormitório do
código em si. As ferramentas SAST podem oferecer APIs, CLIs ou ainda plugins nativos
para tal integração, normalmente são bem simples de se implantar.

A grande vantagem é que você define suas políticas (quais ações irão ser triggers,
em quais branches etc) uma única vez e pronto, só buscar os resultados do Scan, que
normalmente são enviados diretamente para o seu bug tracking favorito (falaremos mais

38
adiante). É possível também fazer o bloqueio de um pull request, por exemplo, caso o scan
tenha encontrado vulnerabilidades críticas, por exemplo.

A desvantagem é similar a integração da IDE, se você não possui um bom fluxo

de trabalho definido (git flow) por exemplo, seu SAST pode ser um gargalo de scans,
causando uma lentidão neste fluxo todo.

Pipeline
Esse é o modelo mais popular, integração na pipeline, no build, na esteira ou
simplesmente no processo de CI/CD. Ou seja, no momento que você disparar seu
orquestrador (Jenkins, Azure DevOps etc) haverá uma tarefa específica lá para executar o
scan SAST. Neste momento é comum ativar a quebra de build, caso o resultado do SAST
devolva um número X de vulnerabilidades críticas, por exemplo. Essa integração em si,
acontece via plug-in nativo, via CLI ou ainda API, a flexibilidade das ferramentas de CI +
SAST permitem tal versatilidade.

A grande vantagem é que este modelo é transparente, o desenvolvedor não precisa se

preocupar com muita coisa, apenas se o build dele passou ou não, e atuar nas correções
se for o caso.

A desvantagem é que este modelo SOZINHO já é um tiro no pé, pois a definição de CI/CD
você já está na frente do processo, as análises poderiam ter sido feitas antes, neste
momento o risco de encontrar mais vulnerabilidades, quebrar o build e gerar ruído é
maior, logo corremos o risco de "ficar de fora".

CLI e API
As integrações mais versáteis são definitivamente essas duas (que resolvi falar
delas juntas), elas são agnósticas, e funcionam em praticamente qualquer lugar. Se o seu
SAST por exemplo não possui um plugin para sua IDE, você pode automatizar algumas
funções usando o CLI pois pode ser executado de qualquer lugar, o mesmo vale para seu
CI / CD, praticamente todos do mercado possuem uma forma de command line.

APIs são praticamente universais, hoje em dia todo software (que preste) estende
suas funcionalidades via APIs, que você pode consumir e integrar da maneira mais
cômoda para você e seu cenário. APIs são mais utilizadas para reporting e indicadores,
mas também muito úteis para funções mais comuns.

A grande vantagem desses dois é justamente sua flexibilidade, fica praticamente

algo personalizado quando você integra utilizando alguma dessas formas.

A desvantagem é a manutenção, qualquer atualização no CLI você precisa replicar

no seu lado para garantir que continue funcionando, e no caso das APIs é que você precisa
desenvolver algo do seu lado, APIs não “funcionam sozinhas”.

39
A análise

O scan estático acontece quando seu código é analisado pela engine do SAST, uma
vez que o código não é executado mas sim apenas lido, daí o nome de análise estática. A
engined o SAST vai "montar" um flow do seu código, como se fosse um diagrama para
entender os fluxos, validações, como os parâmetros são tratados etc etc etc e determinar
com base nisso se o fluxo do código possui alguma vulnerabilidade, claro que para
determinar isso o SAST têm uma base de como as vulnerabilidades acontecem para poder
comparar.

Importante destacar que, parte dos resultados de um SAST dependendo da

ferramenta mais ou menos, são falsos positivos, ele te mostra como problema mas na
verdade não é. Meu feeling por experiência é que até 30% dos resultados podem ser falsos
positivos, especialmente em linguagens como C e C++. Já em C# e Java até 15% o que não
é ruim considerando a quantidade de verdadeiros positivos (que é o que buscamos)
encontrados. Por isso é importante ler o capítulo futuro onde irei abordar o tema Gestão
de vulnerabilidades.

Conclusão

A análise SAST é uma das principais armas contra vulnerabilidades em software

(eu diria a principal), ela é a primeira linha de defesa (tirando os plugins lint) tecnológica
(tirando processos e práticas como falamos anteriormente) para o código fonte. Seu poder
é indispensável para um S-SDLC saudável e eficaz na luta contra as vulnerabilidades, e
dependendo de como você integra ao seu SDL esse poder pode ainda ter ganhos extras.

O sucesso de um projeto SAST depende muito de como ele será integrado ao seu
processo SDL, uma implantação errada pode custar caro para sua segurança, tanto para a
falsa sensação de segurança quanto para o bypass de processos por conta do ruído
desnecessário que pode ser causado.

SCA - Software Composition Analysis

Introdução

Ter um SCA hoje integrado ao seu ciclo de desenvolvimento é tão crítico quanto
respirar (não dá para ficar sem). Estima-se que X% de um software é composto por
bibliotecas de terceiros, ou seja, SCA é ainda mais crítico que SAST para cuidar do seu
código de fato, eu diria que para ter 100% de cobertura de testes de segurança, você precisa
de SAST + SCA, se tiver que escolher apenas um para começar, comece POR SCA (abrange
mais código). Esse tipo de análise é bem mais simples que o SAST, uma vez que é
basicamente um “cara crachá”, não tem de fato um processamento pesado, leitura de
código etc, as ferramentas de SCA apenas interpretam seu arquivo de referências

40
basicamente o nome de uma biblioteca e sua versão, e consulta esses dados numa base de
vulnerabilidades públicas para saber se aquele componente é vulnerável.

Integrações

As integrações com ferramentas de SCA se assemelham muito com o SAST, mas

ao meu ver, o melhor momento de utilizar esse tipo de análise é diretamente na IDE do
desenvolvedor. Uma vez que ele adiciona bibliotecas no dia a dia, a análise constante
mostra praticamente instantaneamente se determinado componente adicionado traz ou
não risco ao seu software. Outro detalhe importante é que a análise é bem rápida,
novamente é só uma consulta a um serviço / banco de dados, não tem processamento,
logo integrar à IDE é uma maneira muito eficaz de fazer essa análise.

A análise

Importante fato sobre ferramentas de SCA é que todas (especialmente as

gratuitas), de certo modo, consultam bases públicas de vulnerabilidades como:

● National Vulnerability Database

● Common Vulnerabilities And Exposures
● VulnDB – Vulnerability Intelligence
● Open Vulnerability And Assessment Language

Algumas ferramentas enterprise, além de oferecerem funcionalidades interessantes como

reporting, integrações etc, possuem bases privadas de vulnerabilidades (além de consultar
também as públicas) que variam de acordo com cada fabricante.

Esse fato é importante para te ajudar na escolha da sua ferramenta SCA, pois pode
determinar o tempo que uma vulnerabilidade será incorporada por determinada
ferramenta em sua base de dados, logo isso afeta também o seu poder de descoberta.

Algumas ferramentas SCA podem depender do seu gerenciador de pacotes, por

exemplo em projetos .Net o NuGet, em projetos NodeJs o NPM etc, logo é importante ter
em mente que a estrutura de dependências do seu projeto pode afetar os resultados da
análise, por exemplo, se você possui dependências que só são utilizadas em
desenvolvimento e não em produção, talvez queira excluir da análise, então é importante
considerar essa questão também para evitar “falsos positivos”.

41
IaC - Infrastructure as code

Introdução

Com a ascensão da computação em nuvem, novas demandas e formas de trabalho

vão surgindo, IaC (Infrastructure as code) é uma realidade em grande parte do mundo
tecnológico, e por se tratar de código, temos que cuidar do nosso código certo?

Lembra quando você precisava acessar o painel de administração do seu provedor,

escolher qual versão do sistema operacional você queria, escolher tamanho e tipo do disco,
memória, configurações de rede, etc etc? Isso ainda existe, mas praticamente todos estão
migrando para o IaC, que é fazer tudo isso com uma simples “receita” que é um código
que contém esses dados, que será interpretado pelo seu provedor e irá de fato criar /
provisionar a infra-estrutura desejada. Não importa a linguagem ou framework seja
Ansible, Terraform, Cloud Formation entre tantos outros, o fato é que todas essas
“receitas” podem conter vulnerabilidades, mas não as vulnerabilidades comuns de
execução de aplicação, as vulnerabilidades aqui são mais relacionadas a configurações
indevidas, por exemplo, sua receita pode conter instruções para provisionar um servidor
linux, que possua a porta 22 (SSH) aberta para a internet, isso é um risco do ponto de vista
de segurança, então uma ferramenta de IaC iria apontar essa instrução como insegura.

Integrações

As integrações aqui seguem o mesmo padrão descrito anteriormente, IDE, CI/CD,

CLI, APIs ou plugins. O fato é que novamente estamos falando de código, logo a IDE é
onde o problema nasce, então é o melhor lugar para encontrá-lo, além claro de garantir o
double check na pipeline (onde normalmente o IaC é executado).

A maioria das ferramentas de IaC funcionam como CLI, geram um relatório

simples em alguns formatos de arquivo diferentes e pronto, sem muito dashboard ou
“enfeites”, de fato são análises mais simples e rápidas e não necessitam tanta função além
do scan e resultados.

A análise

A análise IaC é praticamente igual ao SAST, afinal é uma análise de código,

baseada em regras pré-definidas que executam uma varredura em busca de match. A
diferença é que código IaC não possui fluxo, chamadas de métodos / funções, são apenas
instruções simples, então a análise em si é muito mais rápida e possui menos falsos /
positivos que um SAST comum.

42
Automação
Daria para escrever um livro somente sobre este tópico, automação de testes de
segurança, afinal é tanta ferramenta de AST (Application Security Testing) que
literalmente daria para gastar uma vida aqui. É um tópico extenso, é possível fazer
diversos tipos de automação quando se trata de testes, ainda mais com o advento das
APIs, plugins e afins, mas tentarei ser breve.

Note que, na maioria das automações, irei incluir bug tracking (Vulnerability
Management) e notificação pois é fundamental alertar e gerir sobre as vulnerabilidades.

Dica 💡
Toda vez que você tiver alguma tarefa com “cara processo”, tipo, duas ou mais etapas
comece pensar em automatizar. Mesmo que seja uma etapa, o que “dispara” essa tarefa? Após ser
concluída, o que precisa acontecer? Muitas vezes você vai perceber que praticamente TUDO pode
ser automatizado de alguma forma.

Então vamos lá, vou seguir mais ou menos a estrutura de como foi este capítulo
para explicar algumas automações possíveis em cada cenário, com diagramas:

Code Review

Existem diversas formas de se fazer um code review, mas basicamente ele se inicia
após a conclusão de uma “task”, ou feature por exemplo, ou seja, o desenvolvedor finaliza
uma task e faz um push do código, ai começa o code review que normalmente é feito por
duas ou mais pessoas para garantir a qualidade do código + a adição de uma ferramenta
de segurança básica.

Algo mais ou menos assim:

43
 A ação de review pode ser ainda manual ou automatizada, por exemplo, o review
pode ser feito de forma empírica por uma ou mais pessoas, mas dependendo das políticas
e práticas da empresa, um review pode ser apenas um scan SAST por exemplo, ou um
scan SAST + scan de qualidade com o SonarQube por exemplo, e vale lembrar ainda que
as ferramentas de scan geram bugs / vulnerabilidades, esses outputs devem alimentar
um outro processo, Vulnerability Management que veremos mais adiante neste livro.
Esses outputs também são automatizados neste momento, como por exemplo:

44
 Essas duas formas de automatizar ou incluir automação no processo são na minha
visão indispensáveis (caso você faça code review) no processo de desenvolvimento
seguro, afinal você ganha muita escalabilidade, além de flexibilidade no processo. Você
ainda pode incluir a parte do “review done”, onde o desenvolvedor que originou o repo
acion será notificado, a task atualizada, etc, mas como disse daria para fazer um livro só
sobre isso (quem sabe), melhor parar por aqui.

Políticas de repositório

Aqui tá fácil, você consegue aplicar políticas nativamente no seu repositório para
garantir o nível de qualidade / segurança desejado, a automação praticamente é o
repositório quem lida, como mencionado aqui.

45
 O que pode ser acrescido aqui é, a criação destas políticas com base em algum
input de negócio, ou mesmo incidente, com APIs o céu é o limite, ou seu bolso.

SAST

O scan SAST muitas vezes é subestimado com relação à capacidade de automação.

As pessoas sempre associam SAST com pipeline, na verdade outros testes também, mas o
fato é que quando se trata de código, precisamos analisar sempre em busca de
vulnerabilidades, temos que começar direito como vimos aqui.

Mas vamos lá, muita automação claro que depende da capacidade da ferramenta
que você utiliza, os cenários descritos abaixo são possíveis na maioria delas:

IDE
Simples e objetivo, você pode automatizar o scan SAST para executar a partir de
uma ação na IDE, seja ao salvar um arquivo, ou mesmo abrir um projeto etc.

46
Repositório
Aqui é uma ligação direta entre o SAST e seu repositório, onde o SAST faz o get
do seu código automaticamente para executar o scan. Eu recomendo muito essa
integração, pois você não depende de nada além do SAST (e seu repo claro) para fazer
scans recorrentes, por exemplo, scan noturno diário para garantir uma análise completa
da sua branch / projeto constantemente, sem depender de action, IDE, pipeline etc.

Dica 💡
Faça essa integração no seu SAST e deixe agendado um scan noturno diário da sua branch
principal ao menos (outras branches também), você garante um resultado fresquinho todos os dias
para trabalhar nas correções e garantir menos vulnerabilidades no ambiente de produção.

Repo Actions
Como comentado anteriormente você define ações no seu repositório que irão
disparar um scan, mais ou menos assim:

47
Dica 💡
Aqui dá para fazer também a “quebra” de flow com base nos resultados do SAST, ou seja,
cancela / bloqueia o pull / merge request caso o threshold do SAST seja atingido, falarei sobre o
threshold logo mais adiante.

Pipeline
A mais óbvia das automações / integrações, a pipeline ou CI (continuous
integration) é um conceito bem forte no mercado, e podemos /devemos tirar proveito
disso para introduzir (garantir) segurança no processo também. As demais integrações
por serem menos óbvias talvez também a resistência em aceitar seja maior, aqui não todo
mundo já conhece e, aceita.

O diagrama abaixo é simples, mas as possibilidades são infinitas uma vez que o
start de uma pipeline pode se dar por qualquer fonte, seja um repo action, seja
manualmente, seja por uma API etc.

Dica 💡
Um ponto muito importante aqui e que traz uma vantagem enorme é a quebra do build, ou
seja, interromper / falhar a pipeline com base nos resultados do SAST. O que eu costumo sugerir
com relação a quebra de build irei descrever a seguir.

● Projeto novo modelo conservador, quebrar build quando houver

vulnerabilidades:
○ 3+ Altas / Críticas
○ 5+ Médias

48
 ○ 10+ Baixas
● Projeto novo modelo “não vai subir ninguém”, quebrar build quando houver
vulnerabilidades:
○ 0+ Altas / Críticas
○ 0+ Médias
○ 0+ Baixas

● Projeto legado, faz um primeiro scan e obtém os resultados e aí defina o threshold

para quebrar build quando houver MAIS vulnerabilidades do que o estado atual,
por exemplo você fez um scan e o resultado foi 95 vulnerabilidades altas, 50
médias e 200 baixas, então a quebra seria:
○ 95+ Altas / Críticas
○ 50+ Médias
○ 200+ Baixas

Esse último cenário ajuda a introduzir a cultura no time sem ruído (ain eu preciso
entregar e não vou conseguir corrigir tudo), ou ainda (ain desliga o scan) e coisas do tipo.
Você garante que o projeto NÃO VAI PIORAR, e vai começar a introduzir a cultura de
correção e educação com relação a criação de vulnerabilidades e o que é aceito de risco no
projeto.

49
API
APIs são a maravilha do desenvolvimento moderno, praticamente você conecta
TUDO à TUDO literalmente, não vou nem gastar tempo aqui desenhando algo, minha
única recomendação é, antes de usar uma API verifique se de fato não há um plugin
nativo, uma conexão direta ou mesmo um CLI que te auxilie, pois API demanda
desenvolvimento e manutenção, e isso pode ser um ponto crítico para o seu projeto. Uma
vez que você precisa manter algo ainda mais software, encarece demais a flexibilidade.

Dica 💡
Se você está adquirindo um SAST Enterprise (ou qualquer outra solução), garanta que ele
possua uma API extensa que você possa tirar proveito, você irá precisar cedo ou tarde, especialmente
na questão de indicadores e reporting.

SCA

Automações em SCA seguem o mesmo raciocínio do SAST (exatamente os

mesmos), podem ser feitas da mesma forma, a diferença é que na parte da IDE não precisa
fazer scan a cada vez que salva um arquivo, mas sim é possível adicionar uma automação
para cada nova biblioteca adicionada, fazer um scan imediatamente, por exemplo:

IaC

Automações em IaC seguem o mesmo raciocínio do SAST (exatamente os

mesmos), podem ser feitas da mesma forma, a diferença é que na parte da pipeline eu
consideraria a quebra de build “não vai subir ninguém”. No caso do IaC você

50
normalmente está provisionando um ambiente (seja produção ou não), os riscos
envolvidos são talvez ainda maiores que na própria aplicação, então aqui eu seria mais
rigoroso quanto a tolerância à vulnerabilidades.

KPIs
KPI ou Key Performance Indicator são o que eu gosto de chamar de “painel do
carro”, onde basicamente você tem informações objetivas para tomada de decisão. Em
Application Security é fundamental ter KPIs para cada etapa implantada, assim você
entende a saúde do projeto em si (como está a implantação de cada ferramenta por
exemplo) e claro, as informações sobre os seus projetos e resultados de scans etc.

Abaixo irei listar alguns KPIs que julgo necessários, ao menos a informação em si
pois a forma de filtrar ou agrupar pode variar de projeto para projeto assim como de
empresa para empresa, e vale separar ainda por SAST, SCA e IaC e também TUDO
JUNTO:

● Total de vulnerabilidades, em número e porcentagem

○ Por criticidade
○ Por projeto
○ Por time
○ Por dev
○ Por linguagem
● Total de scans, em número e porcentagem
○ Por projeto
○ Por time
○ Por dev
● Total de projetos
● Top
○ Top x vulnerabilidades (x < 10 eu recomendo)
■ Por criticidade
■ Por projeto
■ Por time
■ Por dev
■ Por linguagem
■ Por CWE / CVE
● Vulnerabilidades por período

Abaixo alguns exemplos para te incentivar, mas não acostuma que não terá em todo capítulo:

51
52
53
54
55
56
Ferramentas

● Visual Studio - Recomendo

● Visual Code - Recomendo
● SonarLint
● Checkmax Codebashing - Recomendo
● Kontra
● Veracode Security Labs - Recomendo
● Github - Recomendo
● Gitlab
● BitBucket
● Checkmarx SAST - Recomendo
● Checkmarx SCA - Recomendo
● Mend SCA - Recomendo
● Snyk SAST
● Veracode SAST
● Azure Pipelines - Recomendo
● Jenkins - Recomendo
● CircleCI
● Black Duck - Recomendo
● Kics - Recomendo

Conclusão
A conclusão é simples, faz o que eu falei acima e pronto não discute! Brincadeiras
à parte, é um fato que precisamos tanto práticas defensivas como Code Review, quanto
de suporte tecnológico para conseguir escalar como SAST e SCA e ainda IaC se for o seu
caso (algumas empresas ainda não usam tal tecnologia). Detalhe, implantando essas 3
soluções SAST + SCA + IaC você garante 100% de cobertura de testes de segurança no
seu código.

Minha sugestão é que você faça o seguinte (para começar):

● Tenha uma plataforma de treinamento de segurança para os desenvolvedores.

● Tenha um simples check list e implemente um processo simples de code review.
● Tenha uma ferramenta de SAST e:
○ Integre na IDE se possível;
○ Integre no seu repositório com scans noturnos;
○ Integre na sua pipeline com quebra de build para vulnerabilidades críticas;
● Tenha uma ferramenta de SCA e:

57
 ○ Integre na IDE obrigatoriamente;
○ Integre na sua pipeline com quebra de build para vulnerabilidades críticas;
● Tenha uma ferramenta de IaC e:
○ Integre na IDE;
○ Integre na sua pipeline com quebra de build para vulnerabilidades críticas
e médias;

Curiosidade

Se você tem o famoso casal SAST + SCA você garante já 100% de cobertura de teste de
segurança no seu código, você está fazendo scan do código fonte que você produz + as bibliotecas de
terceiros que você utiliza, com o SCA.

58
 Capítulo 3

E os meus segredos?

“Isso nunca vai acontecer comigo.”

—Cássio B. Pereira

59
Guia
Seguindo nosso guia, considere que estamos na fase de codificação ou CODE.

Introdução
Bom, os meus segredos mesmo eu espero que você nunca descubra mas, e os
segredos do seu software? É praticamente impossível um software que não possua uma
informação sensível ou, segredo, que precise consumir de alguma forma para funcionar.
Não falo apenas de usuário / senha, IP, endereços ou API keys, mas também portas,
diretórios, arquivos etc, são informações que não devem estar em config files por aí, eles
são muito frágeis. A verdade é que existem informações comuns que consideramos
segredos, e outras mais específicas para determinado negócio ou contexto que só você vai
conseguir classificar, o fato é que, muitas dessas informações na maioria das vezes vazam
simplesmente pelo fato de estarem armazenadas em locais impróprios e em plain text.
Você precisa da combinação de dois fatores para guardar bem os seus segredos.

Como
Você precisa armazenar seus segredos de forma segura combinando dois fatores,
local seguro e formato seguro. Local se refere no onde de fato, e formato se esse dado deve
ou não ser criptografado e como. Te explico, o dinheiro físico no banco não fica no
estacionamento ou no saguão, ele fica no cofre, uma sala específica, num local específico,
com chaves e segredos e mecanismos específicos para proteger melhor o ativo, no caso o

60
dinheiro. Com os segredos da nossa aplicação é a mesma coisa, queremos eles protegidos
de tal forma que, somente nossa aplicação possa acessá-los, nem mesmo nós como
desenvolvedores. É advinha, a ferramenta para isso se chama Vault, ou traduzindo, cofre.

Os cofres armazenam de maneira segura, permitem o acesso de maneira segura,

possuem mecanismos de defesa das mais variadas formas e são simples de integrar com
seu software. A maioria dos cofres armazena os dados no formato chave:valor e gera uma
chave única para acesso aos dados conforme permissões, essa chave ainda pode ser
rotacionada para aumentar o nível de proteção, a aplicação por sua vez só precisa da
“chave do cofre” para acessar os dados, e no formato chave:valor precisa da chave para
acessar o valor, em resumo.

Cuidados
Todo mundo agora se pergunta, mas e essa chave do cofre onde armazenar? Não
seria melhor deixar os dados diretamente na aplicação? O ponto é que, quando se trata de
vazamento de dados, todo cuidado é pouco, portanto armazenar essa chave do lado da
aplicação é uma tarefa um tanto quanto complicada. Muitos cofres trabalham com o
conceito de Identity Access Management IAM, ou seja, você cadastra sua aplicação no
cofre, configura as permissões e acessos e ele se encarrega de fazer essa gestão, por tanto,
ninguém ou “nada” conseguiria acessar o cofre, a não ser sua aplicação apenas, esse é o
melhor jeito ao invés de armazenar uma chave do cofre em algum lugar, mesmo que
criptografado, etc você teria muito mais trabalho, apesar de ser possível e viável também.

Automação
A maioria das soluções de cofre fornece APIs, como o Azure Vault ou o HashiCorp
Vault ou ainda CLIs muito simples de utilizar, e até mesmo interface de administração
para configurações gerais. Isso facilita muito a integração e automação dessas soluções, as
automações podem ser das mais variadas, como por exemplo:

● Ao realizar um deploy da sua aplicação, solicitar uma nova chave ao cofre e

invalidar a antiga;
● A cada x minutos, fazer um renew das chaves / acessos mais críticos;
● A cada nova aplicação, cadastrar no cofre e gerar chave;
● Para cada aplicação descontinuada, revisar as chaves;

Dica 💡
Vale destacar ainda que, automação neste ponto é praticamente crucial uma vez que a
sensibilidade das informações e da operação em si é alta, quanto menos intervenção manual melhor.

61
KPIs
Indicadores são importantes bla bla bla, o ponto aqui é saber como o seu cofre está
operando, não do ponto de vista Ops de fato mas do ponto de vista de AppSec, vamos ao
que interessa:

● Quantidade de chaves (acessos) disponíveis e válidos;

● Quantidade de chaves revogadas;
● Quantidade de aplicações cadastradas;
● Quantidade de acessos no período;

Isso é o mínimo para entender como seu cofre está inserido no seu ciclo de SDLC.

Ferramentas
● HashiCorp Vault - Recomendo
● SpectralOps
● AWS Secrets Management
● Google Cloud Key Management
● Azure Key Vault - Recomendo
● Confidant
● Keywhiz
● StrongBox

Conclusão

Segredos em todo lugar

Muitos desses segredos de aplicação não ficam armazenados apenas em código

(como má prática), mas também:

● Informações no próprio banco de dados

● Informações em variáveis de ambiente nos servidores
● Informações em arquivos de configuração
● Dados em variáveis na sua pipeline (CI/CD)
● E sabe Deus onde mais…
● Ahhh, aquele script powershell com privilégios de admin sabe? Tem SENHA LÁ!

Gente… gente…. comecem a utilizar um cofre PELO AMOR DE DEUS, muitas das
invasões em empresas, vazamento de dados e outros ataques se dão pela facilidade na
qual atacantes conseguem acesso à alguns segredos, pois de fato eles estão facilmente
acessíveis (inclusive à quem não deveria ter acesso). E antes de acabar essa parte, uma

62
ferramenta popular de cofre é o Hashicorp Vault, além do cofre nativo do seu provedor
de cloud, como Azure Vault por exemplo.

63
 Capítulo 4

CI / CD com segurança, mas ainda não é

DevSecOps

“Automação é a chave para o sucesso.”

—Cássio B. Pereira

64
Guia
Seguindo nosso guia, considere que estamos na fase de BUILD, TEST e RELEASE.

Introdução
Se você ainda não possui um fluxo de CI / CD (Continuous integration /
Continuous delivery) na sua empresa, trabalho, projeto sei lá… eu sugiro que você pare
aqui, estude sobre, implemente e depois volte, você corre o risco de não entender muita
coisa. De qualquer modo, conhecimento também nunca é demais, não é mesmo?

CI / CD é a sigla que representa Continuous Integration e Continuous Delivery,

conceitos fortes já no meio, assim como DevOps. Muita gente acha que DevSecOps, é
colocar uma ferramenta de segurança integrada no CI/CD e pronto, mas não é e veremos
mais detalhes num capítulo mais adiante. Essa é uma das fases mais críticas no SDL pois
é onde “vai rodar tudo” para entregar uma versão do software em determinado ambiente,
seja de teste ou produção. É get de código, é compilação, é teste disso, daquilo e daquilo
outro, é scan de segurança (mentira, pessoal não faz), é gestão de dependências, enfim
muita coisa acontece durante essa etapa que é orquestrada por uma ferramenta de CI,
como Jenkins, CircleCI, Azure Pipelines etc. Vale acrescentar que, quanto mais etapas no
CI, maior é a complexidade da chamada pipeline, e consequentemente maior demanda de
gestão, normalmente executada por um profissional de DevOps.

65
Build
A fase de build pode se confundir muitas vezes com compilação, claro que envolve
compilação para as linguagens que necessitam, mas se sua aplicação utiliza uma
linguagem que não necessita, por quê então teria a fase de build na pipeline? A fase de
build é literalmente CONSTRUÇÃO, ou seja, construir o pacote (software) com todos os
componentes necessários, artefatos, testes etc.

Aqui podemos voltar um pouco no tema SAST e SCA por exemplo, e verificar se
temos uma integração para análise neste momento. Algumas ferramentas SAST analisam
o código fonte puro, sem compilar, o disparo acontece neste momento. Enquanto outros
precisam analisar o binário, logo você precisará compilar primeiro antes de fazer a análise.
O scan de SCA também se encaixa aqui, este não depende de compilação, mas sim do
gerenciamento de pacotes apenas (muita vezes), ou seja, durante o processo de construção
da sua aplicação na pipeline, já temos a possibilidade de fazer 2 testes de segurança, no
início do processo.

Vale destacar que o SAST e SCA aqui devem ter um papel de double check, se
considerarmos que você já faz os scans necessários ANTES de chegar na pipeline, seja na
IDE ou utilizando repo actions, ou ainda os scans agendados diretamente no repositório,
ou seja, se você faz scan antes, encontra problemas antes e os resolve antes, aqui é um
double check, caso algum merge tenha trago problemas que não foram encontrados
anteriormente, ou ainda algo que não foi corrigido e deveria (crítico). Não mencionei
anteriormente de propósito, mas alguns SASTs possuem a função de scan incremental, ou
seja, um scan de menos código uma vez que ele compara o último scan FULL e faz scan
só do que foi alterado. Neste momento o scan incremental pode ser uma opção (se você
tem bem definido suas entregas e execução de pipeline) caso precise de performance na
execução da pipeline, ou ainda o scan full, se suas entregas são críticas.

Um contra-ponto aqui é, se você quebra sua esteira com base nos resultados do
SAST / SCA, logo não precisa de performance na execução, ou a performance não é um
fato crítico uma vez que você vai esperar a pipeline finalizar de qualquer jeito. Assim
como você espera os TESTES finalizar, qual o problema em esperar o SAST também? Vejo
muita gente com essa questão “ainn o scan SAST demora muito (5 minutos) trava minha
esteira toda”, e a esteira do cidadão demora já 23 minutos…

Test

CI/CD

Este momento é crucial no CI/CD (mesmo fora dele) pois demanda um certo
tempo de execução, onde testes serão executados para garantir a qualidade definida do

66
software. Você pode optar por incluir o seu SAST / SCA neste momento também, apesar
de eu não ver muita vantagem, afinal se você pode fazer o scan antes, por quê deixar para
depois?

Manual

Apesar dos testes automatizados estarem dominando o mundo de CI/CD, alguns

testes ainda são manuais, como o famoso teste funcional por parte do usuário (ou área de
negócio).

IAST
Aqui vale o encaixe de uma ferramenta muito poderosa chamada IAST (Interactive
Application Security Testing), basicamente quando a aplicação sofre iterações (ações) o
IAST de forma passiva (através de um agente) intercepta as requisições e analisa para
determinar se é ou não uma vulnerabilidade. É um grande aumento do seu poder de
defesa contra vulnerabilidades em software, mas há uma desvantagem neste ponto pois,
ferramentas IAST são um tanto quanto escassas no mercado , uma muito conhecida e
poderosa é o Checkmarx IAST.

Pentest
Testes manuais também abrem margem para aumentar ainda mais nosso poder
de segurança, aqui podemos introduzir o famoso pentest, ou teste de penetração. Um
profissional de segurança especializado realiza testes (inclusive automatizados) na
aplicação em busca de vulnerabilidades específicas que não foram (puderam) ser
encontradas nas fases anteriores.

O pentest aqui incluído no CI/CD ou no SDL como um todo, deve ser um pentest
com escopo muito bem definido, o pentest comum é muito abrangente, leva tempo e tem
seu custo relativamente alto. Aqui não cabe essa abordagem, o pentest durante o SDL, ou
ainda durante a fase de testes manuais de um software, deve ter o escopo definido a ponto
de o teste não demandar mais tempo que o necessário para manter o ciclo viável, por
exemplo, não cabe um pentest de 40hrs nesta fase, não faria sentido.

Mas você pode se perguntar, e o DAST? Falaremos mais adiante.

Release
A entrega ou release, acontece em algum dos ambientes listados abaixo, talvez
você conheça outros termos mas em geral são definidos assim:

● Dev ou desenvolvimento
● Teste ou QA
● Homologação

67
 ● Pré-produção
● Produção

Normalmente as etapas que compõem uma pipeline dependem do ambiente para o qual
a entrega / release será feita. Se sua empresa possui um nível de maturidade em AppSec
maior, tendem a ter mais testes e etapas na pipeline de produção também.

Antimalware
Na entrega do software de fato é importante garantir que não estamos entregando
algo malicioso, como assim? Já imaginou entregar um software com malware para o seu
cliente / usuário? Muitas vezes não temos controle de todo o fluxo de SDL na nossa
empresa, portanto é crucial termos uma forma de validar isso. A forma mais comum é
fazer um scan de malware (antivírus / antimalware), ou seja, quando sua pipeline estiver
prestes a executar a última (ou últimas) etapas inclua uma task para fazer esta análise,
uma ferramenta bem comum para isso é o Virus Total ou ainda o Metadefender.

Assinatura digital
Uma demanda relativamente forte do mercado é a garantia de integridade das
informações, “nós” como desenvolvedores de software devemos garantir que nosso
software, foi feito por nós mesmo… como isso? Faça o teste, clique com o botão direito do
mouse em algum software que você tem instalado no computador, sei lá pega o VSCode
e analisa, você verá algo mais ou menos assim:

Isso significa que o arquivo [Link] foi assinado digitalmente pela Microsoft
Corporation, pois só ela possui um certificado (gerado por uma entidade certificadora)
em seu nome permitindo assim garantir sua assinatura digital. Em resumo, isso prova que

68
a Microsoft gerou este executável e não o Zé das Couves (que não desenvolve o VSCode,
imagino eu).

Existem várias formas de assinar um arquivo digitalmente e não vale entrar no

mérito aqui, depende do seu sistema operacional, depende se você vai assinar um arquivo
comum ou uma imagem docker etc, o fato é, tenha um certificado digital para sua empresa
e comece assinar os seus arquivos ANTES de entregá-los (release) em produção,
especialmente se o seu software não é uma aplicação web (que ninguém deveria ver
arquivo nenhum). E aqui vale um destaque importante, não vale nada assinar seus
arquivos e entregar malware, então uma análise malware como falamos acima é
fundamental junto com este processo.

Automação
Estamos no centro das automações quando falamos de CI, o principal objetivo de
um CI é manter as integrações adivinhe, contínuas (hur dhur).

Tudo que foi falado em Cuidados com o código, se aplica exatamente neste ponto
da automação, o CI é o grande orquestrador, o grande maestro, o responsável por manter
o seu ciclo de testes, validações etc integrado e íntegro para garantir a melhor qualidade
possível, automaticamente. E com a segurança não é diferente, no seu CI você deve
integrar todos os testes possíveis, como na figura abaixo:

Slide da minha apresentação no Meetup da OWASP Poland em 2022, conteúdo completo

aqui

Aqui vai um diagrama de como normalmente (e recomendo) que uma pipeline

automatize os testes de segurança, eu inclui apenas SAST, SCA e DAST para ilustrar, mas

69
considere todos os demais testes necessários com seus devidos requisitos como na figura
acima:

KPIs
Indicadores são poderosos, já falei né? É muito importante medir o seu “sucesso”,
ou mesmo sua operação, ou simplesmente responder a pergunta, “estou no caminho
certo?” Pois bem, alguns indicadores que julgo importantes aqui são:

● Tempo de execução da pipeline;

● Tempo de execução da pipeline só com testes de segurança;
● Frequência de deploy (te ajuda a tunar suas ferramentas de segurança, como SAST
e DAST);
● Frequência de falhas (Tanto de execução quanto dos testes em si);

Tudo isso, seguindo o padrão de agrupamento por time / squad, projeto, produto, etc,
além claro, do agrupamento por período.

Ferramentas
Aqui vale um outro livro só para listar o tanto de ferramenta que tem para CI, mas
vou listar talvez as mais populares:

● Jenkins - Recomendo
● Azure Pipelines - Recomendo
● AWS Codepipeline

70
 ● CircleCI
● TeamCity
● Bamboo
● GitLab
● Buddy
● Travis CI
● Codeship

Conclusão
Nem tudo é sobre o seu CI / CD meu jovem, perceba que são diversas etapas
orquestradas, que devem sim executar diversas tarefas a fim de continuamente integrar
(CI) diversas ferramentas e processos para garantir entregas contínuas (CD) de um modo
escalável. Daria para fazer tudo isso manualmente, mas não faria sentido dependendo do
seu projeto (processo ou empresa), o problema ao meu ver é que tudo fica concentrado no
CI/CD e muita coisa poderia ter sido feita antes no SDL, otimizando assim o processo
como um todo e especialmente o fator tempo, quando se trata de vulnerabilidades (e
bugs) o quanto antes encontramos, antes corrigimos.

71
 Capítulo 5

Fiz deploy, e agora?

“Subiu?”
—Cássio B. Pereira

72
Guia
Seguindo nosso guia, considere que estamos na fase de DEPLOY.

Introdução
É muito comum pensarmos que após o deploy não precisamos mais fazer nada,
mas é um erro pois muitas vezes temos algumas atividades a serem realizadas e o que
importa é entender que essas atividades necessariamente precisam de segurança e não
devem ser descartadas. Como destacado anteriormente o deploy acontece em ambientes
diversos, a grande questão é entender quais atividades (testes) de segurança precisamos
aplicar para cada ambiente. É nesse momento que destacamos o teste dinâmico de
aplicações ou famoso DAST (Dynamic Application Security Testing) que ainda é
conhecido popularmente como web scanner. Comentei anteriormente que o pentest
também faz parte do nosso dia a dia, no entanto é importante destacar que o DAST é um
teste feito após o deploy (o pentest também), mas o DAST pode ser automatizado neste
caso, o pentest nem tanto. Propositalmente eu comentei de pentest durante o teste manual
(seguindo o SDL) e não estou comentando sobre pentest agora mas também seria possível
executar um pentest neste momento, logo após o deploy, aliás é neste momento, vai fazer
pentest onde se não há aplicação? Apenas no nosso ciclo de entrega eu quero que você
compreenda que, os momentos são diferentes, um teste manual PODE ser requisitado
mesmo durante a execução de uma pipeline (que vai aguardar a intervenção manual).

73
Como
É fácil pensar que após fazer o deploy da aplicação acabou, agora o usuário
“valida” (se não for produção) e sucesso. Mas a verdade é que não é bem assim (ou não
deveria ser), quando falamos de segurança de aplicações são muitas etapas durante o SDL
e em cada uma delas devemos considerar algum tipo de teste de segurança.

Muitos de vocês sabem eu morava em São Paulo, e é uma cidade um tanto quanto
não segura, normalmente as casas em São Paulo são equipadas com cerca elétrica com
câmera de monitoramento, com alarme, com cachorro, enfim são diversas as proteções
que os moradores colocam para inibir a ação de ladrões ou pessoas que querem furtar a
casa ou coisa do tipo. Quando a gente fala de segurança em aplicações é mais ou menos a
mesma coisa, é importante pensar que durante o ciclo de desenvolvimento de software ou
SDL devemos considerar várias camadas de proteção e é exatamente isso que a gente vai
fazer agora na parte de deploy ela não deixa de ser uma etapa no ciclo de desenvolvimento
logo também demanda de alguma proteção.

Tanto pentest quanto IAST dariam também para encaixar neste momento como já
comentei, mas o ponto aqui é a gente focar no DAST que talvez seja uma forma de testar
aplicação digamos, mais eficaz. Vale lembrar que quando você faz um deploy para
produção não é recomendada a execução de um DAST, por quê você pode causar a
indisponibilidade do ambiente, assim como causar uma queda de performance ou outros
problemas. É altamente recomendável que você execute um DAST em qualquer ambiente
não produtivo, a fim de garantir que o teste será executado e você não causará “fogo
amigo”.

Se você quer muito testar produção, o IAST aqui faria mais sentido uma vez que
ele é passivo, apenas intercepta as requisições a fim de fazer a análise, o DAST é ativo e
vai disparar requests maliciosos contra a aplicação podendo causar danos.

KPIs
Da para encaixarmos aqui os mesmos KPIs de CI/CD além deste:

● Quantidade de deploys;
○ Por ambiente;
○ Por projeto
○ Por time

É mais que necessário saber quantos deploys você faz, por ambiente a fim de
garantir a segurança destes e afinar os testes inclusive. Por exemplo, para deploys em
produção, eu particularmente não recomendo rodar teste DAST, apenas em ambientes
menos críticos.

74
Automação
Após o deploy você pensa, acabou né? Sim acabou, valeu, falou… brincadeira. Não
acabou não, alias agora que começa a treta, antes era só “dev”, agora você está em
produção, ou seja, o risco é real agora.

Automação que cabe aqui eu diria que são as conexões com as ferramentas de
monitoramento, que veremos já no próximo capítulo.

Algumas delas básicas que eu poderia citar são:

● Garantir a geração de logs, nos locais adequados;

● Avisar as ferramentas de monitoramento sobre o novo deploy;
● Notificar as pessoas sobre o novo deploy;
● Ativar o IAST, se possível integrar ao SAST;

Ferramentas
Algumas ferramentas populares para testes após o deploy (na minha visão) são:

● OWASP ZAP
● Acunetix / Netsparker Recomendo
● Bright (NeuraLegion) Recomendo
● Probely
● Fortify WebInspect
● WhiteHat Dynamic
● Checkmarx IAST Recomendo

Dica 💡
NÃO EXECUTE DAST EM PRODUÇÃO! Ain mas Cássio… NÃO!! FODACY! Não
faça isso! Você, sua empresa, etc não têm maturidade para isso, e discutiremos noutro livro!

Conclusão
É comum encontrar aplicações sem o mínimo de monitoramento, o que ao meu
ver é desastroso do ponto de vista de cyber segurança, afinal, é crucial saber o que
acontece com sua aplicação, especialmente se ela for Web. Inclusive (e não à toa) está no
OWASP Top 10 como a 9º vulnerabilidade mais comum Security Logging and Monitoring
Failures pois justamente muitos ataques são bem sucedidos por falta de monitoramento,
que poderia alertar sobre um ataque e por sua vez permitir uma ação de defesa mais
rápida, mitigando o ataque, reduzindo o impacto etc.

75
 Capítulo 6

Conheça o comportamento da sua aplicação

“Se você não conhece o comportamento da sua aplicação, não saberá quando for atacado.”
—Cássio B. Pereira

76
Guia
Seguindo nosso guia, considere que estamos na fase de OPERATE e MONITOR.

Introdução
Você quer fazer uma bela viagem de carro, talvez pelo nordeste brasileiro, ou pelas
montanhas nevadas aqui na Polônia, não importa você prepara sua viagem, roteiro,
gastos, o que levar na mala, onde você quer parar para abastecer, etc etc. Chegou o grande
dia, você coloca tudo dentro do carro, liga o carro e vrooom, durante a viagem você precisa
parar para abastecer, comer, esticar as pernas, de repente trocar um pneu pois imprevistos
acontecem, e você toma todas essas decisões com base no comportamento do seu carro (e
do seu corpo), que por sua vez te dá informações (logs) sobre o que está acontecendo, por
exemplo, o indicador de combustível vai piscar, emitir um som ou algo assim quando
entrar na reserva, enquanto isso você pode acompanhar durante O TEMPO TODO o
medidor, além claro de outras informações úteis como velocidade, temperatura do motor
etc.

Você já percebeu que, sem INFORMAÇÃO não dá para seguir a viagem, aliás até
dá, mas você não saberá quando precisa tomar alguma ação caso necessário, ou seja, um
carro sem painel, um ser humano sem (dor, ou indicações do que precisa como fome) não
vai funcionar corretamente, especialmente quando um problema acontecer.

77
Como

Reforçando o que falamos na conclusão do capítulo anterior um dos principais

problemas em aplicações é a ausência de logs e monitoramento como você pode ver na
íntegra no OWASP Top 10 como a 9º vulnerabilidade mais comum Security Logging and
Monitoring Failures. Ou seja, aplicações simplesmente não geram logs de segurança para
monitoramento (existem logs de auditoria também, não trataremos neste livro), o que é
praticamente dirigir um veículo sem o painel com as principais informações necessárias
para a operação. Conhecer o que ACONTECE na sua aplicação é fundamental para se
proteger de um ataque, de forma preventiva e principalmente reativa.

Imagine que você criou e publicou uma API na internet que tem como
funcionalidade principal mostrar a temperatura em qualquer cidade do mundo, você
informa o nome da cidade e a API te responde com a temperatura em graus Celsius.
Exemplo:

GET [Link]

RESPONSE 22º

Agora as perguntas são:

● Quantos requests a sua API possui por minuto? Hora? Dia? Mês?
● Qual a cidade mais pesquisada?
● Quantos requests sua API respondeu com erro?
● Será que tem algum bot fazendo “crawling” da sua API para roubar os dados?
● Qual a origem das requisições (IP location)?

Algumas perguntas de negócio, outras de segurança… o fato é, como você

responde todas elas? De forma fácil e eficaz? Com LOGS, algo que TODO SISTEMA
OPERACIONAL, TODO WEBSERVER têm NATIVAMENTE. Você muitas vezes não
precisa nem habilitar, já estão lá, noutros caso você precise apenas habilitar, e configurar
os dados que você quer, e pronto.

Não precisa ter um Web Application Firewall para monitorar sua API, não precisa
ter um Web Server específico para isso, você só precisa basicamente de espaço em disco
para os logs. O log principal que queremos aqui é o Access Log, que contém informações
muito úteis do ponto de vista de segurança para monitoramento, por exemplo:

● Quantos requests a sua API possui por minuto? Hora? Dia? Mês?
○ No Access Log garantir o campo Data e hora, depois agrupar por período.
● Qual a cidade mais pesquisada?
○ No AccessLog garantir o campo URL + parâmetros.
● Quantos requests sua API respondeu com erro?

78
 ○ No AccessLog garantir o campo Response Code
● Será que tem algum bot fazendo “crawling” da sua API para roubar os dados?
○ Uma combinação de informações
● Qual a origem das requisições (IP location)?
○ No AccessLog garantir o campo IP ou Client_IP e X-Forwarded-For

De posse dessas informações, você consegue responder a essas e outras questões

EM TEMPO REAL praticamente, podendo até mesmo impedir um ataque quando houver,
ou de forma preventiva entendendo o comportamento normal da sua aplicação.

Mais um pouco de exemplo, se durante 1 mês todo (30 dias) sua API recebe mil
(1.000) requests, e você analisou dados de 12 meses por exemplo, isso quer dizer que,
quando sua API começar a receber mil (1.000) requests num só dia, opaaaa temos um
problema, pode ser um DoS, DDoS, algum bot tentando mapear seus dados, etc, o fato é
que sem saber que mil (1.000) é seu comportamento normal para 1 mês, como você saberia
que sofre um ataque? Não saberia meu caro, por isso é crucial entender o comportamento
da sua aplicação EM PRODUÇÃO, não me venha monitorar ambiente de testes e querer
aplicar regras para produção que não faz sentido.

Se sua API deve servir apenas usuários do Brasil por exemplo, sabendo os IPs de
origem das requisições, você consegue saber se tem alguém não permitido acessando sua
API, neste caso só um requisito de negócio para requets originários do Brasil, para
proteger e bloquear mesmo, você precisa aplicar técnicas de Autenticação e Autorização
que não trataremos neste livro.

O que você deve fazer é o seguinte, habilite os AccessLog da sua aplicação, seja no
SO, no Web Server, no CDN, no WAF não interessa, habilite da cadeia toda, e assim você
terá uma visão completa e fácil, acerca do MONITORAMENTO de sua aplicação e poderá
rastrear qualquer acontecimento, e terá dados para prevenção e reação tranquilamente.
Claro que, só ter os logs não ajuda muita, cada arquivo fica muito pesado, além de não ser
de fácil leitura para um humano, então coletar esses logs (dados), centralizar eles num
banco de dados só, e aí sim transformá-los em informações úteis é uma tarefa fundamental
para este capítulo te trazer “sucesso” em sua proposta.

KPIs
Alguns KPIs que você deve considerar aqui para garantir a saúde do seu
monitoramento são:

● Volume de logs em MB / GB
● Se a coleta de logs está ativa ou não, por source
● Volume do seu banco de dados de logs

79
Automação
Logs são simples de automatizar, pois uma vez habilitado ele será gerado “para
sempre”, mas alguns pontos vale uma atenção especial:

● Configurar um Log rotation, de quanto em quanto tempo você vai “limpar” os

dados;
○ Tanto nas fontes (ex. server), quanto no seu syslog central.
● Configurar um alerta, caso seu log pare de ser gerado;
○ Tanto nas fontes (ex. server), quanto no seu syslog central.
● Configurar um alerta, para espaço em disco;
○ Tanto nas fontes (ex. server), quanto no seu syslog central.
● Configurar um coletor automático de logs, ou seja, você gera o log em qualquer
lugar (ex servidor web + cdn), e seu coletor busca nos 2 lugares e centraliza.
● Configurar um banco de dados centralizado para os logs, assim você terá o log de
todas as fontes (cadeia da sua aplicação) em um único local.
● Se é uma aplicação nova, configurar a geração dos logs no deploy (CI ou IaC se for
o caso).

Ferramentas
Aqui é o seguinte, eu poderia escrever outro livro só sobre ferramentas e formas
de gerar e gerenciar logs, de todos os tipos e “tamanhos” mas vou focar ok?

A primeira ferramenta a destacar é claro, o seu próprio ambiente nativo, ou seja,

se sua aplicação for Web e por exemplo a infraestrutura é 1 servidor web + 1 cdn + 1 banco
de dados, você precisa habilitar os logs nativos (Access Log) nos 3 locais, daí estará apto
a implantar o ELK como falarei a seguir. O log em si como falei no capítulo, é algo nativo
você já tem, só precisa “consumir”.

Hoje ao meu ver, o jeito mais fácil de implantar uma infraestrutura de coleta +
armazenamento + exibição de logs com o propósito de monitoramento de aplicações, é a
stack ELK. Você pode até se perguntar, mas Cássio existem ferramentas próprias para
isso, como é o caso do SIEM, certo? Sim, certo. O ELK tem propósitos gerais, logo, ele
passará a ser o seu SIEM Assim como é também o Splunk.

Pois bem, quando falamos de ELK estamos falando de 3 ferramentas:

● Elasticsearch - E = Banco de dados para armazenar os seus logs

● Logstash - L = Agente coletor para buscar (e tratar) os seus logs
● Kibana - K = Painel de visualização para agrupar e facilitar a visualização

80
 Seguindo o modelo que mencionei anteriormente, 1 servidor web + 1 cdn + 1 banco
de dados, você irá configurar seu logstash para buscar os logs dos 3 locais, que por sua
vez irá enviar ao Elasticsearch onde você poderá visualizar usando o Kibana, simples não?

O ELK é free, também possui versão enterprise e também uma versão SaaS (que
uso e recomendo).

Conclusão
Enquanto você dorme (literalmente) alguém ou algum grupo está de olho na sua
aplicação, dados, usuários, clientes, fornecedores o que for, pois deve (e tem) algum valor
para quem os quer, inclusive para você, senão você não os teria Então é crucial que
você conheça TUDO sobre a sua aplicação, é até estranho falar isso pois, normalmente
você que a desenvolveu já deveria saber, mas no mundo real não é assim. Diversos times
envolvidos, diversas tecnologias, requisitos… no final tudo junto funciona (de alguma
forma), e você precisa saber como tudo funciona e se encaixa para quando houver um
problema (veja que não disse SE HOUVER), você esteja mais preparado para lidar com a
situação, ou o que chamamos em InfoSec responder o incidente.

81
 Capítulo 7

Não basta encontrar problemas, tem que

resolvê los

“É igual ir ao médico, fazer exame, fazer exame, fazer exame e não resolver os problemas.”
—Cássio B. Pereira

82
Guia
Seguindo nosso guia, consideramos aqui TODAS as fases.

Introdução
Eu tenho o feeling de que aqui está um dos principais problemas em Application
Security, fazer uma simples (e boa) gestão de vulnerabilidades. E aí fica a pergunta, por
que é tão difícil definir e seguir um simples processo? Praticamente em toda empresa em
que trabalhei, havia um processo de “tasks” ou “bug management”, onde as demandas
eram catalogadas, priorizadas e acompanhadas, simples não? Não.

A verdade é que “o cliente nunca sabe o que quer”, e as prioridades mudam a todo
momento, é item que entra, que sai, que aumenta o escopo… praticamente um loop
infinito no que diz respeito à gestão de demandas. E as metodologias ágeis (salvadoras da
pátria), ao meu ver só colaboram para essa bagunça (antes de você dar xilique,
metodologia ágil são boas, se bem executadas), logo o bom e velho “planeja, executa” cai
por terra, afinal o “planeja” acontece a todo instante e a execução fica perdida.

Quando trazemos isso para o mundo da segurança, falamos especificamente em

VULNERABILIDADE, ou seja, mais um task a ser executada na sprint ou planejada para
o futuro, ou um simples BUG a ser resolvido para ficar mais claro. E convenhamos que é
uma task não tão complicada, não é uma nova feature, ou vai mudar a arquitetura inteira

83
(às vezes), não… é coisa simples (eu afirmo). Uma, duas linhas de código (muitas vezes),
e voilà done.

Então o que fazer?

Basicamente, implementar (e executar) um processo simples e eficaz de Gestão de

Vulnerabilidades é o que você precisa fazer. Você pode, claro, incorporar as
vulnerabilidades no seu processo atual de tasks, seja um backlog, ou algo do tipo, mas
não se esqueça que vulnerabilidade não é bug ou feature, algumas delas são URGENTE e
demandam uma atenção especial.

Não vou reinventar a roda, aqui no SANS você encontra prontinho um modelo a
seguir, onde basicamente ele te entrega um processo pronto, você só precisa implementar
na sua empresa. Em resumo o modelo propõe os seguintes passos:

● Preparação
○ Definir escopo de scan, ativos, donos e scans;
● Scan de vulnerabilidade
○ Scan inicial e coleta de resultados;
● Definir ações de remediação
○ Analisar as vulnerabilidades e decidir entre aceitar risco ou resolver;
● Implementação as ações de remediação
○ Implementar as correções;
● Re-scan
○ Fazer um novo scan e validar as correções;

Agora pare este capítulo, vá implementar este processo e somente depois continue
a leitura.

KPIs
Quando se trata de gestão de vulnerabilidades (tasks, bugs) os KPIs já são meio
que pré definidos, basta você pesquisar por qualquer project management KPIs na
internet, ou ainda utilizar os que a sua empresa/equipe já utiliza mas eu recomendo os
seguintes:

● Tempo de ciclo: O tempo necessário para concluir uma determinada

vulnerabilidade.
● Porcentagem de conclusão no prazo: se uma vulnerabilidade foi ou não concluída
em um determinado prazo.
● Tempo gasto: a quantidade de tempo gasto na vulnerabilidade.

84
 ● Horas planejadas vs. Tempo gasto: quanto tempo você estimou que uma
vulnerabilidade levaria em relação às horas reais.
● Capacidade de recursos: O número de indivíduos trabalhando em uma
vulnerabilidade.
● Quantidade de vulnerabilidades
○ Por criticidade
○ Por projeto
○ Por time / squad
○ Por dev
○ Por linguagem

Automação
Claro como a água cristalina, são as possibilidades de automação quando se trata
de “tasks”, ou mais especificamente vulnerabilidades.

Isso se dá pela grande variedade de ferramentas de scan ou fontes de “entrada”

de uma vulnerabilidade, assim como as inúmeras ferramentas de gestão, como
mencionado anteriormente o Jira por exemplo. Então para ser direto e simples, faça algo
como:

Ferramentas
Além das ferramentas de Bug tracking tradicionais, ou mesmo task managers que
são muito úteis neste caso, você pode optar por algo ainda mais específico como o Defect
Dojo por exemplo, que é específico para gestão de Application Security.

85
 Existem outras no mercado, enterprise, mas elas disponibilizam um scanner junto.
E não quero confundir você, uma coisa é scan (de código, infra, ativos, etc), outra coisa é
a gestão dos problemas encontrados de forma centralizada, e aqui um task manager
resolve, QUALQUER UM, feito é melhor que perfeito lembre-se sempre desta frase..

Conclusão
Não basta encontrar problemas, você precisa endereçá-los, priorizá-los, testá-los,
até que de fato seu ciclo de vida seja concluído.

86
 Capítulo 8

KPIs, para onde vou? O que faço?

“Ter indicadores, é um fator crítico de sucesso para o seu projeto de AppSec.”

—Cássio B. Pereira

87
Guia
Seguindo nosso guia, consideramos aqui TODAS as fases.

Introdução
Agora que comecei a escrever esse capítulo, estou pensando que nem precisava
dele. Praticamente todos os capítulos anteriores mencionam algo sobre KPIs e como
implementá-los. Bom, já que estamos aqui…

É um assunto pouco discutido na verdade, muitas empresas e profissionais se

preocupam (quando o fazem) apenas com a implementação em si, e não com um
monitoramento ou acompanhamento contínuo sobre a operação como um todo,
processos, ferramentas, pessoas… E muitas vezes é o que "mata" o projeto. Um bom
acompanhamento através de indicadores bem definidos, pode não só salvar um projeto,
como também pode fazer o "tuning" ou a tão comentada melhoria contínua.

KPIs
Mas vamos lá, que indicadores são esses? Indicam o que? São números? Textos?
Porcentagem? Como vivem? Onde vivem? Do que se alimentam?

Em resumo você precisa de informações (não dados, mas composta por eles) que
lhe dirão sobre a saúde do seu projeto / programa / departamento de AppSec. Essas
informações normalmente são extraídas ou consumidas das mais variadas fontes de dados

88
dentro do seu ciclo de desenvolvimento seguro, seja das ferramentas implementadas ou
mesmo o input de dados manuais por parte das pessoas envolvidas. Claro que, essa parte
mais manual é chata, mas vale lembrar que NEM TUDO pode ser automatizado.

A melhor forma de definir indicadores é através de perguntas, perguntas que você

precisa das respostas, que irá encontrar nos indicadores. Por exemplo:

● Quantas vulnerabilidades eu tenho?

● Qual a vulnerabilidade mais encontrada?
● Qual time produz mais vulnerabilidades?
● O que eu preciso me preocupar urgentemente?
● Qual o volume de correção de vulnerabilidades?
● Etc

Essas perguntas (que podem variar de empresa, negócio, projetos etc) é que
definirão quais informações extrair e apresentar como indicadores. Simples, não?

Automação
É de extrema importância afirmar e te preparar para que 90% da sua estratégia de
indicadores seja automatizada, sim, coletar, centralizar e apresentar os dados de forma
automática e independente é crucial, se você precisar fazer tudo manualmente você
simplesmente não irá fazer. Ou seja, os 10% que restam são de fato informações ou dados
que não podem por qualquer razão ser automatizado.

Ferramentas
Aqui sem muita novidade, os indicadores são praticamente dados que você já tem
nas suas ferramentas do dia a dia, SAST, SCA, DAST, IAST, IAC, etc. Você só precisa
centralizá-las para que essas informações pulverizadas possam compor uma informação
única a fim de auxiliar em uma decisão ou na resposta a uma pergunta.

Por exemplo, imagine que a pergunta que seu CISO faça para você seja, “Quantas
vulnerabilidades temos para o projeto X?”.

Suas possíveis respostas:

● Não sei, não temos nenhuma segurança aqui. “Rimos muito, fui kickado”.
● No SAST, temos 10, no SCA temos 5 e no IaC temos 2.
● Temos 17 vulnerabilidades para o projeto X.
● Temos 17 vulnerabilidades para o projeto X no total, sendo 3 críticas.

89
 Qual delas é a melhor resposta, pode até gerar uma discussão. Mas sem dúvidas o
CISO quer saber, quantas vulnerabilidades DEVO ME PREOCUPAR agora? Logo, a
última opção parece ser mais razoável, onde você mostra o total de vulnerabilidades e
ainda o total de vulnerabilidades que devem receber uma atenção mais urgente.

A segunda resposta é muito boa também, mas não para o nível executivo e sim
operacional da coisa. Perceba que indicadores têm um objetivo, informar de forma bem
objetiva a fim de permitir uma decisão, ou, responder uma pergunta específica.

Conclusão
Indicadores, métricas, KPIs não importa o nome, só vai mudar o nome se afeta seu
bônus no fim do ano mas isso não importa aqui, o que importa aqui é, DEFINA suas
métricas, é impossível ter um carro e viajar / dirigir constantemente sem um painel, sem
saber as informações de quando colocar combustível´, qual velocidade você está, como
está a temperatura do ar condicionado etc, as informações operacionais e executivas são
informações que irão te habilitar a tomar decisões sobre sua própria estratégia, não dá
para viver sem elas.

90
 Capítulo 9

DevSecOps, agora sim!

“Automação não é tudo, cultura é fundamental também.”

—Cássio B. Pereira

91
Guia
Seguindo nosso guia, consideramos aqui TODAS as fases.

Introdução
Sim, tudo o que vimos até aqui não é DevSecOps, é AppSec. Cuidamos de aspectos
essenciais para a segurança da aplicação em si, durante as diversas fases do ciclo de
desenvolvimento de software ou SDL. Ou seja, introduzimos o SDLC, Secure
Development Life Cycle.

Mas o que é então DevSecOps? É simples, é quando você tem tudo isso (como na
figura), de forma integrada, automatizada e auditada principalmente. O fato de você ter
um processo de threat modeling, um SAST e um SCA integrados no seu CI/CD
quebrando a pipeline, um vault para armazenar secrets e um painel de logs da sua
aplicação, não é DevSecOps. DevSecOps passa a ser real quando você tem tudo isso e,
quando você consegue responder perguntas do tipo:

● Quem tem permissão de alterar a pipeline x?

● Onde estão os logs de execução de testes de segurança para o repositório x?
● Qual vulnerabilidade ocorre com mais frequência nos meus testes de segurança?
● Quais os desenvolvedores possuem acesso de commit no repositório x?
● Se uma aplicação está sob ataque, quem pode ver os logs de segurança?
● Onde estão as modelagens de ameaças feitas para a aplicação x?

92
 ● Quem é o dono da aplicação x?

Perceba que são questões além de AppSec, mesmo que relacionadas, questões que ligam
o desenvolvedor, a segurança e operações de fato, agora para cada uma dessas questões,
uma resposta de faz necessária, e é como chegar a essa resposta que vai nos guiar para
implementar mais log, mais automação, mais controle de acesso, tornando assim de fato
o Dev o Sec e o Ops integrados a fim de trazer a segurança necessária para o negócio.

Hoje em dia (2023 / 2024) muito se fala em Supply Chain Attacks, ou Segurança
de Supply Chain… imagina o seguinte, você usa o VSCode como IDE, e ele tem uma
vulnerabilidade, isso é AppSec? DevSecOps? TI? Veja este vídeo (inclusive eu estava lá
ao vivo na plateia na DefCon em 2023) DEF CON 31 - Visual Studio Code is Why I Have
Workspace Trust Issues - Chauchefoin, Gerste e perceba que, um problema na IDE que
você usa para criar o seu código, é Supply Chain, a IDE é PARTE daquele software que
você está desenvolvendo, como você garante que a IDE de TODOS os desenvolvedores
está segura? Que a máquina deles está atualizada e com as políticas de segurança
aplicadas? Percebe que, DevSecOps é além de um scanzin na esteira? É quando você
conecta TUDO, TUDO, entende? TUDO… T.U.D.O. TUUUUUDOOOOO para garantir
que, o DESENVOLVIMENTO, a SEGURANÇA e a OPERAÇÃO estejam íntegras.

KPIs
É jovem, é um trampo…. agora imagine gerar KPIs de TODA A TI, a fim de ter
métricas de segurança para TUDO? Vou nem entrar neste tópico, é um livro só para isso!

Automação
HAHAHAHAH claro, agora o que e como vai depender completamente do que
você quer / precisa monitorar certo? Uma boa dica, tenha um SIEM para registrar isso
tudo. Também é tópico para outro livro!

Mas outra dica é, TODA ferramenta de TI em geral possui logs nativos, você só
precisa LER esses logs, de forma centralizada.

Ferramentas
Uma coisa que é fato, nada disso será possível sem ferramentas e não há uma única
que salve o dia… mas, existem algumas que facilitam e muito este trabalho, e aqui vou
mencionar uma categoria de ferramenta que ainda não comentei muito, que são os ASPM
ou Application Security Posture Management, ou ainda CSPM Cloud Security Posture
Management eles praticamente centralizam toda a parte de AppSec, CloudSec num lugar

93
só conectando nas suas mais variadas ferramentas e soluções. A dica é, comece com um
cara desses:

● CyCode
● Apiiro
● Jit
● Enso Security
● Panoptica

Não são ferramentas de DevSecOps, mas vão te poupar muito trabalho uma vez que
conectam em diversas fontes para praticamente responder as questões que levantamos no
início deste tópico.

Conclusão
DevSecOps é um mundo onde muito se fala e pouco se faz, justamente porque é
um trabalho gigantesco, então cuidado quando ouvir falar sobre DevSecOps, é diferente
de AppSec, estão relacionados e conectados mas são coisas completamente diferentes,
AppSec está dentro de DevSecOps, que estão dentro de Segurança da Informação.

94
Fim

95
É sério, é o fim mesmo…

96
Para de dar scroll…

97
Você é louco(a)?

98
Não tem mais nada… pós créditos nada… aqui não é Marvel.

99
Chega!

100
CHEGA!!!

101
Tá bom vai…

102
Toma um desconto para o Explicando, Application Security.

103
Só usar o cupom “LITUDO” na checkout.

104
Agora tchau!

105