Uma das desafios duradouros de construir aplicações modernas é torná-las mais seguras sem interromper os processos de alta velocidade DevOps ou degradar a experiência do desenvolvedor. O cenário de ameaças cibernéticas de hoje está repleto de ataques sofisticados voltados para diferentes partes da cadeia de fornecimento de software e a urgência para as organizações produtoras de software adotarem práticas de DevSecOps que integrem profundamente a segurança ao longo do ciclo de vida do desenvolvimento de software nunca foi tão grande.
No entanto, COMO as organizações lidam com isso é de importância crítica. Por exemplo, bloquear a plataforma de desenvolvimento, instituir revisões de código exaustivas e impor processos de aprovação pesados podem melhorar a postura de segurança dos pipelines e do código, mas não espere que as equipes de aplicativos operem com fluidez o suficiente para inovar. O mesmo vale para os testes de segurança de aplicativos; descobrir uma montanha de vulnerabilidades pouco ajuda se os desenvolvedores não tiverem tempo ou orientação adequada 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 a liberação de código inseguro e garantir a integridade do software e de todos os seus artefatos.
Mas 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 seguintes cinco princípios orientadores são essenciais para chegar lá.
Princípio 1: Estabelecer uma cultura de colaboração orientada 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 comprovado por um estudo recente da indústria que revelou que “mais da metade (51%) dos tomadores de decisão de TI relatam resistência completa à mudança em suas equipes, enquanto 47% dizem que há colaboração insuficiente 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 uma prioridade para todas as partes interessadas.
Fazer da segurança uma responsabilidade compartilhada
Se sua organização constrói, vende ou consome software (o que hoje é toda e 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 quão bem os processos de DevSecOps se encaixam e podem impulsionar uma melhor tomada de decisão na escolha de plataformas DevOps, ferramentas e soluções individuais de segurança.
As mentalidades não mudam da noite para o dia, mas o alinhamento e um senso de responsabilidade com a segurança podem ser alcançados através do seguinte:
1. Compromisso com treinamentos internos regulares de segurança – adaptados ao DevSecOps – que incluem desenvolvedores, engenheiros DevOps e engenheiros de segurança. Lacunas e necessidades de habilidades não devem ser subestimadas.
2. Adoção pelos desenvolvedores de metodologias e recursos de codificação segura
3. A engenharia de segurança contribui para revisões de arquitetura, projeto 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 os silos funcionais e colaborar continuamente
Como o DevSecOps é resultado da confluência entre 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 críticas para o sucesso. Tipicamente, as organizações centradas em DevOps que operam sem nenhum framework formal de DevSecOps veem a segurança entrando na imagem como um convidado indesejado. Mudanças de processo ou ferramentas que são repentinamente impostas (em vez de escolhidas e instituídas de forma colaborativa) resultam inevitavelmente em atrito no pipeline de desenvolvimento e tarefas desnecessárias para os desenvolvedores. Um cenário comum envolve a segurança que impõe verificações adicionais de segurança de aplicativos sem consideração de seu posicionamento no pipeline, ou quanto trabalho é necessário para processar a saída do scanner e remediar vulnerabilidades, o que invariavelmente cai para os desenvolvedores.
Impulsionar a colaboração e operar como uma equipe coesa de DevSecOps envolve:
1. 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 falha de mudanças
– % de diminuição das vulnerabilidades implantadas em produção
– % de artefatos implantados em produção com SBOM/SLSA
– Diminuir o tempo de liderança para a remediação de vulnerabilidades de dia zero
2. Envolvimento dos desenvolvedores de software e equipes DevOps em todo o processo de avaliação e aquisição de novas ferramentas de segurança
3. Garantir que nenhum processo de DevSecOps tenha um único gatekeeper funcional
4. Otimização iterativa das escolhas de ferramentas e práticas de segurança para a produtividade e velocidade dos desenvolvedores
Princípio 2: Deslocar a informação de segurança para a esquerda, não a carga de trabalho de segurança
Abordar o assunto de DevSecOps e é impossível não mencionar ‘deslocamento para a esquerda’. O mantra de segurança de deslocamento para a esquerda é tão prevalente nos artigos, blogs e materiais de marketing orientados para DevSecOps atuais que é fácil pensar que, simplesmente ao mover verificações de segurança mais para cima no ciclo de vida de desenvolvimento de software, você alcançou um programa de DevSecOps funcional. A realidade é que O QUE você desloca para a esquerda é o que torna ou quebra o sucesso do seu DevSecOps.
O deslocamento do teste de segurança para a esquerda é 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 pegar vulnerabilidades de código e artefatos conhecidas e remediá-las em tempo hábil. No entanto, se os desenvolvedores sozinhos suportarem a carga total de executar testes, coletar saída de scanner, priorizar vulnerabilidades sobre a remediação, a carga mental e a fadiga resultantes certamente afetarão a velocidade para a produção. Em vez disso, a melhor abordagem reside em seguir estas diretrizes:
1. A segurança deve ser responsável pela orquestração e automação de testes de segurança de aplicativos ao longo dos pipelines de CI e CD
2. 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
3. Acelere a remediação gerando orientações de ação orientadas para os desenvolvedores para entender e resolver cada vulnerabilidade
Princípio 3: Manter a devida governança e barreiras de segurança
Porque tudo se move rápido no mundo do DevOps, é fácil cometer erros. Mas até mesmo pequenos erros ou omissões, como um CVE (Vulnerabilidades e Exposições Comuns) perdido ou uma alteração de configuração não autorizada dentro de um pipeline de desenvolvimento, podem vir com um risco significativo 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 de DevSecOps for eficaz, você facilitou para as partes interessadas fazerem as coisas certas e difícil para elas fazerem as coisas erradas. Isso pode ser alcançado com a seguinte orientação:
1. Aplicar Controle de Acesso Baseado em Função (RBAC) refinado em todo o ambiente de desenvolvimento para garantir o uso e a operação adequados. O RBAC geralmente é baseado em uma única propriedade (função), mas o RBAC refinado permite segurança mais forte ao levar em consideração várias propriedades, como horário do dia, grupos de usuários, hierarquia organizacional, etc.
2. Sobrepor políticas nos 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 do Open Policy Agent (OPA) é uma excelente abordagem de política como código para isso.
3. Usar 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 em relação à execução de verificações de segurança. O uso de modelos deve ser reforçado por políticas que garantam que as verificações de segurança sejam realizadas.
Princípio 4: Concentrar-se em proteger a cadeia de fornecimento de software (e não apenas 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 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 os clientes e consumidores do software em risco. O risco de segurança e conformidade geral de uma aplicação é uma função de todo o código, pessoas, sistemas e processos que contribuem para o desenvolvimento e entrega dos artefatos de software daquela aplicação, tanto dentro como fora de uma organização.
Como tal, os artefatos de software de código aberto são um alvo desejável para ciberataques, como evidenciado pelos ataques de alto perfil que comprometeram Solarwinds, Log4j e Codecov. Comprometer um bloco de construção de software, e há potencial para causar estragos nos dez 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, que é a SOMA 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 propósito crítico de garantir a integridade de qualquer software produzido pela organização, as equipes de DevSecOps devem adotar ferramentas e práticas em conformidade com o framework SLSA e com o Decreto Executivo 14.028.
Proteger a cadeia de fornecimento de software requer que as equipes de DevSecOps:
1. Governem o uso de componentes de software de código aberto em toda a CI e CD dos pipelines. Isso é melhor alcançado por meio de uma abordagem de política como código (com base no padrão OPA), que permite a autoria de políticas personalizadas que considerem uma ampla gama de atributos de artefatos OSS, como versão, licença, PURL e fornecedor, juntamente com indicadores líderes de risco. Seja para garantir o uso adequado de bibliotecas de software de código aberto ou bloquear o uso de artefatos OSS específicos por motivos de segurança, uma governança robusta é essencial.
2. Adotar capacidades abrangentes para gerar, gerenciar e analisar listas de materiais de software (SBOMs) para artefatos de software. Um SBOM é essencial para entender os componentes e dependências dentro de um aplicativo, o que, por sua vez, permite que as organizações gerenciem efetivamente os riscos de software. Cada vez mais organizações consumidoras de software estão exigindo SBOMs detalhados de fornecedores, em conformidade com os mandatos do Decreto Executivo 14.028.
3. Gerar e verificar 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 adulteração de artefatos. Ele permite criar um registro verificável em toda a cadeia de fornecimento 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, mais forte a garantia de integridade.
4. Estabelecer 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 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. 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é a implantação. Ter uma cadeia de custódia de software detalhada também acelera substancialmente a remediação de vulnerabilidades, que, de outra forma, é um processo exaustivo de analisar manualmente logs e reunir informações incompletas ao rastrear a nova vulnerabilidade de volta aos componentes de software afetados.
Princípio 5: Alcançar ‘segurança contínua’ por meio de automação e IA
O DevOps tornou-se sinônimo das práticas de integração e implantação contínuas, então é lógico que o DevSecOps resulte em segurança contínua. Uma grande parte do sucesso do DevSecOps é ser capaz de acompanhar (e até mesmo se adiantar) à velocidade de desenvolvimento de aplicativos. Embora leve tempo para um programa de DevSecOps nascente desenvolver 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:
1. Orquestrar verificações de segurança ao longo dos pipelines. Isso é mais fácil de ser alcançado com uma abordagem de plataforma, em que a plataforma subjacente de DevOps se integra com uma variedade de ferramentas de varredura SAST, SCA, Container 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 aplicada para falhar um pipeline se critérios de segurança específicos não forem cumpridos.
2. Automatizar a deduplicação e priorização de lista de vulnerabilidades para os desenvolvedores. Uma das maiores áreas de trabalho para os desenvolvedores é lidar com um montante de dados não processados de saída do scanner. Para otimizar o tempo de remediação para vulnerabilidades críticas (além de preservar a produtividade e experiência dos desenvolvedores), automatizar o processo de deduplicação e priorização de vulnerabilidades é uma necessidade.
3. Gerar orientações de remediação com IA. Para aprimorar ainda mais a velocidade de remediação e minimizar a fadiga dos desenvolvedores, fornecer explicações geradas por IA para as vulnerabilidades e orientações prescritivas de remediação é um grande benefício para os desenvolvedores.
