Uma das desafios persistentes 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. A paisagem atual de ameaças cibernéticas está repleta de ataques sofisticados direcionados a todas as partes da cadeia de abastecimento de software e a urgência para que organizações produtoras de software adotem práticas de DevSecOps que integrem profundamente a segurança ao longo do ciclo de vida de desenvolvimento de software nunca foi tão grande.
No entanto, COMO as organizações abordam esse desafio é de extrema importância. Por exemplo, restringir a plataforma de desenvolvimento, instituir revisões de código exaustivas e impor processos de aprovação rigorosos podem melhorar a postura de segurança dos pipelines e do código, mas não conte com as equipes de aplicativos para operarem com fluidez o suficiente para inovar. O mesmo vale para os testes de segurança de aplicativos; descobrir uma montanha de vulnerabilidades pouco adianta se os desenvolvedores não tiverem tempo adequado ou orientação para corrigi-las.
Em um nível mais alto, construir e executar uma prática de DevSecOps significa que sua organização é capaz de operar uma plataforma de entrega segura, testar vulnerabilidades de software, priorizar e remediar vulnerabilidades, evitar o lançamento de código inseguro e garantir a integridade do software e de todos os seus artefatos.
Porém, construir e executar uma prática de 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 cinco princípios orientadores a seguir são essenciais para alcançar esse objetivo.
Princípio 1: Estabelecer 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. Isso é especialmente verdadeiro para o DevSecOps, como evidenciado por um estudo recente do setor revelando que “mais da metade (51%) dos tomadores de decisão de TI relatam resistência à mudança entre suas equipes, enquanto 47% afirmam haver colaboração insuficiente entre as equipes”.
A importância da cultura para o sucesso do DevSecOps não deve ser subestimada e isso começa com a aceitação da segurança como prioridade para todas as partes interessadas.
Tornar a segurança uma responsabilidade compartilhada
Se sua organização constrói, vende ou consome software (o que hoje é qualquer organização concebível no planeta), então cada funcionário tem um 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 quão bem os processos de DevSecOps se encaixam e podem impulsionar uma tomada de decisão melhor ao escolher plataformas DevOps, ferramentas e soluções de segurança individuais.
As mentalidades não mudam da noite para o dia, mas a alinhamento e um senso de responsabilidade de segurança podem ser alcançados por meio do seguinte:
– Comprometimento com treinamentos internos regulares de segurança – adaptados para o DevSecOps – que incluem desenvolvedores, engenheiros de DevOps e engenheiros de segurança. Lacunas e necessidades de habilidades não devem ser subestimadas.
– Adoção por parte dos desenvolvedores de metodologias e recursos de codificação segura
– A engenharia de segurança contribui para revisões de arquitetura e design de aplicativos e ambientes. É sempre mais fácil identificar e corrigir problemas de segurança no início do ciclo de vida de desenvolvimento de software.
Quebrar silos funcionais e colaborar continuamente
Uma vez que o DevSecOps é resultado da confluência de desenvolvimento de software, operações de TI e segurança, a quebra de silos e a colaboração ativa de forma contínua são fundamentais para o sucesso. Tipicamente, organizações centradas em DevOps que operam sem nenhum framework de DevSecOps formal veem a segurança entrar na imagem como um intruso indesejado. Mudanças de processo ou ferramentas que são impostas repentinamente (em vez de escolhidas e institucionalizadas de forma colaborativa) invariavelmente resultam em fricção no pipeline de desenvolvimento e trabalho desnecessário para os desenvolvedores. Um cenário comum envolve a segurança impondo 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 remediar vulnerabilidades, o que inevitavelmente fica a cargo dos desenvolvedores.
Promover a colaboração e operar como uma equipe de 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 redução do tempo gasto em auditoria
– % de aumento na frequência de implantação
– % de redução na taxa de falha de mudanças
– % de redução de vulnerabilidades implantadas em produção
– % de artefatos implantados em produção com SBOM/SLSA
– Redução no tempo de resolução de vulnerabilidades do dia zero
– Participação de desenvolvedores de software e equipes de DevOps durante os processos de avaliação e aquisição de novas ferramentas de segurança
– Garantir que nenhum processo de DevSecOps tenha um único guardião funcional
– Otimizar de forma iterativa as escolhas de ferramentas e práticas de segurança para a produtividade e velocidade do desenvolvedor
Princípio 2: Deslocar as informações de segurança para a esquerda, não a carga de trabalho de segurança
Aborde o assunto do DevSecOps e é impossível não mencionar o ‘deslocamento para a esquerda’. O mantra de segurança do deslocamento para a esquerda é tão prevalente nos artigos, blogs e materiais de marketing orientados para DevSecOps atuais que é fácil pensar que, simplesmente movendo as verificações de segurança mais cedo no ciclo de vida de desenvolvimento de software, você alcançou um programa de DevSecOps funcionando. A realidade é que o QUE você move para a esquerda é o que determina o sucesso ou fracasso de sua prática de DevSecOps.
A segurança do deslocamento 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 (em vez de apenas antes da produção) resulta em uma melhor chance global de encontrar vulnerabilidades conhecidas de código e artefato e remediá-las de forma oportuna. No entanto, se os desenvolvedores sozinhos suportarem o ônus de executar testes, coletar saída do scanner, priorizar vulnerabilidades e remediá-las, a carga mental resultante e o trabalho certamente impactarão a velocidade de produção. Em vez disso, a melhor abordagem reside em seguir estas diretrizes:
– A segurança deve ser a responsável pela orquestração e automação de testes de segurança de aplicativos ao longo dos pipelines de CI e CD
– Remover o ônus 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 de forma oportuna
– Acelerar a remediação gerando orientação acionável orientada aos desenvolvedores para entender e resolver cada vulnerabilidade
Princípio 3: Manter governança adequada e limites de segurança
Como tudo se move rapidamente no mundo do DevOps, é fácil cometer erros. Mas mesmo pequenos erros ou omissões, como um CVE (Vulnerabilidades e Exposições Comuns) não detectado ou uma alteração de configuração não autorizada dentro de um pipeline de desenvolvimento, podem trazer riscos significativos de segurança e conformidade. Por esse motivo, o valor de uma governança abrangente e rigorosos limites em todo o ambiente de desenvolvimento não pode ser superestimado. Se sua prática de DevSecOps for eficaz, você tornou 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 o seguinte guia:
– Aplicar controle de acesso baseado em funções detalhado em todo o ambiente de desenvolvimento para garantir o uso e a operação corretos. Controle de acesso baseado em funções geralmente é baseado em uma única propriedade (função), mas o controle de acesso detalhado permite mais segurança, levando em consideração várias propriedades, como hora do dia, grupos de usuários, hierarquia organizacional, etc.
– Sobrepor políticas nos pipelines para permitir que os desenvolvedores controlem seus pipelines e para permitir que as equipes de segurança e conformidade exijam verificações de segurança. O padrão de Agente de Políticas Abertas (OPA) é uma excelente abordagem de política como código para isso.
– Usar modelos sempre que possível para eliminar erros involuntários que levam a riscos de segurança e conformidade. Os modelos devem conter as melhores 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 garantam que as verificações de segurança sejam realizadas.
Princípio 4: Concentrar-se na segurança da cadeia de abastecimento de software (e não apenas no seu próprio código fonte)
O desafio de garantir a segurança de aplicações modernas tornou-se 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, colocando em risco os clientes e consumidores do software. O risco geral 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 daquele aplicativo, dentro e fora de uma organização.
Como tal, os artefatos de software de código aberto são um alvo desejável para cibercriminosos, como evidenciado pelos ataques de alto perfil que comprometeram Solarwinds, Log4j e Codecov. Comprometer um componente de construção de software, e há potencial para causar estragos nos 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 abastecimento de software, que é o SOMATÓRIO TOTAL de todo o código, pessoas, sistemas e processos que contribuem para o desenvolvimento e entrega de artefatos de software, dentro e fora de uma organização.
Para o importante objetivo de garantir a integridade de qualquer software produzido pela organização, as equipes de DevSecOps devem adotar ferramentas e práticas de acordo com o framework SLSA e com o Decreto Executivo 14028.
Garantir a cadeia de abastecimento de software requer que as equipes de DevSecOps:
– Registrem o uso de componentes de software de código aberto ao longo dos pipelines de CI e 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 consideram uma ampla gama de atributos do artefato OSS, como versão, licença, PURL e fornecedor, juntamente com indicadores líderes de risco. Seja o objetivo 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 a geração, gestão e análise de listas de materiais de software (SBOMs) para artefatos de software. Uma SBOM é essencial para entender os componentes e dependências dentro de um aplicativo, o que, por sua vez, permite que as organizações gerenciem os riscos do software de forma eficaz. Cada vez mais organizações consumidoras de software exigem SBOMs detalhadas de fornecedores, de acordo com os mandatos do Decreto Executivo 14028.
– Gerem e verifiquem a conformidade com o SLSA além dos requisitos mínimos do nível 1. O framework SLSA é um meio altamente eficaz de proteger contra a adulteração de artefatos. Ele permite a criação de um registro verificável em toda a cadeia de abastecimento, 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 maior o nível, maior a garantia de integridade.
– Estabeleçam uma cadeia de custódia completa para todos os artefatos de software. No âmbito do software, a cadeia de custódia é uma evidência detalhada de tudo o que acontece com 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 subjacente de CI/CD mais ferramentas de pipeline integradas e é crucial para manter a confiabilidade do software, desde o desenvolvimento até o deployment. Ter uma cadeia de custódia de software detalhada também acelera substancialmente a remediação de vulnerabilidades, que de outra forma seria um processo exaustivo de analisar logs manualmente e juntar informações incompletas para rastrear a nova vulnerabilidade até os componentes de software afetados.
Princípio 5: Alcançar a ‘segurança contínua’ por meio de automação e IA
O DevOps tornou-se sinônimo das práticas de integração contínua e implantação contínua, portanto, é razoável que o DevSecOps resulte em segurança contínua. Uma grande parte do sucesso do DevSecOps é conseguir acompanhar (e até mesmo superar) a velocidade de desenvolvimento de aplicativos. Embora sempre leve tempo para um programa de DevSecOps incipiente construir agilidade além da eficácia, a 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á-los:
– Orquestrar verificações de segurança ao longo dos pipelines. Isso é mais facilmente alcançado com uma abordagem de plataforma, onde a plataforma de DevOps subjacente integra uma variedade de ferramentas de verificação SAST, SCA, Contêiner e DAST e executa verificações quando o pipeline é executado. A governança baseada em políticas é outra forma relacionada de mitigação automática. Por exemplo, uma política do OPA pode ser aplicada para falhar um pipeline se critérios de segurança específicos não forem atendidos.
– Automatizar a deduplicação e priorização de listas de vulnerabilidades para os desenvolvedores. Uma das áreas de trabalho mais árduas para os desenvolvedores é lidar com uma montanha de dados brutos de saída de scanner não processados. Com o objetivo de otimizar o tempo de remediação para vulnerabilidades críticas (junto com a preservação da produtividade e experiência do desenvolvedor), automatizar o processo de deduplicação e priorização de vulnerabilidades é imprescindível.
– Gerar orientação de remediação com IA. Para melhorar ainda mais a velocidade de remediação e minimizar o trabalho 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úvidas sobre a importância crítica de uma prática de DevSecOps altamente eficaz para organizações produtoras de software, há 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
