Uma das desafios persistentes na construção de aplicações modernas é torná-las mais seguras sem interromper os processos de alta velocidade do DevOps ou degradar a experiência do desenvolvedor. O cenário de ameaças cibernéticas atual está repleto de ataques sofisticados direcionados a todas as partes da cadeia de fornecimento de software e a urgência para que organizações produtoras de software adotem práticas DevSecOps que integrem a segurança profundamente 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 extrema importância. 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 dos pipelines e do código, mas não conte com as equipes de aplicativos para operar de forma fluida o suficiente para inovar. O mesmo vale para testes de segurança de aplicativos; descobrir um monte de vulnerabilidades não é útil 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 DevSecOps significa que sua organização é capaz de operar uma plataforma de entrega segura, testar vulnerabilidades de software, priorizar e remediar vulnerabilidades, prevenir o lançamento de código inseguro e garantir a integridade do software e de todos os seus artefatos.
No entanto, 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á.
Tenet 1: Estabelecer uma cultura colaborativa e 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. Isto é especialmente verdade no caso do DevSecOps, como evidenciado por um estudo recente da indústria que revelou que “mais da metade (51%) dos tomadores de decisão de TI relatam uma resistência total à mudança entre suas equipes, enquanto 47% afirmam que há uma colaboração insuficiente entre equipes.”
A importância da cultura para o sucesso do DevSecOps não deve ser subestimada e começa aceitando a segurança como uma prioridade para todos os interessados.
Torne a segurança uma responsabilidade compartilhada
Se sua organização constrói, vende ou consome software (o que hoje é toda organização concebível do planeta), então cada funcionário tem um impacto na postura de segurança geral – não apenas aqueles com ‘segurança’ em seus cargos. No cerne do DevSecOps está uma cultura de responsabilidade compartilhada e operar com uma mentalidade de segurança comum determina quão bem os processos DevSecOps se encaixam e podem impulsionar uma melhor tomada de decisões ao escolher plataformas DevOps, ferramentas e soluções de segurança individuais.
As mentalidades não mudam da noite para o dia, mas o alinhamento e um senso de responsabilidade de segurança podem ser alcançados por meio do seguinte:
Compromisso com treinamento interno regular de segurança – adaptado ao DevSecOps – que inclui desenvolvedores, engenheiros 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 seguros
Engenharia de segurança que contribui com avaliações de arquitetura e design de aplicativos e ambientes. É sempre mais fácil identificar e corrigir problemas de segurança cedo no ciclo de vida do desenvolvimento de software.
Quebrar silos funcionais e colaborar continuamente
Uma vez que o DevSecOps é resultado da confluência do desenvolvimento de software, operações de TI e segurança, quebrar silos e colaborar ativamente de forma contínua é fundamental para o sucesso. Tipicamente, organizações centradas em DevOps que operam sem nenhum framework formal de DevSecOps veem a segurança entrando como um intruso indesejado. Mudanças de processo ou ferramentas que são impostas repentinamente (em vez de serem escolhidas e instituídas de forma colaborativa) resultam invariavelmente em atrito no pipeline de desenvolvimento e em trabalho desnecessário para os desenvolvedores. Um cenário comum envolve a segurança impondo verificações adicionais de segurança de aplicativo sem consideração sobre o local deles no pipeline ou quanto trabalho é necessário para processar a saída do scanner e remediar vulnerabilidades, o que inevitavelmente recai sobre os desenvolvedores.
Impulsionar 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:
Redução percentual de incidentes de segurança de aplicativos
Redução percentual do tempo gasto em auditoria
Aumento percentual na frequência de implantação
Redução percentual da taxa de falha de mudança
Redução percentual de vulnerabilidades implantadas na produção
Porcentagem de artefatos implantados na produção com SBOM/SLSA
Redução do tempo de liderança para a remediação de vulnerabilidades do dia zero
Envolvimento de desenvolvedores de software e equipes de 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 guardião funcional
Otimizar de forma iterativa as escolhas de ferramentas e práticas de segurança para a produtividade e velocidade do desenvolvedor
Tenet 2: Deslocar as informações de segurança para a esquerda, não a carga de trabalho de segurança
Abordar o assunto do DevSecOps e é impossível não mencionar o ‘mover para a esquerda’. O mantra de segurança deslocada para a esquerda é tão prevalente nos artigos, blogs e materiais de marketing orientados para DevSecOps atuais, que é fácil pensar que simplesmente movendo verificações de segurança mais para cima no ciclo de vida do desenvolvimento de software você alcançou um programa de DevSecOps funcional. A realidade é que O QUE você move para a esquerda é o que faz ou quebra o sucesso do seu DevSecOps.
A segurança deslocada para a esquerda é baseada 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 pegar vulnerabilidades conhecidas no código e nos artefatos e remediá-los de forma oportuna. No entanto, se os desenvolvedores sozinhos suportarem todo o ônus de executar testes, coletar saída de scanner, priorizar vulnerabilidades além de remediá-las, a carga mental 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 possuir a 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 em tempo hábil
Acelerar a remediação ao gerar orientação prescritiva orientada para desenvolvedores para entender e resolver cada vulnerabilidade
Tenet 3: Manter a governança apropriada e as barreiras protetoras
Porque tudo se move rápido no mundo do 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 vir com um grande risco 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 é eficaz, você tornou fácil para os interessados fazerem as coisas certas e difícil para fazerem as certas. Isso pode ser alcançado com as seguintes orientações:
Aplicar Controle de Acesso Baseado em Funções (RBAC) detalhados em todo o ambiente de desenvolvimento para garantir o uso e operação correta. O RBAC geral é tipicamente baseado em uma única propriedade (função), mas o RBAC detalhado permite uma segurança mais forte levando em conta múltiplas propriedades, como hora do dia, grupos de usuários, hierarquia organizacional, etc.
Sobrepôr políticas em cima dos pipelines para permitir que os desenvolvedores controlem seus pipelines e dar às equipes de segurança e 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 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 varreduras de segurança. O uso de modelos deve ser aplicado por meio de políticas que garantam que as varreduras de segurança sejam realizadas.
Tenet 4: Focar na segurança da cadeia de fornecimento 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 quantidade de componentes de software de código aberto (OSS) e outros artefatos de terceiros que 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 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 esses 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. Comprometa 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 é o 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 conforme o framework SLSA e com a Ordem Executiva 14028.
Segurar a cadeia de fornecimento de software exige que equipes de DevSecOps:
Governar 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 autoria de políticas personalizadas que levam em consideração uma ampla gama de atributos de artefatos de OSS, como versão, licença, URL, 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 de OSS específicos por motivos de segurança, uma governança forte é essencial.
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 os riscos de software de forma eficaz. Cada vez mais, organizações consumidoras de software estão exigindo SBOMs detalhados dos fornecedores, conforme os mandatos da Ordem Executiva 14028.
Gerar e verificar a conformidade do nível 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 do desenvolvimento de software. Quanto maior o nível, maior a garantia de integridade.
Estabelecer uma cadeia de custódia completa para todos os artefatos de software. No domínio 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 o construiu ou modificou, quais testes de segurança foram realizados 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 de pipeline integradas e é crucial para manter a confiabilidade do software do desenvolvimento à 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 logs manualmente e reunir informações incompletas para rastrear a nova vulnerabilidade de volta aos componentes de software afetados.
Tenet 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 faz 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é superar) a velocidade de desenvolvimento de aplicações. Embora invariavelmente leve tempo para um programa de 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:
Orquestrar varreduras de segurança ao longo dos pipelines. Isso é mais facilmente alcançado com uma abordagem de plataforma, em que a plataforma subjacente DevOps se integra a uma variedade de ferramentas de varredura SAST, SCA, Contêiner e DAST e executa as 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 atendidos.
Automatizar a deduplicação e priorização de listas de vulnerabilidades para os desenvolvedores. Uma das maiores áreas de trabalho para os desenvolvedores é lidar com uma montanha de dados de saída do scanner não processados. Para otimizar o tempo de remediação de 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ções 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ção prescritiva de remediação é 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 geral de segurança do aplicativo sem adicionar trabalho ou degradar a experiência do desenvolvedor.
Os cinco pilares do DevSecOps (junto com seus respectivos conjuntos de diretrizes) discutidos neste texto capacitam as equipes de DevSecOps a construir e manter uma base operacional sólida. À medida que as tecnologias e práticas modernas de DevOps continuam a evoluir rapidamente, sempre haverá questões de segurança desconhecidas a serem abordadas. Contanto que desenvolvedores, engenheiros DevOps e profissionais de segurança trabalhem juntos como uma unidade coesa, o caminho para a excelência do DevSecOps é muito mais claro. Se você estiver interessado em uma visão mais profunda desses conceitos, eu incentivo você a baixar o Guia Definitivo para Entrega Segura de Software
