Mudança de DevOps para DevSecOps

Ao criar ou modernizar uma disciplina de Segurança do Desenvolvimento, este artigo descreve como a integração da segurança nas práticas de desenvolvimento permite a transição das operações para programadores (DevOps) para as operações de segurança para desenvolvedores (DevSecOps), e ajuda a garantir a entrega das aplicações.

As organizações modernas dependem do desenvolvimento rápido de software para promover inovação, responder a necessidades empresariais em mudança e manter vantagem competitiva. O DevOps possibilita esta agilidade através da integração e entrega contínuas. No entanto, o aumento da velocidade também introduz novos riscos de segurança.

Os ciclos de lançamento contínuos reduzem o tempo entre as decisões de design e a implementação em produção, aumentando a probabilidade de serem introduzidas fraquezas em ambientes de produção, incluindo:

• Fraquezas no design da aplicação
• Dependências vulneráveis
• Erros de configuração
• Falhas de automação de infraestruturas
• Má gestão de segredos ou higiene.

Risco DevOps

Os ambientes DevOps modernos expandem a superfície de ataque através de sistemas de desenvolvimento, pipeline e produção. Ferramentas DevOps, como repositórios de código-fonte, pipelines e sistemas de automação, são alvos de alto valor para atacantes.

Se o código malicioso for introduzido cedo, pode passar por verificações de segurança existentes e chegar aos sistemas de produção.

Os objetivos comuns de ataque incluem:

• Injeção de código malicioso em artefactos de compilação.
• Comprometer identidades de desenvolvedores ou contas de serviço.
• Aceder ou exfiltrar dados de produção.

Os atacantes frequentemente visam aplicações personalizadas e ambientes de desenvolvimento para obter acesso a:

• Dados sensíveis da organização ou do cliente.
• Lógica empresarial proprietária e propriedade intelectual.
• Infraestrutura de produção através de sistemas de desenvolvimento comprometidos.
• Clientes posteriores por comprometimento da cadeia de fornecimento de software.

Os potenciais riscos de segurança são resumidos no seguinte diagrama:

Risco de aplicação e desenvolvimento

As cargas de trabalho das aplicações podem ser comprometidas devido a fraquezas introduzidas durante o desenvolvimento ou por comprometimento da infraestrutura usada para as construir e implementar.

Integrar a segurança nos processos de desenvolvimento reduz a probabilidade de estes riscos se propagarem para a versão em produção.

Deslocação para a esquerda

Shift left é uma abordagem de engenharia de segurança que integra a segurança numa fase mais precoce do ciclo de desenvolvimento.

Em vez de validar a segurança já no final do processo, as organizações incorporam-na em:

• Visualização
• Design
• Desenvolvimento
• Operations

Isto reduz os custos de remediação e a exposição ao risco.

Para apoiar esta abordagem, as organizações devem"

• Use boas práticas estruturadas, como o Ciclo de Vida de Desenvolvimento de Segurança (SDL), logo no início do processo, em vez de mais tarde, quando os problemas se tornam dispendiosos e difíceis de resolver.
• Para sustentar esta abordagem, integre governação, risco e conformidade (GRC) na estratégia de desenvolvimento.

O que é DevSecOps?

O DevSecOps cumpre a abordagem Shift Left ao estender o DevOps e integrar a segurança em todas as fases do ciclo de vida do desenvolvimento de software – desde a concepção da ideia até ao design, desenvolvimento e operações.

• Nas abordagens tradicionais de desenvolvimento, a validação de segurança era frequentemente realizada como uma porta final de qualidade antes do lançamento. Isto criou atrasos, aumentou os custos de remediação e permitiu que as vulnerabilidades persistissem até ao final do ciclo de vida.

• O DevSecOps transfere a segurança mais cedo e integra-a continuamente nos processos de desenvolvimento e operação.

• O DevSecOps reduz as fricções entre equipas de desenvolvimento, operações e segurança, alinhando-as em torno de objetivos comuns de velocidade de inovação, fiabilidade e resiliência de segurança, permitindo que as equipas abordem as questões mais importantes de forma precoce e contínua.

• O DevSecOps integra a segurança em:

  • Design arquitetónico
  • Implementação de aplicações
  • Automatização de infraestruturas
  • Processos de implementação e operacionais

Benefits

O DevSecOps permite que as equipas de desenvolvimento, segurança e operações possam:

• Identificar e remediar problemas mais cedo no ciclo de vida.
• Reduzir a exposição em produção.
• Mantenha a velocidade de entrega enquanto gere o risco.

A segurança torna-se parte da forma como o software é construído e entregue, em vez de um controlo aplicado após a entrega.

Ciclo de vida seguro da inovação

A inovação progride tipicamente através de duas fases do ciclo de vida:

Após o lançamento inicial, o desenvolvimento torna-se iterativo à medida que as cargas de trabalho evoluem com:

• Alteração da tolerância ao risco
• Requisitos de candidatura e maturidade
• Obrigações regulatórias
• Condições de ameaça

Integrar a segurança no desenvolvimento

As abordagens tradicionais de desenvolvimento validam a segurança numa fase tardia do ciclo de vida, como uma etapa final de validação antes do lançamento, após estarem concluídas a conceção e a implementação. Em ambientes de desenvolvimento modernos, o adiamento da validação aumenta:

• Complexidade da vulnerabilidade
• Custo da remediação
• Atrasos operacionais e perturbações
• Exposição aumentada ao risco à exploração ativa

O DevSecOps integra a segurança continuamente ao longo do desenvolvimento e operações, para resolver problemas mais cedo, reduzir riscos e melhorar a consistência.

Práticas-chave

A segurança deve estar integrada nos processos de desenvolvimento existentes para ser eficaz, escalável e sustentável. Deve ser integrado diretamente na forma como as aplicações são desenhadas, construídas, implementadas e operadas, não implementado num fluxo de trabalho separado ou paralelo. É recomendável:

• Mapear fluxos de trabalho de ponta a ponta desde a ideia até ao desenvolvimento, implementação e operações contínuas.
• Definir papéis, ferramentas e responsabilidades claras para a segurança em cada fase do ciclo de vida.
• Estabelecer caminhos de remediação consistentes para vulnerabilidades, defeitos e problemas de design.

Adapte as práticas de segurança com base no risco de carga de trabalho. Aplicações críticas para o negócio exigem maior rigor, enquanto cenários de menor risco podem seguir abordagens simplificadas.

No mínimo, certifique-se de:

• Identifique as etapas, pessoas e tecnologias envolvidas no seu ciclo de vida de desenvolvimento.
• Defina como as atividades de segurança se integram em cada etapa, em vez de as tratar como pontos de controlo separados.
• Estabelecer processos para lidar tanto com mudanças importantes como com correções rotineiras ao longo do ciclo de vida.

Automatizar a segurança no desenvolvimento e implementação

A automação é essencial para garantir a segurança de forma consistente e em grande escala ao longo do desenvolvimento e das operações.

• Integrar os controlos de segurança e as ferramentas diretamente em pipelines de CI/CD.
• Automatizar atividades-chave como modelação de ameaças, análise de código, validação e aplicação de políticas.
• Use o Infrastructure as Code (IaC) para permitir implementações repetidas e seguras.

Fundações de plataforma como as zonas de aterragem do Azure podem suportar esta abordagem através de

Fundações de plataforma como Azure landing zones podem apoiar esta abordagem fornecendo padrões padronizados para segurança, governação e integração DevOps.

Resultados esperados

Organizações que mudam de DevOps para DevSecOps podem:

• Reduzir a probabilidade de vulnerabilidades serem introduzidas nas cargas de trabalho de produção
• Limitar a capacidade dos atacantes de explorar infraestruturas de desenvolvimento ou automação
• Melhorar a resiliência das aplicações a técnicas de ataque em evolução
• Apoiar os requisitos regulatórios e de conformidade organizacional
• Manter a velocidade da inovação sem aumentar o risco operacional ou de segurança

Dicas para percorrer esta jornada

Adotar o DevSecOps requer mudanças organizacionais e culturais.

Educação e mudanças culturais

Estes são passos iniciais críticos. A equipa que tem tem de desenvolver novas competências e adotar novas perspetivas para compreender o modelo DevSecOps.

A educação e a mudança cultural exigem tempo, foco, patrocínio executivo e acompanhamento regular para ajudar as pessoas a compreender plenamente e a ver o valor da mudança.

Mudar drasticamente culturas e competências pode, por vezes, recorrer à identidade profissional dos indivíduos, criando potencial para uma forte resistência. É fundamental compreender e expressar o porquê, o quê e o como da mudança para cada indivíduo e a sua situação.

A mudança leva tempo

Só pode avançar tão rápido quanto a sua equipa se adapta às implicações de fazer as coisas de formas novas. As equipas têm de desempenhar o seu trabalho atual enquanto se transformam.

É fundamental priorizar cuidadosamente o que é mais importante e gerir as expectativas sobre a rapidez com que esta mudança pode acontecer.

Focar-se numa estratégia de rastejar, andar e correr, onde os elementos mais importantes e fundamentais vêm em primeiro lugar, serve bem a sua organização.

A mudança introduz atrito (temporário)

Todas as novas tecnologias, metodologias e outras mudanças introduzem atrito e confusão. É fundamental focar-se num atrito saudável que impulsione o pensamento crítico para reduzir riscos, evitando ao mesmo tempo atritos prejudiciais que desaceleram processos com benefícios ou redução de risco limitados.

Recursos limitados

Um desafio que as organizações normalmente enfrentam cedo é encontrar talento e competências tanto em segurança como no desenvolvimento de aplicações.

À medida que as organizações começam a colaborar de forma mais eficaz, podem encontrar talentos ocultos, como programadores com uma mentalidade de segurança ou profissionais de segurança com experiência em desenvolvimento.

Mudanças em curso

As aplicações estão a mudar rapidamente. Para além das novas funcionalidades, a definição técnica e a composição de uma aplicação estão a mudar fundamentalmente com a introdução de tecnologias como a cloud, serverless e IA.

Esta mudança está a alterar as práticas de desenvolvimento, a segurança das aplicações e até capacita os não programadores a criar aplicações.

Considere um modelo SRE

Algumas implementações DevSecOps combinam responsabilidades de operações e segurança numa função de engenheiro de fiabilidade do local (SRE ).

Embora tal modelo possa funcionar, é frequentemente uma mudança extrema em relação à cultura e práticas empresariais existentes.

Se está a considerar um modelo SRE, recomendamos que comece por integrar a segurança no DevOps usando ganhos rápidos práticos e progressos incrementais descritos nesta orientação, para garantir que está a obter um bom retorno sobre investimento (ROI) e a satisfazer necessidades imediatas.

Isto acrescenta gradualmente responsabilidades de segurança ao seu pessoal de operações e desenvolvimento, aproximando as equipas de um estado final de SRE.

Passos seguintes

Saiba mais sobre as melhores práticas de desenvolvimento seguro.