Cinco princípios básicos de práticas DevSecOps altamente eficazes

Um dos desafios duradouros da construção de aplicações modernas é torná-las mais seguras sem interromper os processos de DevOps de alta velocidade ou degradar a experiência do desenvolvedor. O cenário atual de ameaças cibernéticas está repleto de ataques sofisticados direcionados a todas as diferentes partes da cadeia de fornecimento de software program e a urgência para que as organizações produtoras de software program adotem práticas DevSecOps que integrem profundamente a segurança em todo o ciclo de vida de desenvolvimento de software program nunca foi tão grande.

No entanto, COMO as organizações fazem isso é de importância crítica. Por exemplo, bloquear a plataforma de desenvolvimento, instituir revisões exaustivas de código e impor processos de aprovação pesados ​​pode melhorar a postura de segurança de pipelines e códigos, mas não conte com equipes de aplicativos para operar com fluidez suficiente para inovar. O mesmo vale para testes de segurança de aplicativos; descobrir uma montanha de vulnerabilidades não adianta muito se os desenvolvedores não tiverem tempo ou orientação inadequados para corrigi-las.

Em alto nível, construir e executar uma prática DevSecOps significa que sua organização é capaz de operar uma plataforma de entrega segura, testar vulnerabilidades de software program, priorizar e remediar vulnerabilidades, impedir a liberação de código inseguro e garantir a integridade do software program e de todos os seus seus artefatos.

Mas construir e executar uma prática DevSecOps altamente eficaz significa atingir todos esses objetivos com a mesma (ou superior) velocidade de desenvolvimento e nível geral de satisfação do desenvolvedor. Os cinco princípios orientadores a seguir são essenciais para chegar lá.

Princípio 1: Estabeleça uma cultura colaborativa e voltada para a segurança

Uma cultura forte e produtiva é essencial para o sucesso de qualquer equipe, mas também é o elemento mais difícil de acertar. Isto é especialmente verdadeiro no caso do DevSecOps, como evidenciado por um estudo recente da indústria que revela que “mais de metade (51%) dos decisores de TI relatam resistência whole à mudança entre as suas equipas, enquanto 47% dizem que há colaboração insuficiente entre equipas”.(1).”

A importância da cultura para o sucesso do DevSecOps não deve ser subestimada e começa com a aceitação da segurança como uma prioridade para todas as partes interessadas.

Faça da segurança uma responsabilidade compartilhada

Se a sua organização cria, vende ou consome software program (que hoje é o caso de todas as organizações concebíveis no planeta), então cada funcionário tem um impacto na postura geral de segurança – não apenas aqueles com “segurança” em seus cargos. Em sua essência, DevSecOps é uma cultura de responsabilidade compartilhada, e operar com uma mentalidade comum orientada para a segurança determina o quão bem os processos DevSecOps se encaixam e podem conduzir a uma melhor tomada de decisão ao escolher plataformas, ferramentas e soluções de segurança individuais de DevOps.

As mentalidades não mudam da noite para o dia, mas o alinhamento e um sentido de responsabilidade de segurança podem ser alcançados através do seguinte:

• Compromisso com treinamento common de segurança interna – adaptado para DevSecOps – que inclui desenvolvedores, engenheiros de DevOps e engenheiros de segurança. As lacunas e necessidades de competências não devem ser subestimadas.
• Adoção do desenvolvedor de metodologias e recursos de codificação seguros
• A engenharia de segurança contribui para a arquitetura de aplicativos e ambientes e para revisões de design. É sempre mais fácil identificar e corrigir problemas de segurança no início do ciclo de vida de desenvolvimento de software program.

Elimine silos funcionais e colabore continuamente

Como o DevSecOps é o resultado da confluência de desenvolvimento de software program, operações de TI e segurança, quebrar silos e colaborar ativamente e continuamente é elementary para o sucesso. Normalmente, as organizações centradas em DevOps que operam sem qualquer estrutura formal de DevSecOps veem a segurança entrando em cena como um invasor indesejado. Mudanças de processo ou ferramentas que são impostas repentinamente (em oposição a escolhidas e instanciadas de forma colaborativa) invariavelmente resultam em atritos no pipeline de desenvolvimento e trabalho desnecessário para os desenvolvedores. Um cenário comum envolve a segurança exigindo verificações adicionais de segurança de aplicativos sem considerar sua colocação no pipeline ou quanta carga de trabalho é necessária para processar a saída do scanner e corrigir vulnerabilidades, o que inevitavelmente recai sobre os desenvolvedores.

Impulsionar a colaboração e operar como uma equipe coesa de DevSecOps envolve:

• Definir e chegar a acordo sobre um conjunto de objetivos de segurança mensuráveis, tais como:
  • % de redução de incidentes de segurança de aplicativos
  • % de redução do tempo gasto em auditoria
  • % de aumento na frequência de implantação
  • % de redução na taxa de falha de alteração
  • % de redução de vulnerabilidades implantadas na produção
  • % de artefatos implantados em produção com SBOM/SLSA
  • Diminuição do tempo de espera para correção de vulnerabilidade de dia zero

• Envolvimento de desenvolvedores de software program e equipes de DevOps em todos os processos de avaliação e aquisição de novas ferramentas de segurança
• Garantir que nenhum processo DevSecOps tenha um único gatekeeper funcional
• Otimizando iterativamente as escolhas de ferramentas e práticas de segurança para produtividade e velocidade do desenvolvedor

Princípio 2: Mude as informações de segurança para a esquerda, não a carga de trabalho de segurança

Aborde o assunto DevSecOps e será impossível não mencionar 'shift-left'. O mantra de segurança shift-left é tão predominante em artigos, blogs e materiais de advertising atuais orientados para DevSecOps que é fácil pensar que simplesmente movendo as verificações de segurança mais adiante no ciclo de vida de desenvolvimento de software program você alcançou um programa DevSecOps funcional. A realidade é que O QUE você muda para a esquerda é o que faz ou quebra o sucesso do seu DevSecOps.

A segurança da mudança para a esquerda baseia-se na ideia comprovada de que a realização de testes de segurança de aplicativos mais cedo nos pipelines de desenvolvimento de software program (em vez de brand antes da produção) resulta em uma melhor likelihood geral de detectar vulnerabilidades conhecidas de códigos e artefatos e corrigi-las em tempo hábil. No entanto, se os desenvolvedores suportarem sozinhos todo o fardo de executar testes, coletar resultados do scanner e priorizar vulnerabilidades além de remediá-las, a carga psychological e o trabalho resultantes certamente afetarão a velocidade de produção. Em vez disso, a melhor abordagem consiste em seguir estas diretrizes:

• A segurança deve ser responsável pela orquestração e automação de testes de segurança de aplicativos em pipelines de CI e CD
• Elimine o fardo de desduplicar e priorizar as vulnerabilidades detectadas pelos desenvolvedores. Em vez disso, a segurança deve garantir que os desenvolvedores obtenham uma lista de vulnerabilidades totalmente processada em tempo hábil
• Acelere a correção gerando orientações práticas orientadas ao desenvolvedor para compreender e resolver cada vulnerabilidade

FIGURA 1: Orquestração de testes de segurança de aplicativos em todo o pipeline de desenvolvimento de software program

Princípio 3: Manter governança e proteções adequadas

Como tudo acontece rápido no mundo DevOps, é fácil cometer erros. Mas mesmo pequenos erros ou omissões, como uma CVE (Vulnerabilidades e Exposições Comuns) perdida ou uma alteração não autorizada de configuração em um pipeline de desenvolvimento, podem acarretar grandes riscos de segurança e conformidade. Por esta razão, o valor de uma governação abrangente e de barreiras de protecção rigorosas em todo o ambiente de desenvolvimento não pode ser sobrestimado. Se sua prática de DevSecOps for eficaz, você tornou mais fácil para as partes interessadas fazerem as coisas certas e difícil para elas fazerem as coisas erradas. Isso pode ser alcançado com as seguintes orientações:

• Aplique controle de acesso baseado em função (RBAC) refinado em todo o ambiente de desenvolvimento para garantir uso e operação adequados. O RBAC geral normalmente é baseado em uma única propriedade (função), mas o RBAC refinado permite uma segurança mais forte, levando em consideração diversas propriedades, como hora do dia, grupos de usuários, hierarquia da organização, and many others.
• Sobreponha políticas sobre pipelines para permitir que os desenvolvedores controlem seus pipelines e para dar às equipes de segurança e conformidade a capacidade de exigir verificações de segurança. O padrão Open Coverage Agent (OPA) é uma excelente abordagem de política como código para isso.
• Use modelos sempre que possível para eliminar erros não forçados que levam a riscos de segurança e conformidade. Os modelos devem conter as melhores práticas de segurança, especialmente no que diz respeito à execução de verificações de segurança. O uso de modelos deve ser aplicado por meio de políticas que garantam a execução de verificações de segurança.

Princípio 4: Concentre-se em proteger a cadeia de fornecimento de software program (e não apenas em seu próprio código-fonte)

O desafio de proteger aplicações modernas tornou-se cada vez mais complexo, em grande parte devido à vasta gama de componentes de software program de código aberto (OSS) e outros artefactos de terceiros que os produtores de software program utilizam para construir as suas aplicações. Cada um desses componentes introduz novas vulnerabilidades potenciais no produto closing, o que coloca em risco os clientes e consumidores do software program. O risco geral de segurança e conformidade de um aplicativo é uma função de todos os códigos, pessoas, sistemas e processos que contribuem para o desenvolvimento e entrega dos artefatos de software program desse aplicativo, tanto dentro quanto fora de uma organização.

Como tal, os artefactos de software program de código aberto são um alvo desejável para os ciberataques, como evidenciado pelas violações de alto perfil que comprometeram o Solarwinds, o Log4j e o Codecov. Comprometa um bloco de construção de software program e há potencial para causar estragos em dezenas ou centenas de milhares de consumidores finais desse componente. Por esse motivo, o foco do DevSecOps deve se expandir além do código-fonte da organização para toda a cadeia de fornecimento de software program, que é a SOMA TOTAL de todos os códigos, pessoas, sistemas e processos que contribuem para o desenvolvimento e entrega de artefatos de software program, tanto dentro e fora de uma organização.

Com o propósito crítico de garantir a integridade de qualquer software program produzido pela organização, as equipes DevSecOps devem adotar ferramentas e práticas de acordo com a estrutura SLSA e com a Ordem Executiva 14028.

Proteger a cadeia de fornecimento de software program exige que as equipes de DevSecOps:

• Governe o uso de componentes de software program de código aberto em pipelines de CI e CD. Isto é melhor conseguido através de uma abordagem de política como código (baseada no padrão OPA), que permite a criação de políticas personalizadas que levam em consideração uma ampla gama de atributos de artefatos OSS, como versão, licença, PURL e fornecedor, juntamente com principais indicadores de risco. Quer o objetivo seja garantir o uso adequado de bibliotecas de código aberto ou bloquear o uso de artefatos OSS específicos por motivos de segurança, uma governança forte é essencial.
• Adote recursos abrangentes para gerar, gerenciar e analisar listas de materiais de software program (SBOMs) para artefatos de software program. Um SBOM é essencial para compreender os componentes e as dependências de um aplicativo, o que, por sua vez, permite que as organizações gerenciem os riscos de software program de maneira eficaz. Cada vez mais organizações consumidoras de software program exigem SBOMs detalhados dos fornecedores, consistentes com os mandatos da Ordem Executiva 14028.
• Gere e verifique a conformidade do SLSA além dos requisitos mínimos do nível 1. A estrutura SLSA é um meio altamente eficaz de proteção contra adulteração de artefatos. Permite criar um registo verificável em toda a cadeia de abastecimento com informações que associam identidades e sistemas ao software program. Essas informações podem ser verificadas e assinadas durante todo o ciclo de vida de desenvolvimento do software program. Quanto maior o nível, mais forte será a garantia de integridade.
• Estabeleça uma cadeia de custódia completa para todos os artefatos de software program. No domínio do software program, a cadeia de custódia é uma evidência detalhada de tudo o que acontece com um artefato de software program ao longo dos pipelines de desenvolvimento, incluindo quem construiu ou modificou o artefato, quais testes de segurança ele foi submetido e quais foram os resultados dos testes. Alcançar uma cadeia de custódia completa é em grande parte uma função da plataforma CI/CD subjacente, além de ferramentas de pipeline integradas, e é essential para manter a confiabilidade do software program desde o desenvolvimento até a implantação. Ter uma cadeia de custódia de software program detalhada também acelera substancialmente a correção de vulnerabilidades, que de outra forma seria um processo exaustivo de analisar manualmente os logs e reunir informações incompletas para rastrear a nova vulnerabilidade até os componentes de software program afetados.

Princípio 5: Alcançar “segurança contínua” através da automação e IA

DevOps tornou-se sinônimo de práticas de integração e implantação contínuas, por isso é lógico que DevSecOps deva resultar em segurança contínua. Uma grande parte do sucesso do DevSecOps é ser capaz de acompanhar (e até mesmo ficar à frente) da velocidade de desenvolvimento de aplicativos. Embora invariavelmente leve tempo para que um programa DevSecOps nascente desenvolva agilidade além de eficácia, uma chave para acelerar a maturidade do DevSecOps é o uso de automação inteligente e IA. Aqui estão várias recomendações importantes sobre como e onde aplicá-las:

• Orquestre verificações de segurança em pipelines. Isso é mais fácil de conseguir com uma abordagem de plataforma, em que a plataforma DevOps subjacente se integra a uma variedade de ferramentas de varredura SAST, SCA, Container e DAST e executa varreduras quando o pipeline é executado. A governança política como código é outra forma relacionada de mitigação automática. Por exemplo, uma política OPA pode ser aplicada para falhar um pipeline se critérios de segurança específicos não forem atendidos.
• Automatize a desduplicação e a priorização de listas de vulnerabilidades para desenvolvedores. Uma das maiores áreas de trabalho para os desenvolvedores é ter que lidar com uma montanha de dados de saída do scanner não processados. Com o objetivo de otimizar o tempo de correção de vulnerabilidades críticas (além de preservar a produtividade e a experiência do desenvolvedor), é essencial automatizar o processo de desduplicação e priorização de vulnerabilidades.
• Gere orientações de correção com IA. Para aumentar ainda mais a velocidade da correção e minimizar o trabalho dos desenvolvedores, fornecer explicações geradas por IA para vulnerabilidades e orientações prescritivas de correção é um enorme benefício para os desenvolvedores.

Conclusão

Embora não haja dúvidas sobre a importância de uma prática DevSecOps altamente eficaz para organizações produtoras de software program, existem muito poucos padrões claros sobre como construir uma que fortaleça a postura geral de segurança de aplicativos sem adicionar trabalho ou degradar a experiência do desenvolvedor.

Os cinco princípios principais do DevSecOps (juntamente com seus respectivos conjuntos de diretrizes) discutidos neste documento permitem que as equipes de DevSecOps construam e mantenham uma base operacional sólida. À medida que as tecnologias e práticas modernas de DevOps continuam a evoluir rapidamente, sempre haverá problemas de segurança desconhecidos para resolver. Enquanto desenvolvedores, engenheiros de DevOps e profissionais de segurança trabalharem juntos como uma unidade coesa, o caminho para a excelência em DevSecOps será muito mais claro. Se você estiver interessado em se aprofundar mais nesses conceitos, recomendo que você baixe o Guia definitivo para entrega segura de software program.