Incluindo Ferramentas de Segurança no Pipeline
•Transferir como PPTX, PDF•
0 gostou•60 visualizações
Palestra no meetup de DevSecOps - Julio Arruda
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Incluindo Ferramentas de Segurança no Pipeline
Semelhante a Incluindo Ferramentas de Segurança no Pipeline (20)
Incluindo Ferramentas de Segurança no Pipeline
- 1. Incluindo Ferramentas de Segurança no Pipeline Claudio Romão |@claudiobernardo Head DevOps & Training – Cloud Motion
- 2. Processo Atual Release Ciclo 1 Ciclo 2 Ciclo 3 Produção
- 3. Processo Atual Release Ciclo 1 Ciclo 2 Ciclo 3 Produção
- 4. 5 Shift-left
- 5. Processo Atual Release Ciclo 1 Ciclo 2 Ciclo 3 Produção
- 6. Mas o que podemos adicionar? • Adicionar informações de segurança no requisito • Adicionar requisitos de segurança • Treinamento do time de dev para desenvolver de modo seguro • Análise estática de código • Análise de pacotes utilizados • Compliance as a code
- 7. Mas o que podemos adicionar? • Gestão de Configuração • Cofres • Testes de segurança: PenTest • Monitoramento das aplicações e infra • Métricas e relatórios para acompanhamento • Governança
- 8. 9
- 9. 10 Push CI
- 10. 11 90% dos projetos usam pacotes open-source
- 11. Open Source License • Todos os pacotes Open Source possuem um tipo de licença • Instalar ou usar em algum processo do seu ciclo de pipeline você está concordando com a licença daquele software • A licença geralmente está em um arquivo ou quando você instala algum software naquele checkbox que quase ninguém lê. • Existem vários tipos de licenças open source e é aí que temos o problema.
- 12. Permissive Licenses • Esse tipo permite que você utilize, modifique e redistribua da maneira que quiser. Sem ter a necessidade de colocar o seu código como aberto. • MIT • .net Core • Jquery • BSD License • GO 13
- 13. Copyleft Licenses • Elas permitem que você utilize e altere, porém você tem que colocar seu software nos mesmos termos do “trabalho original” • GNU - GPL • Isso pode ser um problema, pois você tem que talvez disponibilizar seu código dependendo dos termos descritos na licença. Caso esteja desenvolvendo algo comercial, você pode estar em risco. 14
- 14. Riscos de Open Source • Segurança • Licenciamento • Saúde/Estabilidade • Tempo de resposta 15
- 15. 16 Push CI
- 16. 17 Publish Dev Prd Monitoramento e Aprendizado
- 18. Ferramentas • Roslyn • Sonarlint • Azure Repos – branch policy com acesso a serviços externos • SonarCloud / SonarQube (versão free) – Análise estática de código • WhiteSource / WhiteSource Bolt (versão free) – Análise de Bibliotecas Open Source • OWASP ZAP – PentTest (modo passivo para CI / Ativo para Noturno) • Azure Pipelines - Tokenização de variáveis • Azure Policy – Verificação de ferramentas de compliance na Nuvem • Inspec – Verificação de compliance de vms e seus componentes • Chef – ferramenta de gestão de configuração como código. 19
- 19. Demonstrações 20
Notas do Editor
- Depois veio a onda do DevOps, então encurtamos e melhoramos a maneira que planejávamos e desenvolvíamos software, deixamos o processo mais rápido e cíclico porém, a equipe de segurança continuava ficando no final do processo, onde podia impedir um sistema de ir ou não para produção. Nesse contexto nós temos dois grandes problemas. O primeiro e bem conhecido é que quanto mais perto de produção eu descubro um bug, mais caro é para arrumar por n razões (já tem muita coisa que depende da área defeituosa – acoplamento; hoje já não lembramos muito bem de o porque aquilo foi implementado daquele jeito; a pessoa que fez já não faz mais parte do time, ou está em outro projeto ou até mesmo saiu da empresa.) O segundo problema e bem mais sério é: Se descobrirmos um problema de segurança no final, perto da data de entrega nos resta apenas duas saídas: 1 – Não liberar a ida para produção do sistema ou feature nova que foi implementada; pois não queremos nos arriscar a perder dados sensíveis ou até mesmo ter um possível ponto de invasão. 2 – Ceder a pressão de mercado e interna (CEO, áreas de negócio) e liberar mesmo sabendo dos riscos. Idealmente geraríamos um débito técnico – que seria nesse caso igual pegar dinheiro com agiota – e teríamos que resolver o mais rápido possível. Isso vai gerar novos trabalhos que não estavam planejados e consequentemente impactar na capacidade do time de continuar desenvolvendo projetos novos que vão trazer mais benefícios para a empresa.
- 2 – Ceder a pressão de mercado e interna (CEO, áreas de negócio) e liberar mesmo sabendo dos riscos. Idealmente geraríamos um débito técnico – que seria nesse caso igual pegar dinheiro com agiota – e teríamos que resolver o mais rápido possível. Isso vai gerar novos trabalhos que não estavam planejados e consequentemente impactar na capacidade do time de continuar desenvolvendo projetos novos que vão trazer mais benefícios para a empresa.
- 2 – Ceder a pressão de mercado e interna (CEO, áreas de negócio) e liberar mesmo sabendo dos riscos. Idealmente geraríamos um débito técnico – que seria nesse caso igual pegar dinheiro com agiota – e teríamos que resolver o mais rápido possível. Isso vai gerar novos trabalhos que não estavam planejados e consequentemente impactar na capacidade do time de continuar desenvolvendo projetos novos que vão trazer mais benefícios para a empresa.
- Segunda avaliações de algumas empresas de segurança, existem mais de 2500 tipos de licenças open source. Não existe um padrão, quem está desenvolvendo pode criar os termos que quiser e você acaba concordando com eles quando começa a utilizar a biblioteca Mas existe um esforço sendo feito para padronizar essas licenças para que o desenvolvedor não precise escrever a própria. Open Source Initiative (OSI) : Existem em torno de 96 tipos de licenças “aprovadas” por eles
- Segurança: Por ser um OSS não quer dizer que ele não é seguro. Softwares comerciais geralmente notificam quando existem patch Com Open Source você tem que estar de olho para saber se tem vulnerabilidades e se já existem patches que corrijam o erro. E Você geralmente tem que pegar e reinstalar essa nova versão Você precisa estar ciente: Saber que existe alguma vulnerabilidade no pacote Saber quais são os OSS usados no seu sistema – ter um inventário. Senão você não tem como saber o que tem que atualizar pq está vulnerável. Quais versões você está executando: Saber se ela está desatualizada e precisa ser atualizada. Dependências.: Não basta ter uma lista de OSS que vc está usando, tipo o package.config, pq uma biblioteca lá pode depender de outras e você fica sem visão disso.