Uma das questões duradouras na 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 de ameaças cibernéticas de hoje está repleto de ataques sofisticados direcionados a diferentes partes da cadeia de abastecimento de software, e a urgência para que organizações produtoras de software adotem práticas DevSecOps que integrem a segurança ao longo do ciclo de vida do desenvolvimento de software nunca foi tão grande.
No entanto, COMO as organizações abordam isso é de importância crítica. Por exemplo, restringir a plataforma de desenvolvimento, instituir revisões exaustivas de código e impor processos de aprovação pesados podem melhorar a postura de segurança de pipelines e códigos, mas não espere que as equipes de aplicativos operem com fluidez o 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 adequado ou orientação para corrigi-las.
Em um nível mais elevado, construir e executar uma prática DevSecOps significa que sua organização é capaz de operar uma plataforma de entrega segura, testar vulnerabilidades de software, priorizar e remediar vulnerabilidades, impedir o lançamento de código inseguro e garantir a integridade do software e de todos os seus artefatos.
Mas construir e executar uma prática DevSecOps altamente eficaz significa alcançar todos esses objetivos com a mesma (ou maior) velocidade de desenvolvimento e nível geral de satisfação do desenvolvedor. Os seguintes cinco princípios orientadores são essenciais para chegar lá.
Princípio 1: Estabelecer uma cultura colaborativa, focada em segurança
Uma cultura forte e produtiva é essencial para o sucesso de qualquer equipe, mas é também o elemento mais difícil de acertar. Isso é especialmente verdadeiro para o DevSecOps, como evidenciado por um estudo recente da indústria que revelou que “mais da metade (51%) dos tomadores de decisão em TI relatam resistência total à mudança entre suas equipes, enquanto 47% dizem que há pouca colaboração entre equipes”.
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 prioridade para todas as partes interessadas.
Faça da segurança uma responsabilidade compartilhada
Se sua organização desenvolve, vende ou consome software (o que atualmente é verdade para toda e qualquer organização concebível no planeta), então cada funcionário tem impacto na postura de segurança geral – não apenas aqueles com ‘segurança’ em seus títulos. No cerne, o DevSecOps é uma cultura de responsabilidade compartilhada, e operar com uma mentalidade comum orientada para a segurança determina o quanto os processos do DevSecOps se encaixam e podem impulsionar uma melhor tomada de decisão na escolha de plataformas DevOps, ferramentas e soluções de segurança individuais.
As mentalidades não mudam de uma hora para outra, mas alinhamento e um senso de responsabilidade de segurança podem ser alcançados através do seguinte:
– Compromisso com treinamentos de segurança internos regulares – adaptados ao DevSecOps – que incluem desenvolvedores, engenheiros DevOps e engenheiros de segurança. Lacunas e necessidades de habilidades não devem ser subestimadas.
– Adoção por desenvolvedores de metodologias e recursos de codificação segura
– Engenharia de segurança contribui para revisões de arquitetura, ambiente e design de aplicativos. É sempre mais fácil identificar e corrigir problemas de segurança no início do ciclo de vida do desenvolvimento de software.
Quebre os silos funcionais e colabore continuamente
Dado que o DevSecOps é resultado da confluação de desenvolvimento de software, operações de TI e segurança, romper os silos e colaborar ativamente de forma contínua é essencial para o sucesso. Tipicamente, organizações centradas no DevOps operando sem nenhum framework DevSecOps formal veem a segurança entrando na imagem como um intruso indesejado. Mudanças de processo ou ferramentas que são impostas de repente (em vez de escolhidas e instanciadas colaborativamente) inevitavelmente resultam em fricção no pipeline de desenvolvimento e esforço 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 quanto trabalho é necessário para processar a saída do scanner e corrigir vulnerabilidades, o que inevitavelmente recai sobre os desenvolvedores.
Promover a colaboração e operar como uma equipe DevSecOps coesa envolve:
– Definir e concordar com um conjunto de objetivos de segurança mensuráveis, como:
– % de diminuição de incidentes de segurança de aplicativos
– % de diminuição do tempo gasto em auditoria
– % de aumento na frequência de implantação
– % de diminuição na taxa de falhas de mudança
– % de diminuição de vulnerabilidades implantadas em produção
– % de artefatos implantados em produção com SBOM/SLSA
– Diminuição do tempo de liderança para remediação de vulnerabilidades zero-day
– Envolvimento de desenvolvedores de software e equipes DevOps ao longo dos processos de avaliação e aquisição de novas ferramentas de segurança
– Garantir que nenhum processo DevSecOps tenha um único gatekeeper funcional
– Otimizar iterativamente escolhas de ferramentas e práticas de segurança para a produtividade e velocidade do desenvolvedor
Princípio 2: Deslocar informações de segurança para a esquerda, não a carga de trabalho de segurança
Mencione DevSecOps e é impossível não mencionar ‘mover para a esquerda’. O mantra de segurança à esquerda é tão prevalente nos artigos, blogs e materiais de marketing orientados ao DevSecOps atuais, que é fácil pensar que, simplesmente movendo verificações de segurança mais cedo no ciclo de vida do desenvolvimento de software, você alcançou um programa de DevSecOps funcional. A realidade é que O QUE você desloca para a esquerda é o que determina o sucesso ou o fracasso do seu DevSecOps.
O shift-left de segurança é baseado na ideia comprovada de que realizar testes de segurança de aplicativos mais cedo nos pipelines de desenvolvimento de software (em oposição a apenas antes da produção) resulta em uma melhor chance geral de detectar vulnerabilidades conhecidas de código e artefatos e remediá-las em tempo hábil. No entanto, se os desenvolvedores sozinhos carregam todo o ônus de executar testes, coletar saídas de scanner e priorizar vulnerabilidades além de remediá-las, a carga mental e o esforço resultante certamente impactarão a velocidade para a produção. Em vez disso, a melhor abordagem reside em seguir estas diretrizes:
– A segurança deve ser responsável pela orquestração e automação de testes de segurança de aplicativos ao longo de pipelines de CI/CD
– Remova o fardo de deduplicar e priorizar vulnerabilidades detectadas dos desenvolvedores. Em vez disso, a segurança deve garantir que os desenvolvedores recebam uma lista de vulnerabilidades totalmente processada em tempo hábil
– Acelere a remediação gerando orientações acionáveis de resolução para cada vulnerabilidade
Princípio 3: Manter a governança adequada e as barreiras de proteção
Porque tudo se move 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 de configuração não autorizada dentro de um pipeline de desenvolvimento, podem trazer consigo riscos significativos de segurança e conformidade. Por esse motivo, o valor de uma governança abrangente e barreiras rigorosas em todo o ambiente de desenvolvimento não pode ser superestimado. Se sua prática DevSecOps for eficaz, você terá facilitado para os interessados fazerem o que é certo e difícil para eles fazerem o que é errado. Isso pode ser alcançado com as seguintes orientações:
– Aplicar Controle de Acesso baseado em Funções (RBAC) de granularidade fina 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 de granularidade fina permite uma segurança mais forte levando em consideração várias propriedades, como horário do dia, grupos de usuários, hierarquia organizacional, etc.
– Sobrepor políticas em cima dos pipelines para permitir que os desenvolvedores controlem seus pipelines e dar à segurança e às equipes de conformidade a capacidade de exigir verificações de segurança. O padrão Open Policy Agent (OPA) é uma excelente abordagem de política como código para isso.
– Usar modelos sempre que possível para eliminar erros desnecessários que levam a riscos de segurança e conformidade. Os modelos devem conter boas práticas de segurança, especialmente em relação à execução de verificações de segurança. O uso de modelos deve ser aplicado por meio de políticas que garantem que as verificações de segurança sejam realizadas.
Princípio 4: Concentre-se em garantir a cadeia de suprimentos de software (e não apenas o seu próprio código-fonte)
O desafio de garantir aplicações modernas tem se tornado cada vez mais complexo, em grande parte devido à vasta gama de componentes de software de código aberto (OSS) e outros artefatos de terceiros que os produtores de software usam para construir suas aplicações. Cada um desses componentes introduz novas vulnerabilidades potenciais no produto final, o que coloca em risco os clientes e consumidores do software. O risco global de segurança e conformidade de um aplicativo é uma função de todo o código, pessoas, sistemas e processos que contribuem para o desenvolvimento e entrega dos artefatos de software desse aplicativo, tanto dentro quanto fora de uma organização.
Por esse motivo, os artefatos de software de código aberto são um alvo desejável para cibercriminosos, como evidenciado pelos breaches de alto perfil que comprometeram Solarwinds, Log4j e Codecov. Comprometer um bloco de construção de software, e há potencial para causar estragos nos dezenas de milhares 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 suprimentos de software, que é o SOMATÓRIO de todo o código, pessoas, sistemas e processos que contribuem para o desenvolvimento e entrega de artefatos de software, tanto dentro quanto fora de uma organização.
Para o propósito crítico de garantir a integridade de qualquer software produzido pela organização, as equipes DevSecOps devem adotar ferramentas e práticas de acordo com o framework SLSA e com o Decreto Presidencial 14028.
Garantir a cadeia de suprimentos de software requer que as equipes DevSecOps:
– Regulem o uso de componentes de software de código aberto ao longo dos pipelines de CI/CD. Isso é melhor alcançado por meio de uma abordagem de política como código (com base no padrão OPA), que permite a criação de políticas personalizadas que considerem uma ampla gama de atributos do artefato OSS, como versão, licença, PURL e fornecedor, juntamente com indicadores líderes de risco. Se o objetivo for 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.
– Adotem capacidades abrangentes para gerar, gerenciar e analisar faturas de materiais de software (SBOMs) para artefatos de software. Um SBOM é essencial para entender os componentes e dependências dentro de uma aplicação, o que, por sua vez, permite que organizações gerenciem riscos de software de forma eficaz. Cada vez mais organizações consumidoras de software estão exigindo SBOMs detalhados de fornecedores, de acordo com as determinações do Decreto Presidencial 14028.
– Gerem e verifiquem a conformidade do SLSA além dos requisitos mínimos do nível 1. O framework SLSA é um meio altamente eficaz de proteção contra manipulação de artefatos. Ele permite a criação de um registro verificável em toda a cadeia de suprimentos com informações que associam identidades e sistemas ao software. Essas informações podem ser verificadas e assinadas ao longo do ciclo de vida de desenvolvimento de software. Quanto mais alto o nível, maior a garantia de integridade.
– Estabeleçam uma cadeia completa de custody para todos os artefatos de software. No mundo do software, a cadeia de custódia é uma evidência detalhada de tudo o que acontece a um artefato de software ao longo dos pipelines de desenvolvimento, incluindo quem construiu ou modificou o artefato, quais testes de segurança ele passou 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 mais ferramentas integradas de pipeline, e é crucial para manter a confiança do software do desenvolvimento à implantação. Ter uma cadeia de custódia de software detalhada acelera substancialmente a remediação de vulnerabilidades, que, de outra forma, é um processo exaustivo de análise manual de logs e montagem de informações incompletas para rastrear a nova vulnerabilidade até os componentes de software afetados.
Princípio 5: Alcance ‘segurança contínua’ por meio de automação e IA
DevOps se tornou sinônimo das práticas de integração e implantação contínua, então faz todo o sentido que o DevSecOps resulte em segurança contínua. Uma grande parte do sucesso do DevSecOps está em ser capaz de acompanhar (e até mesmo superar) a velocidade de desenvolvimento de aplicativos. Embora inevitavelmente leve tempo para um programa DevSecOps nascente construir 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 ao longo dos pipelines. Isso é mais facilmente alcançado com uma abordagem de plataforma, em que a plataforma DevOps subjacente se integra a uma variedade de ferramentas de varredura SAST, SCA, Contêiner e DAST e executa varreduras quando o pipeline é executado. A governança de política como código é outra forma relacionada de mitigação automática. Por exemplo, uma política OPA pode ser imposta para falhar um pipeline se critérios de segurança específicos não forem atendidos.
– Automatize a deduplicação e priorização de listas de vulnerabilidades para os desenvolvedores. Uma das maiores áreas de toil para os desenvolvedores é lidar com uma montanha de dados de saída de varredura não processados. Para otimizar o tempo para a remediação de vulnerabilidades críticas (juntamente com a preservação da produtividade e experiência do desenvolvedor), a automação do processo de deduplicação e priorização de vulnerabilidades é essencial.
– Gere orientações de remediação com IA. Para aprimorar ainda mais a velocidade de remediação e minimizar o esforço dos desenvolvedores, fornecer explicações geradas por IA para vulnerabilidades e orientações de remediação prescritivas é um grande benefício para os desenvolvedores.
Conclusão
Embora não haja dúvida sobre a criticidade de uma prática DevSecOps altamente eficaz para organizações produtoras de software, há muito poucos padrões claros sobre como construir uma que fortaleça a postura de segurança geral do aplicativo sem adicionar toil ou degradar a experiência do desenvolvedor.
Os cinco principais princípios do DevSecOps (juntamente com seus respectivos conjuntos de diretrizes) discutidos neste artigo permitem que as equipes DevSecOps constr
