Quer experimentar?
Visão geral do DevSecOps
O que é DevSecOps?
DevSecOps é a integração de práticas de segurança a um modelo de fornecimento de software de DevOps. Sua base é uma cultura em que o desenvolvimento e as operações são executados com processos e ferramentas que promovem a divisão de responsabilidade na criação segura de software.
A definição do modelo de DevSecOps, em um nível de alto funcionamento, é integrar objetivos de segurança o mais cedo possível no ciclo de vida do desenvolvimento. Embora a segurança seja “responsabilidade de todos”, as equipes de DevOps estão posicionadas de maneira especial na interseção entre desenvolvimento e operações, e são capacitadas para aplicar a segurança em amplitude e profundidade.
Qual é a diferença entre DevOps e DevSecOps?
A diferença entre DevOps e DevSecOps é, em poucas palavras, a cultura da responsabilidade compartilhada. DevOps é um conceito discutido e escrito há mais de uma década e contém várias definições. Em sua essência, o DevOps é um paradigma organizacional que alinha as práticas de desenvolvimento e operações como uma responsabilidade compartilhada.
Essa prática começou como uma coleção frouxa de práticas comuns compartilhadas entre equipes de engenharia de software de alto desempenho, mas se transformou em uma declaração moderna de cultura e processo de engenharia: DevOps As organizações com responsabilidade compartilhada pelo desenvolvimento e operações são capazes de iterar mais rapidamente e, como resultado, têm mais sucesso. O DevSecOps estende essa filosofia, codificando objetivos de segurança como parte da estrutura geral de metas. Pense no DevSecOps como a continuação natural do DevOps, e não como uma ideia ou conceito separado. As equipes bem-sucedidas na aplicação das práticas de DevOps devem pensar nele como uma etapa evolutiva, e não revolucionária.
Muitos concordariam que a meta era criar um ambiente no qual o valor comercial fosse gerado ao passar do código para a produção com um fluxo contínuo e sustentável. Com esse novo modelo, surgiram ferramentas e metodologias que aumentaram o ritmo e ocasionaram um gargalo, com as práticas tradicionais de segurança com ciclos de feedback lentos se tornando obstáculos para as práticas de DevOps de alto ritmo. Como resultado, as práticas de segurança muitas vezes eram realizadas apenas na pós-produção ou por equipes externas injetadas no processo, o que deixava tudo ainda mais lento.
Para tornar mais clara a diferença entre DevOps e DevSecOps, o DevSecOps abrange as práticas de segurança e a cultura de responsabilidade compartilhada do DevOps. As atividades projetadas para identificar e resolver problemas de segurança de maneira ideal são injetadas logo no início do ciclo de vida do desenvolvimento de aplicativos, e não após o lançamento do produto. Para esse fim, as equipes de desenvolvimento realizam muitas das tarefas de segurança de maneira independente no decorrer do ciclo de vida de desenvolvimento (SDLC).
Essa abordagem ajuda a minimizar as vulnerabilidades que chegam à produção, reduzindo assim o custo associado à correção de falhas de segurança. Ela cria escalabilidade ao mesmo tempo em que estabelece uma cultura colaborativa que aproxima a segurança dos objetivos de DevOps. O DevSecOps visa a incorporar segurança em todas as etapas do processo de entrega, desde o estágio de requisitos, e estabelecer um plano para automação da segurança.
A importância do DevSecOps
Por que as práticas de DevSecOps são importantes?
A transformação digital se tornou um requisito existencial para quase todas as empresas e inclui três movimentos significativos: mais software, tecnologias de nuvem e metodologias de DevOps.
Mais software significa que uma quantidade maior de riscos da organização passa a ser digital, o que aumenta o nível de dívidas técnicas e, portanto, a segurança dos aplicativos, tornando cada vez mais desafiador proteger os ativos digitais.
Nuvem significa o uso de tecnologias mais recentes que introduzem riscos diferentes, mudam com mais rapidez e são mais acessíveis ao público, eliminando ou redefinindo o conceito de perímetro seguro. Isso também significa que muitos dos riscos de TI e infraestrutura migram para a nuvem, e outros estão se tornando puramente definidos por software, reduzindo muitas vulnerabilidades e destacando a importância do gerenciamento de permissões e do acesso.
Por fim, o DevOps representa uma mudança na forma como o software é desenvolvido e entregue, acelerando o ciclo desde a escrita do código até o fornecimento de valor ao cliente, com adaptações feitas conforme o estado do mercado. Equipes de desenvolvimento capacitadas enviam software de maneira contínua e mais rápida do que nunca, com base em decisões de tecnologia e implementação de maneira autônoma e sem intermediários. Os lentos e tradicionais loops de feedback que atrapalham o desenvolvimento não são tolerados, pois as equipes priorizam cada vez mais a autossuficiência: você escreve, você executa.
À medida que o restante da organização evolui, as equipes de segurança se deparam com demandas maiores e muitas vezes se tornam um gargalo. As ferramentas e práticas de segurança de aplicativos herdadas, projetadas no ritmo mais lento da era pré-nuvem, são o apoio das equipes de segurança na jornada crítica de fornecer aplicativos de alta qualidade. Essas equipes, com falta de pessoal devido à grave escassez de talentos no setor de segurança, tornam-se um gargalo e não conseguem acompanhar o ritmo. Como resultado, as equipes de desenvolvimento enviam aplicativos não seguros, as equipes de segurança ficam esgotadas, e a segurança torna-se pessimista, anulando a aceleração que os negócios buscam obter.
Para lidar com esses desafios, as pessoas começaram a mudar suas práticas, e isso deu origem ao DevSecOps. Uma cultura de DevSecOps traz segurança para o âmbito do DevOps e permite que as equipes de desenvolvimento protejam o código escrito em seu próprio ritmo, ao mesmo tempo em que geram maior colaboração entre os profissionais de desenvolvimento e segurança. Ela ajuda as equipes de segurança a se tornarem uma organização de suporte que compartilha conhecimento e ferramentas para aumentar a autonomia dos desenvolvedores, além de viabilizarem o nível de supervisão que a empresa exige.
6 Benefícios do modelo de DevSecOps
Entrega mais rápida: a velocidade de entrega de software aumenta quando a segurança é integrada ao pipeline. Os bugs são identificados e corrigidos antes da implantação, o que possibilita que os desenvolvedores se concentrem no fornecimento de recursos.
Postura de segurança reforçada: a segurança é um recurso desde a fase de design. Um modelo de responsabilidade compartilhada garante que a segurança seja totalmente integrada, desde a criação e a implantação até a proteção das cargas de trabalho de produção.
Custos reduzidos: a identificação de vulnerabilidades e bugs antes da implantação resulta em uma redução exponencial dos riscos e dos custos operacionais.
Aumento do valor do DevOps: a integração de práticas de segurança no DevOps permite melhorar a postura geral da segurança como uma cultura de responsabilidade compartilhada. O Relatório de Insights de DevSecOps de 2020 da Snyk/Puppet constatou que esse é o caso em organizações maduras de DevSecOps.
Melhoria da integração e do ritmo da segurança: o custo e o tempo da entrega segura de software são reduzidos ao eliminar a necessidade de modernizar os controles de segurança após o desenvolvimento.
Geração de mais sucesso para a empresa: uma convicção maior na segurança do software desenvolvido e a adoção de novas tecnologias permitem mais crescimento de receita e ampliação das ofertas de negócios.
Adoção do DevSecOps: integração da segurança ao pipeline de CI/CD
A maioria das organizações de DevOps modernas dependerá de alguma combinação de sistemas de integração contínua e implantação/entrega contínua, na forma de um pipeline de CI/CD. O pipeline é uma excelente base a partir da qual uma variedade de testes e validações de segurança automatizados podem ser executados, sem exigir o trabalho manual de um operador humano.
Para integrar objetivos de segurança no início do desenvolvimento de um aplicativo, comece antes que a primeira linha de código seja escrita. A segurança pode integrar e iniciar a modelagem efetiva de ameaças durante o conceito inicial do sistema, aplicativo ou história individual do usuário. Análises estáticas, linters e mecanismos de política podem ser executados sempre que um desenvolvedor faz o check-in do código, garantindo que qualquer problema mais simples seja tratado antes que as alterações avancem mais adiante.
A análise de composição de software pode ser aplicada de maneira holística para confirmar se as dependências de código aberto têm licenças compatíveis e não apresentam vulnerabilidades. Um subproduto comportamental disso é que os desenvolvedores nutrem um senso de responsabilidade sobre a segurança dos seus aplicativos, obtendo feedback imediato a respeito da segurança relativa do código que escreveram.
Após o check-in e a compilação do código, você pode começar a empregar testes de integração de segurança. A execução do código em uma área restrita para testes de contêiner permite a realização de testes automatizados de parâmetros como chamadas de rede, validação de entradas e autorização. Esses testes geram feedback ágil, permitindo iteração e triagem rápidas de quaisquer problemas identificados, causando interrupção mínima no fluxo geral. Se ocorrerem problemas como chamadas de rede inexplicadas ou entradas não sanitizadas, os testes falharão, e o pipeline gerará feedback acionável na forma de relatórios e notificações para as equipes relevantes.
Depois que o artefato de implantação passa pela primeira bateria de testes de integração, ele segue para o próximo estágio do teste de integração. Agora ocorre a implantação em uma área restrita mais ampla, uma cópia limitada do ambiente de produção eventual. Nessa fase, mais testes de integração de segurança podem ser realizados, embora com um objetivo diferente.
Agora é possível testar recursos como registro em log correto e controles de acesso. O aplicativo registra métricas relevantes de segurança e desempenho corretamente? O acesso está limitado ao subconjunto correto de indivíduos (ou totalmente impedido)? A falha novamente resulta em itens de ação para as equipes relevantes.
Por fim, o aplicativo segue para a produção. No entanto, o trabalho do DevSecOps continua a sério. A correção automatizada e o gerenciamento da configuração garantem que o ambiente de produção esteja sempre executando as versões mais recentes e seguras das dependências de software. Na teoria, infraestrutura imutável significa que todo o ambiente é frequentemente demolido e reconstruído, constantemente submetido a uma bateria de testes ao longo da extensão do pipeline.
A utilização de um pipeline de CI/CD para DevSecOps ajuda a integrar os objetivos de segurança em cada fase, sem adicionar burocracia e controles pesados, permitindo que o rápido fornecimento de valor de negócios seja mantido.
Como capacitar a cultura de DevSecOps
Então, como uma organização pode fazer a escalada evolutiva do “DevOps” para o “DevSecOps”? Não basta entregar um conjunto de KPIs de segurança a uma equipe de DevOps já ocupada e dar o assunto como encerrado. É preciso propiciar uma cultura colaborativa e compartilhada de rápida iteração.
Se a meta é integrar objetivos de segurança com antecedência, isso tem de ser feito da forma mais simples possível. O ônus de integrar equipes e objetivos de segurança ao fluxo de valores não deve recair sobre os desenvolvedores. A adição de outras etapas só aumenta o tempo necessário para fornecer recursos aos clientes. A segurança deve ser uma organização ágil, com uma abordagem pragmática para aplicar a segurança com o mínimo de interrupção.
Durante o processo de planejamento, especialmente no que se refere à infraestrutura, os engenheiros de segurança devem estar envolvidos nas discussões e ter autoridade para rejeitar escolhas ruins/não seguras, mas com conhecimento suficiente para oferecer alternativas. Muitas vezes, as equipes de segurança sobrecarregadas simplesmente dizem “não” e delegam a descoberta de alternativas às equipes de DevOps. Novamente, isso remonta a capacitar as organizações de segurança com o nível certo de recursos.
Com a segurança e o DevOps colaborando de modo regular desde o início, os objetivos de segurança ficam intimamente integrados ao esqueleto da infraestrutura. Os recursos e aplicativos implantados em produção serão o resultado de uma colaboração abrangente e eficaz entre as equipes de segurança, desenvolvimento e operações. A segurança não precisará pedir auditorias nem recursos extras às equipes de desenvolvimento após o fato: elas saberão que eles foram incorporados desde o primeiro dia.
Se a sua organização evoluiu para praticar o DevSecOps, você sabe que tem capacidade para rapidamente e agradar clientes com novos recursos e funcionalidades aprimoradas, mas sem deixar a segurança em segundo plano.
Leia este artigo da Snyk sobre como implementar DevSecOps em 4 etapas se você ainda não fez isso.
Próximo na série
Top 8 DevSecOps Best Practices - Build Securely
Gone are the days of waiting until the end of a development lifecycle to execute security testing and implement security best practices.
Continuar lendo