07 - Cultura e Práticas DevOps (2022) - 4 DevSecOps e Maturidade DevOps

Prévia do material em texto

DevSecOps e 
Maturidade DevOps
Marco Mendes
DevSecOps
Marco Mendes
DevSecOps – Por quê?
• DevOps não envolve apenas as equipes de 
desenvolvimento e de operações.
• O envolvimento das áreas de segurança no final da 
construção de produtos é um desastre para a 
estabilidade da organização.
• É necessário que a equipe de segurança da TI 
desempenhe um papel integrado em todo o ciclo 
de vida das aplicações da sua empresa.
DevSecOps – O que?
• No DevSecOps, segurança é uma responsabilidade 
comparElhada e integrada do início ao fim.
• DevSecOps significa pensar na segurança da 
aplicação e da infraestrutura desde o início.
• Isso implica também automaEzar algumas 
barreiras de segurança para evitar que o fluxo de 
trabalho de fique lento. 
DevSecOps – Exemplos
• Verificação automa/zada da segurança do 
código após commits.
• Verificação de segurança automa/zada de 
contêineres Dockers.
• Verificação de segurança automa/zada de 
ambientes.
DevSecOps – Exemplos
• Testes de segurança 
• Dias de jogos
• Times vermelhos e /mes azuis
DevSecOps – Exemplos
• Gerenciamento integrado de senhas e 
segredos
• Engenharia do caos que removem instâncias 
inseguras de produção (ex. Ne#lix Security 
Monkey)
• Automação de gerenciamento das 
configurações de serviços e sistemas
DevSecOps – Exemplos
• Coleta de dados de log e eventos
• Monitoramento de integridade de chaves de arquivo e 
registro
• Inventário de processos em execução e aplica;vos 
instalados
• Monitoramento de portas abertas e configuração de rede
• Detecção de kits de acesso de administrador (rootkit) ou 
artefatos de malware
DevSecOps – Exemplos
• Segurança automaEzada de ambientes de nuvens
• Conformidade a regulações como GDPR/LGPD ou 
ISO 27001
• Avaliação de configuração e monitoramento de 
políEcas
• Execução de respostas aEvas
Segurança por Desenho no 
Ciclo DevSecOps
DevSecOps –
Algumas ferramentas
• SonarQube
• Veracode
• Wazuh
• GitHub Ac;ons
• Trivy
• Starboard
• OWASP Zed AQack Proxy
• Hashicorp Vault
• Aqua Security
Resumo
• DevSecOps demanda esforço
cultural de colaboração entre
desenvolvedores, qualidade e
/mes de segurança e produção
• Segurança por desenho cria
segurança integrada por todo o
ciclo de vida de produtos.
Escala de Maturidade 
para DevOps
Marco Mendes
1 - Inicial
• Não temos consciência da prá;ca DevOps.
• Não temos um processo claramente definido
• Não temos qualidade consistente.
• Não existe instrumentação nem medições.
• Não temos resultados efe;vos, nem medições 
sobre os problemas.
• Temos consciência da prá;ca DevOps.
• O processo de trabalho está emergindo.
• Realizamos já laboratórios e experimentações.
• Não temos qualidade consistente.
• Não existe instrumentação ou ela é muito precária.
• Não temos resultados efe;vos.
2 - Consciente
• Temos consciência da prá;ca DevOps.
• O processo de trabalho está padronizado.
• Temos uma suíte de ferramentas definido e que 
suporta o processo de trabalho.
• Não temos qualidade plenamente consistente.
• A instrumentação está mais avançada e temos 
plena consciência de nossos desvios.
• Os resultados começam a surgir, mas ainda não são 
plenamente efe;vos. 
• Sabemos que ir além desse nível é desafiante, 
longo e árduo, pois as fontes de variabilidade 
devem ser atacadas dia após dia.
3 - Gerenciado
4 - Quan8ta8vo
• Temos consciência da prá;ca DevOps.
• O processo de trabalho está padronizado.
• Temos uma suíte de ferramentas definido e que 
suporta o processo de trabalho.
• A instrumentação está mais avançada e já 
endereçamos nossos desvios ao longo do tempo.
• Temos qualidade plenamente consistente.
• Os resultados são claros e conseguimos 
demonstrar o efeito em indicadores como redução 
do tempo de entrega, aumento da vazão ou 
redução do uso de horas humanas.
Escala de 
Maturidade
• Sempre avalie a maturidade dentro de um 
contexto. Times diferentes podem ter 
maturidade diferentes. 
• Não use maturidade para falar da “empresa” 
como um todo.
• Qual o limite da “organização” que estamos 
observando? Um Eme? Uma tribo? Uma área? 
Um serviço que envolve múlEplos Emes?
• Avalie o dialeto dos desenvolvedores e Emes. 
• Exemplo: Se as pessoas acreditam que fazem 
integração con]nua mas não tem automação de 
testes, observamos a maturidade baixa do Eme.
• Colete evidências pois falar é fácil.
Pipelines DevOps
Mecanismos automa-zados 
para reduzir o tempo de 
entrega de demandas, 
aumentar o feedback entre 
pessoas e também habilitar 
experimentos e inovações. 
1 - Inicial
• Não temos consciência sobre a cultura e pipelines 
DevOps.
• Existe medo e desconfiança sobre ferramentas de 
pipelines.
• Não temos processos padronizados para criar e 
promover builds.
• Não temos ferramentas em experimentação tais como 
AzureDevOps, Jenkins, Chef, Puppet ou GitLab
• Não temos qualidade consistente.
• Não existe instrumentação nem medições.
• Não temos resultados efeIvos, nem medições sobre os 
problemas.
2 - Consciente
• Temos consciência que precisamos implementar 
pipelines.
• O processo de trabalho de construir e promover está 
emergindo. 
• Realizamos já laboratórios e experimentações em 
ferramentas como Azure DevOps, GitLab ou Jenkins
• Não temos qualidade consistente.
• Não existe instrumentação do uso de ferramentas de 
pipelines.
• Não temos resultados efeIvos.
• Podemos ficar algumas semanas ou meses nesse 
estágio até que ganhemos tração.
3 - Gerenciado
• Temos uma suíte de ferramentas para pipelines definido e 
que suporta o processo de trabalho.
• A qualidade dos pipelines ainda é variável e eles ainda não 
estão plenamente estáveis.
• A instrumentação dos pipelines começa a avançar e temos 
plena consciência de nossos desvios. Sabemos onde 
devemos melhorar.
• Começar a experimentação com ferramentas diferentes 
para contextos técnicos disBntos.
• Os resultados começam a surgir, mas ainda não são 
plenamente efeBvos. Mas sabemos, por exemplo, que já 
reduzir o esforço humano por tarefas agora feitos por 
robôs.
• Podemos ficar meses ou trimestres nesse estágio, pois 
pode ser demorado atacar as fontes de variabilidade.
4 - Quan7ta7vo
• Temos uma suíte de ferramentas para pipelines definido e 
que suporta os processos de trabalho.
• Temos um ecossistema de pipelines para domínios diversos 
(ex. construção, qualidade, entregas ou segurança)
• A qualidade dos pipelines é consistente. Os pipelines estão 
estáveis e são usados em base diária pelos Bmes.
• A instrumentação dos pipelines está mais avançada e 
minimizamos os nossos desvios. 
• Temos métricas de uso dos pipelines para diversos 
domínios.
• Podemos evidenciar quantas horas de pessoas 
economizamos, o aumento da consistência na construção e 
entrega de builds e outros processos técnicos, redução de 
defeitos e até o mesmo a redução no tempo médio de 
entrega nesses processos.
Resumo
• A experimentação conNnua com
ferramentas de pipeline provoca
debates técnicos e o aumento
grada/vo de maturidade.
• O aumento da maturidade de
pipelines gera resultados efe/vos
na redução do tempo de entrega
de demandas, redução de defeitos
e horas de seres humanos que
foram salvas.
Maturidade de 
Automação de Testes
Marco Mendes
Automação de testes é peça
fundamental nos processos DevOps
1 - Inicial
• Não temos consciência sobre automação de testes.
• Os processos são manuais.
• Como realizar regressão com testes manuais é 
muito caro, o ;me de testes precisa fazer testes 
exploratórios e muitos problemas vazam para a 
produção.
• A qualidade é pífia e temos muitas reclamações de 
clientes. 
2 - Consciente
• Temos consciência sobre o processo de automação 
de testes.
• Alguns experimentos com ferramentas de testes 
automa;zados em nível de unidade, contrato ou 
telas começam a emergir.
• Os termos TDD e BDD começam ser discu;dos.
• Alguns sistemas começam a ter processos 
automa;zados, mas a cobertura de testes ainda é 
baixa.
3 - Gerenciado
• Temos uma suíte de ferramentas para automaçãode testes 
em curso.
• Abordagens TDD e BDD começam a ser experimentadas 
com resultados efeBvos na qualidade.
• Testes não-funcionais automaBzados começam a emergir 
também tais como performance, usabilidade ou segurança.
• Os esforços de aumento da cobertura de testes estão a 
pleno vapor. Os testes de regressão rodam de forma 
sistemaBzada, em base diária.
• Mas podemos ficar meses ou trimestres aqui até que 
tenhamos larga automação de testes e mais frequência de 
builds sólidos.
• Os resultados começam a surgir, mas ainda não são 
plenamente efeBvos. 
4 - Quan7ta7vo
• Abordagens TDD e BDD são comuns 
para suportar a automação de testes.
• A cobertura de código excede em 
muitas empresas 80%, fornecendo 
muita solidez para melhorias e 
inovações.
• Temos automação de testes funcionais 
e testes não-funcionais e cobrimos a 
pirâmide de testes.
• Medimos o resultado econômicos dos 
esforços de testes e já jusIficamos o 
retorno de invesImento
Frequência	
de	Regressão
de	Testes
Processos
Técnicos
de	Automação
de	Testes
4	– Testes	automatizados
em	larga	escala,	inclusive
não-funcionais
1	– Testes	Manuais
2	e	3	- Automação	de	Testes
se	Estabelecendo
Resumo
• Automação de testes cria
processos conNnuos de aumento
de maturidade de qualidade.
• Larga automação de testes fornece
segurança e resiliência para
suportar inovações e evoluções
técnicas nos produtos.
Maturidade de 
Automação de Builds
Marco Mendes
A automação de builds é prá'ca 
essencial para garan'r que os 
executáveis dos seus produtos sejam 
gerados de forma consistente, em 
base diária. 
Esta prá'ca busca evitar o problema 
comum do código funcionar apenas 
máquina do desenvolvedor.
1 - Inicial
• Não temos consciência sobre automação de builds.
• Os processos são manuais.
• Não temos nenhum automação de testes.
• Dependemos das IDEs para compilar o código
• A qualidade é completamente dependente do 
artesanato individual.
• Aqui ouvimos “Na minha máquina funciona” com 
mais frequência que gostaríamos. 
2 - Consciente
• Temos consciência sobre o processo de automação de 
builds.
• O processo de trabalho de construir builds está 
emergindo. 
• Temos já experimentos em curso com ferramentas 
como maven, gradle, npm, yarn e não dependemos 
mais das IDEs para compilar o código
• Estamos começando a testar ferramentas de pipelines 
de automação de builds. (ex. GitLab ou GitHub AcIons)
• A automação de testes de unidade começa a ser 
discuIda.
• A instrumentação do processo de builds ainda não 
existe e não temos métricas desse processo. 
3 - Gerenciado
• Temos uma suíte de ferramentas para pipelines de 
builds definido e que suporta o processo de trabalho.
• Os builds rodam em base diária, mas ainda temos 
problemas de qualidade devido a baixa automação de 
testes ou políIcas pobres de gestão de configuração.
• Os esforços de aumento da cobertura de testes estão a 
pleno vapor.
• Introduzimos processos técnicos sólidos nos builds, 
como verificação de qualidade de código ou segurança.
• Os resultados começam a surgir, mas ainda não são 
plenamente efeIvos. 
• Podemos ficar meses ou trimestres aqui até que 
tenhamos larga automação de testes e mais frequência 
de builds sólidos.
4 - Quan7ta7vo
• Entramos no terreno da Integração Con9nua.
• Grande frequência de builds e os builds tem 
processos sólidos de verificação de qualidade de 
código, segurança e automação de testes.
• Abordagens TDD e BDD são comuns para suportar 
a automação de testes.
• A cobertura de código excede em muitas empresas 
80%, fornecendo muita solidez para melhorias e 
inovações.
• A instrumentação é sólida. Podemos demonstrar a 
redução de horas humanas, do tempo de entrega e 
defeitos em produção.
Frequência
de	Geração
de	Builds
Processos
Técnicos
Automatizados 4	- Integração	
Contı́nua
1	- Ausência	de	
automação	de	builds
2	e	3	- Automação	de	Builds
em	Estabelecimento
Resumo
• Automação de builds com
maturidade crescente cria
processos repeNveis e aumento
consistente da qualidade.
• Integração conNnua é um processo
de automação de builds em alta
maturidade (nível 4)
Maturidade de 
Automação de Entregas
Marco Mendes
A automação das entregas é 
uma prá5ca que buscar garan5r 
que o processo de promoção do 
executável para os ambientes de 
testes, homologação e produção 
sejam automa5zados e assim 
tornados consistentes e 
eficientes. 
1 - Inicial
• Não temos consciência sobre automação de 
entregas.
• Aqui ouvimos “Na minha máquina funciona” com 
mais frequência que gostaríamos. 
• A promoção de builds é manual.
• Os processos de transporte de esquemas e dados 
nos bancos de dados são morosos.
• Temos muitas instabilidades em produção.
• Não é incomum que o transporte para produção 
demore horas ou dias.
2 - Consciente
• Temos consciência sobre o processo de automação 
de entregas.
• Ferramentas como Chef, Puppet ou Azure Pipelines 
começam a ser experimentadas.
• O conceito de conteinerização de ambientes 
começa a ser discu;do e ferramentas como Docker
começam a ser usadas.
• Promoções do ambiente de integração para 
ambiente de testes começam ser realizados de 
forma automa;zadas. 
3 - Gerenciado
• Temos uma suíte de ferramentas para promoção de builds.
• Os processos de gestão de mudanças ITIL começam a ser 
incorporados nas ferramentas de automação de entregas.
• A promoção de contêineres é usual já e temos propriedade 
no uso de contêineres.
• Introduzimos processos técnicos sólidos nos builds, como 
verificação de qualidade de código ou segurança.
• Os resultados começam a surgir, mas ainda não são 
plenamente efeBvos. 
• Ainda podemos lutar com o transporte automaBzados de 
dados de banco de dados e dependências de outras 
aplicações
• Podemos ficar meses aqui até que tenhamos resolvido a 
automação do transporte de dados e dependências de 
outras aplicações.
4 - Quan7ta7vo
• Entramos no terreno do CD (Implantação Con-nua e 
Entrega Con-nua
• Entregamos na frequência demanda pelo negócio.
• O transporte de builds, esquema e dados são todos 
automaIzados.
• Conteineres são usados em largas escala e já temos 
repositórios privaIvos implementados.
• Os processos de entrada em produção são sólidos, 
inclusive a reversão de builds.
• PráIcas como implantações canários, implantações 
azul-verde e testes A/B são suportadas sem maiores 
problemas.
• Medimos o efeito econômico da melhoria de qualidade, 
tempo e custos associados aos processos de entrega.
Frequência
de	Promoção
de	Builds
Processos
Técnicos
Automatizados,
Inclusive	BD	e	
Ambientes	de
Produção
4	– CD
1	- Ausência	de	
automação	de	
entregas
2	e	3	– Promoção	de	Entregas
em	Estabelecimento
Resumo
• Automação na promoção de
entregas promove maior
maturidade e menor fricção entre
áreas de desenvolvimento, QA e
produção.
• Entrega e implantação conNnua é
um processo de automação de
entregas em alta maturidade (nível
4)
Maturidade de Automação de 
Ambientes e Infraestrutura 
como Código
Marco Mendes
1 - Inicial
• Aqui sobwares, aplica;vos e servidores Web são 
instalados manualmente.
• A infraestrutura é csica ou virtualizada. Não temos 
consciência sobre contêineres e orquestradores de 
contêineres.
• O trabalho de infraestrutura e produção é manual 
e temos, se exis;rem, scripts locais usados no nível 
pessoal dos vários SysAdmins.
2 - Consciente
• Temos consciência sobre o processo de automação 
de ambientes.
• Ferramentas como Docker, Kubernetes, Chef, 
Puppet, Ansible, Terraform e outras começam a ser 
experimentadas.
• Pequenos scripts de automação de ambientes 
começam a ser experimentados.
• A cultura de infraestrutura como aluguel (nuvens) 
se torna lugar comum.
3 - Gerenciado
• Temos uma suíte de ferramentas para automação 
de ambientes e elas são usadas em larga escala 
pelos ;mes de produção.
• Times de desenvolvimento tem governança para 
uso de ambientes provisionados dinâmica
• O uso de Docker com repositórios priva;vos e o 
uso de Kubernetese soluções como OpenShib se 
torna pervasivo por toda a TI.
• Ainda não temos instrumentação do processo nem 
medições dos seus beneccios econômicos.
4 - Quan7ta7vo
• Aqui temos automação da infraestrutura em larga 
escala.
• O Ime está apto a operar seus ambientes em estruturas 
virtualizadas, nuvem e até mesmo mulI-nuvem, 
conforem direcionadores de negócio e critérios de 
apIdão dos seus produtos.
• O uso de plataformas como Ansible, Terraform e 
Kubernetes está largamente disseminado, até mesmo 
em ambientes de desenvolvimento.
• PráIcas avançadas como Engenharia do Caos são 
experimentadas.
• Temos indicadores claros sobre os beneacios 
econômicos, temporais e de qualidade no uso da 
infraestrutura como código.
Frequência
de	Aplicação
de	Scripts
Processos
de	Automação
de	Ambientes
e	Infraestrutura
Como	Código
4	– IaC em	larga
escala
1	- Ausência	de	IaC
2	e	3	– IaC em	estabelecimento
Resumo
• Infraestrutura é completamente
virtualizada através de
contêineres, orquestradores e
ferramentas de provisionamento
de ambientes.
• Ambientes se tornam facilmente
gerenciáveis e fricção entre /mes
de desenvolvimento, qualidade e
produção se reduz largamente.